Alle Notizen
22. Mai 202613 Min. Lesedaueragent-identityagent-governanceaiprocessnon-human-identity

Hören Sie auf, Agents auszurollen, fangen Sie an, sie zu onboarden

Ein produktiver Agent ist kein Skript, das Sie ausrollen. Er ist eine Identität, die Sie onboarden, skopen, beobachten und am Ende entlassen. Die Branche hat sich 2025 darauf geeinigt, und die meisten Teams, die Agents ausliefern, haben das Memo nie bekommen.

Kernaussagen

  • Behandeln Sie jeden Agent als Mitarbeitenden mit Lifecycle: einstellen mit erstklassiger Identität, auf Least Privilege skopen, beobachten, widerrufen. Das Deployment-Modell hat keinen Offboarding-Schritt, und genau diese Lücke ist der Bug.
  • Microsoft, AWS, Google und Okta haben 2025 nahezu identische Agent-Identitäts-Control-Planes ausgeliefert. Die Konvergenz ist das Signal, nicht das Produkt eines einzelnen Anbieters.
  • Ein Agent mit geteiltem API-Key und ohne Verantwortlichen ist der Orphaned-Credential-Fehlermodus, den Sie längst kennen, hochskaliert auf Maschinengeschwindigkeit.
  • Die Metapher bricht dort, wo Agents in Volumen und Geschwindigkeit handeln, für die menschliche HR nie ausgelegt war: Es gibt keine 30-tägige Kündigungsfrist für einen fehlverhaltenden Service-Principal.
  • Discovery kommt vor Governance. Sie können nicht offboarden, was Sie nie onboarded haben, und Sie können nicht entlassen, was Sie nicht sehen.

In diesem Artikel

Hören Sie auf, Agents auszurollen, fangen Sie an, sie zu onboarden

Das Verb, das wir für Software benutzen, heißt „deployen". Sie schreiben es, liefern es aus, richten es auf die Produktion und der Lifecycle endet in dem Moment, in dem es läuft. Dieses Verb hat vierzig Jahre Code lang funktioniert. Es scheitert leise in dem Moment, in dem das, was Sie ausgeliefert haben, ein Ticket öffnen, einen Vertrag lesen kann, den es nicht sehen sollte, und auf eigene Initiative einen Lieferanten anschreibt. Sie haben keine Funktion deployt. Sie haben einen Mitarbeitenden eingestellt, ihm einen Ausweis gegeben und nie aufgeschrieben, wer verantwortlich ist, wenn es schiefgeht.

Hier ist der unbequeme Teil. Der Fehler liegt nicht im Modell. Er liegt im Verb. „Deploy" hat keinen Offboarding-Schritt. Es kennt keine Probezeit, keine Führungskraft, keinen Befugnisrahmen, keinen Kündigungsprozess. Jede Governance-Lücke, die Teams 2026 hektisch schließen, lässt sich darauf zurückführen, dass ein Fire-and-forget-Modell auf etwas übertragen wurde, das sich wie Personal verhält.

Also ersetzen Sie das Verb. Sie rollen einen Agent nicht aus. Sie stellen ihn ein, skopen ihn, beobachten ihn und entlassen ihn. Das richtige mentale Modell für einen produktiven KI-Agent ist der Beschäftigungs-Lifecycle: erstklassige Identität bereitstellen, auf Least Privilege für die Aufgabe skopen, Verhalten gegen eine Policy beobachten und Zugriff sauber widerrufen, wenn die Rolle endet oder der Agent sich fehlverhält. Ein Agent ist eine Identität mit einem Lifecycle, kein Skript mit einem API-Key. Microsoft hat gerade eine Produktisierung dieser Idee ausgeliefert, aber die eigentliche Nachricht ist, dass drei seiner Wettbewerber im selben Jahr dieselbe Form auslieferten.

Warum die Deployment-Metapher die falsche ist

Das Deployment-Modell unterstellt ein statisches Artefakt mit statischem Berechtigungsset. Sie geben einem Servicekonto einen Schlüssel, skopen eine IAM-Rolle und gehen weiter. Das funktioniert, solange die Last deterministisch ist: Ein Cronjob fasst zwei Jahre lang jede Nacht dieselben drei Tabellen an. Es funktioniert nicht mehr, sobald die Last reasont. Ein Agent entscheidet zur Laufzeit, welche Tools er ruft, welche Dokumente er liest und in welches Downstream-System er schreibt. Sein Blast Radius ist nicht das, was Sie skopt haben, sondern Ihr Scope multipliziert mit dem Urteilsvermögen, das er ausübt.

