Fragen Sie ein Security-Team, wie viele Angestellte Zugriff auf die Produktion haben. Sie bekommen eine Zahl, und sie stimmt ungefähr.
Fragen Sie, wie viele Agenten, Skripte und Service-Konten ihn haben. Die Pause vor der Antwort ist das ganze Problem.
Ein Agent ist weder Nutzer noch Service-Konto
Identitätssysteme wurden um zwei Annahmen herum gebaut, und Agenten brechen beide.
An einer menschlichen Identität hängt eine Person. Es gibt eine Vorgesetzte, einen Laptop, ein Eintrittsdatum und — entscheidend — ein Austrittsdatum, das die Deprovisionierung auslöst. Wechselt jemand die Rolle, fängt ein Access Review die Berechtigungen, die er nicht mehr braucht. Der ganze Apparat hängt an einem menschlichen Lebenszyklus.
Das Service-Konto ist das andere Modell: eine feste Berechtigung, die eine vorhersehbare Sache nach Plan tut. Es fährt jede Nacht dieselbe Abfrage. Liest es plötzlich eine andere Tabelle, ist das eine untersuchenswerte Anomalie.
Ein Agent ist keins von beidem. Er hat kein Lebenszyklus-Ereignis, an dem die Deprovisionierung hängen könnte, und sein Verhalten ist konstruktionsbedingt nicht vorhersehbar — der ganze Sinn ist ja, dass er entscheidet, was zu tun ist. Die Anomalieerkennung, die bei Service-Konten funktioniert, produziert gegen etwas, dessen Normalzustand «etwas Neues tun» heisst, ständige Fehlalarme.
Abb. — Die zwei Kontrollmodelle, auf denen Identitätssysteme gebaut wurden. Agenten passen in keins.
Die drei Ausfälle, die sich in der Praxis zeigen
Überdimensionierte Zugangsdaten, nahezu überall. Ein Agent muss aus sechs Systemen lesen — also bekommt er einen Schlüssel mit breitem Zugriff auf alle sechs, weil sauberes Scoping sechs Gespräche mit sechs Verantwortlichen bedeuten würde. Dieser Schlüssel ist jetzt die wertvollste Berechtigung im ganzen Bestand — und er liegt irgendwo, wo ein prompt-injizierter Agent überredet werden könnte, ihn zu benutzen.
Kein Widerrufspfad. Geht ein Mensch, löst HR das Offboarding aus. Hört ein Team auf, einen Agenten zu benutzen, löst nichts irgendetwas aus. Die Berechtigung bleibt unbegrenzt gültig — an einer Workload, die niemand überwacht, referenziert in einer Konfigurationsdatei, deren Autor längst weg ist.
Zusammenbruch der Zuordnung. Ein Agent, der im Auftrag eines Nutzers handelt, authentifiziert sich üblicherweise als er selbst — das Audit-Log verzeichnet also den Agenten, nicht die Person, deren Anfrage ihn losschickte. Geht etwas schief, sehen Sie, was passiert ist — aber nicht warum und für wen. In einem regulierten Umfeld ist das keine Unannehmlichkeit; es ist ein Prüfungsbefund.
Das Injektionsproblem darunter
Es gibt einen Fehlermodus ohne sauberes Gegenstück in der klassischen Sicherheit, und er gehört klar ausgesprochen.
Ein Agent, der nicht vertrauenswürdige Inhalte liest — eine E-Mail, ein Support-Ticket, eine Webseite, ein hochgeladenes Kundendokument —, kann von diesen Inhalten angewiesen werden. Die Anweisung kommt als Daten an und wird als Absicht behandelt. Ein Angreifer muss nicht die Zugangsdaten Ihres Agenten kompromittieren; er muss nur Text dort platzieren, wo der Agent liest.
Deshalb zählt Berechtigungs-Scoping hier mehr als in konventionellen Systemen. Sie können nicht vollständig verhindern, dass ein Agent manipuliert wird. Sie können sicherstellen, dass ein manipulierter Agent nichts Wertvolles erreicht.
Die praktische Konsequenz: Nehmen Sie an, dass jeder Agent, der externe Inhalte berührt, irgendwann etwas tun wird, was ein Angreifer ihm aufgetragen hat — und entwerfen Sie den Wirkradius entsprechend.
Wie gut aussieht
Eine Identität pro Agent, pro Umgebung. Geteilte Zugangsdaten über mehrere Agenten zerstören die Zuordnung genau dann, wenn Sie sie brauchen — also immer während eines Vorfalls.
Scopes, die eng genug sind, um unbequem zu sein. Gleicht ein Agent Rechnungen ab, liest er Rechnungen und schreibt Abgleichdatensätze. Kunden-Personendaten braucht er nicht — und dass die Freigabe einfacher wäre, ist kein Grund.
Kurzlebige Zugangsdaten statt statischer Schlüssel. Ein Agent, der sich ein fünfzehn Minuten gültiges Token holt, ist ein kategorisch kleineres Problem als einer mit einem Schlüssel, der gilt, bis ihn jemand rotiert — also jahrelang.
Ein Ablaufdatum auf jeder Agenten-Identität. Keine Review-Erinnerung — ein echtes Ablaufen, das sie stilllegt. Die Verlängerung sollte verlangen, dass jemand bestätigt, dass sie noch gebraucht wird. Diese eine Kontrolle eliminiert das Problem des verwaisten Agenten — das sonst unlösbar ist, weil niemand Abwesenheit bemerkt.
Und delegierte Identität, wo es sie gibt: Der Agent, der für einen bestimmten Nutzer handelt, sollte dessen Kontext in die Audit-Spur tragen — damit das Log auch das Wer beantwortet, nicht nur das Was.
Warum das Tooling noch nicht nachgezogen hat
Es lohnt sich zu verstehen, warum das schwer ist — statt anzunehmen, Ihre Anbieter seien einfach hintendran.
Identitätsplattformen sind um Personenverzeichnisse herum gebaut. Das Datenmodell hat einen Menschen im Zentrum, mit Attributen wie Abteilung und Vorgesetzter — und die Governance-Funktionen — Access Reviews, Zertifizierungskampagnen, Funktionstrennung — nehmen alle an, dass ein Mensch eine Frage über einen anderen Menschen beantwortet. Agenten in dieses Modell zu zwängen produziert schiefe Ergebnisse: ein Access Review, das eine Vorgesetzte bittet zu bestätigen, ob ein Stück Software eine Berechtigung noch braucht, die sie nicht versteht.
Die Cloud-Anbieter haben die Maschinen-Identitäts-Primitive — Workload Identity Federation, kurzlebige Tokens, Rollen pro Workload — und sie sind genuin gut. Die Lücke: Sie arbeiten auf der Infrastrukturschicht, während das tatsächliche Verhalten des Agenten auf der Anwendungsschicht passiert. Ihr Cloud-Anbieter kann Ihnen sagen, dass eine Workload eine Rolle angenommen hat. Er kann Ihnen nicht sagen, dass der Agent danach vierhundert Kundendatensätze gelesen hat, weil ein Support-Ticket es ihm auftrug.
In dieser Lücke sitzt die aktuelle Tooling-Generation, und sie ist früh. Bis dahin funktionieren die unglamourösen Kontrollen: enge Scopes, kurze Zugangsdaten, harte Abläufe — und jemand, dessen Name draufsteht.
Wo anfangen
Zuerst inventarisieren — und erwarten Sie, dass die Zahl falsch ist. Die meisten Organisationen entdecken Agenten und Integrationen, an deren Beauftragung sich niemand erinnert, mit Zugangsdaten, die niemand rechtfertigen kann. Diese Entdeckung ist unangenehm — und sie ist der Sinn der Übung.
Stellen Sie zu jedem drei Fragen. Was kann das erreichen? Was würde es uns kosten, wenn es morgen vollständig kompromittiert wäre? Wem gehört es — mit Namen?
Die dritte Frage ist die, die am häufigsten scheitert — und der Agent ohne benannten Besitzer ist der, der in zwei Jahren noch mit Produktionszugriff laufen wird.
Dann zuerst den schlimmsten Wirkradius beheben. Nicht die meisten Agenten, nicht die einfachsten — die eine Berechtigung, deren Kompromittierung am meisten schmerzen würde. Enger scopen, ein Ablaufdatum setzen — und bestätigen, dass die Audit-Spur wirklich aufzeichnet, was sie tut.
Das ist keine neue Disziplin, sondern eine alte, angewandt auf eine Population, die schneller wuchs als jeder Prozess. Die Organisationen, die das gut handhaben, sind nicht die mit dem besten Tooling. Es sind die, die zu zählen begannen, bevor sie einen Grund dafür hatten.
