Unternehmen setzen KI-Agenten schneller ein, als sie sie erfassen können. Die Kontrollen, mit denen sie Identitäten steuern, stammen aus einer Zeit, in der eine Berechtigung ein halbes Jahr überdauerte. Diese Lücke schließt sich nicht von selbst.
Am 8. September hat die Google Threat Intelligence Group einen Angriff aus dem zweiten Quartal öffentlich gemacht. Ein mutmaßlich finanziell motivierter Täter drang in die Cloud-Umgebung einer Organisation ein. Dort baute er aus einem KI-Coding-Assistenten, einem Prompt und einem Satz vorbereiteter Anweisungen ein autonomes Multi-Agenten-Framework. Als Drehbuch dienten vorkonfigurierte Markdown-Dateien. Damit erntete er Tausende fremder Zugangsdaten. Zwischen Planung und Abschluss lagen weniger als sechs Stunden. Die Agenten steuerten die Scan-Pipeline selbst, behoben Fehler in Echtzeit und rotierten IP-Adressen ohne manuelles Eingreifen. Der Datenverkehr lief über die Cloud-Infrastruktur des Opfers und damit über legitime Adressen.
Google ordnet den Fall vorsichtig ein: agentengestützt, nicht vollautonom. Die Einordnung ist korrekt. Am Befund ändert sie nichts. Der Report benennt ihn selbst: Die Verzögerung durch den Menschen in der Schleife schrumpft, und mit ihr das Zeitfenster, in dem Verteidiger reagieren können.
Angegriffen wurde nicht das Modell
Keine dieser Aktionen nutzte eine Schwachstelle im Sprachmodell. Getroffen hat es das Drumherum: einen kompromittierten Cloud-Zugang, gültige Tokens, zu weit gefasste Rechte.
Wie banal der Einstieg sein kann, zeigt ein Fall, den die Forschungsorganisation METR Ende August selbst offengelegt hat. Ein Mitarbeiter betrieb Agenten auf einer eigenen EC2-Instanz, abgesichert über eine Google-Anmeldung. Die zugehörige, schnell zusammengeschriebene Anwendung hatte einen Fail-open-Fehler: Fiel die Authentifizierung aus, blieb die Tür offen, statt sich zu schließen. Das Agenten-Dashboard stand damit tagelang im öffentlichen Netz. Der Angreifer fand es vermutlich über Certificate-Transparency-Listen, in denen er nach frisch registrierten Domains mit KI-Bezug suchte. Dann forderte er den laufenden Agenten auf, den API-Schlüssel des Modellanbieters auszugeben, und hinterlegte einen SSH-Schlüssel, um den Zugang zu behalten. Drei Wochen lang verbrauchte er darüber Rechenleistung im kommerziellen Gegenwert von rund 600.000 Dollar. Aufgefallen ist es lange nicht.
Wer solche Fälle liest, erkennt ein vertrautes Muster. Zugangsdaten liegen offen. Rechte sind zu weit. Niemand fühlt sich zuständig. Neu ist allein das Tempo, mit dem daraus Schaden wird.
Das ist die relativ gute Nachricht: Angegriffen wird eine Schicht, die Unternehmen selbst kontrollieren. Die schlechte steht daneben. Genau diese Schicht behandeln die meisten Organisationen bei KI-Agenten so, wie sie Dienstkonten vor fünfzehn Jahren behandelt haben. Einmal angelegt, nie wieder angefasst.
Die Zahlen laufen der Governance davon
Gartner erwartet, dass bis Ende 2026 rund 40 Prozent aller Unternehmensanwendungen autonome Agenten enthalten. IDC rechnet bis dahin mit mehr als 1,3 Milliarden Agenten im produktiven Einsatz. Diese Agenten entstehen nicht in der IT-Abteilung. Sie entstehen in Entwicklungsteams, in Fachbereichen, bei Dienstleistern und in SaaS-Diensten, die ihre Agentenfunktionen im Hintergrund aktivieren.
Die Erhebungen zur Gegenseite fallen deutlich aus. Eine von Saviynt beauftragte CISO-Befragung aus dem Jahr 2025 kommt zu dem Ergebnis, dass 91 Prozent der Unternehmen kaum oder gar keine Sicht auf ihre KI-Identitäten haben. 83 Prozent sorgen sich, dass diese Identitäten auf kritische Systeme zugreifen. Die Enterprise Management Associates berichteten im Dezember 2025 unabhängig davon, dass 79 Prozent der Unternehmen agentische KI ohne schriftliche Richtlinie in Betrieb genommen haben.
Sorge und Kontrolle klaffen also weit auseinander. Das ist kein Technologieproblem. Es ist ein Inventarproblem.
Ein Agent ist eine Identität, die in kein Schema passt
Ein KI-Agent authentifiziert sich, ruft APIs auf, liest Daten, schreibt Daten, löst Transaktionen aus. Damit erfüllt er jede brauchbare Definition einer Identität. Trotzdem sprengt er die Annahmen, auf denen klassisches Identity Management ruht.
Ein Mitarbeiter durchläuft einen Eintrittsprozess. Ein Agent entsteht, weil jemand ein Framework startet. Ein Mitarbeiter hat einen Vorgesetzten, der seine Rechte bestätigt. Ein Agent hat oft niemanden, der sich zuständig fühlt. Ein Mitarbeiter verlässt das Unternehmen und wird deprovisioniert. Ein Agent läuft weiter, bis jemand seine Cloud-Ressource abschaltet.
Joiner, Mover, Leaver beschreibt diese Welt nicht mehr. Eine Rezertifizierung im Halbjahresrhythmus prüft einen Zustand, den es zum Prüfzeitpunkt längst nicht mehr gibt.
Der Agent erbt die Rechte, nicht das Urteilsvermögen
Rollenbasierte Autorisierung beantwortet die Frage, ob ein Zugriff erlaubt ist. Sie beantwortet nicht die Frage, ob diese konkrete Aktion zu dem Auftrag passt, für den der Agent existiert. Ein Agent mit Schreibrechten auf ein Verzeichnis darf Dateien löschen. Ob er sie löschen soll, weil jemand ihn bat, aufzuräumen, steht in keiner Rolle. Solange die Prüfung im nachgelagerten Log stattfindet, prüft sie nach dem Abfluss.
Dazu kommt die Zurechnung. Agenten handeln mal eigenständig, mal im Auftrag eines Menschen, mal im Auftrag eines anderen Agenten. Wer eine Aktion auf den ursprünglichen Prompt zurückführen will, braucht diese Kette lückenlos. Klassische Protokolle liefern sie nicht. Sie zeigen, dass ein technischer Account etwas getan hat, nicht warum und in wessen Auftrag.
Der Prüfer wird die Frage ohnehin stellen
Die Regulierung nimmt das Thema vorweg. NIS2 verlangt Zugriffskontrolle und Nachweisbarkeit über alle Systemidentitäten. DORA fordert von Finanzunternehmen ein Lebenszyklusmanagement für jede Identität, die auf kritische Systeme zugreift. Der EU AI Act verlangt für Hochrisiko-Systeme eine dokumentierte menschliche Aufsicht.
Keine dieser Vorschriften nennt KI-Agenten beim Namen. Alle drei erfassen sie. Wenn ein Prüfer fragt, wer einen bestimmten Agenten autorisiert hat und wer seine Rechte verantwortet, darf die Antwort nicht lauten, dass sich das nicht rekonstruieren lässt.
Drei Schritte, in dieser Reihenfolge
Erkennen kommt zuerst. Ein Verzeichnis, das auch die Agenten erfasst, die niemand angemeldet hat, und das jedem Eintrag einen Verantwortlichen zuordnet. Sinnvollerweise zwei: einen fachlichen und einen technischen. Wer nur den Infrastrukturadministrator einträgt, hat die Verantwortung nicht geklärt, sondern verschoben. Zum Inventar gehören außerdem die Bausteine ringsum, also MCP-Server, Modelle, Werkzeuge und die Zugriffspfade dazwischen.
Autorisieren kommt zur Laufzeit. Die Prüfung muss lauten: Passt diese Aktion zu dem Auftrag? Handelt der Agent eigenständig oder für jemanden? Und sie muss fein genug greifen, um einzelne Objekte innerhalb einer Anwendung zu unterscheiden, nicht nur ganze Systeme.
Beenden kommt zum Schluss und wird am häufigsten vergessen. Ein Agent, dessen Projekt ausgelaufen ist, muss seine Tokens verlieren. Sofort, nicht beim nächsten Quartalsreview. Ein verwaister Agent mit gültigen Credentials ist eine offene Tür, die niemand mehr bewacht.
Der Markt sortiert sich gerade entlang dieser drei Aufgaben. Die etablierten Anbieter erweitern ihre Plattformen jeweils aus ihrer eigenen Historie heraus, von der Governance, vom Verzeichnis oder von den privilegierten Zugängen her. Saviynt hat im Juli mit Zuma eine Plattform vorgestellt, die die Schritte zusammenführt: Ein Modul erfasst Agenten, nicht-menschliche Identitäten und deren Zugriffswege, ein vorgeschaltetes Gateway prüft jede Aktion gegen Auftrag, Kontext und Risiko, ein drittes Modul regelt Registrierung, Verantwortlichkeit und Abschaltung. Welcher Ansatz sich durchsetzt, ist offen. Über den Erfolg entscheidet ohnehin zuerst, ob ein Unternehmen seine Agenten überhaupt kennt.
Das Tempo ist das Problem
Daraus folgt keine neue Sicherheitsdisziplin. Es folgt die alte, ausgeführt in einem anderen Takt. Least Privilege, saubere Token-Verwaltung, ein Verantwortlicher für jede Identität. Diese Grundsätze sind vierzig Jahre alt und halten der Prüfung stand. Nur der Prüfzyklus hält ihr nicht mehr stand.
Sechs Stunden reichten, um Tausende Zugangsdaten abzuräumen. In einem halben Jahr zwischen zwei Rezertifizierungen liegen rund 730 solcher Zeitfenster.
Weitere Artikel
NIS2-Umsetzung: IT-Sicherheit wird zur strategischen Führungsaufgabe
VivaTech Confidence Barometer ’25: So steht Deutschland im Vergleich da
Das Ende von Sicherheitslücken? „Wir verkürzen die Suchzeit von 44 Minuten auf 40 Sekunden”
Claroty-Studie: Drei Viertel der Industrieunternehmen wurden im vergangenen Jahr Opfer eines Ransomware-Angriffs