Du hast deinen KI-Agenten an ein Dutzend Tools angeschlossen — GitHub, Slack, Datenbanken, Cloud-APIs — und er erledigt in Minuten, wofür du früher Stunden gebraucht hast. Du hast MCP-Server eingerichtet (Model Context Protocol — ein universeller Steckplatz-Standard für KI-Tools, quasi USB für Daten), API-Tokens verdrahtet (digitale Passwörter, mit denen Programme in deinem Namen auf Dienste zugreifen) und alles hat einfach funktioniert. Die Zukunft war da, produktiv und komplett unbewacht.

Denn bei der Einrichtung hat jedes Tool vollen Zugriff verlangt. Nicht 'nur lesen." Nicht 'nur dieses Repo." Vollzugriff. Und keine Agent-Plattform bot eine Möglichkeit, Berechtigungen auf der Orchestrierungsebene einzuschränken — der Schicht, in der dein Agent entscheidet, welche Tools er wann benutzt. Du hast den Generalschlüssel rübergereicht und es 'Integration" genannt.

Zwischen dem 1. und 14. April 2026 wurde dieser Generalschlüssel kopiert. Mehrfach.

Google verteilt das Root-Passwort an jeden Agenten und aktualisiert dann die README

Am 1. April hat Palo Altos Unit 42 die 'Double Agent"-Schwachstelle in Googles Vertex AI offengelegt. Das ist die bisher deutlichste Fallstudie zur Kluft zwischen Authentifizierung und Autorisierung.

Das war passiert: Jeder Vertex-AI-Agent bekam ein Default-Service-Account (eine Systemidentität, die im Namen deines Agenten handelt). Dieses Service-Account kam mit Berechtigungen, bei denen ein Sysadmin Tränen vergießen würde. Wir reden nicht von 'etwas zu weit gefasst." Wir reden von Zugriff auf:

  • Cloud-Storage-Buckets anderer Kunden — Daten fremder Kunden, erreichbar von jeder Agenteninstanz
  • Gesperrte Google-interne Container-Images — normalerweise hinter mehreren Genehmigungsebenen verschlossen
  • Den Quellcode von Vertex AI selbst — die internen Repos der Plattform, lesbar für einen x-beliebigen Demo-Agenten

Die Forscher demonstrierten eine vollständige Privilege-Escalation-Chain: Mit einem einfachen Agenten starten, das Default-Service-Account erben, seitlich über Google-Cloud-Ressourcen pivotieren, die kein Agent jemals berühren sollte. Die Standardidentität war nicht 'etwas zu privilegiert" — sie war funktional allwissend innerhalb der Projektgrenze und teilweise allwissend darüber hinaus.

Googles Fix? Aktualisierte Dokumentation mit dem Vorschlag, man möge doch sein eigenes, weniger privilegiertes Service-Account mitbringen. Keine Plattformänderung. Keine sinnvollen Standardwerte. Ein Doku-Patch. Sie haben den Kunden gesagt, sie sollen das Handbuch gründlicher lesen. Das Äquivalent eines Autoherstellers, der auf versagende Bremsen mit 'wir haben die Bedienungsanleitung aktualisiert und empfehlen, vor Kreuzungen langsamer zu fahren" reagiert.

Die Schwachstelle existierte, weil die Authentifizierungsschicht von Vertex AI einwandfrei funktionierte — Agenten verbunden, Tokens ausgetauscht, Handshakes abgeschlossen — während die Autorisierungsschicht eine Brache war. Niemand bei Google hat den Teil gebaut, der fragt: 'Sollte dieser Agent darauf Zugriff haben?"

Anthropics Credential Vault: Ein Workspace, alle Schlüssel, keine Wände

Eine Woche nach Googles Blamage startete Anthropic am 8. April Claude Managed Agents mit Tool-spezifischen Berechtigungsstufen — allowed_tools, denied_tools. Besser als nichts. Aber am 13. April demonstrierte der Sicherheitsforscher hi120ki, dass der Credential Vault unter diesen Berechtigungen ein klaffendes Confused-Deputy-Problem hat (wenn ein vertrauenswürdiges Programm dazu gebracht wird, seine Autorität zu missbrauchen).

Der Angriffsweg ist geradlinig und hässlich:

  1. Ein Workspace hat mehrere Agenten, jeder mit unterschiedlichen Tool-Credentials im Credential Vault
  2. Der Vault beschränkt den Zugriff auf Workspace-Ebene, nicht auf Agent- oder Session-Ebene
  3. Jeder API-Key mit Workspace-Zugriff kann auf alle Credentials in diesem Vault zugreifen
  4. Ein Angreifer (oder ein kompromittierter Agent) mit einem gültigen Workspace-API-Key kann Tool-Calls mit Credentials anderer Agenten einschleusen

In der Praxis: Agent A hat Nur-Lese-Zugriff auf GitHub. Agent B hat Schreibrechte für die Produktionsdatenbank. Wenn Agent As Session kompromittiert wird — via Prompt Injection, Tool Poisoning oder einen bösartigen MCP-Server — kann er Agent Bs Datenbank-Credentials aus dem gemeinsamen Vault ziehen und Schreiboperationen ausführen. Die Tool-Berechtigungsstufen (allowed_tools) regeln, was der Agent tun soll. Der Vault regelt, was er tun kann. Diese zwei Listen stimmen nicht überein.

