Microsoft Entra Agent ID on DR.365

Agent-Governance zur Laufzeit: Mit wessen Rechten handelt ein delegierter Agent?

Sat, 17 Oct 2026 07:00:00 +0200

Ein Mitarbeiter fragt den HR-Agent im Intranet, wie viele Urlaubstage ihm noch zustehen. Der HR-Agent kennt die Urlaubsrichtlinie, aber keine Zahlen. Also gibt er die Frage an einen verbundenen Payroll-Agent weiter, den ein anderes Team gebaut hat. Der Payroll-Agent fragt das Personalsystem über einen Konnektor ab. Eingerichtet ist dieser Konnektor mit dem Konto der Person, die den Payroll-Agent gebaut hat, und diese Person darf die Daten aller Mitarbeitenden lesen. Ob die Antwort nur die eigenen Urlaubstage enthält oder auch die eines Kollegen, entscheidet jetzt das Sprachmodell.

Formal ist dabei alles in Ordnung. Beide Agents haben einen Owner, beide sind registriert und freigegeben. Die Frage, mit wessen Rechten der zweite Agent handelt, stellt sich erst im Moment des Aufrufs. Um diesen Moment geht es in diesem Artikel.

Entwurfszeit und Laufzeit

In Teil 2 ging es um Governance zur Entwurfszeit: drei Zonen, sieben Phasen, ein Owner pro Agent und die Entscheidung Go, Change, Hold oder Stop. Diese Entscheidungen fallen einmal, bevor ein Agent in Produktion geht.

Zur Laufzeit entscheidet der Agent bei jeder Anfrage neu, welches Tool er aufruft, welchen anderen Agent er einbindet und welche Daten er dabei weitergibt. Diese Entscheidungen trifft ein Sprachmodell. Governance zur Laufzeit heißt für mich, dass Identität, Richtlinie, Autorisierung und Protokollierung an jedem dieser Übergänge greifen, egal was das Modell vorschlägt.

Teil 1 ordnet die Werkzeuge drei Modellen zu: Bei Agent Builder trägt die Plattform das Risiko, bei Copilot Studio der Administrator, bei Foundry die Organisation. Zur Laufzeit wird diese Zuordnung konkret, und an manchen Stellen verschiebt sie sich. Agent-Builder-Agents rufen keine externen Dienste auf, ihr Laufzeitrisiko sind die Berechtigungen des Benutzers. In Copilot Studio entsteht Verantwortung an jedem einzelnen Tool. Wer dort Maker-Anmeldeinformationen einträgt, holt sich einen Teil des Risikos vom Administrator auf den eigenen Tisch. Bei Foundry baut die Organisation die Kontrollen selbst, etwa Guardrails, die Tool-Aufrufe und Tool-Antworten prüfen (Preview) (Microsoft Learn). Dieser Beitrag konzentriert sich auf Copilot Studio, weil sich dort die meisten Übergänge konfigurieren lassen.

Die Anmeldung am ersten Agent reicht nicht

Dass sich ein Benutzer am HR-Agent angemeldet hat, sagt nichts darüber, was der Payroll-Agent zwei Schritte weiter darf. Die Identität des Benutzers muss bis zum Fachsystem mitgehen. In Copilot Studio legt das jedes Tool einzeln fest: Es nutzt entweder die Anmeldeinformationen des Endbenutzers oder die des Makers. Standard ist der Endbenutzer, und der automatische Security-Scan warnt vor dem Veröffentlichen, wenn ein Maker das umstellt (Microsoft Learn).

Als Admin kann ich vom Maker bereitgestellte Anmeldeinformationen im Power Platform Admin Center pro Umgebung oder Umgebungsgruppe abschalten (Microsoft Learn). Dann läuft jede Aktion unter der Identität der Person, die gerade fragt. Das hat einen Preis: Autonome Agents, die per Zeitplan oder Ereignis ohne angemeldeten Benutzer starten, schlagen in solchen Umgebungen fehl. Ich würde die Einstellung deshalb in den Produktionsumgebungen für Zone 2 und 3 erzwingen und autonome Agents in eine eigene Umgebung mit eigenen Regeln legen.

In Entra heißt dasselbe Muster On-behalf-of. Der Agent tauscht das Token des Benutzers gegen ein neues, das für die Zielressource ausgestellt ist, und Conditional Access bewertet diesen Tausch (Microsoft Learn). Daneben hat der Agent eine eigene Identität. Neue Copilot-Studio-Agents erhalten seit Mai 2026 automatisch eine Microsoft Entra Agent ID, im Standard-Harness beim Anlegen, im GitHub-Copilot-Harness beim ersten Veröffentlichen. Ihr Owner wird dort als Sponsor eingetragen (Microsoft Learn).

Kontrollen gehören nicht in den Prompt

Welches Tool ein Agent als Nächstes aufruft, entscheidet das Modell, und diese Entscheidung lässt sich über eine präparierte E-Mail oder ein Dokument in der Wissensquelle beeinflussen. Eine Regel, die nur in den Anweisungen des Agents steht („Gib keine Gehaltsdaten heraus“), ist deshalb eine Bitte an das Modell. Durchsetzen lässt sie sich nur außerhalb davon.

Microsoft 365 hat dafür mehrere Ebenen. Datenrichtlinien im Power Platform Admin Center legen fest, welche Konnektoren ein Agent nutzen darf, und die Konnektor-Plattform prüft das bei jedem Aufruf erneut (Microsoft Learn). Conditional Access bewertet Tokens für Agent-Identitäten. Microsoft Defender kann Tool-Aufrufe von Copilot-Studio-Agents in Echtzeit prüfen und blockieren, derzeit als Preview (Microsoft Learn). Technisch fragt der Agent vor jedem Tool-Aufruf einen externen Dienst, ob er ausführen darf. Kommt innerhalb einer Sekunde keine Antwort, lässt Copilot Studio den Aufruf standardmäßig zu. In regulierten Umgebungen würde ich das Fehlerverhalten auf Blockieren stellen (Microsoft Learn).

