Agent-Lebenszyklus: So bekommst du deine Agents in den Griff

Agents sind Software und brauchen dieselben Pflichten wie jede andere Anwendung: einen Owner, Tests, eine Freigabe, Betrieb und ein geplantes Ende. Ein Lebenszyklus in sechs Phasen, von Entstehen bis Stilllegen, ordnet das.

Er beantwortet die drei Fragen, die in fast jedem Tenant offen sind: Welche Agents habt ihr eigentlich? Wem gehören sie? Und dürfen sie, was sie tun? Um genau diese Fragen ging es in meiner Session auf dem M365 Summit Mainz. Die vollständigen Folien findest du auf der Seite zur Session.

Warum ist ein Agent eine eigene Software?

Agents sind Custom Apps. Sie werden schneller gebaut als klassische Anwendungen, und sie werden von viel mehr Menschen gebaut. Die Pflichten bleiben trotzdem dieselben wie bei jeder anderen Anwendung im Unternehmen:

• Verantwortung: ein Owner, der zuständig bleibt.
• Anforderungen: Zweck, Zielgruppe, Daten, Kosten.
• Tests: Qualität und Sicherheit vor dem Go-live.
• Freigabe: ein Gate, das zum Risiko passt.
• Betrieb: Inventar, Nutzung, Kosten.
• Stilllegung: ein geplantes Ende statt Wildwuchs.

Dazu kommt, dass Agents heute auf fünf Wegen entstehen, und jeder braucht eine eigene Antwort. Agent Builder steht allen Mitarbeitenden offen, SharePoint-Agents allen mit Bearbeitungsrechten auf der Site; hier geht es weniger ums Begrenzen als ums Teilen, die Wissensquellen und Oversharing. In Copilot Studio greifen Managed Environments und Connector-DLP der Power Platform. Für Microsoft Foundry gilt: immer projektbasiert, Ressourcen nur per Antrag, dazu Azure-Governance. Bei persönlichen Agents wie Copilot Cowork ist die Frage, wer Zugriff bekommt und welche Plugins und MCP-Server erlaubt sind. Und bei Partner-Agents entscheidet die Freigabe je Publisher-Typ. Agent Governance heißt: jede Plattform im Griff haben und trotzdem plattformübergreifend handeln.

Welche Phasen hat der Lebenszyklus eines Agents?

Der Lebenszyklus ordnet alles, was mit einem Agent passiert, in sechs Phasen. Jede hat eine Leitfrage:

Vier Dinge laufen über alle Phasen mit: die Einstufung, die Ownership, die Kosten und die Richtlinien. Wer einen Agent weiterentwickelt, geht zurück in Phase 2. Und ein Gremium schaut regelmäßig auf den Prozess selbst und schärft Regeln, Fristen und Schwellen nach.

Bevor jemand baut, helfen sieben Fragen: Welches Problem lösen wir, und für wen? Welche Schritte, Entscheidungen und Übergaben gibt es? Was startet den Prozess, eine Person, ein Ereignis oder ein Zeitplan? Welche Daten braucht es, und wer darf zugreifen? Was ist der kleinste Schritt, der sofort hilft? Wer liefert fachlichen Kontext, wer technische Expertise? Und wird der Agent einmal eingerichtet oder dauerhaft betrieben?

Wie viel Prüfung braucht ein Agent?

Der wichtigste Hebel ist eine Einstufung, das Agent-Tiering. Ohne sie behandelst du einen persönlichen Helfer genauso wie einen Agent, der einen Geschäftsprozess ersetzt. Dann erstickt entweder die Governance an Kleinkram, oder sie lässt das Kritische durch. Ein Beispiel für vier Stufen:

• Persönlich: ein Nutzer, eigene Produktivität. Kommt nie in den Katalog, kein Review.
• Team: Produktivität im Team, team-owned. Kandidat für den Katalog, wenn er geteilt wird. Review jährlich, optional.
• Business Important: die Grauzone zwischen Fachbereich und IT. Ausdrückliche Ownership und ein Business Sponsor. Review halbjährlich.
• Business Critical: automatisiert oder ersetzt einen Geschäftsprozess. IT-owned, Security Review ist Pflicht. Review quartalsweise.

