Inventur vor Governance

Die Reihenfolge, in der Organisationen Agent-Governance angehen, ist fast immer verkehrt herum. Erst kommt eine Richtlinie, dann ein Freigabeprozess, dann ein Gremium. Und dann stellt jemand die Frage, mit der man hätte anfangen müssen: Wie viele Agents laufen bei uns eigentlich?

Diese Depesche ist ein Nachschlagewerk zur Inventur. Oben steht das Datum der letzten Prüfung.

Warum zuerst gezählt wird

Eine Richtlinie ohne Inventar regelt die Agents, die noch gebaut werden. Die, die schon laufen, berührt sie nicht. Und die sind das Problem, denn sie sind ohne Regeln entstanden, in einer Zeit, in der niemand hingesehen hat.

Dazu kommt ein politischer Effekt, den ich in jedem Projekt beobachte: Eine Zahl verändert die Diskussion. Solange über Agent-Governance abstrakt gesprochen wird, ist es eine Position auf einer Roadmap. Sobald eine Liste mit 140 Einträgen auf dem Tisch liegt, von denen 60 keinen erkennbaren Besitzer haben, ist es ein Thema mit Termin.

Die Klassen, in denen ich zähle

Nicht jeder Agent braucht dasselbe Maß an Kontrolle. Das Risiko hängt an der Autonomie, und ich sortiere in drei Stufen.

Grün: interaktiv. Der Agent antwortet, wenn jemand ihn fragt, greift auf Wissen zu, tut nichts von sich aus. Ein FAQ-Agent auf einer SharePoint-Bibliothek. Hier reicht Sichtbarkeit.

Gelb: handelnd. Der Agent schreibt in Systeme, ruft Connectoren auf, verschickt etwas. Er tut es noch auf Anstoß, aber die Folgen verlassen den Chat. Hier brauchst du Besitzer, Berechtigungsprüfung und Protokollierung.

Rot: autonom. Der Agent läuft nach Zeitplan oder auf Ereignis, greift auf sensible Daten zu, ruft externe APIs auf, delegiert an andere Agents. Hier brauchst du alles: Identität, Conditional Access, DLP, Nachweisführung, benannte Verantwortung.

Die meisten Organisationen sind heute überwiegend grün. Der Sprung passiert leise: In dem Moment, in dem jemand einen Zeitplan einstellt oder einen Connector hinzufügt, wandert ein Agent von grün nach gelb oder rot, ohne dass jemand eine Entscheidung getroffen hätte. Genau diesen Übergang solltest du sichtbar machen.

Wo du tatsächlich nachsiehst

Es gibt keine einzelne Stelle, an der alles steht. Es sind mindestens sechs.

Copilot Studio. Seit Mai 2026 gibt es ein Agent-Inventarschema, mit dem sich alle Copilot-Studio-Agents einer Organisation entdecken und auditieren lassen, aus dem Admin Center, über die API oder über Azure Resource Graph. Der Weg über Azure Resource Graph ist der interessante, weil er sich abfragen und in einen Report schreiben lässt statt in einem Portal zu leben.

Microsoft 365 Copilot. Agents, die Nutzer im Agent Builder gebaut haben. Die tauchen bei den meisten in keiner Liste auf, weil sie nie als Software wahrgenommen wurden.

Agent 365. Die Registry als übergreifendes Inventar, dazu Defender for Agents für die Erkennung von Schatten-KI. Fremde Plattformen wie AWS Bedrock AgentCore und Google Gemini Enterprise sind über Registry-Sync in der Preview dabei, allerdings ohne Durchsetzung zur Laufzeit.

Microsoft Foundry. Agents in Foundry-Projekten, hosted agents, Routinen mit Zeitplan. Die Ansprechpartner sitzen hier meist in der Entwicklung und nicht im Modern-Work-Team, weshalb diese Liste in Governance-Projekten regelmäßig vergessen wird.

Power Platform. Agent Flows, Flows mit KI-Aktionen, Prompts im Prompt Builder. Formal keine Agents, praktisch dieselbe Frage: Was passiert automatisch, mit welchen Rechten?

Alles außerhalb. Ein Skript mit einem API-Schlüssel auf einem Rechner in der Fachabteilung. Ein Zapier-ähnlicher Dienst mit einem Konto, das jemand vor zwei Jahren angelegt hat. Diese Liste findest du nicht per Werkzeug, sondern per Gespräch.

Die Felder, die eine Zeile braucht

Halte es schmal genug, dass es jemand tatsächlich ausfüllt.

Die Zeile "Mitgeführte Zugänge" ist die, die Werkzeuge dir nicht füllen. Agent 365 regelt, wer der Agent ist. Was er an nachgelagerten Grants, Schlüsseln und Secrets mit sich führt, liegt außerhalb dieses Rahmens und damit in deiner Verantwortung.

Die Zeile "Letzte Nutzung" ist die, die am meisten bewirkt. In jeder Inventur, die ich begleitet habe, war ein erheblicher Teil der gefundenen Agents seit Monaten unbenutzt. Abschalten ist die günstigste Governance-Maßnahme, die es gibt.

Der Ablauf

1. Technische Erfassung aus Copilot Studio, Agent 365, Foundry und Power Platform. Das ist ein Nachmittag, wenn die Zugänge da sind.
2. Besitzer zuordnen. Alles ohne Besitzer bekommt eine Frist, danach wird es deaktiviert, nicht gelöscht. Deaktivieren ist reversibel und erzeugt genau die Rückmeldung, die du brauchst: Wer sich meldet, ist der Besitzer.
3. Klassifizieren in grün, gelb, rot. Zu zweit, nicht allein.
4. Aufräumen. Unbenutzt und ohne Besitzer wird abgeschaltet. Das schrumpft die Liste oft um ein Drittel.
5. Erst jetzt regeln. Die Richtlinie, die du jetzt schreibst, kennt die Realität und passt darauf.
6. Wiederholen. Quartalsweise, mit derselben Abfrage. Eine Inventur, die einmal stattfindet, ist eine Momentaufnahme, keine Kontrolle.

Die Fragen, an denen ich einen Reifegrad ablese

Vier Fragen, und wer sie ohne Zögern beantworten kann, ist weiter als die meisten:

• Kannst du sagen, wie viele Agents in eurem Tenant laufen?
• Hat jeder davon eine benannte Person als Besitzer?
• Weißt du, welche davon ohne menschlichen Anstoß handeln?
• Weißt du, welche Zugangsdaten sie mit sich führen?

Die vierte Frage ist die, bei der es fast immer still wird.

Der ehrliche Nachsatz

Eine Inventur ist unspektakulär. Sie ist keine Demo, sie macht sich schlecht auf einer Folie, und niemand wird dafür befördert.

Sie ist trotzdem die einzige Maßnahme dieser Liste, die ohne Lizenzentscheidung, ohne Projekt und ohne Freigabe funktioniert. Du kannst am Montag damit anfangen. Alles andere in der Agent-Governance setzt voraus, dass sie existiert.

Quellen

• Use the agent inventory schema, Microsoft Learn, zur Erfassung über Admin Center, API und Azure Resource Graph
• What is Microsoft Entra Agent ID?, Microsoft Learn
• Protect agent identities with Microsoft Entra, Microsoft Learn
• Agent 365 und Entra Agent ID im Vergleich, Oasis Security, 3. Juni 2026, Sekundärquelle zu Abdeckungsgrenzen, Altbestand und Registry-Sync für fremde Plattformen
• Agent 365 Security Guide, 18. Juni 2026, Sekundärquelle zur Risikoeinteilung nach Autonomiegrad