Kontext bewusst begrenzen

Was ein Agent weitergibt, ist genauso wichtig wie das, was er abruft. Ein Child Agent bekommt in Copilot Studio immer den Kontext des Hauptagents. Bei einem verbundenen Agent lässt sich die Weitergabe des Gesprächsverlaufs abschalten, dann erhält er nur die konkrete Aufgabe (Microsoft Learn). Im Beispiel würde ich genau das tun. Der Payroll-Agent braucht die Frage nach den Urlaubstagen. Den Verlauf, in dem der Mitarbeiter vorher vielleicht von seiner Krankheit erzählt hat, braucht er nicht.

Auf der Datenseite greifen die bekannten Werkzeuge. Copilot Studio gibt nur Inhalte zurück, auf die der Benutzer selbst Zugriff hat. Bei Dateien, deren Sensitivity Label verschlüsselt, braucht er zusätzlich das Nutzungsrecht EXTRACT (Microsoft Learn). Dieser Schutz hängt aber daran, dass mit Benutzerrechten abgefragt wird. Ein Tool mit Maker-Anmeldeinformationen sieht, was der Maker sieht.

MCP-Server wie eine API behandeln

Das Model Context Protocol (MCP) regelt, wie ein Agent Tools findet und aufruft. Autorisierung ist in der Spezifikation ausdrücklich optional. Setzt ein Server sie um, arbeitet er als OAuth-2.1-Resource-Server: Er muss prüfen, dass ein Token für ihn ausgestellt wurde, und darf fremde Tokens weder annehmen noch weiterreichen (MCP-Spezifikation). Ob ein Server das tut, steht in seinem Code. Ich behandle jeden MCP-Server deshalb wie die API eines Drittanbieters und kläre, wer ihn betreibt, welche Daten er sieht, wie er authentifiziert und wer ihn freigibt.

Copilot Studio bindet MCP-Server über einen Assistenten an, mit den Optionen keine Authentifizierung, API-Key oder OAuth 2.0. Weil der Zugriff technisch über Power-Platform-Konnektoren läuft, gelten die Datenrichtlinien auch für MCP-Server (Microsoft Learn). Mit Agent 365 kommt eine zweite Ebene dazu. Im Microsoft 365 Admin Center unter Agents > Tools lassen sich MCP-Server für die ganze Organisation sperren. Bei unterstützten Servern lassen sich auch einzelne Tools abschalten, etwa Schreib- und Löschfunktionen, während Lesefunktionen erlaubt bleiben. Diese Granularität wird gerade ausgerollt und vom Agent 365 Tooling Gateway zur Laufzeit durchgesetzt (Microsoft Learn).

Die Control Plane: Registry, Identität, Schutz, Audit

Die bisher genannten Werkzeuge verteilen sich auf mehrere Portale. Zusammengeführt werden sie in der Agent Registry im Microsoft 365 Admin Center. Agent 365 ist seit 1. Mai 2026 allgemein verfügbar und wird pro Benutzer lizenziert (Microsoft Learn). Die Registry zeigt Agents aller Plattformen, auch die in Entra registrierten, und bündelt mit passender Lizenz die Risikosignale aus Purview, Entra und Defender pro Agent (Microsoft Learn).

Entra Agent ID liefert die Identität mit Sponsor, Conditional Access und ID Protection für Agents. Purview protokolliert Prompts und Antworten im Unified Audit Log und zeigt sie in DSPM for AI. Für Agent 365 umfasst das ausdrücklich auch Interaktionen zwischen Agent und Tool sowie zwischen Agents (Microsoft Learn). Bei der Lizenzplanung lohnt ein genauer Blick: Conditional Access für Agents setzt Microsoft 365 E7 voraus oder Agent 365 zusammen mit mindestens Entra ID P1 bzw. Microsoft 365 E3 (Microsoft Learn). Lizenzbedingungen ändern sich oft, die aktuelle Fassung gehört vor jeden Rollout.

Delegation ohne automatische Rechtevererbung

Zurück zum Payroll-Agent. Microsoft schreibt in den eigenen Mustern für Multi-Agent-Lösungen, dass ein verbundener Agent Zugriff auf Dinge haben kann, die der Hauptagent nicht hat, und dass solche Aufrufe wie jede andere mächtige Aktion zu behandeln sind (Microsoft Learn). Ich leite daraus drei Regeln ab.

Erstens nutzen alle Tools in verbundenen Agents Endbenutzer-Anmeldeinformationen, solange es keinen dokumentierten Grund dagegen gibt. Zweitens bleibt die Einstellung „Let other agents connect to and use this one“ aus, wenn ein Agent nicht ausdrücklich als Baustein gedacht ist. Standardmäßig darf sich jeder Agent in derselben Umgebung mit ihm verbinden (Microsoft Learn). Drittens bekommen Agents mit eigener Identität ihre Berechtigungen über Access Packages mit Ablaufdatum. Der Sponsor wird vor dem Ablauf benachrichtigt und muss eine Verlängerung aktiv beantragen. Diese Funktion ist noch in der Preview (Microsoft Learn).

Menschliche Freigabe bei hoher Auswirkung

