Jeder KI-Agent ist eine nicht-menschliche Identität. Schluss mit God-Mode.

Jeder KI-Agent, den Sie ausliefern, ist eine nicht-menschliche Identität, und die meisten Teams geben jedem einzelnen gerade God-Mode. Ein Agent ist kein Feature, er ist ein Konto: Er hält Zugangsdaten, trägt Berechtigungen, ruft APIs auf und handelt auf Systemen, während kein Mensch die Tastenanschläge sieht. Das Risiko, das Ihnen den Schlaf rauben sollte, ist nicht, dass das Modell etwas Dummes sagt. Es ist, dass das Modell einen langlebigen API-Schlüssel, eine Datenbankrolle und einen Ausgangspfad hält, und eine einzige gekaperte Anweisung all das dem Angreifer in die Hand gibt. Vezas Bericht „State of Identity & Access 2026“ beziffert das Ausmaß: Maschinenidentitäten übertreffen Menschen bereits im Verhältnis 17 zu 1, und nur 0,01 Prozent dieser nicht-menschlichen Identitäten kontrollieren 80 Prozent aller Cloud-Berechtigungen. Agenten werden dieses Verhältnis bald harmlos aussehen lassen.

Behandeln Sie den Agenten also als das, was er ist, eine Identität, und steuern Sie ihn entsprechend. Hier ist, warum die Zugangsdaten Ihre eigentliche Angriffsfläche sind, warum Ihre Agentenzahl bereits außer Kontrolle ist, und das Bauprinzip, das einen kompromittierten Agenten von allem Wichtigen fernhält.

Nicht das Modell ist Ihre Angriffsfläche. Es sind die Zugangsdaten.

Entwickler fixieren sich auf das Modell, den Prompt, den Jailbreak. Angreifer fixieren sich darauf, was der Agent erreichen kann. Ein Chatbot erzeugt Text, und das ist der gesamte Wirkungsradius. Ein Agent liest Code, fragt Datenbanken ab, öffnet Tickets, verschickt Mails, bewegt Geld. In dem Moment, in dem Sie ihm ein Werkzeug geben, geben Sie ihm eine Identität mit dauerhaftem Zugriff, und dieser Zugriff verschwindet nicht, wenn das Gespräch endet. Wie es ein viel geteilter Beitrag diesen Monat formulierte, hat sich die Unternehmensfrage von „was können Agenten?“ zu „wer haftet, wenn etwas schiefgeht?“ verschoben. Das ist eine Identitätsfrage, keine Modellfrage.

Dasselbe Argument haben wir von der Prompt-Seite in warum sich Prompt Injection nicht wegpatchen lässtgemacht: Nehmen Sie an, der Agent wird getäuscht, und sorgen Sie dafür, dass die Täuschung nichts erreicht. Identität ist die andere Hälfte dieser Wette. Ein gekaperter Agent mit einem begrenzten Zehn-Minuten-Token ist ein Vorfallbericht. Ein gekaperter Agent mit einem dauerhaften Admin-Schlüssel ist ein Datenleck.

Sie haben bereits mehr nicht-menschliche Identitäten als Menschen

Bevor Sie einen einzigen Agenten hinzufügen, ertrinkt Ihr Stack bereits in Maschinenidentitäten: Service-Konten, CI-Tokens, Webhook-Secrets, OAuth-Apps, Cronjobs. Die Umfrage der Cloud Security Alliance zu nicht-menschlichen Identitäten und KI-Sicherheit 2026 ergab, dass nur 15 Prozent der Organisationen sich zutrauen, einen NHI-basierten Angriff zu verhindern, und mehr als 16 Prozent die Erstellung KI-bezogener Identitäten überhaupt nicht erfassen. Sie können nicht steuern, was Sie nie registriert haben.

Agenten gießen Öl ins Feuer. Sie starten Sub-Agenten, fordern Werkzeuge zur Laufzeit an und verketten Aktionen über Systeme, die nie miteinander reden sollten. Veza fand heraus, dass ruhende Konten bereits 38 Prozent aller Konten ausmachen, und zählte 824.000 verwaiste Identitäten mit aktiven Berechtigungen und ohne menschlichen Eigentümer. Jeder Agent, den Sie ohne Eigentümer, Ablaufdatum und Protokoll aufstellen, ist eine weitere davon, nur dass diese hier von selbst handeln kann.

Konfigurationsmüdigkeit ist der Grund, warum Agenten God-Mode bekommen

Hier ist die Falle, unverblümt benannt von Kenton Varda (Cloudflare) in einem Beitrag mit Hunderten von Antworten: „Wenn Sie die Berechtigungen jedes Agenten einzeln konfigurieren müssen, haben Sie verloren. Denn Sie werden nur die Geduld haben, so viele Agentenberechtigungen zu konfigurieren.“ Er hat recht, und das ist das ganze Problem. Least Privilege, das davon abhängt, dass ein Mensch jeden Agenten sorgfältig begrenzt, stirbt in dem Moment, in dem Sie zwanzig Agenten und eine Deadline haben. Der Weg des geringsten Widerstands ist, die breite Rolle zu kopieren, die Sie schon haben, den Schlüssel einzufügen, der schon funktioniert, und weiterzumachen. Multiplizieren Sie das mit einem Team, und Sie haben das Problem „0,01 Prozent kontrollieren 80 Prozent“ mit Absicht hergestellt.

Die Antwort ist nicht mehr Disziplin. Sie ist, den begrenzten Weg zum einfachen Weg zu machen: Identität automatisch pro Agent ausgestellt, Berechtigungen aus der Aufgabe abgeleitet, Zugangsdaten, die von selbst ablaufen. Wenn das Richtige mehr Mühe kostet als das weit offene, bekommen Sie jedes Mal das weit offene.