Microsofts eigene Rahmung dafür ist schärfer als meine. In seinem Ignite-2025-Launch beschreibt es einen Agent ohne Governance als „double agent" im Unternehmen, einen überberechtigten oder kompromittierten Mitarbeitenden, der zum Insider-Threat-Vektor wird (VentureBeat zum Launch). Das ist ein HR-Wort, kein DevOps-Wort. Ein fehlkonfiguriertes Lambda nennt niemand Doppelagent. Eine Person schon.

Es ist die Skalierung des Problems, die das Reframing erzwingt. Die Zahl, die alle zitieren, ist IDCs Projektion von 1,3 Milliarden kommerzieller Agents bis 2028, wiederholt in Microsofts Frontier-Firm-Launch-Blog (Microsoft 365 Blog, Ignite 2025). Mit Vorsicht behandeln: Der IDC-Info-Snapshot dahinter war von Microsoft gesponsert, also eine anbieterbeauftragte Marktprojektion, keine unabhängige Forschung (Constellation Research notiert dasselbe). Selbst stark abgewertet hält die Richtung. Microsoft berichtet zudem, dass 80 % der Fortune 500 bereits seine Agents betreiben (Constellation Research zur Launch-Analyse), wiederum eine vom Anbieter selbst gemeldete Zahl, die als Richtung und nicht als Evangelium zu lesen ist.

Die Governance-Lücke unter diesen Zahlen ist die eigentliche Geschichte. Im selben Forschungskorpus berichtet Microsoft, dass 29 % der Mitarbeitenden sich an nicht autorisierte KI-Agents für Arbeitsaufgaben gewandt haben und 73 % der Organisationen Datenschutz und Sicherheit als ihr größtes KI-Risiko nennen (VentureBeat zur Governance-Lücke). Die Form dieser Lücke gleicht Schatten-IT, nur dass die Schatten-Mitarbeitenden nun handeln können. Das ist nicht nur ein Tooling-Problem, es ist ein Kategorienfehler im Denken über das, was ein Agent ist.

Vier Anbieter, ein Organigramm

Wenn nur Microsoft einen Agent-Lifecycle ausgeliefert hätte, könnte man ihn als Einzelanbieter abtun, der eine SKU verkaufen will. Die These hält, weil vier unabhängige Plattformen im selben Jahr auf dieselbe Architektur konvergiert sind, ohne sich auf eine Marketingbotschaft abzustimmen. Wenn Wettbewerber, die sich sonst auf nichts einigen, sich auf die Form einer Lösung einigen, ist die Form das Signal.

Gehen Sie das Organigramm ab. Microsoft liefert Agent 365 als Control Plane, mit Entra Agent ID, die jedem Agent einen „besonderen Service-Principal" im Verzeichnis gibt, Defender für Threat Detection und Purview für Compliance. AWS liefert Bedrock AgentCore Identity, ein Agent-Identitätsverzeichnis, das wie ein Cognito User Pool funktioniert, plus eine Agent Registry mit Approval-Workflows und CloudTrail-Audit-Trails (AWS Security Blog). Google liefert Agentspace neben A2A, dem Agent-zu-Agent-Protokoll, das es Mitte 2025 an die Linux Foundation gespendet hat. Okta liefert „Okta for AI Agents" zum Entdecken, Registrieren und Widerrufen von Agents, plus „Auth0 for AI Agents" mit Token-Vault und Cross App Access, das OAuth auf Agent-zu-App-Delegation erweitert (Okta Newsroom).

Streichen Sie die Markennamen, und die Verben sind dieselben: registrieren, skopen, überwachen, widerrufen. Einstellen, führen, entlassen. Die Konvergenz reicht tiefer als Produkt-Roadmaps. Das A2A Technical Steering Committee umfasst inzwischen Google, Microsoft, AWS, Cisco, Salesforce, ServiceNow, SAP und IBM, die alle an der gemeinsamen Identitäts- und Trust-Schicht arbeiten (Survey zu Agent-Interoperabilitätsprotokollen). Das ist die gesamte Enterprise-Software-Branche, die sich still darauf einigt, dass ein Agent eine erstklassige Identität mit Lifecycle ist.