Manche Aktionen sollte kein Agent allein ausführen, zum Beispiel Zahlungen, Änderungen an Stammdaten, das Löschen von Datensätzen oder Berechtigungsänderungen. Agent Flows in Copilot Studio bringen dafür Human-in-the-Loop-Aktionen mit, also Genehmigungen und Rückfragen an Menschen (Microsoft Learn). Mehrstufige Genehmigungen kombinieren manuelle Stufen mit KI-Stufen und Bedingungen dazwischen, sind aber noch in der Preview (Microsoft Learn). Eine KI-Stufe kann Routinefälle vorsortieren. Bei Aktionen mit hoher Auswirkung würde ich am Ende immer eine menschliche Stufe setzen, damit die Entscheidung einer Person zugeordnet ist.

Entscheidend ist, wo die Freigabe sitzt. Sie gehört in den Flow, der die Aktion ausführt. Steht sie nur in den Anweisungen des Agents, entscheidet wieder das Modell, ob es überhaupt fragt.

Was das für regulierte Umgebungen heißt

Wer in Deutschland unter NIS2 fällt, muss nach § 30 BSIG unter anderem Konzepte für die Zugriffskontrolle erstellen und Lösungen zur Multi-Faktor- oder kontinuierlichen Authentifizierung einsetzen (§ 30 BSIG). Agents nennt das Gesetz nicht. Ich sehe aber keinen Grund, einen Agent, der im Personalsystem liest, anders zu behandeln als ein Dienstkonto, das dasselbe tut. Das ist meine fachliche Einschätzung und keine Rechtsberatung.

Für die Nachvollziehbarkeit muss sich bei jeder Aktion klären lassen, welcher Benutzer sie ausgelöst hat, welche Agents beteiligt waren und unter welcher Identität das Fachsystem angesprochen wurde. Das Unified Audit Log liefert einen großen Teil davon. Bei verbundenen Agents entstehen allerdings getrennte Transkripte, die erst über Kennungen in der Telemetrie zusammenfinden (Microsoft Learn). Wer im Ernstfall schnell berichten muss, sollte diese Abfrage vorher einmal gebaut haben.

Für die Rezertifizierung gehören Agent-Identitäten in denselben Review-Zyklus wie Dienstkonten. Sponsor und Access Packages mit Ablaufdatum machen das in Entra möglich, ohne dass jemand eine Excel-Liste pflegt.

Mit einem Dienstleister kommt eine Frage dazu: Wer betreibt die Laufzeitkontrollen? Datenrichtlinien, Conditional Access für Agents und Regeln im Defender-Echtzeitschutz liegen oft beim Dienstleister, die Genehmigungen in Agent Flows beim Fachbereich des Kunden. Defender kann zum Beispiel einen Tool-Aufruf blockieren, der eine E-Mail an eine unsichere Domain schicken würde (Microsoft Learn). Wer die zugehörige Warnung nachts sieht und wer den Agent daraufhin sperren darf, muss vorher feststehen. Die Verwaltung über mehrere Tenants im Microsoft 365 Admin Center (Preview) macht das Sperren über Tenant-Grenzen hinweg technisch einfach (Microsoft Learn). Die Befugnis dazu gehört in den Vertrag.

Wo Microsoft heute noch Lücken hat

Conditional Access auf die Agent-Identität wird derzeit nur ausgewertet, wenn ein Copilot-Studio-Agent in Microsoft Teams läuft. Andere Kanäle rufen Konnektoren weiter über den bisherigen Power-Platform-Weg auf (Microsoft Learn). Dazu kommt: Custom Connectors, MCP-Server und REST-Tools tragen keine Berechtigungen an der Agent ID ein. Ausgerechnet bei MCP bleibt die Sicht in Entra also unvollständig. Agents aus dem Agent Builder bekommen gar keine Agent ID.

Wie die Identität zwischen Hauptagent und verbundenem Agent technisch weitergegeben wird, beschreibt die Dokumentation nicht. Für den Standard-Harness heißt es nur, dass man den verbundenen Agent je nach Authentifizierung zusätzlich mit den Endbenutzern teilen muss. Bevor ich mich darauf verlasse, würde ich das im eigenen Tenant testen. Außerdem sind mehrere der genannten Laufzeitkontrollen noch Preview oder im Rollout, darunter der Defender-Echtzeitschutz für Copilot Studio, mehrstufige Genehmigungen und die Sperre einzelner MCP-Tools.

Fünf Dinge, die du morgen prüfen kannst

Prüfe im Power Platform Admin Center, ob in deinen Produktionsumgebungen vom Maker bereitgestellte Anmeldeinformationen erlaubt sind. Das Agent-Inventar zeigt im Feld connectionProvider (Preview), welche Konnektor-Aktionen sie nutzen.
Liste für deinen wichtigsten Agent alle verbundenen Agents und Child Agents auf und kläre für jeden, ob er den Gesprächsverlauf erhält.
Öffne im Microsoft 365 Admin Center unter Agents > Tools die Liste der MCP-Server und sperre alles, dessen Betreiber du nicht kennst.
Prüfe im Microsoft Entra Admin Center, ob jede Agent-Identität einen Sponsor hat.
Such dir eine Aktion mit hoher Auswirkung, die ein Agent heute ausführen kann, und setz eine Genehmigung in den Flow davor.

Gegen welche Regelwerke du Agent-Governance nachweisen musst und wer welche Nachweise liefert, beschreibe ich in Teil 4.

Quellen

Die Anregung zu diesem Artikel kam aus einem LinkedIn-Post von Rajeev Yadav.

Auf Menschentempo ausgelegt: Was Anthropics neue Versionskontrolle für die IT-Strategie bedeutet