Dazu kommen Vorlagen: persönliche Agents zum Kopieren, ohne eigenen Lebenszyklus. Mein Tipp: Nutzt euer bestehendes Klassifizierungsschema, statt ein neues zu erfinden. Oder kürzer: Ein Team-Agent braucht fünf Felder, kein Gremium.

An der Stufe hängen auch die Tests. Persönliche und Team-Agents reicht ein Selbsttest mit Checkliste, nur mit eigenen oder Team-Daten, ohne Freigabe. Ab Business Important gibt es Testfälle für die Kernfragen, ein Peer-Review von Anweisungen und Wissen und eine Prüfung des Datenzugriffs. Business Critical braucht Evaluation mit Testsets, einen Stresstest, Versuche, den Agent zu brechen, und ein Security Review. Wirkt ein Agent nach außen, kommen Tests gegen Prompt Injection und Missbrauch und eine Rechts- und Datenschutzprüfung dazu. Beim Bauen gilt für alle Stufen Least Privilege: nur die Wissensquellen, die der Agent braucht, nur die Tools, die er braucht, und eine eigene Identität statt der des Erstellers.

Wer gibt einen Agent frei?

Zwei Freigabe-Gates parallel machen eines zur Dekoration. Die eingebaute Freigabe im Microsoft 365 Admin Center kennt weder Business Case noch Risiko. Deshalb funktioniert es besser nacheinander:

1. Pilot im kleinen Kreis. Der Owner teilt mit einer Pilotgruppe, ohne Admin. Das ist das Fenster, in dem die Governance-Daten ergänzt werden.
2. Interner Check. Eine Prozesskontrolle, kein technischer Riegel. Sie wird als Richtlinie festgeschrieben.
3. Org-weit veröffentlichen. Die Einreichung im Admin Center, begleitet von der Person, die den Katalog pflegt. Die eingebaute Freigabe wird so zur Formalität.

Damit das hält, muss eine Bedingung stimmen: Wer im Admin Center Veröffentlichungsanfragen freigibt, ist an den Governance-Prozess gekoppelt.

Warum reicht das Agent-Inventar nicht?

In Phase 4 kommt die Frage, was überhaupt läuft. Das Agent Registry in Agent 365 liefert dafür viel: Name, Plattform, Publisher, Status, Version, Kanäle, den technischen Owner, falls gesetzt, die Anweisungen, aktive Nutzer und Sessions, Freigaben und den Zugriff auf SharePoint und OneDrive. Was es nicht weiß, muss ein Mensch bestätigen: wer verantwortlich ist, wer als Business Sponsor zahlt, wofür der Agent da ist, wie kritisch er ist, wie sensibel seine Daten sind, ob er autonom handelt, was bei einem Ausfall passiert, wie viele Menschen ihn nutzen sollen und wann das nächste Review ansteht.

Kurz: Die Registry zeigt, was existiert. Ob ein Agent existieren sollte und wer dafür geradesteht, weiß nur ein Mensch.

Das fängt beim Owner-Feld an. Es ist oft leer oder nennt nur die Person, die den Agent angelegt hat. Der technische Ersteller ist aber nicht automatisch verantwortlich. Dagegen helfen klare Rollen: ein bestätigter Owner für den Alltag, ein Business Sponsor ab Business Important, der Budget und Lizenz trägt, eine Kuratorin oder ein Kurator für Katalog und Governance-Aktionen, Security und Compliance für alles Kritische und alles mit Personendaten, und eine Gruppe, die über Einstufungen entscheidet und sofort sperren kann. Das Prinzip dahinter: Jede Rolle ist eine Person oder ein Gremium mit Namen, kein Postfach. Microsoft Entra Agent ID verlangt für jede Agent-Identität einen Sponsor, verknüpft das also am besten mit eurem Rollenmodell.

Woran merkst du, ob ein Agent noch gebraucht wird?

Phase 5 und 6 entscheiden, ob dein Inventar in einem Jahr noch stimmt. Statt zu hoffen, dass Owner ihre Agents pflegen, legst du fest, was in typischen Situationen passiert:

Vieles davon geht mit Bordmitteln. Im Admin Center gibt es Regeln, die verwaiste Agent-Builder-Agents an die Führungskraft übergeben oder ungenutzte verwaiste Agents sperren. Und mit einem Lifecycle-Workflow in Microsoft Entra ID Governance lässt sich die Sponsorschaft einer Agent-Identität an die Führungskraft übertragen, wenn der Sponsor geht. Diesen Workflow muss jemand einrichten; er setzt Microsoft 365 E7 voraus oder Agent 365 zusammen mit mindestens Entra P1 oder Microsoft 365 E3.

Für alles andere gilt: Push schlägt Pull. Owner werden aktiv in Teams abgeholt, mit einer Karte im Chat statt einem weiteren Portal, und mit klaren Fristen. Ein möglicher Ablauf ist Anfrage, Erinnerung, letzte Warnung und dann die Sperre über Agent 365, zum Beispiel nach zwei, vier und fünf Wochen. Drei Bauregeln gehören dazu: Die Fristen sind Konfiguration, nicht Richtlinie, jede Organisation stellt sie selbst ein. Eine erneut gesendete Karte verlängert die Frist nie. Und vor jedem Schreiben wird der Datensatz geprüft, sodass doppelte Karten keinen Schaden anrichten.

Und noch ein Punkt gehört in die Planung: Jeder dieser Prozesse endet bei einem Menschen, der etwas prüfen muss. Kapazität ist der echte Engpass. Plane die Person, die den Katalog pflegt, mit Namen, Vertretung und Zeit pro Woche ein.

Was du nächste Woche in deinem Tenant tun kannst

Die ersten fünf Schritte sind reine Bordmittel, die letzten drei sind Entscheidungen:

1. Inventar ziehen: Microsoft 365 Admin Center → Agents → All agents → Export.
2. Verwaiste Agents finden: die Karte „Agents without owners“ und eine Regel zur Neuzuweisung an die Führungskraft.
3. Zugriff steuern: unter Agents → Settings die Bereiche User access, Sharing sowie Agent and plugin access.
4. Oversharing sichtbar machen: die Data access governance reports im SharePoint Admin Center unter Reports. Sie gehören zu SharePoint Advanced Management, das in Microsoft 365 Copilot enthalten ist oder einzeln dazugekauft wird.
5. Kosten begrenzen: eine Abrechnungsrichtlinie mit Budget und Alerts. Ein Budget allein stoppt die Nutzung nicht, es warnt nur. Für Copilot-Studio-Agents gibt es zusätzlich Limits je Agent im Power Platform Admin Center.
6. Stufenmodell festlegen: die bestehende Klassifizierung wiederverwenden.
7. Kurator benennen: Name, Vertretung, Kapazität pro Woche.
8. Betriebsrat und Datenschutz informieren, bevor die erste Eskalation läuft.

Und denk daran, dass es nicht bei Agents bleibt: Plugins, Connectoren, eigene APIs und MCP-Server brauchen dasselbe, nämlich Inventar, Ownership, Freigabe und einen Lebenszyklus. Der erste Hebel ist heute schon da, denn im Admin Center legst du fest, welche Agents und Plugins in eurer Organisation überhaupt erlaubt sind.

Am Anfang dieses Lebenszyklus steht die Idee: Ob sie in Copilot Studio machbar ist, kannst du vor dem Bau kostenlos prüfen lassen.

Wenn ihr diesen Lebenszyklus für euren eigenen Tenant aufsetzen wollt, vom Stufenmodell bis zur ersten Regel im Admin Center, ist das genau die Arbeit im Coaching für IT und Admins.

Stand: Oktober 2026. Viele der Agent-Funktionen im Admin Center und in Entra ändern sich gerade schnell; welche davon eure Lizenzen abdecken, prüfst du am besten vorab in den verlinkten Seiten.

Quellen: eigene Session „Copilot Agent Management“, M365 Summit Mainz, Oktober 2026; Microsoft – Manage agent registry in Microsoft 365 admin center, Agent settings in Microsoft 365 admin center, Governance and lifecycle actions for agents, Owners, sponsors, and managers in Microsoft Entra Agent ID, Create a budget for pay-as-you-go billing, Manage costs for agents powered by the GitHub Copilot harness, Agent identity sponsor tasks in Lifecycle Workflows, Data access governance reports