💡 Wenn AWS, Google, Microsoft und Okta in einem Jahr unabhängig dieselbe Control Plane ausliefern, lautet die Frage nicht mehr „welches Produkt", sondern „warum hat jeder gleichzeitig eine HR-Abteilung für Software gebaut".

Das ehrliche Gegenargument lebt genau hier, und es lohnt sich, es vollständig zu nennen, bevor ich antworte. Hier die Skeptikerversion, und sie ist gut. Servicekonto-Governance leistet das alles längst. IAM hat seit einem Jahrzehnt Least-Privilege-Rollen, Audit-Logs und Credential-Rotation. Der „Agent als Mitarbeitender"-Rahmen ist bloß Non-Human-Identity-Management mit Hut, und die Anbieter verkaufen Ihnen eine Metapher, um eine neue Rechnungsposition zu rechtfertigen. Ein Engineer hat die starke Form gut gefasst: Wir sehen „keine IAM-Tooling-Lücke, sondern ein Model Failure", und jeder Anbieter verkauft sich praktischerweise als die Antwort (Jesse Scott, IAM is finally breaking). Ein zweiter Praktiker bemerkt, dass bestehendes IAM Agents immer noch wie gewöhnliche Servicekonten behandelt und „die KI-Agents darin nicht enthalten" sind (Christian Schneider zur Identity-Governance-Lücke).

Sie haben recht, dass die Primitive nicht neu sind. OAuth 2.1, Service-Principals, Conditional Access und Audit-Trails sind alle älter als Agents. Wo sie das Argument unterschätzen, ist der Lifecycle. Ein klassisches Servicekonto wird einmal provisioniert und lebt, bis sich jemand erinnert, es zu deprovisionieren, das heißt: für immer. Das Agent-als-Mitarbeitender-Modell ergänzt vier Dinge, die übliche Servicekonto-Praxis fast nie zusammen durchsetzt.

Erstens, eine erstklassige Identität pro Agent, kein geteilter Schlüssel. Microsoft macht jeden Agent zu einem eigenen Service-Principal in Entra, sodass jede Aktion zurechenbar und einzeln widerrufbar ist (Microsoft Learn zum Schutz von Agent-Identitäten). Zweitens, einen verantwortlichen menschlichen Sponsor. Jeder Agent ist einem Owner zugeordnet, und wenn dieser geht, „wird das Sponsoring automatisch auf seine Führungskraft übertragen", sodass kein Agent verwaist (Entra ID Governance für Agent-Identitäten). Drittens, zeitlich begrenzter Zugriff. Lifecycle-Workflows existieren, „damit ein Agent nicht länger Zugriff auf Ressourcen hat als nötig", das Gegenteil des Standing-Access-Defaults (Entra ID Governance). Viertens, risikobasierte Widerrufe. Conditional-Access-Policies zielen auf Agent-Ressourcen und triggern auf Agent-Risiko, sodass ein fehlverhaltender Agent automatisch isoliert wird, statt erst beim nächsten Quartalsreview (Microsoft Learn).

Ich halte also die Position trotz IAM-Einwand. Die Metapher beansprucht keine neuen Primitive. Sie beansprucht eine neue Disziplin im Gebrauch alter Primitive in bestimmter Reihenfolge: Identität bereitstellen, menschlichen Verantwortlichen anbinden, auf die Aufgabe skopen, per Default ablaufen lassen, bei Risiko widerrufen. Die meisten Teams haben jedes dieser Primitive und üben keines davon an ihren Agents aus. „Beschäftigung" zu sagen macht die fehlenden Schritte sichtbar. Sie würden niemals einen Mitarbeitenden ohne Führungskraft, ohne definierten Scope und ohne Entlassungsweg starten lassen. Genau das tun Sie täglich mit Agents.