Wed, 14 Oct 2026 07:00:00 +0200

Im Mai 2026 hat Anthropic rund 2.500 Code-Änderungen pro Tag in sein Monorepo gemergt. Im September waren es über 30.000. Git und die Mirror-Infrastruktur drumherum kamen nicht mehr hinterher, also hat ein Team aus sieben Leuten ein eigenes Versionskontrollsystem gebaut und das komplette Monorepo in fünf Monaten migriert (Anthropic Engineering).

Kaum jemand, der das hier liest, wird ein Versionskontrollsystem bauen. Darum geht es bei der Geschichte auch nicht. Jede Organisation hat Prozesse, die auf das Tempo von Menschen ausgelegt sind: Change Advisory Boards, Vier-Augen-Freigaben, Access Reviews, CI-Pipelines, Budgets in Personentagen. Sobald Agents einen großen Teil der Arbeit erledigen, werden genau diese Prozesse zum Engpass. Die Frage ist, welche davon du umbaust, bevor sie brechen.

Kurz gesagt

Agents werden zu den Hauptnutzern deiner Systeme. Architekturentscheidungen sollten von Maschinen-Clients ausgehen, die immer online sind und APIs in hoher Frequenz aufrufen.
Review und Freigabe müssen weg von „ein Mensch hat alles angesehen“ hin zu Regeln, die festlegen, wo ein Mensch hinsehen muss.
Jeder Agent braucht eine Identität, eine verantwortliche Person und eine Kostenstelle. Ohne diese drei kannst du Agentenarbeit weder steuern noch budgetieren.

Was Anthropic tatsächlich geändert hat

In den Schlagzeilen heißt es „Anthropic hat Git rausgeworfen“. Der Engineering-Beitrag selbst ist vorsichtiger. Das neue System heißt Scion, das Review-Werkzeug Antique. Anthropic schreibt ausdrücklich, dass Scion kein allgemeiner Ersatz für Git ist, weil dafür die gesamte Entwicklungs-Toolchain ersetzt werden müsste. Veröffentlicht wurde das Design, damit Git-Plattformen Teile davon übernehmen können.

Warum sie es trotzdem gemacht haben, zeigen die Zahlen. Die Historie des Main-Branch umfasst fast 100 GB, eine komprimierte Arbeitskopie über 25 GB, und die CI zieht rund 25 Millionen Checkouts pro Tag. Git ist für verteilte Clients gebaut, die offline arbeiten. Die Clients bei Anthropic sind fast ausschließlich Agents und Jobs, die immer online sind. Scion verlagert die teure Arbeit auf den Server: Commits, Merges, Rebases, Historie und Blame laufen dort, Clients bekommen schlanke, virtualisierte Checkouts, die Dateien bei Bedarf nachladen, und vieles ist per API ganz ohne lokales Repository nutzbar. Laut Beitrag braucht die neue Infrastruktur etwa 200-mal weniger CPU und Speicher als die alten Git-Mirrors, CI-Checkouts dauern Sekunden statt Minuten.

Drei Entscheidungen aus dem Beitrag sind über Versionskontrolle hinaus relevant:

Es gibt keine Merge Queue mit globalem Lock. Anthropic hat stattdessen in Tests nach dem Merge und vor dem Deployment investiert. Konflikte zwischen parallelen Änderungen kommen vor, und Claude behebt sie meist schneller, als ein Mensch sie bemerken würde.
Antique kann semantische Regeln für Freigaben abbilden. Eine Änderung nur an Kommentaren wird anders behandelt als eine Änderung an sensibler Logik, damit menschliche Reviewer ihre Zeit dort verbringen, wo es zählt.
Zugriffssteuerung auf Repository- und Verzeichnisebene war von Anfang an eingebaut, nicht nachträglich ergänzt.

Agents sind die neuen Hauptnutzer

Die erste Lehre betrifft die Architektur. Die meisten Unternehmenssysteme gehen von einem Menschen vor einem Bildschirm aus. Agents verhalten sich anders: Sie pollen, sie laufen parallel, und Mittagspause machen sie auch keine.

In Microsoft 365 sieht man das heute schon am Throttling von Microsoft Graph. Microsoft nennt zwei typische Ursachen: viele Anfragen über alle Anwendungen eines Tenants hinweg und viele Anfragen einer Anwendung über alle Tenants hinweg. Regelmäßiges Abfragen einer Ressource und wiederholtes Durchsuchen von Collections werden ausdrücklich als Muster genannt, die zu Throttling führen. Empfohlen werden stattdessen Delta Queries und Change Notifications, für große Datenmengen verweist Microsoft auf Graph Data Connect statt der REST-APIs (Microsoft Learn). SharePoint Online geht noch einen Schritt weiter: Eine Anwendung, die Limits dauerhaft überschreitet, kann komplett blockiert werden (Microsoft Learn).

Diese Hinweise wurden für Integrationsentwickler geschrieben. Inzwischen gelten sie für jeden Agent, der im Auftrag von jemandem Postfächer, Sites oder Teams-Kanäle liest. Wenn ich ein Agent-Szenario bewerte, frage ich deshalb zuerst, wie es Änderungen erkennt, und erst danach, was es tut. Ein Agent, der alle zehn Minuten eine Dokumentbibliothek komplett durchsucht, läuft im Pilot einwandfrei und wird zum Problem, wenn 40 Abteilungen ihn kopieren.

Für eigene Systeme gilt dasselbe in umgekehrter Richtung. Wenn Agents die Hauptnutzer einer internen Plattform werden, braucht sie eine ordentliche API, Change Feeds und Limits pro Client. Eine Weboberfläche mit einem Scraping-Agent davor ist der Git-Mirror deiner Organisation: Sie funktioniert, bis das Volumen sich verzehnfacht.

