Ein KI-Agent ist ein Service-Account, der denken gelernt hat. Er hält Zugangsdaten, trägt Berechtigungen, ruft Systeme auf und handelt von selbst, das einzig Neue ist, dass er jetzt entscheidet, was als Nächstes zu tun ist. Das sollte jedem vertraut klingen, der Enterprise-Infrastruktur betrieben hat, denn wir haben bereits Millionen nicht-menschlicher Identitäten gebaut, die ohne Aufsicht handeln, und wir wissen bereits, wie schlecht wir sie steuern. Vezas Bericht „State of Identity & Access 2026“ fand heraus, dass Maschinenidentitäten Menschen im Verhältnis 17 zu 1 übertreffen, und dass nur 0,01 % dieser nicht-menschlichen Identitäten 80 % aller Cloud-Berechtigungen halten. Agenten fügen gleich eine Population hinzu, die von selbst wächst.
Ich bin seit siebzehn Jahren in der Enterprise-Netzwerksicherheit, und die meiste Zeit ging nicht dafür drauf, clevere Angreifer zu stoppen. Sie ging dafür drauf, Zugriff aufzuräumen, den niemand besaß: Firewall-Regeln, deren Antragsteller vor Jahren ging, Service-Accounts mit Passwort im Skript und Admin-Rechten, die niemand rechtfertigen konnte, Tokens, die das Projekt überlebten, das sie brauchte. Die KI-Agenten-Welle ist dasselbe Problem mit angeschraubtem Motor, und ich möchte erklären, warum genau die Leute, die das letzte Chaos aufräumten, dieses kommen sehen.
Der Zugriff, den niemand besitzt
Jeder Bestand, den ich auditiert habe, hat dieselbe Archäologie. Eine Permit-Regel, freitags um 16 Uhr hinzugefügt, um ein Release auszuliefern, ein Jahrzehnt später noch im Regelwerk. Ein Service-Account für eine einmalige Migration, nie gelöscht, hält jetzt Domain-Admin. Ein Integrations-Token, von jemandem in eine Konfigurationsdatei eingefügt, der seither zweimal das Unternehmen gewechselt hat. Niemand ist bösartig. Alle hatten zu tun. Zugriff wurde unter Druck erteilt und nie wieder angefasst, weil das Wiederanfassen von Zugriff undankbare Arbeit ist, die keine Deadline je belohnt.
Die Zahlen sagen, dass sich nichts geändert hat außer dem Ausmaß. Veza fand heraus, dass ruhende Konten bereits 38 % aller Konten ausmachen, und zählte 824.000 verwaiste Identitäten mit aktiven Berechtigungen ohne menschlichen Eigentümer im HR-System. Das ist keine KI-Statistik. Das ist der gewöhnliche Zustand von Enterprise-Identität in 2026, bevor Agenten ankommen. Wir haben das Problem des Zugriffs-den-niemand-besitzt für Service-Accounts nie gelöst. Wir sind dabei, es erneut zu erben, vervielfacht, für Dinge, die aus eigenem Antrieb handeln.
Warum Agenten es schlimmer machen, nicht nur größer
Eine vernachlässigte Firewall-Regel ist immerhin statisch. Sie tut, was sie gestern tat, bis ein Mensch sie ändert. Ein KI-Agent ist nicht statisch: Er fordert Tools zur Laufzeit an, startet Sub-Agenten und verkettet Aktionen über Systeme, die einander nie vertrauen sollten. Der Zugriffsgraph wächst jetzt zwischen Ihren Prüfungen, von selbst, eine Eigenschaft, die kein Service-Account je hatte.
Und die Zugangsdaten-Hygiene um sie herum ist bereits schlecht und wird schlechter. GitGuardians „State of Secrets Sprawl 2026“ fand heraus, dass auf öffentliches GitHub geleakte KI-Dienst-Secrets 1,27 Millionen erreichten, ein Plus von 81 % in einem Jahr, und dass Commits, die mit Hilfe eines Coding-Agenten geschrieben wurden, Secrets mit 3,2 % leakten, gegenüber einem Basiswert von 1,5 %, das Werkzeug, das Sie für mehr Tempo einführen, leakt Schlüssel mit der doppelten Rate. Derselbe Bericht zählte 24.008 Secrets allein in Konfigurationsdateien des Model Context Protocol, davon 2.117 noch gültig. Der Klebecode, der Agenten an Tools anbindet, ist der neue Ort, an dem Schlüssel im Klartext sterben. Die Mess-Seite davon habe ich in vom CVSS zur Angriffserfolgsrate für KI ins Risikoregister gebracht.
Ein Agent versagt, wie ein Service-Account versagt
Wenn ein Service-Account missbraucht wird, gibt es selten einen cleveren Exploit. Der Angreifer phisht eine Zugangsdatei oder findet einen Schlüssel in einem Repo und nutzt dann den stehenden Zugriff, den der Account schon hatte. Keine Privilege-Escalation nötig, weil das Privileg schon dasaß. Ein KI-Agent versagt genauso. Er muss nicht aus dem Modell ausbrechen; ein gekaperter Agent nutzt einfach die Autorität, die Sie ihm bereits gegeben haben. Das ist das Confused-Deputy-Muster, über das ich für die Modellebene in Prompt Injection als Confused-Deputy-Problem geschrieben habe, und es ist der Grund, warum die tragende Kontrolle die Identität ist, nicht der Prompt. Sie können den Agenten nicht zuverlässig vor Täuschung bewahren. Sie können entscheiden, wie wenig er hält, wenn er getäuscht wird.
Nur 15 % der Organisationen trauen sich zu, einen Angriff über nicht-menschliche Identitäten zu verhindern, so die Umfrage der Cloud Security Alliance 2026, und mehr als 16 % erfassen die Erstellung KI-bezogener Identitäten nicht einmal. Diese Lücke ist keine KI-Kompetenzlücke. Es ist dieselbe Identitäts-Governance-Lücke, die seit der Service-Account-Ära offen ist, jetzt Akteuren ausgesetzt, die schneller handeln können als Ihre vierteljährliche Zugriffsprüfung.
Die Disziplin überträgt sich exakt
Hier ist die gute Nachricht und der Grund, warum ich aus der Netzwerksicherheit zur KI-Sicherheit kam und nicht umgekehrt. Der Fix ist nicht neu. Die Zunft lernte ihn auf die teure Weise und schrieb ihn in jedes Rahmenwerk, dem wir unterliegen. Ein KI-Agent ist eine Identität, also steuern Sie ihn wie eine.
| Die Lektion, die ich im Netzwerk lernte | Wie sie auf einen KI-Agenten zutrifft |
|---|---|
| Jede Regel hat einen benannten Eigentümer | Jeder Agent hat einen benannten menschlichen Eigentümer, bei Erstellung erfasst, sonst ist er eine künftige Waise |
| Regeln in einem Zyklus rezertifizieren | Jede Agentenidentität prüfen: noch gebraucht, noch richtig gescopt, oder entziehen |
| Außer Betrieb nehmen, was das Projekt nicht mehr braucht | Agent und Zugangsdaten beenden, wenn die Arbeit endet, nicht den ruhenden 38 % überlassen |
| Least Privilege auf Quelle, Ziel, Dienst | Den Agenten auf die Aufgabe begrenzen, kurzlebige Zugangsdaten, Default-Deny auf die aufrufbaren Tools |
| Keine Änderung ohne prüffähigen Nachweis | Protokollieren, welcher Agent was getan hat, unter wessen Autorität, auf welche Eingabe |
Nichts davon ist exotisch. Es ist die Disziplin hinter der Enterprise-Firewall-Automatisierung, neu gezeichnet für eine Oberfläche, die es nicht gab, als die Kontrollen geschrieben wurden. Die Rahmenwerke decken es bereits ab. ISO 27001 Anhang A verlangt Identitäts-Lebenszyklus und privilegiertes Zugriffsmanagement, ohne Ausnahme für nicht-menschliche Identitäten. NIS2 und DORA fordern beide Zugriffssteuerung und Asset-Management über jede Komponente, die den Betrieb beeinflussen kann, und ein autonomer Agent ist eindeutig eine Komponente. Den breiteren europäischen Fall mache ich in KI-Sicherheitsberatung für europäische Unternehmen.
Was zu tun ist, bevor Ihre Agentenzahl davonläuft
Das Fenster, das billig zu tun, ist jetzt, solange Sie eine Handvoll Agenten haben und keine Population. Jeder dieser Punkte hat einen Firewall-Vorfahren, was genau der Grund ist, warum er funktioniert.
- Inventarisieren Sie die nicht-menschlichen Identitäten, die Sie bereits haben. Service-Accounts, Tokens, OAuth-Apps und jeden Agenten. Sie können nicht steuern, was Sie nie registriert haben, und die Registrierung ist Befund Nummer eins in jedem Audit.
- Geben Sie jedem Agenten Eigentümer und Ablaufdatum. Ein Agent, für den kein Mensch verantwortlich ist, ist das 824.000-Waisen-Problem im Werden. Erfassen Sie den Eigentümer bei Erstellung, oder liefern Sie ihn nicht aus.
- Auf die Aufgabe begrenzen, die Zugangsdaten ablaufen lassen. Ein dokumentenzusammenfassender Agent hat nichts mit Produktiv-Datenbankzugriff zu tun. Kurzlebige, eng gescopte Zugangsdaten machen einen geleakten Token binnen Minuten wertlos.
- Nehmen Sie Agenten in Ihren Zugriffsprüfzyklus auf. Wenn Sie menschlichen Zugriff jährlich rezertifizieren und Maschinenidentitäten nie prüfen, auditieren Sie die falsche Hälfte Ihres Bestands.
- Protokollieren Sie gegen die Identität. „Welcher Agent, in wessen Auftrag, mit welcher Berechtigung“ ist die erste Frage nach jedem Vorfall und die am schwersten rückwirkend zu beantwortende.
Warum diese Perspektive es wert ist, geliehen zu werden
Ich kam nicht aus der Forschung zur KI-Sicherheit. Ich kam von PAN-OS, Check Point, Cisco und Fortinet, von OT-Segmentierung und ISO-27001-Audits, in die KI. Diese Reihenfolge ist der ganze Punkt. Die Agenten-Versagen, die 2026 landen, sind keine neuartigen KI-Probleme; es sind Identitäts-Governance-Probleme mit einem Modell obendrauf, und die Leute, die sie am besten sehen, sind die, die eine Karriere damit verbrachten, Zugriff aufzuräumen, den niemand besaß. Dieselbe Konvergenz habe ich von der Vorfall-Seite in warum eine Firewall-CVE und ein KI-Agenten-Breach derselbe Fehler sind argumentiert, und ich habe produktive KI unter dieser Disziplin ausgeliefert, aufgeschrieben in den Lektionen aus dem Bau von RogueAI.
Sie müssen Identitäts-Governance nicht so neu lernen, wie es die Netzwerkwelt tat, einen Breach nach dem anderen. Die Antwort ist bereits aufgeschrieben. Behandeln Sie jeden Agenten als eine Identität, die Sie besitzen, begrenzen, prüfen und abschalten können, und die agentische Welle wird zu einem bekannten Problem mit bekanntem Heilmittel, statt zum nächsten Jahrzehnt verwaisten Zugriffs, der darauf wartet, dass ein Auditor ihn findet.
Rollen Sie KI-Agenten aus und sind sich nicht sicher, wer den Zugriff besitzt, den sie halten? Diese Lücke ist jetzt prüfbar, statt nach einem Vorfall. Ich führe Projekte, die Enterprise-Identitäts- und Netzwerksicherheits-Disziplin auf KI-Workloads bringen: Eigentümerschaft, Least Privilege, Lebenszyklus und Change-Control, gebaut, um ein echtes Audit zu überstehen. Review anfragen. Siehe auch FwChange.com für Firewall-Change-Automatisierung und RogueAI für das Produktiv-KI-Portfolio.