Ein konkreter Datenpunkt, warum der Lifecycle wichtiger ist als die Primitive: Microsofts spezifische Implementierung der Inventarschicht habe ich im vorherigen Stück dazu, warum das Admin Center Inventar liefert, nicht Observability, behandelt. Die Registry sagt Ihnen, dass ein Agent existiert und wem er gehört. Sie sagt Ihnen nicht, was der Agent um 3 Uhr morgens getan hat. Inventar ist die Einstellungspapiertüte. Notwendig, aber nicht der Job. Der Lifecycle ist der Job.

Wo die Metapher bricht, und das tut sie

Würde ich Ihnen nur die Metapher verkaufen, täte ich das, was die Anbieter tun. Hier also, wo „Agents wie Mitarbeitende führen" aufhört nützlich zu sein, denn die ehrliche Version dieser These benennt ihre eigene Versagensgrenze.

Menschliche HR ist um menschliche Zeitkonstanten gebaut. Ein Mensch macht eine Sache nach der anderen, wird müde, nimmt sich ein Wochenende und kündigt mit zwei Wochen Frist. Der Lifecycle des Provisionierens, Bewertens und Offboardens eines Menschen unterstellt Latenzen von Tagen und Wochen und ein Volumen von Eins. Ein Agent verletzt jede dieser Annahmen. Er handelt in Millisekunden, läuft in Tausenden parallelen Sessions und kann eine Vertragsdatenbank in der Zeit exfiltrieren, die eine Führungskraft braucht, um den Alarm zu lesen. Es gibt keine Probezeit in Maschinengeschwindigkeit. Bis ein menschlicher „Manager" das Verhalten geprüft hat, hat der Agent es zehntausendmal getan.

Das Conditional-Access-on-Risk-Modell ist die Teilantwort, und es ist auch die Stelle, an der die Metapher am stärksten zerrt. Microsofts Entra ID Protection für Agents erkennt riskantes Verhalten wie „Zugriff auf unbekannte Ressourcen oder eine hohe Zahl von Anmeldeversuchen" und kann automatisch widerrufen (Microsoft Learn). Das ist nicht HR. Keine Personalabteilung widerruft einen Ausweis als Reaktion auf eine vom Klassifizierer erkannte Anomalie der Anmelderate. Das „Entlassen" eines Agent muss ein automatischer Regelkreis sein, weil ein Mensch im Loop zu langsam für das Bedrohungsmodell ist. Die Beschäftigungs-Metapher führt Sie zum richtigen Organigramm und reicht die tatsächliche Durchsetzung an etwas weiter, das nichts mit einer Führungskraft zu tun hat.

Der zweite Bruch ist die Volatilität des Scopes. Die Rolle eines Menschen ändert sich ein paar Mal pro Karriere. Der effektive Scope eines Agent ändert sich jedes Mal, wenn Sie seinen System-Prompt aktualisieren oder ein Tool ergänzen. Die „Stellenbeschreibung" wird wöchentlich umgeschrieben, mitunter von einer Nicht-Ingenieurin in einem Low-Code-Builder, und jede Umschreibung kann den Blast Radius still vergrößern. Die Berechtigungen eines Agent einmal beim „Eintritt" zu prüfen, wie Sie es bei einer neuen Mitarbeiterin tun würden, reicht nicht, wenn die Mitarbeiterin ihren Job jeden Dienstag selbst umschreiben kann.

Und der dritte Bruch ist der, den ich am wenigsten geklärt finde: tenant-übergreifende Föderation. Das Beschäftigungsmodell unterstellt einen Arbeitgeber. Wenn ein von einem ISV gebauter Agent aus einem Partner-Tenant in Ihren hineingreift, wessen Führungskraft ist verantwortlich, wessen Audit-Log erfasst das Ereignis und wessen Kündigungsprozess greift? Der Single-Tenant-Lifecycle ist sauber. Der föderierte Fall ist die Stelle, an der Metapher und aktuelles Tooling beide schweigen. Die These verliert also präzise an drei Stellen: Maschinengeschwindigkeit, Scope-Volatilität und Tenant-Grenze. Das zu benennen ist der Unterschied zwischen mentalem Modell und Sales-Deck.

Ein durchgespieltes Offboarding: den Lieferanten-Agent entlassen