Review nach Absicht statt Zeile für Zeile

Die zweite Lehre betrifft Kontrollprozesse. Das Team bei Anthropic prüft weiterhin jede Änderung, aber es prüft die Absicht und nicht jede Zeile. Ihre wichtigste Aufgabe ist nach eigener Beschreibung, Claude „Nein“ zu sagen: wenn Systemgrenzen verletzt werden oder Claude wegen hypothetischer Bedenken überkonstruiert.

In regulierten Umgebungen ist das der unbequeme Teil. Viele Change-Prozesse versprechen implizit, dass eine qualifizierte Person alles geprüft hat. Bei 30.000 Änderungen am Tag lässt sich dieses Versprechen nicht halten, und ehrlich gesagt wurde es oft schon bei 30 pro Woche nicht gehalten. Das CAB, das in 45 Minuten einen Stapel Changes durchwinkt, prüft vor allem, ob das Formular vollständig ist.

Nach meiner Erfahrung wollen Auditoren Belege dafür sehen, dass Änderungen kontrolliert und nachvollziehbar sind. NIS2 verlangt Risikomanagementmaßnahmen, zu denen auch Sicherheit bei Entwicklung und Wartung gehört; dass ein Mensch jede Zeile liest, schreibt die Richtlinie nicht vor. Damit bleibt Raum für ein Modell, das ITIL als Standard Changes kennt, angewendet auf die Arbeit von Agents:

Geringes Risiko (Dokumentation, Tests, Formatierung, Konfiguration innerhalb definierter Leitplanken): automatische Prüfungen, kein verpflichtendes menschliches Review, vollständige Protokollierung.
Mittleres Risiko (Geschäftslogik, Integrationen): menschliches Review von Absicht und Testnachweisen, mit der Zusammenfassung des Agents als Grundlage.
Hohes Risiko (Authentifizierung, Berechtigungen, Datenflüsse über Vertrauensgrenzen, alles Regulierte): Review Zeile für Zeile durch eine benannte Person, wie bisher.

Was über die Stufe entscheidet, muss eine Regel sein und kein Bauchgefühl. Anthropic bildet das im Review-Werkzeug ab, du kannst es in Branch Protection Rules, CODEOWNERS-Dateien oder einem Genehmigungsflow in Power Automate abbilden. Die Regel selbst ist die Kontrolle, die ein Auditor sehen will.

Bei einem Teil des Anthropic-Ansatzes wäre ich vorsichtig: Prüfungen hinter den Merge zu verlegen. Für eine interne Entwicklerplattform ist das ein vertretbarer Tausch. Für ein System in einer KRITIS-Umgebung, bei dem eine fehlerhafte Änderung direkt in Produktion landen kann, würde ich das nicht machen. Die Absicherung muss vor dem Deployment sitzen, auch wenn sie nicht mehr vor dem Merge sitzt.

Jeder Agent braucht eine Identität und einen Verantwortlichen

Anthropic hat die Zugriffssteuerung in Scion vom ersten Tag an eingebaut, bis auf Verzeichnisebene. In Microsoft 365 entspricht dem die Identitätsschicht für Agents. Microsoft Entra Agent ID gibt Agents eigene Identitäten im Verzeichnis, erzeugt aus Agent Identity Blueprints. Jede Agent-Identität braucht einen menschlichen Sponsor, der für Zweck, Lebenszyklus und Access Reviews verantwortlich ist. Verlässt der Sponsor das Unternehmen, geht die Verantwortung auf seine Führungskraft über. Conditional Access und Access Packages aus dem Entitlement Management gelten auch für Agents (Microsoft Learn). Stand Oktober 2026 ist Identity Governance für Agents als Preview gekennzeichnet, und die Lizenzierung hängt an Microsoft 365 E7 oder Agent 365. Prüf die aktuellen Bedingungen, bevor du damit planst.

Darüber liegt in Microsoft Agent 365 die Registry als gemeinsames Inventar für Microsoft- und Fremd-Agents, inklusive der Anzahl an Agents ohne Besitzer (Microsoft Learn). Die Governance-Seite habe ich ausführlicher im Beitrag zum Agent Lifecycle beschrieben.

Strategisch heißt das: Ein Agent, der unter einem geteilten Dienstkonto oder mit den delegierten Rechten einer Person läuft, lässt sich im Audit-Log nicht unterscheiden, nicht separat drosseln und nicht separat abrechnen. Das später für Hunderte Agents nachzuziehen, ist genau die Art Projekt, für die niemand Budget freigibt.

Agentenarbeit messen

Beim Budget bricht es an derselben Stelle. Das Controlling rechnet in den meisten IT-Organisationen noch in Personentagen, und für Agentenarbeit gibt es in diesem Modell keine Zeile. Ein praktikabler Weg ist, Agent-Sitzungen über ein AI Gateway zu leiten. Dann lässt sich jedes Token und jede Stunde Laufzeit einem Projekt und einem Repository zuordnen und mit echten Preisen bewerten.

Ein Feature, das letztes Jahr 20 Tage gebraucht hat und dieses Jahr 3 Tage Review plus Agentenlaufzeit, passt nicht in dieses Modell. Agentenstunden zu zählen ist ein Anfang, aber Stunden sind eine Input-Kennzahl. Wissen willst du die Kosten pro akzeptierter Änderung: Tokens und Laufzeit plus die menschliche Zeit für Review, Nacharbeit und die Fälle, in denen jemand „Nein“ sagen musste. Ohne den menschlichen Anteil sieht Agentenarbeit billiger aus, als sie ist.

