Du hast deinen KI-Agenten mit Slack, GitHub und Jira verbunden. Die Plattform zeigte brav einen Dialog: "Slack-Zugriff erlauben?" Du hast auf Ja geklickt. Du hast dich verantwortungsvoll gefühlt. Du hattest das Gefühl, alles unter Kontrolle zu haben.

Hattest du nicht. Der Agent hat gerade deinem CEO einen Bug-Report per DM geschickt, der eigentlich für #engineering gedacht war. Der Berechtigungsdialog hat nie nach Empfängern, Channels oder danach gefragt, was "Slack-Zugriff" eigentlich bedeutet, wenn eine Maschine die Schlüssel in der Hand hält.

Drei Plattformen, ein Muster, null Tiefgang

Vor zwei Wochen ging die Diskussion noch darum, dass Agent-Plattformen überhaupt keine sinnvolle Autorisierung haben — Agenten mit Root-Zugriff und niemand, der sudo baut. Diese Diskussion ist bereits überholt. Alle drei großen Plattformen haben inzwischen ihre Antwort geliefert: Tool-Approval-Workflows, diese "Bist du sicher?"-Prompts, die aufpoppen, bevor ein KI-Agent (ein Programm, das in deinem Namen handelt, nicht nur chattet) etwas Folgenreiches tut. Die Autorisierungslücke wurde nicht geschlossen. Sie wurde tapeziert.

Googles ADK hat auf der Cloud Next (22.–24. April) Action Confirmations eingeführt. Anthropics Managed Agents, gestartet am 8. April, hatten von Tag eins Per-Tool Permission Policies. OpenAIs Agents SDK lieferte needs_approval-Callbacks im Update vom 15. April. Drei Unternehmen, konvergierend zur selben Idee — wie drei Architekten, die unabhängig voneinander dasselbe undichte Dach entwerfen.

Das Muster ist bei allen dreien identisch: Du genehmigst oder verweigerst Zugriff auf Tool-Ebene. "Slack erlauben" oder "Slack verweigern." Binär. An oder aus. Ein Türsteher, der am Gebäudeeingang Ausweise kontrolliert, während drinnen jede Wohnungstür sperrangelweit offensteht.

Wo die echte Gefahr lauert

Der Blast Radius eines fehlgeleiteten Tool-Calls — der Schaden, den er tatsächlich anrichten kann — steckt in den Parametern: In welchen Slack-Channel die Nachricht geht, auf welchen Git-Branch jemand einen Force-Push macht, welche SQL-Query gegen die Produktionsdatenbank läuft, welches Jira-Projekt der Agent mit automatisch generierten Tickets flutet.

Fairerweise: Google ADK und OpenAI übergeben Tool-Call-Parameter an vom Entwickler geschriebene Callbacks. Du kannst Code schreiben wie return amount > 1000, um teure Operationen zu blockieren. Aber hier liegt der entscheidende Unterschied: Die Plattform gibt dir einen Hook, kein Sicherheitsnetz. Du schreibst die Regeln selbst, in purem Python, für jedes Tool, für jeden Parameter, für jeden Grenzfall. Keine deklarative Policy-Engine. Keine eingebauten Allowlists. Kein "Nur in #engineering und #random posten"-Schalter im Dashboard.

Anthropics Implementierung ist noch simpler — ihre Permission Policies operieren rein auf Tool-Namen. Das user.tool_confirmation-Event akzeptiert genau zwei Antworten: "allow" oder "deny". Kein Feld für Argument-Constraints. Keine bedingte Logik. Der Agent kann entweder Slack nutzen oder nicht.

Wie Sicherheitsforscher Simon Willison im September 2024 schrieb: "Sobald ein LLM-Agent nicht vertrauenswürdigen Input verarbeitet hat, muss er so eingeschränkt werden, dass es unmöglich ist, dass dieser Input irgendwelche folgenschweren Aktionen auslöst." Tool-Level-Gates erreichen das nicht. Sie beschränken, welche Aktionen existieren — nicht, was diese Aktionen tun.

Diesen Film haben wir schon gesehen

Das Muster ist ein Copy-Paste von den mobilen Berechtigungen um 2008. Android 1.0 gewährte pauschalen "Kamera-Zugriff" — kein Unterschied zwischen einer Selfie-App und einem Dokumentenscanner, der heimlich deinen Schreibtisch fotografiert. Google brauchte sieben Jahre und Android 6.0 Marshmallow (2015), um Runtime Permission Scoping zu liefern — kontextbezogene Kontrollen darüber, wie eine App die Kamera nutzt, nicht nur ob sie es darf.

Agent-Plattformen stehen heute auf dem Android-1.0-Stand. Der Berechtigungsdialog existiert. Er fühlt sich nach Sicherheit an. Ist er aber nicht.

Microsoft hat ausgesprochen, was alle denken

Am 22. April veröffentlichte Microsofts Entwickler-Blog ein nüchternes Eingeständnis: "Instruction-Following allein sollte nicht als Sicherheitsgrenze behandelt werden." Ihre eigenen Red-Team-Tests — durchgeführt im Rahmen des Agent Governance Toolkit, das sie Anfang des Monats als Open Source veröffentlicht hatten — ergaben eine Policy-Verletzungsrate von 26,67% bei rein prompt-basierten Guardrails. Einer von vier gefährlichen Calls rutscht durch, wenn du dich darauf verlässt, dass das LLM sich selbst kontrolliert.

AGT ist das, was einer echten Lösung am nächsten kommt: eine Middleware-Schicht zwischen deinem Agenten und seinen Tools, die deklarative Policy-Regeln in YAML, OPA oder Cedar durchsetzt. Sie inspiziert tatsächlich Parameter. Sie gated tatsächlich auf Basis von Argument-Werten. Aber es ist Middleware, die du selbst dranbaust — nicht nativ in irgendeiner Agent-Plattform. Gutes Panzertape, aber Panzertape.

Der Preis des Richtigmachens

Parameter-Level-Gating ist wirklich schwer. Es erfordert semantisches Verständnis — zu wissen, dass #general ein öffentlicher Channel ist, während #exec-compensation es nicht ist. Es fügt jedem Tool-Call Latenz hinzu, in Systemen, die ohnehin gegen Context-Window-Limits kämpfen (wie viel Text die KI gleichzeitig "sehen" kann). Und am schlimmsten: Es erzeugt Approval Fatigue — je granularer die Gates, desto schneller trainieren sich Nutzer selbst darauf, "Alles genehmigen" zu klicken, ohne zu lesen — genau das Verhalten, das Berechtigungen zum Sicherheitstheater macht.

Was du wirklich tun solltest

Bis Plattformen parameter-bewusste Gates als natives Feature liefern, hast du zwei ehrliche Optionen. Erstens: Bau Middleware, die Tool-Call-Argumente gegen Allowlists prüft — sichere Channels, sichere Branches, sichere Query-Muster. Zweitens: Akzeptiere, dass "Slack erlauben" bedeutet "dem Agenten erlauben, alles zu tun, was die Slack-API hergibt", und plane entsprechend.

Der Berechtigungsdialog deiner Agent-Plattform ist ein Placebo. Er kontrolliert, welche Türen der Agent öffnen darf, aber nicht, was er im Raum anstellt. Drei Plattformen haben im April 2026 dasselbe Schloss ausgeliefert, und keine hat den Riegel mitgeliefert.