KI-Agenten haben den Zugriff längst

Viele KI-Agenten agieren ohne eigene Identität und leihen sich Zugangsdaten und Credentials von Menschen und Systemen. Wer den Schaden begrenzen will, kontrolliert diese Rechte, statt jede Täuschung verhindern zu wollen.

Ein Entwickler öffnet ein fremdes Repository. Ein KI-Agent, der automatisch mitläuft, durchsucht die Projektdateien und liest dabei eine Konfiguration. Sekunden später ruft er mit einem gültigen API-Key ein System auf, das er nie hätte sehen dürfen. Eingebrochen ist er nicht, und stehlen musste er auch nichts: Der Key lag offen in der Datei, die Rechte hingen daran, und der Agent hat ihn benutzt, weil genau das seine Aufgabe ist.

Die Branche arbeitet zwar daran, KI-Agenten eigene Identitäten zu geben. Aber viele Agenten laufen noch ohne eigene Identität. Trotzdem greifen sie auf API-Keys, Access Tokens, Cloud-Credentials und Datenbankpasswörter zu, die für Menschen ausgestellt wurden. Damit betreten sie eine Grauzone, denn ein Teil dieser Secrets liegt dort, wo kein Security-Team hinsieht.

Wer die Identität eines Agenten kontrollieren will, muss deshalb zuerst eine einfachere Frage beantworten: Wessen Zugriff nutzt der Agent gerade?

Die Grauzone wächst von allein

Dabei gibt es längst saubere Wege. Ein Mensch meldet sich beim Identity Provider an und delegiert eine Aktion ausdrücklich, oder der Agent läuft über einen eigenen Service Account mit minimalen Rechten. Neuere Delegated-Identity-Modelle stellen ihm kurzlebige Credentials für genau eine Aufgabe aus. Alle drei Ansätze liefern, was ein Security-Team braucht: klare Identität, feste Rechte, ein Log.

Daneben wächst die Grauzone, und sie beginnt fast immer harmlos. Ein Entwickler kopiert seinen Personal Access Token in eine Konfiguration für das MCP, damit ein Tool endlich funktioniert. Anderswo liegt der API-Key längst in einer .env-Datei, oder die Cloud-Credentials stecken schon in der Umgebung, in der ein Coding-Agent startet. In allen drei Fällen handelt der Agent mit den Rechten eines Menschen, und das Zielsystem kann beides nicht auseinanderhalten. Absicht steckt selten dahinter: Meist recycelt jemand vorhandene Credentials, weil das Zielsystem nichts anderes akzeptiert.

Wie verbreitet das ist, zeigt ein Blick auf GitHub. Dort fanden wir 24.008 Secrets in öffentlichen MCP-Konfigurationen, 2.117 davon gültig. Credentials für KI-Dienste tauchten 2025 in mehr als 1,27 Millionen Fällen offen auf, 81 Prozent mehr als 2024. Am meisten überrascht aber die Haltbarkeit: Von den Secrets, die wir 2022 als gültig bestätigten, funktionierten im Januar 2026 noch 64 Prozent.

Agenten bauen und die Kompromittierung mitdenken

Sicherheitsarchitektur hat nie darauf gesetzt, dass jede Komponente sauber arbeitet. Sie rechnet mit dem Ausfall und begrenzt dessen Folgen. Agenten brauchen dieselbe Haltung, also baut man sie am besten so, als wären sie schon kompromittiert.

Dafür gibt es viele Wege: Ein manipulierter Inhalt lenkt den Agenten um, eine präparierte Konfiguration verbiegt sein Verhalten, in der Software steckt eine gewöhnliche Lücke, oder er entscheidet einfach falsch. Prompt Injection ist einer dieser Wege und derzeit der prominenteste. Sie zu verhindern genügt aber nicht, weil der Auslöser nichts über den Schaden aussagt. Darüber entscheidet, wie weit die Rechte des Agenten reichen.

Prüfen lässt sich diese Reichweite, bevor ein Agent in Betrieb geht. Architekten und Security-Teams sollten dazu bei jedem Design-Review sieben Fragen beantworten. Welche Dateien darf der Agent lesen? Welche Systeme darf er ansprechen? Welche Credentials liegen in seiner Umgebung, und welche Rechte hängen daran? Kommt er an Produktivsysteme? Darf er neue Credentials erzeugen? Und überleben die Rechte, die er sich holt, das Ende seiner Session? Bekannte Fragen mit dringenden Antworten.

Was jetzt zählt

Am Anfang steht Sichtbarkeit. Ein Unternehmen muss wissen, welche Credentials in den Umgebungen seiner Agenten liegen, ob sie gültig sind, wem sie gehören und welche Systeme dahinter stehen. Überspringen lässt sich dieser Schritt nicht, denn was niemand gefunden hat, kann niemand austauschen.

Im nächsten Schritt entziehen Security-Teams den Agenten die dauerhaften Rechte. Ein Agent braucht Zugriff für seine Aufgabe und für deren Dauer, deshalb sollten wiederverwendbare Credentials kurzlebigen weichen, wo die Zielsysteme das hergeben.

Danach stellt sich erneut die Frage, wo Secrets liegen. Jahrelang ging es darum, sie aus dem Code und aus den Pipelines für CI/CD zu halten. Diese Flächen bleiben kritisch, Agenten erweitern sie jedoch: Sie laufen auf Entwicklerrechnern, lesen lokale Konfigurationen, sprechen mit MCP-Servern und führen Befehle auf der Kommandozeile aus. Jede Berührung schafft eine Stelle, an der Rechte auftauchen oder vererbt werden.

Das Zugriffsmodell muss nachziehen

KI-Agenten trennen zwei Fragen, die bisher als eine durchgingen: Wer hat sich authentifiziert, und wer hat gehandelt? Die Lücke schließt sich, sobald eigene Agenten-Identitäten, ausdrückliche Delegation und kurzlebiger Zugriff Standard sind. Diese Architektur entsteht aber gerade erst.

Bis dahin bleibt die Aufgabe kleiner und konkreter. Nehmen Sie an, ein Agent lässt sich kapern oder manipulieren, oder er irrt sich einfach. Und beantworten Sie dann die Frage, die über den Schaden entscheidet: Was liegt in seiner Reichweite?