Jemand in Ihrem Engineering-Team hat letztes Quartal einen MCP-Server ausgerollt. Er authentifiziert sich mit einem Token, das ein Entwickler angelegt hat, der inzwischen das Team gewechselt hat. Er kann Ihre Produktionsdatenbank lesen und in Slack schreiben. In Ihrem IdP erscheint er nicht, beim Wechsel seines Autors wurde er nie offgeboardet, und in Ihrem Access Review steht er auch nicht.
Drei Fragen, die Sie heute nicht beantworten können: Wer ist verantwortlich, was kann er erreichen, und was hat er getan?
Sie haben mehr davon, als Sie denken
Non-Human Identity ist nichts Neues. Jedes Unternehmen hat Service-Accounts. Geändert hat sich, wie schnell sie entstehen und wer sie anlegt.
Zuletzt bearbeitet von jemandem, der das Unternehmen verlassen hat. Sie listet sechs der vierzehn Accounts, die es gibt.
Für eine Migration angelegt, nie rotiert, immer noch gültig, immer noch mit Zugriff auf Produktion.
Ein Entwickler hat an einem Dienstag ein Tool an Google Workspace angebunden, und seither liest es E-Mails.
433 Identitäten, 321 davon human, 112 nicht. cc_github und das MCP-Token stehen in derselben Tabelle wie Amy Lee, mit denselben Spalten und denselben Offboarding-Zuständen.
Human und non-human sind zwei Reiter einer Liste, nicht zwei Produkte. Das ist die ganze Haltung in einem Bild: 433 Identitäten, 112 davon keine Personen, in derselben Tabelle mit denselben Spalten und denselben Offboarding-Zuständen.
Dass sich diese Accounts ansammeln, liegt an der Struktur und nicht an Nachlässigkeit. Ein Service-Account wird angelegt, um etwas freizumachen, in dem Moment, in dem jemand ausliefern will. Es gibt keinen Eintrittsprozess, keine Führungskraft, keinen HR-Datensatz und nichts, was jemals ein Ereignis erzeugen wird, das sagt: Das sollte enden.
Die Population wächst also nur, und jeder Einzelne davon ist ein funktionierender Zugang.
Drei Dinge, die Agenten geändert haben
Die Entscheidung ist in die Laufzeit gewandert. Ein Service-Account tut, was programmiert wurde, die Code-Review war also die Kontrolle. Ein Agent entscheidet beim Ausführen, was er tut. Damit ist der vergebene Umfang kein Sicherheitsnetz mehr, sondern die gesamte Grenze.
Die Handlungsfläche ist breiter geworden. Ein Service-Account ruft eine API auf. Ein Agent verfügt über eine Reihe von Tools und kombiniert sie, und das Risiko liegt in Kombinationen, die niemand aufgezählt hat, als jedes Tool einzeln freigegeben wurde.
Der Lebenszyklus ist kürzer geworden. Agenten entstehen an einem Nachmittag, angelegt von dem, der einen brauchte. Sie überleben das Projekt, den Sprint und oft die Person, weil an ihnen nichts abläuft.
Vier Dinge müssen zutreffen
1Jeder Agent hat einen Verantwortlichen
Kein Team. Eine namentlich benannte Person, die für sein Handeln einsteht.
Verantwortung ist die Kontrolle, an der alles andere hängt. Ein Agent ohne Verantwortlichen kann nicht geprüft werden, weil niemand sagen kann, ob sein Zugriff noch nötig ist, und er kann nicht offgeboardet werden, weil ihn nichts mit dem Austritt einer Person verbindet.
Iden behandelt Verantwortung als Pflicht und nicht als Feld. Ein Agent, dessen Verantwortlicher geht, wird nicht stillschweigend zum Waisen: Er erscheint im Offboarding dieser Person als Punkt, der neu zugeordnet werden muss, und der Austritt bleibt offen, bis das geschehen ist.
Das funktioniert nur, weil Agenten und Menschen im gleichen System liegen. Es ist das stärkste Argument dagegen, hierfür ein eigenes Werkzeug zu kaufen.
2Der Umfang wird aufgezählt, nicht unterstellt
Ein Token, das die Produktionsdatenbank lesen kann, kann sie vollständig lesen. Ein Agent, der drei Tabellen braucht, sollte drei Tabellen erreichen.
Jede Berechtigung eines Agenten wird so erfasst wie die einer Person: was er erreichen kann, welche Policy das erlaubt hat und wer es freigegeben hat. Damit wird eine Prüfung möglich, weil Sie dem Verantwortlichen die tatsächlichen Möglichkeiten eines Agenten vorlegen können statt den Namen einer Rolle.
Die Accounts einer Applikation. billing@, hs-syn@ und ein MCP-Integrationsnutzer stehen mit allen anderen in der Liste und tragen dieselben Profile und Permission Sets.
Drei dieser Salesforce-Accounts sind keine Personen. Sie tragen dasselbe Profil, dieselbe Lizenz und dieselben Permission Sets wie alle darüber, und das ist der einzige Weg, zu beantworten, was ein Integrationsnutzer tatsächlich erreichen kann, ohne eine Konfigurationsdatei zu lesen.
3Zugangsdaten laufen ab
Das Token, das nie rotiert, ist das häufigste Finding in dieser Kategorie und das mit dem längsten Nachlauf: an einem Nachmittag vor zwei Jahren ausgegeben, immer noch gültig, immer noch mit Zugriff auf Produktion.
Kurzlebige Zugangsdaten pro Session sind die richtige Obergrenze. Wo ein Agent langlebige halten muss, tragen sie ein Ablaufdatum und einen Verantwortlichen, der vorher informiert wird.
4Das Log trennt den Agenten von der Person
Das ist die Zuordnungslücke, und dieser Teil geht in den meisten Umgebungen schief.
Ein Agent handelt im Auftrag eines Nutzers. In einem Log nach Art von Okta oder Entra sehen Sie einen Handelnden: entweder den Agenten, dann verschwindet der Mensch, oder den Menschen, dann verschwindet der Agent. Keines von beidem sagt Ihnen, was passiert ist.
Drei Fälle, die in einem solchen Log identisch aussehen und es nicht sind:
- Der Nutzer hat genau diese Handlung angefordert.
- Der Nutzer hat etwas Weitergehendes angefordert, und der Agent hat dies als Zwischenschritt gewählt.
- Der Agent hat es nach Zeitplan getan, und der Nutzer war überhaupt nicht beteiligt.
Diese Lücke zu schließen braucht die Identität des Agenten, den Menschen, für den er gehandelt hat, die Session, die beide verbindet, und den Auftrag, den der Agent bekommen hat. Iden hält alle vier fest, sodass eine Incident-Analyse die Kette rekonstruieren kann statt sie zu erraten.
Ein SOC-2-Review für eine Applikation. Zwei Zeilen sind markiert, weil die Person im HR-System inaktiv ist und den Zugriff noch hat. Drei der Zeilen sind keine Personen.
Und sie werden geprüft wie alle anderen. Drei Zeilen in dieser Kampagne sind keine Personen, und sie stehen darin, weil ein Service-Account mit Zugriffen, die seit zwei Jahren niemand angesehen hat, in den meisten Beständen die älteste und weitreichendste Berechtigung ist.
Agenten, die Iden aufrufen, nicht nur Iden, das Agenten verwaltet
Alles bisher ist die eine Hälfte des Problems: Ihre Agenten sind Identitäten und brauchen Governance.
Die andere Hälfte läuft in die Gegenrichtung. Ihre Agenten können Iden aufrufen, und für Routinearbeit rund um Identitäten sollte die Arbeit genau dort passieren.
Ein Entwickler braucht mitten in einer Coding-Session Zugriff für eine Kollegin auf einen Dienst. Er öffnet keine Identity-Konsole und kein Ticketformular. Er sagt es in der Session, in der er ohnehin ist. Sein Agent löst die Identität auf, prüft, welche Policy greift, und legt die Anfrage an, und der Entwickler hat nie verlassen, was er gerade tat.
Drei Einschränkungen machen das sicher statt leichtsinnig.
Zugriff ist delegiert, nie besessen. Ein Agent, der Iden aufruft, trägt die Identität dessen, der ihn gestartet hat: der Administrator, der die Aktion ausführt, oder die Person, die Zugriff anfragt. Er hat keinen eigenen Status, und das ist dieselbe Regel, für die diese Seite überall sonst argumentiert. Es wäre sonderbar, von Ihren Agenten Verantwortung und Zuordnung zu verlangen und unseren dann anonymes Handeln zu erlauben.
Er reicht ein, er vergibt nicht. Das Modell ermittelt, was angefragt wird, wer dafür verantwortlich ist und welche Policy greift, und legt dann ein Zugriffsticket an, das dem Freigabeprozess folgt, den Ihre Administratoren definiert haben. Die Intelligenz liegt darin, die Anfrage richtig zu stellen. Die Entscheidung bleibt, wo sie war.
Jede Oberfläche nutzt dieselbe Policy-Engine. Ein Coding-Agent, Slack, die Konsole und die API sind verschiedene Türen in denselben Datensatz. Durch welche Tür die Arbeit kam, ist ein Feld im Log und kein anderes Regelwerk.
Ausführlich behandelt wird das unter agentic IGA, einschließlich der Frage, wie es sich von einem Assistenten unterscheidet, der im Produkt eines Anbieters lebt.
Was sich tatsächlich ändert
Was das nicht leistet
Es verhindert nicht, dass ein Agent innerhalb seines Umfangs etwas Unsinniges tut. Governance entscheidet, was er erreichen kann, nicht ob jede Handlung klug war. Das ist eine andere Kontrolle und liegt überwiegend in der Laufzeit.
Es findet nicht, was Sie nie angebunden haben. Ein Agent, der sich mit einem statischen Schlüssel gegen eine Applikation authentifiziert, für die Iden keinen Konnektor hat, ist unsichtbar, genau wie jeder andere Zugriff in einer nicht angebundenen Applikation.
Und es entscheidet die Standardfrage nicht. SPIFFE, Workload Identity Federation und die MCP-Autorisierungsspezifikation sind alle in Bewegung, und wer behauptet, das sei eine gelöste Schicht, will etwas verkaufen. Stabil ist der Teil darüber: Verantwortung, Umfang, Ablauf und Zuordnung sind erforderlich, wie auch immer die Technik darunter ausgeht.