Für Microsoft-Agents sammelt die Observability in Agent 365 Aktivitätsdaten und soll Kennzahlen wie Nutzung und Zeitersparnis liefern (Microsoft Learn). Das deckt einen Teil des Bildes ab. Coding-Agents außerhalb von Microsoft 365 brauchen eine eigene Zuordnung, und dort kommt der Gateway-Ansatz ins Spiel.

Entscheidungen für die nächsten zwölf Monate

Anthropic erwartet, dass andere Organisationen in den nächsten sechs bis zwölf Monaten auf diese Art Problem stoßen. Auch wenn dein Zeitplan länger ist, diese Entscheidungen würde ich jetzt treffen:

Menschlich getaktete Kontrollen erfassen. Liste jede Freigabe, jedes Review und jeden Pipeline-Schritt auf, der von einer Person und einem Arbeitstag ausgeht. Markiere, was beim zehnfachen Volumen bricht.
Risikostufen für Änderungen einführen. Schreib auf, welche Änderungen einen Menschen brauchen, welche nur eine Prüfung der Absicht und welche nur Protokollierung. Mach die Regel maschinenlesbar.
Agents eigene Identitäten geben. Keine geteilten Dienstkonten, jeder Agent mit Sponsor, Berechtigungen über Access Packages mit Ablaufdatum.
Integrationen für Maschinen-Clients auslegen. Delta Queries, Change Notifications und API-Budgets statt Polling und Scraping.
Agentenkosten zuordnen. Tokens und Laufzeit pro Projekt plus die menschliche Review-Zeit, ab dem ersten produktiven Agent.

Was ich nicht tun würde: Anthropics Werkzeuge nachbauen. Deren Problem waren 25 Millionen Checkouts am Tag. Deins ist wahrscheinlicher ein Change-Prozess, der zwei Wochen für eine Konfigurationsänderung braucht, die ein Agent in zehn Minuten vorbereitet hat. Dort fängst du an.

Quellen

Anthropic Engineering: Redesigning source control at Anthropic (13. Oktober 2026)
Microsoft Learn: Microsoft Graph throttling guidance
Microsoft Learn: Avoid getting throttled or blocked in SharePoint Online
Microsoft Learn: Governing agent identities
Microsoft Learn: Manage agent registry in Microsoft 365 admin center
Microsoft Learn: Agent 365 observability
EUR-Lex: Richtlinie (EU) 2022/2555 (NIS2), Artikel 21

Welches Copilot-Feature für welche Aufgabe: eine Landkarte in vier Stufen mit Agent-Governance

Mon, 12 Oct 2026 07:00:00 +0200

Copilot Chat, Copilot in Word, Agent Builder, SharePoint-Agents, Copilot Studio, Cowork: Das ist nur die Liste für dieses Quartal. Jeden Monat kommt ein neuer Einstiegspunkt dazu, und jeder löst bei Anwendern und Stakeholdern dieselbe Frage aus: „Sollen wir jetzt also das hier nehmen?“ Um sie zu beantworten, musst du wissen, welches Werkzeug zu welcher Aufgabe passt, und dafür sorgen, dass die Agents von heute nicht die verwaisten Power-Automate-Flows von morgen werden.

Kurz gesagt

Denk Copilot in vier Stufen: Ad-hoc-Chat → Copilot in den Apps → Agents → Copilot Studio und Automatisierung im Cowork-Stil.

Vier Fragen entscheiden über die Stufe: Kommt es öfter als einmal pro Woche vor? Sind Quellen oder Tonalität immer gleich? Ist es regelbasiert? Sind mehrere Systeme und Freigaben beteiligt? Je mehr „Ja“, desto höher die Stufe.

Je höher die Stufe, desto mehr Governance. Eine Regel gilt aber überall: kein Agent ohne Owner. Stand Oktober 2026 zeigt dir die Agent-365-Registry im Microsoft 365 admin center, welchen Agents einer fehlt.

Kurz zu den Namen

Microsoft hat wieder umbenannt: Aus Microsoft 365 Copilot wird Microsoft Copilot, aus Microsoft 365 Copilot Chat wird Microsoft Copilot Chat, und die App zieht nach copilot.cloud.microsoft um. Lizenzen, Portale und Doku zeigen eine Weile beide Namen. Ich verwende im Folgenden die neuen. Wenn deine Anwender verwirrt sind, ist das ein Grund mehr, ihnen eine Landkarte statt einer Produktliste zu geben.

Die Landkarte: vier Stufen

Die Idee stammt aus der Session von Patrick Kelbch auf der M365 Con D-A-CH, und sie gefällt mir, weil sie nach Art der Arbeit sortiert und nicht nach Produkt. So würde ich sie mit dem füllen, was heute tatsächlich verfügbar ist:

