Positivlisten für MCP-Server: Warum agentische Systeme Capability-Firewalls benötigen

Promptsicherheit ist nützlich, löst jedoch nicht das eigentliche Problem, wenn ein Agent umfassenden Zugriff auf Tools hat. Die Lösung sind Capability-Firewalls: explizite Positivlisten dafür, welche Aktionen zulässig sind, wo sie ausgeführt werden dürfen und auf welche Daten sie zugreifen dürfen.

Die Reichweite von Tools bestimmt den tatsächlichen Schadensradius

Teams investieren weiterhin viel Energie in die Filterung von Prompts, während sie Agenten gleichzeitig Zugriff auf Shells, Dateisysteme, Ticketing-APIs, Cloud-Dashboards und interne Wissensspeicher gewähren. Das ist der falsche Ansatz. Ein ungewöhnlicher Prompt ist beherrschbar. Ein hochprivilegiertes Tool mit nachlässig definierten Grenzen verursacht echten Schaden.

MCP-Server und ähnliche Agentenkonnektoren sollten wie privilegierte Middleware behandelt werden, nicht wie praktische Plugins. Wenn sie nicht vertrauenswürdige Anfragen mit vertrauenswürdigen Systemen verbinden können, benötigen sie strikte Fähigkeitsgrenzen.

Was eine Capability-Firewall tatsächlich bedeutet

Wenn Ihre Konnektorrichtlinie im Wesentlichen nur zwischen „aktiviert“ und „deaktiviert“ unterscheidet, ist sie zu grob. Echte Sicherheit entsteht durch präzise begrenzte Berechtigungen, nicht durch einen binären Schalter.

Das Fehlermuster, das alle ständig wiederholen

Ein interner Agent erhält Zugriff auf ein flexibles Tool. Das Tool kann umfassend lesen und schreiben. Das System geht davon aus, dass der Prompt und die Systemnachricht den Agenten innerhalb seiner Grenzen halten. Dann lenken ein manipuliertes Dokument, eine irreführende Tool-Ausgabe oder ein schlecht konzipierter Ausweichpfad den Workflow in eine Richtung, die niemals zulässig sein sollte.

Die Ursache ist kein mysteriöses Versagen der AI. Es handelt sich um gewöhnliches Autorisierungsversagen mit AI-Branding.

Mindestkontrollen, die bereits jetzt vorhanden sein sollten

• Tool-spezifische Berechtigungsbereiche statt globaler Agentenberechtigungen.
• Standardmäßig getrennte Lese- und Schreibberechtigungen.
• Positivlisten für ausgehende Hosts bei jedem netzwerkfähigen Konnektor.
• Strukturierte Protokollierung der angeforderten Aktion, des genehmigten Berechtigungsumfangs und des tatsächlichen Ausführungsziels.
• Notausschalter für Konnektoren, die sich ungewöhnlich verhalten.

Das ist keine übertriebene technische Komplexität. Es ist grundlegende Eindämmung. Wenn ein Konnektor auf Produktionssysteme, Finanzdaten, Identitäten oder Kundendaten zugreifen kann, ist Eindämmung seine wichtigste Aufgabe.

Wie für KENSAI relevante Teams das Konnektorrisiko bewerten sollten

Listen Sie zunächst alle Konnektoren auf, die zustandsverändernde Aktionen ausführen können. Fragen Sie anschließend, was geschieht, wenn der Workflow bösartige Anweisungen, irreführenden Kontext oder zu weit gefasste abgerufene Inhalte erhält. Wenn die Antwort Codeausführung, Änderungen an Datensätzen, Zugriff auf Anmeldedaten oder externe Datenübertragung umfasst, muss der Berechtigungsumfang des Konnektors sofort enger gefasst werden.

Die richtige Denkweise ist einfach: Behandeln Sie die Erweiterung von Fähigkeiten wie das Öffnen von Firewall-Ports. Jede neue Aktion muss ihre Berechtigung rechtfertigen.

Die klare Empfehlung

Standardmäßige Verweigerung ist der richtige Ansatz. Geben Sie Agenten nur den kleinsten sinnvoll nutzbaren Satz an Aktionen, begrenzen Sie die Ziele dieser Aktionen und verlangen Sie eine ausdrückliche Freigabe für alles, was kostspielig, destruktiv oder datenschutzrelevant ist. Capability-Firewalls sind weniger spektakulär als Agentendemos, aber sie machen den Unterschied zwischen einem leistungsfähigen System und einem mächtigen Haftungsrisiko aus.