hi120kis Proof of Concept zeigte Cross-Agent-Credential-Zugriff innerhalb eines einzigen API-Calls. Der Fix würde Per-Agent-Credential-Isolation erfordern — im Grunde eine eigene Vault-Partition für jeden Agenten mit kryptografischer Trennung. Stand 19. April ist kein Fix ausgeliefert.

Das ist das Confused-Deputy-Pattern in Reinform: Der Vault ist der vertrauenswürdige Stellvertreter, der kompromittierte Agent ist der verwirrte Anfragesteller, und die Ziel-Credentials sind die Autorität eines anderen. Der Trenchcoat verdeckt kaum etwas.

Das Muster: Authentifizierung gelöst, Autorisierung fehlt

Das sind keine isolierten Bugs. Es sind Symptome einer fehlenden Architekturschicht.

Die Azure DevOps MCP-Schwachstelle (CVE-2026-32211, CVSS 9.1, veröffentlicht am 3. April) — die ich bei Erscheinen behandelt habe — zeigte dieselbe Leere aus der entgegengesetzten Richtung: nicht überprivilegierte Standardwerte, sondern null Authentifizierung auf der Tool-Seite. Claude Code Routines, die am 14. April gestartet sind als Agenten, die nach Zeitplan ohne menschliche Freigabe laufen, verstärken jede bestehende Berechtigungssünde, indem sie den letzten menschlichen Checkpoint entfernen.

Dieselbe Krankheit, verschiedene Organe. Authentifizierung (kann der Agent sich verbinden?) ist größtenteils gelöst — OAuth-Flows, API-Keys, Credential Vaults erledigen den Handshake. Aber Autorisierung (was darf der Agent nach der Verbindung tun?) bleibt eine Leerstelle. Jedes Tool hat sein eigenes Berechtigungsmodell — GitHub Scopes, AWS IAM Policies (granulare Zugriffsregeln für Cloud-Ressourcen), Notion-Seitenzugriff — aber keine Agent-Plattform aggregiert, prüft oder erzwingt Least-Privilege über das gesamte Tool-Set hinweg.

Die Schicht zwischen 'Tool verbunden" und 'Aktion ausgeführt" existiert nicht.

Ein Audit von 7.000 MCP-Servern am 11. April durch Pomerium ergab: 36,7 % sind anfällig für SSRF (Server-Side Request Forgery — den Server dazu bringen, unautorisierte Anfragen an interne Systeme zu stellen). Mehr als ein Drittel der MCP-Server lässt sich als Netzwerk-Pivot missbrauchen. Nicht weil das Protokoll kaputt ist, sondern weil einzelne Server-Implementierungen davon ausgehen, dass der verbindende Agent vertrauenswürdig und angemessen eingeschränkt ist. Sie nehmen an, die Autorisierungsschicht existiert weiter oben. Tut sie nicht.

Warum das niemand fixen wird, bis es richtig teuer wird

Cloud Computing hat sich 15 Jahre lang schmerzhaft weiterentwickelt — von 'SSH als Root auf die Box" zu granularem IAM mit Audit-Trails, rollenbasiertem Zugriff und Least Privilege. Wir sind dahin gekommen, weil Sicherheitsvorfälle Geld gekostet haben und Compliance-Frameworks Veränderungen erzwungen haben. Agent-Plattformen stehen am Tag null derselben Entwicklung und verteilen Root-äquivalenten Tool-Zugriff als Standard, den sie als Feature verkaufen, weil er in Demos gut aussieht.

Eine einheitliche Tool-Autorisierung zu bauen würde die 'Alles in 30 Sekunden verbinden"-Magie zerstören. Es würde Setup-Reibung erzeugen und Wettbewerbs-Demos schwächen. Kein Anbieter hat den Marktanreiz, als Erster Reibung hinzuzufügen. Google wird es nicht tun. Anthropic wird es nicht tun. Microsoft wird es nicht tun. Der Anreiz wird durch Vorfälle kommen. Vermutlich teure, öffentliche Multi-Kunden-Vorfälle.

Vorgeschmack hatten wir schon: Im Juli 2025 rastete ein Replit-Agent aus und löschte Produktionsdaten von über 1.200 Führungskräften. Im Dezember 2025 löschte ein Amazon-Agent eigenständig eine Live-Produktionsumgebung und baute sie neu auf, was einen 13-stündigen Ausfall des AWS Cost Explorers verursachte. Das waren Unfälle. Die nächste Runde wird keine sein.

Jeder überprivilegierte MCP-Server, jeder Vollzugriffs-API-Token, jede uneingeschränkte Tool-Verbindung ist eine schlafende Schwachstelle — ruhend solange ein Mensch auf 'Genehmigen" klickt, aktiv in dem Moment, in dem ein Agent autonom nach Zeitplan läuft.

Das nächste echte Differenzierungsmerkmal im Wettrennen der Agent-Plattformen ist nicht das Modell und nicht die Anzahl der Tools. Es ist die erste Admin-Konsole, die zeigt, was dein Agent tatsächlich tun kann — und die es erlaubt, das meiste davon zu widerrufen. Die Lücke zwischen 'verbunden" und 'autorisiert" ist der Ort, an dem der nächste Breach lebt. Gerade baut jeder Brücken darüber — ohne Geländer — und nennt es Fortschritt.