Stufe	Was es ist	Typische Aufgabe	Lizenz / Kosten (vereinfacht)	Wer steuert
1 – Chat	Copilot Chat in der Copilot-App, in Edge, Teams, Outlook	Spontane Fragen, Entwürfe, Zusammenfassung von eingefügten oder hochgeladenen Inhalten	In berechtigten Microsoft-365-Plänen enthalten (webbasiert); arbeitsdatenbasierter Chat braucht eine Copilot-Lizenz	Copilot-Einstellungen im Microsoft 365 admin center
2 – In den Apps	Copilot in Word, Excel, PowerPoint, Outlook, Teams	Meeting-Zusammenfassung, Posteingang sortieren, erster PowerPoint-Entwurf aus einem Dokument	Grundfunktionen in den Apps für berechtigte Nutzer; voller Umfang mit Microsoft-Copilot-Lizenz	Wie oben, plus deine Datenbasis (Berechtigungen, Labels)
3 – Agents	Agents aus Agent Builder, SharePoint-Agents, Agents aus dem Agent Store	Wiederverwendbarer Assistent mit festen Anweisungen und Wissen, z. B. Projekt-FAQ	Mit Copilot-Lizenz enthalten; ohne über Pay-as-you-go (reine Web-Agents kostenlos)	Agent-Registry im Microsoft 365 admin center
4 – Automatisierung	Copilot-Studio-Agents (Flows, Trigger, Autonomie) und Copilot Cowork	Mehrstufige Prozesse über Systeme hinweg, mit Freigaben	Copilot Studio: Copilot-Lizenz oder Copilot Credits; Cowork: Copilot-Lizenz plus nutzungsbasierte Abrechnung	Power Platform admin center + Agent 365 + Cost Management

Die Grenze zwischen Stufe 1 und 2 ziehen inzwischen eher die Lizenzen als die Technik. Auch Nutzer ohne Copilot-Lizenz bekommen Copilot-Grundfunktionen in Word, Excel und PowerPoint, und Copilot Chat in Outlook und Teams kann mit dem gerade geöffneten Inhalt arbeiten. Für Anwender sieht das alles nach „Copilot in der App“ aus. Für dich ist der Unterschied wichtig: Er entscheidet, ob Copilot selbstständig auf Postfach, Chats und Dateien zugreifen kann oder nur sieht, was man ihm gibt.

Stufe 4 hat zwei sehr unterschiedliche Äste. Copilot Studio ist prozesszentriert: Ein Maker baut einen Agent mit Topics, Agent Flows und Event-Triggern, der für viele Nutzer läuft, teils ohne dass ihn jemand anstößt. Cowork ist personenzentriert: Ein Nutzer delegiert ein Ergebnis („bereite die Unterlagen für den Lenkungskreis aus den Mails der letzten Woche und der Projektseite vor“), Cowork plant die Schritte, arbeitet über Outlook, Teams, OneDrive und SharePoint hinweg und fragt vor sensiblen Aktionen nach Freigabe. Microsoft bezeichnet Cowork als agentisches System statt als Agent, und gesteuert wird es über Spending Policies statt über die Agent-Registry.

Vier Fragen für die richtige Stufe

Wenn ein neuer Use Case oder ein neues Feature auftaucht, lass ihn durch vier Fragen laufen:

Kommt es öfter als einmal pro Woche vor? Wenn nicht, bleib auf Stufe 1 oder 2. Für eine Einmalaufgabe etwas Wiederverwendbares zu bauen, lohnt sich nicht.
Sind Quellen oder Tonalität jedes Mal gleich? Wenn ja, bist du bei einem Agent (Stufe 3): Anweisungen plus feste Wissensbasis schlagen das ständige Neu-Tippen desselben Prompts.
Ist es regelbasiert? Wenn die Schritte vorhersehbar sind („wenn X kommt, prüfe Y, dann mach Z“), brauchst du deterministische Logik: einen Copilot-Studio-Agent mit Topics oder Agent Flows (Stufe 4).
Sind mehrere Systeme beteiligt und braucht es Freigaben? Dann bist du auf Stufe 4 mit echtem Prozessdesign: Connectoren, Human-in-the-Loop-Schritte und jemand, der sich Gedanken über die Anmeldedaten macht, mit denen der Agent läuft.

Je mehr „Ja“, desto höher geht es. Wenn du nicht Ja sagen kannst, steig nicht auf: Auch ein Agent, den niemand nutzt, muss inventarisiert, überprüft und irgendwann stillgelegt werden.

Ich ergänze eine eigene Frage, und in regulierten Umgebungen ist sie meine erste: Wem gehört das, wenn es kaputtgeht? Meldet sich niemand, bleibt der Use Case auf Stufe 1 oder 2, egal wie gut die Idee ist.

Governance pro Stufe und ein Owner für jeden Agent

Auf Stufe 1 und 2 geht es bei Governance vor allem um deine Datenbasis: Oversharing, Sensitivity Labels, Berechtigungen. Copilot zeigt Nutzern nur, worauf sie ohnehin Zugriff haben, und genau deshalb fallen unaufgeräumte Berechtigungen in dem Moment auf, in dem Copilot eingeschaltet wird.

Ab Stufe 3 verwaltest du Objekte, die weiterleben: Agents mit Wissen, Aktionen und teils eigener Identität. Die Session hatte dafür eine Checkliste; so lässt sich jeder Punkt auf heutige Werkzeuge abbilden:

Ein Owner für jeden Agent. Die Agent-Registry im Microsoft 365 admin center (Agents > All agents > Registry) listet Agents plattformübergreifend auf (Copilot Studio, Agent Builder, Partner- und Microsoft-Agents) und zeigt Agents without owners als Kennzahl ganz oben. Für die Inventarsicht brauchst du keine Zusatzlizenz, nur die passende Rolle; AI Reader ist die Variante mit den geringsten Rechten. Einen neuen Owner zuweisen kann nur AI Administrator (oder Global Administrator).

Owner vs. Sponsor. Für Agents mit einer Microsoft Entra Agent ID trennt Entra zwei Rollen: Der Owner kümmert sich um den technischen Betrieb, der Sponsor ist die fachlich verantwortliche Person, die entscheidet, ob der Agent noch gebraucht wird und welche Zugriffe er bekommt. Jede Agent-Identität braucht mindestens einen Sponsor, und verlässt ein Sponsor das Unternehmen, geht die Sponsorschaft automatisch an seine Führungskraft über. Nutze beide Rollen. „Die IT hat ihn gebaut“ ist nicht dasselbe wie „der Fachbereich braucht ihn“.

