Der Agent, der sich am einfachsten erstellen lässt, ist sechs Monate später oft am schwierigsten zu erklären.
Ein Team baut ihn für ein reales Problem. Ein Connector kommt hinzu. Berechtigungen werden erteilt. Die ursprüngliche Entwicklerin wechselt die Rolle, die Wissensquelle zieht um und der Agent bleibt bestehen—nützlich genug, dass ihn niemand entfernt, unklar genug, dass ihn niemand vollständig besitzt.
Agent Sprawl beginnt nicht mit böswilliger Autonomie. Er beginnt mit erfolgreichen Experimenten, die ihre temporären Betriebsannahmen überleben.
Die Antwort ist nicht, Experimente schwer zu machen. Jeder Agent muss jedoch zu einem sichtbaren Teilnehmer der Organisation werden, bevor er dauerhaften Zugriff oder Handlungsspielraum erhält.
Identität ist ein operativer Vertrag
Eine Agentenidentität ist mehr als ein Authentisierungsmechanismus. An ihr treffen Zweck, Zugriff, Verhalten und Verantwortung zusammen.
Ohne eindeutige Identität werden einfache Fragen unnötig schwierig:
- Welcher Agent hat eine Aktion ausgeführt?
- Handelte er für eine Person oder selbständig?
- Welche Berechtigungen nutzte er?
- Wer genehmigte diese Rechte?
- Welche Logs, Policies und Lifecycle-Entscheidungen gehören zu ihm?
- Was muss ebenfalls stoppen, wenn der Agent ausgemustert wird?
Gemeinsame Credentials können einen Prototyp ermöglichen. Später schwächen sie die Verantwortlichkeit, weil mehrere Verhaltensweisen im selben technischen Akteur verschwinden.
Verlangen Sie einen minimalen Agenteneintrag
Bevor ein Agent eine geteilte oder produktive Umgebung erreicht, braucht er sieben Angaben:
- Zweck: Ergebnis und Zielgruppe.
- Business Sponsor: verantwortlich für Wert, Risiko und Fortsetzung.
- Technical Owner: verantwortlich für Konfiguration, Integrationen und Betrieb.
- Identity Pattern: Handelt er für eine Person oder mit eigener Agentenidentität?
- Zugriffsgrenze: Systeme, Daten und Aktionen—inklusive expliziter Ausschlüsse.
- Evidenz: Evaluationen, Monitoring und Incidents der aktuellen Version.
- Review und Ablauf: Datum, an dem Zugriff und Weiterbetrieb erneut begründet werden müssen.
Das ist kein einmaliger Katalogeintrag. Es ist der lebende Kontrolldatensatz des Agenten.
Trennen Sie Sponsorship und Administration
Wer einen Agenten verändern kann, kann nicht automatisch seine Existenz begründen.
Der Technical Owner pflegt Konfiguration und untersucht Incidents. Der Business Sponsor entscheidet, ob das Ergebnis relevant bleibt, der Zugriff verhältnismässig ist und der Agent verbessert, pausiert oder beendet werden soll.
Beide Rollen verhindern zwei bekannte Fehler: das Business-Experiment ohne operativen Unterhalt und den technisch gepflegten Agenten ohne echten Value Owner.
Geben Sie Zugriff einen Zeithorizont
Menschlicher Zugriff wird zunehmend geprüft, genehmigt und befristet. Agentenzugriff verdient dieselbe Disziplin.
Berechtigungen folgen dem Zweck und werden überprüft, wenn Workflow, Tools, Modell oder Zielgruppe wechseln. Befristeter Zugriff ist für Experimente besonders wertvoll. Fortsetzung wird zur Entscheidung statt zum Default.
Ein Ablaufdatum bedeutet nicht zwingend, dass der Agent an diesem Tag stoppt. Es bedeutet, dass jemand neue Evidenz für Zugriff und Betrieb liefern muss.
Planen Sie den Rückbau vor dem Deployment
Ein Agent ist nicht ausgemustert, wenn sein Chat-Eintrag verschwindet.
Retirement kann bedeuten: Identität deaktivieren, Rechte entziehen, Infrastruktur stoppen, Trigger entfernen, Audit-Evidenz bewahren, Nutzer umleiten und abhängige Workflows identifizieren.
Kann das Team diesen Weg nicht beschreiben, versteht es den operativen Fussabdruck noch nicht.
Gesundes Retirement ist kein Scheitern. Es verhindert, dass inaktive Agenten, veraltetes Wissen und unnötige Berechtigungen zum dauerhaften Hintergrundrisiko werden.
Der stärkste Einwand: «Das bremst Experimente»
Es bremst Experimente, die unsichtbare Ownership und unkontrollierten Zugriff benötigen. Das ist nützliche Reibung.
Für persönliche Exploration bleibt der Eintrag leicht. Mit Reichweite, Datensensitivität und Autonomie wachsen Identity- und Lifecycle-Anforderungen. Das Ziel ist kein schwerer Einheitsprozess, sondern ein vorhersehbarer Weg von Exploration zu Enterprise Operation.
Der nächste praktische Schritt
Listen Sie alle auffindbaren Agenten Ihrer Organisation auf. Ergänzen Sie vier Spalten: Identität, Sponsor, letzter Evidenzreview und Ablaufdatum.
Beginnen Sie nicht mit einem neuen Dashboard. Wählen Sie die fünf Agenten mit dem breitesten Zugriff oder grössten Publikum und schliessen Sie zuerst deren Ownership-Lücken.
Ein Agent wird governable, wenn die Organisation erkennt, wer er ist, warum er existiert, was er darf und wann er sich das Recht auf Fortsetzung neu verdienen muss.
English edition: Every Agent Needs an Identity, an Owner and an Expiry Date
Quellen und Einordnung
- Microsoft Agent 365 Overview
- Microsoft Entra und Agent 365
- Microsoft-Leitfaden zum Agent Lifecycle
- Microsoft Entra: Owner und Sponsoren von Agentenidentitäten
Redaktioneller Hinweis: Produktfunktionen und Lizenzierung verändern sich. Prüfen Sie vor der Umsetzung die aktuelle Microsoft-Dokumentation.
