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.

MCP on DR.365