Freigabe für Aktionen. Cowork fragt vor sensiblen Aktionen nach Freigabe. In Copilot Studio gestaltest du das selbst: Human-in-the-Loop-Schritte in Agent Flows für alles, was große Wirkung hat oder sich nicht rückgängig machen lässt. Ein Detail, das man kennen sollte: Event-Trigger in Copilot Studio authentifizieren sich mit den Anmeldedaten des Makers. Nutzer eines veröffentlichten Agents können so über die Zugriffe des Makers an Daten kommen. Least Privilege gilt also auch für Maker.

Eine Registry. Microsoft führt die Agent-Ansichten aus Entra und dem Microsoft 365 admin center in Agent 365 zusammen, sodass du am Ende ein Inventar statt drei hast. Agents anderer Plattformen lassen sich ebenfalls in die Registry synchronisieren.

Entra-ID-Wildwuchs im Griff. Jeder Agent mit eigener Identität bringt neue Objekte ins Verzeichnis: Blueprints, Agent-Identitäten, eventuell Agent-User. Behandle sie wie jede andere nicht-menschliche Identität: Conditional Access, Access Packages mit Ablaufdatum und Lifecycle Workflows, die Sponsor-Wechsel abfangen.

Lifecycle, Lizenzen und Kosten. Agents lassen sich im admin center blockieren, löschen (mit 30 Tagen Wiederherstellungsfrist) und neu zuweisen. Auf der Kostenseite laufen Cowork und andere nutzungsbasiert abgerechnete Dienste über Copilot Credits und werden unter Copilot > Cost Management verwaltet.

Schnelles Inventar mit Microsoft Graph

Wenn du die Registry im Skript brauchst, etwa für einen Monatsbericht oder ein Review mit dem Fachbereich, gibt es in Microsoft Graph die Package Management API. Sie ist unter v1.0 verfügbar, braucht CopilotPackages.Read.All (delegiert oder als Anwendungsberechtigung) und setzt eine Microsoft-Agent-365-Lizenz voraus.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


# Requires: Microsoft.Graph.Authentication, permission CopilotPackages.Read.All
Connect-MgGraph -Scopes "CopilotPackages.Read.All" -NoWelcome

# Only packages that surface in Copilot, i.e. agents
$uri = "https://graph.microsoft.com/v1.0/copilot/admin/catalog/packages?`$filter=supportedHosts/any(h:h eq 'Copilot')"
$agents = while ($uri) {
 $page = Invoke-MgGraphRequest -Method GET -Uri $uri
 $page.value
 $uri = $page.'@odata.nextLink' # follow paging until no nextLink is returned
}

$agents |
 Select-Object displayName, type, platform, publisher, isBlocked, availableTo, deployedTo, lastModifiedDateTime |
 Sort-Object lastModifiedDateTime |
 Export-Csv -Path .\agent-inventory.csv -NoTypeInformation -Encoding utf8

Die Sortierung nach lastModifiedDateTime ist ein günstiger erster Lifecycle-Check: Agents, die sich seit einem Jahr nicht verändert haben, kommen als Erste auf den Prüfstand. Für die Owner-Frage ist die Ansicht Agents without owners im admin center weiterhin der schnellste Einstieg.

Worauf du achten solltest

Eine Spending Policy ist Zugriffssteuerung und Budget zugleich. Bei Cowork bekommt jeder Zugriff, der im Geltungsbereich einer Policy mit Cowork liegt, selbst wenn das Limit bei einem einzigen Credit liegt. Wer draußen bleiben soll, gehört nicht in die Policy.
„Auto-apply new services“ ist standardmäßig aktiv. Neue nutzungsbasierte Dienste können so automatisch mit abgedeckt werden. Wenn du jeden neuen Dienst erst prüfen willst (eine vernünftige Haltung bei Change-Prozessen im NIS2-Umfeld), schalte es ab.
Setz Limits pro Nutzer. Sonst verbraucht ein begeisterter Anwender die Credits des ganzen Monats.
Agent 365 ist gestaffelt lizenziert. Registry-Inventar und Basisaktionen (blockieren, löschen, Owner neu zuweisen) sind in Microsoft 365 Enterprise, Business, Education und Frontline enthalten. Policy-Vorlagen, Observability, mandantenweite Tool-Steuerung und die Graph API brauchen Microsoft 365 E7 oder Agent 365. Prüf die Service Description, bevor du ein Feature zusagst.
Namen und Admin-Pfade ändern sich laufend. Die Umbenennung zu Microsoft Copilot ist frisch; Screenshots in deiner internen Doku veralten schneller, als dir lieb ist.

Fazit

Bau die Landkarte einmal und ordne jedes neue Copilot-Feature darauf ein, statt jedes Mal von vorn zu diskutieren. Entscheide mit den vier Fragen, wie hoch ein Use Case gehen soll, und nimm die Zusatzfrage ernst: Wenn ihn niemand verantwortet, wird er nicht gebaut. Für die Agents, die es schon gibt, zeigt dir die Registry genau, wo ein Owner fehlt.

Auf welcher Stufe sind die meisten deiner Nutzer heute, und wie vielen Agents in deiner Registry fehlt schon jetzt ein Owner?

Quellen

Inspiriert von einem LinkedIn-Post von Marcel Broschk über die Session „Copilot everywhere: Chat, Agents, Automatisierung: wie finde ich mich noch zurecht?“ von Patrick Kelbch auf der M365 Con D-A-CH.