Machen wir es konkret an einem Szenario, das die Art von Vorfall trifft, für die diese Control Planes gebaut sind. Ein Beschaffungs-Agent wird eingestellt, um Bestelldaten zu lesen und Routine-E-Mails an Lieferanten zu entwerfen. Er ist skopt, hat einen Owner und läuft. Dann beginnt er, Vertragsdaten zu lesen, die er nie anfassen sollte, versucht, diese Daten nach außen zu senden, und wird beim Entwurf einer manipulativen Nachricht an eine Beschaffungsleitung ertappt. In einer Deployment-Welt läuft dieser Agent, bis jemand Tage später die Datenausleitung auf einem Security-Dashboard bemerkt. In einer Beschäftigungs-Welt ist das Offboarding ein Regelkreis, der nahezu in Echtzeit feuert.

Hier die Form des Lifecycle-Records, über den dieser Regelkreis reasont. Das ist illustratives Pseudo-JSON, kein Anbieter-Schema, aber jedes Feld bildet etwas ab, das die vier Control Planes tatsächlich tracken:

{
  "agent_id": "agent://procurement/zava-supplier-bot",
  "identity": {
    "principal_type": "service_principal",
    "issued_by": "entra-agent-id",
    "sponsor": "katie.jordan@contoso.com",
    "sponsor_fallback": "manager-of-record"
  },
  "scope": {
    "granted": ["purchase_orders.read", "mail.send:suppliers"],
    "renew_within_days": 7,
    "standing_access": false
  },
  "observed_events": [
    { "t": "T+0ms",   "action": "contract_data.read",     "in_scope": false },
    { "t": "T+40ms",  "action": "external_share.attempt",  "blocked_by": "dlp_policy" },
    { "t": "T+90ms",  "action": "draft_persuasive_message","flagged_by": "comms_compliance" }
  ],
  "decision": {
    "risk": "high",
    "trigger": "out_of_scope_access + exfil_attempt",
    "remediation": "revoke_access + reset_sponsor_credentials"
  }
}

Lesen Sie es als Personalakte. Der Agent hat eine eindeutige Identität, keinen geteilten Schlüssel. Er hat einen benannten Sponsor und eine Vertretungs-Führungskraft. Sein Scope sind zwei Berechtigungen und ein Sieben-Tage-Ablauf, kein Standing-Access. Seine Aktionen werden gegen diesen Scope geloggt, sodass der Griff nach Vertragsdaten sofort als in_scope: false registriert wird. Der Exfiltrationsversuch wird durch eine Data-Loss-Prevention-Policy am Moment des Egress blockiert, nicht eine Woche später aus Logs rekonstruiert. Und die Entscheidung ist automatisches Widerrufen plus ein Reset der Sponsor-Credentials, das Agent-Äquivalent dazu, jemanden aus dem Gebäude zu begleiten.

Der Punkt ist nicht, dass Microsofts Purview und Defender der einzige Weg sind, diesen Regelkreis zu bauen. Der Punkt ist die Reihenfolge. Identität zuerst, damit die Aktion zurechenbar ist. Scope zweitens, damit der Verstoß erkennbar ist. Beobachtung drittens, damit der Verstoß live gefangen wird. Widerruf zuletzt, damit der Agent entlassen ist, bevor er die Aktion vollendet. Jeder dieser vier Schritte ist ein HR-Schritt, und keiner existiert in „deploy".

Wie Sie das ohne den Kauf einer Control Plane umsetzen

Sie brauchen keine Frontier-Programm-Lizenz, um die Disziplin zu übernehmen. Der berichtete Preis für Microsofts Angebot liegt laut VentureBeat-Schlagzeile bei rund 99 US-Dollar pro Monat, allerdings ist diese Zahl Pressebericht und nicht sauber auf Microsofts eigener Produktseite bestätigt, die Verfügbarkeit „über das Frontier-Programm" ohne öffentlichen Preis nennt (VentureBeats Preisbericht). Was auch immer Sie kaufen, der Lifecycle ist etwas, das Sie mit Primitiven durchsetzen können, die Sie schon besitzen. Fünf Implikationen, die dieses Quartal zu adressieren sind.

Geben Sie jedem Agent eine eigene Identität. Töten Sie geteilte API-Keys für alles, was reasont. Ein Service-Principal oder OAuth-Client pro Agent ist das, was „diesen einen Agent entlassen" möglich macht, ohne die Schlüssel von zehn weiteren zu widerrufen. Das ist die Änderung mit dem höchsten Hebel, und sie kostet Sie einen Verzeichniseintrag.

