KI-Agenten sind confused deputies. Das ist ein 38 Jahre altes Sicherheitsmuster, und die Antwort ist genauso alt: setze einen Broker — eine vertrauenswürdige, beobachtbare, deterministische, auditierbare, fälschungssichere, Scope-eingegrenzte, policy-getriebene, nicht-KI-Zwischenschicht — zwischen den Agenten und die SaaS-APIs, die er aufrufen muss; der Broker verwahrt die Anmeldedaten, die dein Agent nicht haben sollte.
1988 veröffentlichte Norm Hardy eine kurze Arbeit über einen echten Vorfall aus seiner Tymshare-Zeit. Ein Fortran-Compiler namens FORT lebte in einem Systemverzeichnis namens SYSX. Um Nutzungsstatistiken zu sammeln, musste der Compiler in (SYSX)STAT schreiben, also hatte das Betriebssystem FORT eine "home files license" erteilt, die ihm das Schreiben jeder Datei innerhalb von SYSX erlaubte. Die System-Abrechnungsdatei (SYSX)BILL lag auch dort. Ein Nutzer, der den Compiler aufrief, konnte einen Dateinamen für die optionale Debug-Ausgabe angeben. Eines Tages gab ein Nutzer (SYSX)BILL an. Der Compiler bat das OS, diese Datei zum Schreiben zu öffnen; das OS, mit Blick auf die home files license, erlaubte es. Die Abrechnungsdaten wurden überschrieben. Der Compiler tat genau das, wofür er gebaut war. Der Fehler war architektonisch.
Hardy nannte das Problem confused deputy: ein privilegiertes Programm (der Stellvertreter) hat eigene Befugnisse; ein weniger privilegierter Aufrufer bittet ihn, etwas zu tun; der Stellvertreter verwechselt, in wessen Auftrag er handelt, und nutzt die eigenen Rechte. Die Lösung: jene Befugnisse dem Stellvertreter ganz wegnehmen und sie hinter eine separate Schicht legen, die jeden Aufruf bei Bedarf vermittelt. Diese Schicht ist der Broker.
38 Jahre später ist jeder KI-Agent, den dein Unternehmen betreibt, ein confused deputy. Und die meisten laufen ohne Broker.
Warum KI-Agenten es schlimmer machen
Hardys FORT hatte einen einzigen Eingabekanal: die Kommandozeile. Ein moderner KI-Agent hat Dutzende: E-Mail-Bodies, abgerufene Webseiten, hochgeladene PDFs, Tool-Ausgaben von MCP-Servern, Nachrichten von Peer-Agenten in einem Multi-Agenten-System. Alles, was im Context-Window landet, kann Anweisungen geben, und der Agent behandelt sie per Design alle als legitim.
Das verletzt eine Annahme, auf die klassische Zugriffskontrolle baut: dass der Aufrufer die Eingabe kontrolliert. In einer Web-App stammen der Aufrufer (die authentifizierte Session) und die Eingabe (der HTTP-Request-Body) aus derselben Quelle. Beim Agenten ist der Aufrufer aber jeder, der den Prompt formt. Damit ist auch jeder, der eine E-Mail schicken oder ein Suchergebnis manipulieren kann, ein Aufrufer.
Im November 2025 zeigten Sicherheitsforscher von PromptArmor, wie das in der Praxis aussieht. Sie versteckten bösartige Anweisungen in 1-Pixel-Schrift in einer Integrationsanleitung. Als ein Entwickler Googles Antigravity-IDE darauf ansetzte, umging der Agent seinen eigenen, auf .gitignore basierenden Dateischutz, indem er cat im Terminal ausführte. Anschließend leakte er den Inhalt von .env-Dateien an eine vom Angreifer kontrollierte webhook.site-URL, über Antigravitys eigenen Browser-Subagenten. Der Nutzer hatte alles korrekt eingerichtet. Die Sandbox hielt. Der Agent konnte schlicht nicht unterscheiden, was der Nutzer wollte und was der Input ihm sagte.
Dieselbe Form wie Hardys FORT, Jahrzehnte später: weite Befugnisse, nicht vertrauenswürdige Eingabe, keine Möglichkeit, beides zu trennen.
Die Community hat Antworten. Sie liegen nur verstreut.
Das ist kein neues Problem. Die Sicherheits-Community schreibt seit Jahrzehnten Antworten:
Capability-based security (Dennis & Van Horn 1966; später die E-Sprache und Mark Millers Caja-Arbeit bei Google). Das Prinzip: keine ambient-Befugnisse auf Basis von Identität oder Standort vergeben; stattdessen explizite, fälschungssichere Capabilities für jede Ressource übergeben, die das Programm anfassen darf. Eine Capability bündelt was du tun darfst und womit du es tun darfst, und kann mit nichts anderem verwechselt werden.
Brokered Credentials (im OWASP LLM Top 10 verankert). API-Tokens gehören nicht in den LLM-Kontext. Eine vertrauenswürdige Zwischenschicht macht den Aufruf im Auftrag des Agenten; das Modell entscheidet was zu tun ist, der Broker erledigt das wie. Eine Prompt-Injection, die das Modell auffordert, seine Anmeldedaten auszugeben, bekommt nichts Verwertbares: die Anmeldedaten sind nicht dort.
Das Phantom-Token-Pattern (Curity, ursprünglich für OAuth in Microservices). Der Agent hält nur ein opakes Session-Handle, nicht das echte Bearer-Token. Ein Proxy validiert das Handle, tauscht es am Netzwerkrand gegen das echte Credential aus und reicht es weiter. Wenn der Agent seine Umgebungsvariablen leakt, bekommt der Angreifer einen String, der mit Sitzungsende verfällt.
Just-in-time Credential Injection (Workload-Identity-Systeme wie Aembit). Pro Aufruf ein kurzlebiges, Scope-eingegrenztes Credential erzeugen, statt langlebige Tokens auszugeben.
Nichts davon fehlt in der Literatur. Was fehlt, sind Defaults. Die meisten Agent-Plattformen geben dem Modell weiterhin ein OAuth-Token in die Hand, ohne Broker dazwischen, und hoffen auf das Beste.
Wie Zeros Broker funktioniert
Wir haben keines der oben genannten Muster erfunden. Wir haben sie in einen einzelnen Broker verdrahtet, der für jeden Agenten auf Zero standardmäßig läuft. Er ist die vertrauenswürdige Zwischenschicht, die diese Muster beschreiben, gebaut für eine KI-Agenten-Plattform. Jeder Aufruf, den ein Agent an einen Connector macht, geht durch den Broker. Jeder Connector ist eine externe SaaS-Integration (Slack, GitHub, Notion und so weiter).
Der Broker steht zwischen jedem Agenten und jedem Connector. Echte Credentials leben nur auf der Broker-Seite der gestrichelten Linie.
Drei Schichten:
1. Credential Isolation
Die Sandbox des Agenten hält nie ein echtes Connector-Credential. Wenn du eine SaaS mit Zero verbindest, bleibt das OAuth-Token oder der API-Key auf der Broker-Seite. Die Sandbox bekommt einen Platzhalter-String, der genug nach Umgebungsgeheimnis aussieht, damit existierende Tools weiter funktionieren. Kein Upstream-SaaS würde ihn akzeptieren.
Wenn der Agent einen Aufruf an einen registrierten Connector-Host macht, matcht der Broker den Request, löst das auth-Template des Connectors auf und injiziert das echte Credential am Netzwerkrand. Der Request geht mit gültiger Auth nach oben; der Agent hat nie etwas Verwertbares gehalten. Ein durch Prompt-Injection kompromittierter Agent, der seine Umgebungsvariablen ausgibt, händigt dem Angreifer einen Platzhalter aus, nicht das SaaS-Token.
Das ist das Phantom-Token-Pattern, angewandt auf KI-Agenten.
2. Connector Policy Gate
Ein Connector in Zero sollte mehr sein als ein Ein/Aus-Schalter. Jeder Connector beschreibt die API-Bases, die er abdeckt, und wie Auth injiziert werden soll. Wo der Upstream-Dienst eine stabile Scope-zu-Endpoint-Zuordnung veröffentlicht, kann der Connector zusätzlich beschreiben, welche benannte Permission jede Method/Path-Kombination abdeckt. Slacks slack-api-ref ist ein gutes Beispiel.
Wenn ein an Slack angebundener Agent also chat.postMessage aufruft, kann der Broker den Request auf chat:write abbilden. Beim Lesen von Audit-Logs ist es admin.analytics:read. Pro Agent legt permission_policies fest, wie sich diese benannten Permissions verhalten: allow, deny oder ask. Die Policy wird vor der Auth-Injektion am Broker durchgesetzt, nicht als Hinweis fürs Modell. Wenn der Agent versucht, einen Aufruf zu machen, der unter eine deny-Permission fällt (etwa weil er prompt-injected wurde), erreicht der Aufruf nie das Upstream-Netzwerk.
Nicht jeder Connector erreicht derzeit diese Auflösung. Manche Upstream-APIs veröffentlichen keine stabile Scope-zu-Endpoint-Zuordnung. GitHubs GraphQL-API ist der kanonische Fall: die REST-Seite lässt sich abbilden, die GraphQL-Seite noch nicht. Bei diesen Connectoren steuert der Broker weiterhin Credential-Injektion und Netzwerkpfad, während das Permission-Gate auf die gröbere Connector- oder Host-Level-Policy zurückfällt, die die Plattform tatsächlich durchsetzen kann. Wir füllen diese Lücken auf, sobald Upstream-Daten verfügbar werden. Wir behaupten keine Abdeckung, die wir nicht gebaut haben.
Tokens tragen keine ambient-Befugnis. Befugnisse werden pro Agent vermittelt, in der feinsten Auflösung, die der Upstream-Dienst unterstützt. Das ist die capability-basierte Hälfte der Antwort.
3. Operational Loop und Audit
Least Privilege funktioniert nur, wenn der Failure-Mode brauchbar ist. Agenten wachsen. Sechs Wochen nachdem ein Research-Agent angefangen hat, von Notion zu lesen, muss er vielleicht eine Zusammenfassung dorthin zurückschreiben. Übliche Fehlermodi anderswo: der Agent läuft still ohne die neue Permission und scheitert, oder der Operator vergibt in Panik zu viele Rechte und holt sie nie zurück.
Ein abgelehnter Connector-Request liefert ein strukturiertes 403: Connector, method, path, base URL und die getroffenen Permission-Namen, sofern der Broker sie identifizieren kann. Der System-Prompt des Agenten weist ihn an, wie er die Ablehnung diagnostiziert und wie er genau die Permission anfordert, die er gerade getroffen hat. Daraus entsteht eine Ein-Klick-Grant-URL für Nutzer oder Admin. So bleibt der Eskalationspfad an die konkret angefragte Permission gebunden, statt sich in "dann gib einfach alles frei" aufzulösen.
Permission-Änderungsanfragen liegen in einer Queue. Owner und Admins können sie aus dem Dashboard heraus genehmigen oder ablehnen; genehmigte Anfragen aktualisieren die Policy des Agenten, und der nächste Retry geht durch. Die meisten Plattformen überspringen diesen Loop. Ohne ihn lebt "Least Privilege" nur auf den Folien, nicht in Produktion.
Derselbe Broker-Pfad speist die Auditierung. Pro-Run-Netzwerklogs zeichnen die Sandbox-Netzwerkaktivität auf: HTTP, TCP, DNS, sowie Paket-Beobachtungen auf tieferer Ebene für Nicht-TCP-Traffic. Connector-gematchte Requests enthalten strukturierte Broker-Metadaten: Connector, getroffene Permission (sofern verfügbar), allow/deny-Ausgang, Auth-Auflösungs-Metadaten, Billable-Flag. Wenn jemand später fragt: "Was hat dieser Agent dienstags um 15 Uhr genau gemacht?", rekonstruierst du die Antwort aus diesen Daten. Prävention übersieht Dinge. Mit der Audit-Spur findest du heraus, was passiert ist.
Was wir nicht gelöst haben
Selbst mit alledem kann ein Agent mit legitimem chat:write weiterhin überredet werden, eine peinliche Nachricht in einem Channel zu posten, auf den er Zugriff hat. Der Broker verkleinert den Wirkungskreis; er eliminiert ihn nicht.
Die andere Hälfte der Antwort: Genehmigungen für hochriskante Aktionen, Output-Validation und das Behandeln von Tool-Returns standardmäßig als nicht vertrauenswürdig. Diese Arbeit ist Roadmap, nicht Produkt. Wer behauptet, confused deputy Ende-zu-Ende gelöst zu haben, will dir etwas verkaufen.
Das sollte die Grundlage sein, nicht ein Feature
Capability-based security gibt es seit den 1970ern. Brokered Credentials stehen im OWASP LLM Top 10. Phantom Tokens sind älter als die LLM-Welle. Nichts davon fehlt, weil niemand die Antwort kannte. Es fehlt, weil frühe Agent-Plattformen auf "demo-tauglich" optimiert und Sicherheit auf ein späteres Release verschoben haben. Oft kam dieses Release nie.
Die nächste Generation von Plattformen sollte höher zielen. Tokens dürfen nicht in den Modell-Kontext kommen. Befugnisse sollten pro Agent aufgelistet werden. Privilegien-Eskalation sollte über einen Menschen laufen. Jede Aktion sollte Ende-zu-Ende auditierbar sein. Nichts davon ist neu. All das sollte die Grundlage sein.
Wenn du eine Agent-Plattform auswählst, bringt "Ist sie sicher?" dich nirgendwohin. Jeder Anbieter sagt ja. Eine bessere Frage: zeig mir deinen Broker, und führe mich durch, was passiert, wenn ein Agent nach einem Scope fragt, den er nicht hat.
Der Broker steht standardmäßig vor jedem Agenten auf Zero. Connector-Inventar, Scope-Mappings, Permission-Policies und Broker-Logik liegen alle im Quellcode-Repository von Zero. Connector fehlt? Eröffne ein Issue.
Quellen
Grundlagen
- Norm Hardy, The Confused Deputy: (or why capabilities might have been invented), ACM SIGOPS Operating Systems Review 22(4), 1988. DOI 10.1145/54289.871709
- Dennis & Van Horn, Programming Semantics for Multiprogrammed Computations, CACM 1966 (die Gründungsarbeit der Capability-Systeme)
- Mark Miller et al., Caja: capability-based security fürs Web, Google
- OWASP LLM Top 10
- Curity, Phantom Token Pattern
Zitierte Vorfälle
- PromptArmor, Google Antigravity Exfiltrates Data, November 2025
- Simon Willison, Berichterstattung und Analyse, 25. November 2025
