Hinter jeder nützlichen Aktion, die ein Agent auf einem fremden System ausführt, steht eine Identität. Fragt ein Agent eine Datenbank ab, ruft eine API auf oder deployt in eine Staging-Umgebung, autorisiert irgendein Credential diesen Schritt. Welche Aktionen ein autonomes System wählt, lässt sich kaum vorhersagen – wohl aber, worauf die dahinterliegende Identität überhaupt zugreifen darf.
Die klassischen Gegenmittel setzen nachträglich an: Scanner beobachten Repositories, Pre-Commit-Hooks fangen ab, was sie können, und Sicherheitsteams rotieren Zugangsdaten, nachdem eine Offenlegung entdeckt wurde. Diese Kontrollen bleiben wichtig, doch Agenten führen ihre Grenzen vor. Sie lesen lokale Dateien, führen Befehle aus, rufen APIs auf, interagieren mit MCP-Servern (Model Context Protocol) und ändern Konfigurationen. Jede zusätzliche Fähigkeit schafft eine weitere Stelle, an der ein Credential nötig wird – und einen weiteren Weg, auf dem es sich verbreitet.
Besonders heikel sind Entwickler-Arbeitsplätze. Zugangsdaten liegen häufig in .env-Dateien und lokalen Konfigurationen, übrig aus einer früheren Debugging-Sitzung und nie für die Versionsverwaltung gedacht. Ein Agent mit breitem Projektzugriff liest diese Dateien mit. Für ihn ist eine Konfigurationsdatei mit einem Produktions-API-Schlüssel schlicht Teil der Arbeitsumgebung – auch wenn der Schlüssel mit der gestellten Aufgabe nichts zu tun hat. Damit verschiebt sich eine alte Annahme: Lokale Klartext-Zugangsdaten sind nicht mehr nur für den Entwickler und die Anwendungen erreichbar, die sie ausdrücklich referenzieren.
Setup-Anleitungen für Agenten und MCP-Server verstärken den Effekt. Weil viele Integrationen eine Authentifizierung verlangen, läuft die vereinfachte Einrichtung oft darauf hinaus, das Credential direkt in eine Konfigurationsdatei zu kopieren. Da diese Datei nie in die Versionskontrolle gelangt, gilt sie schnell als unbedenklich – liegt aber im Klartext auf der Maschine, häufig genau dort, wo der Agent Leserechte hat.
Hinzu kommt die Vervielfältigung: Derselbe Schlüssel landet in einer .env-Datei, in einer CI/CD-Variablen und womöglich in einem Jira-Ticket, während Ingenieure ein fehlgeschlagenes Deployment untersuchen. Jede Kopie authentifiziert. Wer nur die Fassung im Repository rotiert, lässt die übrigen funktionsfähig – weshalb Repository-Scanning allein das Problem nicht löst. Ein erheblicher Teil der Vorfälle entsteht vollständig außerhalb von Code-Repositories, in Kollaborations- und Ticketsystemen.
Ein weiterer Treiber sind zu weit gefasste Berechtigungen. Damit ein Agent brauchbar arbeitet, braucht er Zugriff; Rechte, die im Prototyping vergeben wurden, um Fehler zu vermeiden, wandern in den Produktivbetrieb und werden nicht mehr überprüft. In Multi-Agenten-Systemen wächst das Risiko: Eine Orchestrierungsschicht, die Schlüssel für mehrere Agenten hält, kann einen Dominoeffekt kompromittierter Identitäten auslösen – Angreifer erben dann alles, worauf der Orchestrator zugreifen durfte.
Die Lücke ist messbar. In einer Umfrage von Keeper Security zur RSAC 2026 gaben 46 Prozent der Befragten an, KI-gestützte Werkzeuge hätten Zugang zu kritischen Systemen und sensiblen Daten; 76 Prozent sagten zugleich, diese Identitäten würden nicht konsistent unter Richtlinien für privilegierten Zugriff verwaltet.
Ein generelles Verbot von KI-Coding-Werkzeugen hält der Beitrag weder für realistisch noch für nötig. Stattdessen solle man Agenten als weitere Identität in der Entwicklungsumgebung behandeln: unnötige statische Zugangsdaten beseitigen, dauerhafte Privilegien abbauen, Lebensdauern verkürzen, Identitäten trennen und die Nutzung von Maschinenidentitäten sichtbar halten. Mehr Scanning helfe nicht, da es Credentials erst findet, wenn sie sich bereits verteilt haben. Als eigenes Produkt nennt der Text Keeper Secrets Manager, mit dem sich Infrastruktur-Secrets zentral absichern und hartcodierte Zugangsdaten aus Entwicklungsabläufen entfernen lassen.