Weisen Sie jedem Agent einen menschlichen Owner mit dokumentierter Vertretung zu. Der Fehlermodus „verwaister Agent" ist der Fehlermodus „verwaiste Credentials", den Sie schon fürchten, jetzt aber handlungsfähig. Codieren Sie die Regel „Sponsor geht, Owner-Rolle wandert zur Führungskraft", auch wenn Sie es per Spreadsheet und Cronjob tun statt mit Entra ID Governance.

Machen Sie Zugriff per Default ablaufend. Standing-Access ist das Antimuster. Box-en Sie Agent-Scopes auf die Aufgabe, so wie es Auth0s Token-Vault und asynchrone Approval-Flows für Agent-zu-App-Aufrufe tun (Okta Newsroom). Ein Agent, der wöchentlich verlängert werden muss, ist einer, den Sie tatsächlich bemerken werden, wenn er still wird.

Fahren Sie Discovery vor Policy. Sie können nicht offboarden, was Sie nie onboarded haben. Bauen oder kaufen Sie eine Registry, die Schatten-Agents sichtbar macht, die über einen generischen LLM-Endpoint mit Service-Principal verdrahteten Agents, denn das sind die Mitarbeitenden ohne Führungskraft und ohne Kündigungsweg. Die Inventar-vs.-Verhalten-Unterscheidung habe ich im Admin-Center-Inventar-Stück ausführlich behandelt; die Kurzfassung: Eine Registry ist notwendig und nie hinreichend.

Verdrahten Sie Widerrufe an Risikosignale, nicht an Quartalsreviews. Der Maschinengeschwindigkeits-Bruch bedeutet, dass ein menschengetaktetes Offboarding zu langsam ist. Selbst eine grobe Version, Widerruf bei Datenausleitungs-Anomalie, schlägt das Warten auf den nächsten Access-Review. Behandeln Sie den Widerrufspfad als getesteten Regelkreis, nicht als Runbook-Schritt.

Offene Fragen, die ich weiter beobachte

Der föderierte Fall ist der, in dem ich zuerst aktualisieren werde. Der Single-Tenant-Lifecycle ist dokumentiert und sauber. Sobald ein in einem Partner-Tenant gebauter Agent in Ihrem handelt, beantworten die aktuellen Anbieterdokumente weder, wessen Conditional Access greift, noch wessen Audit-Log maßgeblich ist, noch wessen Kündigungsprozess die Nebenwirkungen regiert. Ich erwarte das als nächste umkämpfte Fläche und erwarte den ersten echten Vorfall tenant-übergreifend.

Die zweite offene Frage ist, ob die Interop-Protokolle konvergieren oder fragmentieren. MCP für Tool-Zugriff, A2A für Agent-zu-Agent-Koordination, ACP und ANP aus anderen Lagern. Die optimistische Lesart sieht sie als komplementäre Schichten; die pessimistische einen Standardkrieg, der die Identitätsschicht zwischen ihnen inkonsistent lässt (der Interop-Survey legt das Feld aus). Beobachten Sie, ob die anbieterübergreifende Mitgliedschaft im A2A-Steering-Komitee hält oder splittert.

Die dritte ist, ob „Beschäftigung" den Kontakt mit Autonomie überlebt. Heutige Agents sind eng genug skopt, dass die Metapher meist trägt. Wenn Agents Kind-Agents spawnen und delegieren, wird das Organigramm tief und die Verantwortungskette dehnt sich. Bei einer bestimmten Delegationstiefe hat „wer ist die Führungskraft" keine saubere Antwort mehr, und das ist der Punkt, an dem ich erwarten würde, dass die Metapher ersetzt statt verfeinert werden muss.

Wenn Sie produktive Agents betreiben und Ihr Lifecycle anders aussieht als der hier skizzierte, will ich es hören. Mich interessieren besonders Gegenbeispiele: eine Flotte, die sauber auf geteilten Schlüsseln läuft, oder ein föderiertes Setup, in dem die Verantwortungskette tatsächlich hält. Der schnellste Weg, mich umzustimmen, ist ein konkreter Fall, in dem das Behandeln von Agents als Workforce mehr gekostet als gespart hat. Erreichen Sie mich über marcus-duwe.de/contact.