Geben Sie jedem Agenten seine eigene begrenzte, kurzlebige Identität

Das Prinzip, das hält, ist langweilig und wird im Code entschieden, nicht pro Prompt. Jeder Agent bekommt seine eigene Identität, nie ein geteiltes Service-Konto. Diese Identität bekommt den engsten Berechtigungssatz, den die Aufgabe braucht, und nichts, was sie später brauchen könnte. Ihre Zugangsdaten sind kurzlebig und werden bei Bedarf erzeugt, sodass ein geleakter Token binnen Minuten wertlos ist. Und jede Aktion ist zuordenbar, denn „welcher Agent hat dies getan, in wessen Auftrag, mit welcher Berechtigung“ ist die erste Frage, die Sie nach einem Vorfall stellen.

Das ist derselbe Eindämmungsinstinkt, den wir auf die Laufzeit in warum Ihr Coding-Agent eine Leine braucht und auf den Host in selbst-gehostete KI-Infrastruktur absichernanwenden: Die Kontrolle liegt außerhalb des Modells, in den Zugangsdaten und der Berechtigung, wo eine eingeschleuste Anweisung sie nie erreicht.

Secrets leaken jetzt schneller, weil Agenten Code schreiben

Das Zugangsdaten-Problem ist nicht theoretisch, und es verschlimmert sich auf einer messbaren Kurve. GitGuardians „State of Secrets Sprawl 2026“ fand heraus, dass KI-Dienst-Secrets, die auf öffentliches GitHub geleakt wurden, 1,27 Millionen erreichten, ein Plus von 81 Prozent in einem Jahr, und dass Commits, die mit Hilfe eines Coding-Agenten geschrieben wurden, Secrets mit 3,2 Prozent leakten, gegenüber einem Basiswert von 1,5 Prozent. Das Werkzeug, dem Sie vertrauen, um schnell zu sein, leakt Schlüssel mit der doppelten Rate. Derselbe Bericht zählte 24.008 Secrets allein in Konfigurationsdateien des Model Context Protocol, von denen 2.117 noch gültig waren, weil der Klebecode, der Agenten an Werkzeuge anbindet, genau dort ist, wo Leute den Schlüssel einfügen und vergessen.

Kurzlebige, begrenzte Zugangsdaten sind das Gegenmittel für all das. Ein Token, der in zehn Minuten stirbt, ist es nicht wert, committet zu werden, nicht wert, gestohlen zu werden, und einem Angreifer, der ihn eine Stunde später findet, nicht viel wert. Sie können nicht verhindern, dass Secrets leaken. Sie können die geleakten nutzlos machen.

Die Bau-Checkliste

Entscheiden Sie diese Punkte einmal, in Ihrer Plattform, damit das Richtige das Standardmäßige ist.

• Eine Identität pro Agent. Nie ein geteiltes Service-Konto. Wenn Sie nicht sagen können, welcher Agent etwas getan hat, können Sie ihn nicht entziehen, ohne zehn andere zu brechen.
• Zugangsdaten erzeugen, nicht speichern. Kurzlebige Tokens bei Bedarf schlagen jeden langlebigen Schlüssel in einer Env-Variable, derselbe Instinkt wie die Kontrolle über eigene Schlüssel und Daten zu behalten.
• Berechtigungen aus der Aufgabe ableiten. Begrenzen Sie auf das, was dieser Lauf braucht, nicht was die Agentenklasse je brauchen könnte. Konfigurationsmüdigkeit löst man durch Automatisierung, nicht durch Willenskraft.
• Geben Sie jedem Agenten Eigentümer und Ablaufdatum. Ein Agent ohne menschlichen Eigentümer ist eine künftige verwaiste Identität. Registrieren Sie ihn, oder liefern Sie ihn nicht aus.
• Protokollieren Sie jede Aktion gegen die Agentenidentität. „Welcher Agent, in wessen Auftrag, mit welcher Berechtigung“ ist die Frage, die Sie schnell beantwortet brauchen.
• Sichern Sie das Unwiderrufliche ab. Geld, Löschungen, Deployments und ausgehende Nachrichten bekommen eine menschliche Bestätigung, nie ein implizites Ja, die Disziplin, die wir über Agenten-Orchestrierung im Produktionsmaßstab anwenden.

Steuern Sie die Identität, nicht das Bauchgefühl

Agentensicherheit wird als neues, exotisches Problem verkauft, und Teile davon sind es. Aber der tragende Fix ist vierzig Jahre alt: Jeder Akteur bekommt seine eigene Identität, das Least Privilege, das er braucht, Zugangsdaten, die ablaufen, und ein Protokoll dessen, was er tat. KI hat das nicht aufgehoben. Sie hat nur Millionen neuer Akteure geschaffen, die nie schlafen und nie um Erlaubnis fragen. Entscheiden Sie jetzt, solange Sie eine Handvoll Agenten haben, dass jeder eine Identität ist, die Sie besitzen, begrenzen und abschalten können. Tun Sie es später, und Sie prüfen 824.000 Waisen. Wir bauen Agenten bewusst so, und dasselbe Denken durchzieht LLM-Funktionen für die Produktion bauen und die private Bereitstellung hinter Vaultic.

Weiterführende Lektüre: siehe warum sich Prompt Injection nicht wegpatchen lässt, selbst-gehostete KI-Infrastruktur absichern und warum Ihr Coding-Agent eine Leine braucht.