Entra Agent ID: Conditional Access für KI-Agenten

Wenn ein Copilot-Agent, ein Claude-Code-Lauf mit MCP-Zugriff oder ein selbst gebautes Automatisierungsskript auf Unternehmensdaten zugreift - mit wessen Identität tut er das eigentlich? In den meisten Umgebungen lautet die ehrliche Antwort: mit einer geteilten. Ein Service-Account, ein App-Secret in einer Pipeline-Variable, ein API-Key, der irgendwann für „den Automatisierungs-Bot” angelegt wurde und seitdem von mehreren Skripten mitbenutzt wird. Für einen KI-Agenten, der autonom entscheidet, welche Aktion als Nächstes folgt, ist das ein Kontrollverlust mit Ansage: Wer eine geteilte Identität verwendet, kann im Audit-Log nicht mehr unterscheiden, welcher Agent, welcher Lauf und welche Entscheidung eine bestimmte Aktion ausgelöst hat.

Microsoft hat dafür mit Microsoft Entra Agent ID eine eigene Antwort gebaut: ein Identitätskonstrukt speziell für KI-Agenten, das nicht auf App-Registrierungen oder klassischen Service Principals aufsetzt, sondern einen neuen Objekttyp einführt. Dieser Artikel ordnet ein, was Entra Agent ID technisch ist, wie sich Agenten-Identitäten von den bisherigen Bausteinen unterscheiden, wie Conditional Access darauf angewendet wird - und was das für Organisationen bedeutet, die nicht nur Copilot-Agenten, sondern auch Claude-Instanzen mit MCP-Zugriff betreiben. Ein eigener Abschnitt behandelt den Punkt, der in den meisten Governance-Ratgebern fehlt: wie sich KI-Governance-Verantwortung nicht nur als Rolle im Organigramm, sondern als Entra-Rolle, Conditional-Access-Policy und Purview-Berechtigung technisch verankern lässt.

Was ist Microsoft Entra Agent ID?

Microsoft Entra Agent ID ist laut Microsoft Learn ein Identitäts- und Sicherheits-Framework, das bestehende Entra-Fähigkeiten auf KI-Agenten ausweitet, damit Organisationen assistive, autonome und nutzerähnliche Agenten authentifizieren, autorisieren, verwalten und schützen können. Zum Verfügbarkeitsstatus lohnt ein genauer Blick, denn die Dokumentation ist zurückhaltender, als die Ankündigungen vermuten lassen: Microsoft Learn nennt für Entra Agent ID weder ein GA-Datum noch ein Preview-Kennzeichen. Festgehalten ist dort die schlichtere Aussage, dass Agent ID allen Entra-Kunden offensteht („Agent ID is available for all Microsoft Entra customers”, abgerufen am 25.08.2026). Wer den Status für eine Freigabe belastbar braucht, sollte sich deshalb nicht auf das Etikett stützen, sondern auf die Lizenz- und Funktionslage. Agent ID selbst steht allen Entra-Kunden offen; für die vollen Sicherheits- und Governance-Fähigkeiten ist zusätzlich eine Microsoft-Agent-365-Lizenz nötig - dazu mehr im Lizenzabschnitt weiter unten.

Technisch bringt die Plattform vier Dinge zusammen: Identitätsverwaltung, Zugriffsschutz, Governance und Compliance für Agenten. Zentrales Konzept ist das Agent Identity Blueprint - eine Vorlage, aus der Agenten-Identitäten mit Eltern-Kind-Beziehung erzeugt werden, sodass sich Sicherheitsrichtlinien konsistent auf große Mengen von Agenten anwenden lassen. Die Plattform unterstützt Standardprotokolle wie OAuth 2.0, MCP und Agent-to-Agent (A2A) - und funktioniert laut Microsoft ausdrücklich sowohl mit Agenten auf Microsoft-eigenen Plattformen als auch mit Agenten von Drittanbietern wie AWS Bedrock oder n8n.

Agentenidentität, App-Registrierung, Service Principal: der Unterschied

Der naheliegende Einwand: Für nicht-menschliche Identitäten gibt es doch längst Service Principals und App-Registrierungen - wozu ein neues Konstrukt? Microsofts Antwort läuft auf zwei Punkte hinaus: Dynamik und Skalierung.

Standard-App-Identitäten wurden für Dienste konzipiert, die eine Organisation baut und dauerhaft betreibt - mit stabiler Lebensdauer, bekanntem Owner und gepflegtem Lifecycle. Agenten entstehen dagegen oft dynamisch, etwa durch Nutzeraktionen in Low-Code-Tools wie Copilot Studio oder durch API-Orchestrierung, und können Minuten existieren oder tausendfach am Tag erzeugt und wieder verworfen werden. Agenten-Identitäten sind für genau diese Ephemeralität gebaut: Organisationen legen sie in großer Zahl an, wenden einheitliche Policies auf alle an und stellen Agenten still, ohne verwaiste Credentials oder Berechtigungen zurückzulassen.

Technisch bleibt eine Agenten-Identität ein Service Principal - allerdings mit einem neuen „agent”-Subtyp und einem anderen Credential-Modell. Ein normaler Service Principal verwaltet seine eigenen Credentials (Zertifikat, Secret oder Managed Identity) und nutzt sie direkt, um Tokens zu erhalten. Bei einer Agenten-Identität hält stattdessen das Blueprint alle Credentials und impersoniert damit jede einzelne Agenten-Identität, um für sie Tokens zu erwerben. Im ausgestellten Token und im Audit-Log erscheint die Agenten-Identität als Client - obwohl technisch das Blueprint den Token-Austausch durchgeführt hat. Das hat eine Konsequenz, die für die Sicherheitsarchitektur zentral ist: Ein kompromittiertes Blueprint kompromittiert alle Agenten-Identitäten, die daraus erzeugt wurden. Wie viele Blueprints eine Organisation betreibt, ist damit eine Security-Boundary-Entscheidung, keine technische Nebenfrage.

Auch strukturell unterscheidet sich das Modell: Standard-Anwendungen haben eine 1:1-Beziehung zwischen Applikation und Service Principal, das Agent-App-Modell ist 1:n - ein Blueprint kann viele Agenten-Identitäten erzeugen, jede mit eigenen Berechtigungen, aber mit von der Blueprint geerbten Protokolleigenschaften. Managed Identities bleiben relevant, wechseln aber die Rolle: Sie sind ein unterstützter Credential-Typ auf dem Blueprint - die sicherste Option für Agenten auf Azure - , ersetzen aber nicht die Agenten-Identität selbst. Wir haben an anderer Stelle beschrieben, wie Managed Identity die Authentifizierung von Diensten statt von Agenten selbst regelt - genau diese Rollenteilung erklärt, warum es Agent ID als eigenes Konstrukt zusätzlich braucht. Wer Agenten heute noch über klassische App-Registrierungen betreibt (frühere Versionen von Copilot Studio und Azure AI Foundry taten das), kann migrieren; Microsoft führt dafür eine eigene Anleitung, und bis dahin laufen beide Modelle nebeneinander im Entra Admin Center, unterscheidbar über Filteroptionen.

Wie Conditional Access auf Agenten-Identitäten wirkt

Conditional Access ist die Policy-Engine, die entscheidet, ob ein Zugriffstoken ausgestellt wird - abhängig von Kontext-, Geräte-, Standort- und Risikosignalen. Für Agenten gilt dasselbe Grundprinzip wie für Nutzer: Bevor Entra ID ein Token ausstellt, prüft es die konfigurierten Policy-Anforderungen. Wichtig ist die Unterscheidung zwischen Subject (die Identität, die das Token erhält) und Audience (die Zielressource) - jedes Token hat genau ein Subject und eine Audience. Braucht ein Agent Zugriff auf mehrere Ressourcen, etwa mehrere MCP-Server, benötigt er in aller Regel für jede ein eigenes Token.

Microsoft unterscheidet drei Zugriffsmuster mit jeweils eigenem Policy-Ziel: Agenten im Namen eines Nutzers (On-Behalf-Of/OBO) - ein Nutzer meldet sich am Agenten an, der Agent greift mit dessen delegierten Rechten zu; weil der Nutzer das Subject ist, zielen Policies hier auf Nutzer und Gruppen, nicht auf die Agenten-Identität. Agenten als eigenständige Anwendung (Client-Credentials-Flow) - ohne angemeldeten Nutzer fragt der Agent ein Token mit eigener Identität an, etwa für einen automatisierten Tagesreport; das Token geht auf die Agenten-Identität, Policies zielen entsprechend auf sie. Agenten mit eigenem Nutzerkonto („agent’s user account”) - manche Agenten erhalten ein eigenes Entra-Benutzerkonto mit Mailbox und Teams-Zugang wie ein digitaler Mitarbeiter; hier ist das Konto selbst das Subject, inklusive Geräte-Compliance auf verwalteten Endpunkten wie Windows-365-Cloud-PCs für Agenten.

Skalierbar wird das über zwei Mechanismen: Blueprint-Targeting, bei dem eine Policy auf ein ganzes Blueprint statt auf einzelne Agenten wirkt und automatisch alle daraus erzeugten - auch künftigen - Agenten-Identitäten abdeckt; und Custom Security Attributes, mit denen sich Agenten und Ressourcen geschäftsspezifisch taggen lassen (etwa „Freigabestatus: IT_Approved”), sodass Policies automatisch auf jeden Agenten mit passendem Tag greifen. Für Zielressourcen gilt eine wichtige Voraussetzung: Sie müssen in Entra ID als Enterprise Application registriert sein - das gilt für Microsoft Graph genauso wie für eigene MCP-Server, Open-API-Tools oder sonstige selbst gebaute Werkzeuge. Ein MCP-Server ohne Entra-Registrierung ist für Conditional Access schlicht unsichtbar.

Auch die Grenzen sind offen dokumentiert und praxisrelevant: Conditional Access greift nicht bei der Token-Anfrage eines Blueprints zur Erstellung neuer Agenten-Identitäten, nicht am internen AAD Token Exchange Endpoint, nicht bei aktivierten Security Defaults - und, am wichtigsten: nicht, wenn ein Agent eine Ressource über einen API-Key statt über den Entra-Auth-Flow anspricht. Dann umgeht der Zugriff die Token-Ausstellung von Entra komplett. Für Agenten-Identitäten selbst ist zudem als einzige Bedingung „Agent Risk” (Preview) verfügbar, und als Zugriffskontrolle steht ausschließlich Blockieren zur Verfügung - keine interaktive Remediation wie MFA, weil kein Mensch anwesend ist, der sie durchführen könnte. Reichhaltigere Kontrollen wie Geräte-Compliance oder Netzwerkstandort bleiben vorerst den (noch in Preview befindlichen) „agent’s user accounts” auf verwalteten Endpunkten vorbehalten.

KI-Governance-Rollen technisch verankern, nicht nur benennen

Die meisten Governance-Ratgeber zu KI im Unternehmen enden bei der Organisationsstruktur: einen Chief AI Officer benennen, ein KI-Gremium einrichten, Verantwortlichkeiten dokumentieren. Das ist nicht falsch, aber es bleibt an der Oberfläche, solange diese Verantwortung nirgends technisch durchsetzbar ist. Entra Agent ID bietet dafür drei konkrete Anknüpfungspunkte.

Erstens: ein eigenes administratives Rollenmodell für Agenten selbst. Microsoft trennt technische Administration von geschäftlicher Verantwortung. Owner sind technische Administratoren, die Setup, Konfiguration und Credential-Management eines Agenten oder Blueprints verantworten - typischerweise Entwickler oder IT-Fachleute, optional besetzt. Sponsoren sind Geschäftsverantwortliche ohne technischen Administrationszugriff: Sie treffen Lifecycle-Entscheidungen, begründen Zugriffsanfragen fachlich und sind bei jeder Agenten-Identität und jedem Blueprint verpflichtend - mindestens ein Sponsor ist Pflicht, maximal 100, davon höchstens fünf Gruppen. Verlässt ein Sponsor die Organisation, geht die Rolle automatisch an dessen Vorgesetzten über - ein Lifecycle-Workflow, der verwaiste Agenten technisch verhindert, statt sie erst im Nachhinein zu entdecken. Manager sind Personen, die einem Agenten in der Organisationshierarchie zugeordnet sind und in dessen Namen Zugriffspakete anfragen können, ohne selbst Änderungs- oder Löschrechte zu haben.

Zweitens: Agenten-Identitäten lassen sich echte Entra-Rollen zuweisen - mit einer harten Sperrliste. Eine Agenten-Identität kann wie eine App oder ein Nutzer eine Microsoft-Entra-Rolle erhalten, allerdings mit Leitplanken: Global Administrator, Privileged Role Administrator und User Administrator lassen sich Agenten grundsätzlich nicht zuweisen, ebenso wenig benutzerdefinierte Rollen; Agenten können auch keine Mitglieder rollen-fähiger Gruppen sein. Zulässig sind ausschließlich niedriger privilegierte Rollen aus einer von Microsoft geführten Liste - und genau hier liegt der Differenzierer für die eigene KI-Governance: Darunter finden sich unter anderem AI Administrator, Purview Workload Content Administrator, Purview Workload Content Reader, Purview Workload Content Writer, Compliance Administrator, Compliance Data Administrator und Security Reader. Wer also eine Governance-Rolle wie „verantwortlich für KI-Compliance-Prüfungen” nicht nur im Organigramm, sondern technisch durchsetzen will, kann einem entsprechenden Prüf- oder Audit-Agenten genau diese Rolle zuweisen - er sieht dann nur, was seine Rolle vorsieht, statt sich auf dokumentierte Absicht zu verlassen. Ergänzend blockiert Microsoft auf Graph-Ebene hochprivilegierte Berechtigungen wie Application.ReadWrite.All, RoleManagement.ReadWrite.All, User.ReadWrite.All und Directory.AccessAsUser.All explizit für Agenten. Für die menschliche Verwaltungsseite gibt es eigene Rollen: Agent ID Administrator und Agent ID Developer.

Drittens: Zugriff läuft über Entitlement Management statt über Ad-hoc-Freigaben. Agenten-Identitäten können Access Packages zugewiesen bekommen - der Agent fragt selbst programmatisch an, sein Sponsor fragt stellvertretend an, oder ein Administrator weist direkt zu. Jede Anfrage durchläuft konfigurierte Genehmigungsschritte, und bei befristeten Zuweisungen erinnert das System den Sponsor vor Ablauf; verlängert er nicht aktiv, verliert der Agent automatisch den Zugriff. „Zugriff nicht länger als nötig” wird damit zu einer erzwungenen Eigenschaft statt zu einer Richtlinie, die im Alltag erodiert.

Ergänzend überwacht Microsoft Entra ID Protection Agenten-Identitäten laufend auf Risikosignale - etwa ungewöhnliche Reconnaissance-Aktivität, Anmeldespitzen, fehlgeschlagene Zugriffsversuche oder neu hinzugefügte und sofort genutzte Blueprint-Credentials. Ein „Learning Mode” unterdrückt dabei Fehlalarme bei neuen Agenten ohne Aktivitätshistorie, eine parallele Erkennung erfasst trotzdem genuin bösartiges Verhalten. Wird ein Risiko bestätigt, lässt sich der Agent über Conditional Access automatisch blockieren.

Claude, AWS Bedrock und MCP-Server: was für Drittanbieter-Agenten gilt

Der wichtigste ehrliche Punkt zuerst: Entra Agent ID ist kein universeller Standard für KI-Agenten-Identität, sondern ein Mechanismus, um Zugriff auf Entra-geschützte Ressourcen zu steuern - Microsoft Graph, Azure-Dienste und alles, was Sie selbst als Anwendung in Entra registrieren, einschließlich eigener MCP-Server. Ein Agent, der ausschließlich gegen Ressourcen arbeitet, die nicht hinter Entra liegen - ein SaaS-Tool mit eigenem API-Key, ein externer MCP-Server ohne Entra-Registrierung - , bewegt sich außerhalb der Reichweite von Agent ID und Conditional Access, unabhängig vom Agenten-Framework.

Innerhalb dieser Grenze unterstützt Microsoft Drittanbieter-Agenten aber ausdrücklich, nicht nur die eigenen Produkte. Dokumentiert sind zwei Integrationsmuster: das Sidecar-Pattern, bei dem der Microsoft Entra ID Auth SDK (Sidecar) als Begleit-Container neben dem Agenten läuft und Tokens für ihn beschafft, ohne dass der Agent selbst je mit Credentials in Berührung kommt, und Workload Identity Federation, bei der Credentials eines externen Identity-Providers wie AWS STS oder GCP Workload Identity direkt gegen ein Entra-Token getauscht werden. Bemerkenswert für unseren Kontext: Microsoft nennt als unterstütztes Sidecar-Szenario ausdrücklich AWS-Bedrock-Agenten „wie Claude”, die Microsoft-365-Daten über Microsoft Graph abfragen sollen, dazu n8n-Agenten und lokale LLM-Setups mit Ollama/LangChain. Die Dokumentation erwähnt Claude damit im Kontext von Claude über AWS Bedrock als Modell-Backend eines fremden Agenten-Frameworks - nicht Claude Code oder das Claude Agent SDK direkt.

Was heißt das konkret für einen Claude-Code-Lauf mit MCP-Zugriff oder eine eigene Anwendung auf dem Claude Agent SDK? Anthropic liefert derzeit keine native Entra-Agent-ID-Integration - Sie müssten das Sidecar- oder Federation-Muster selbst aufsetzen, wenn ein solcher Agent gegen Entra-geschützte Ressourcen authentifizieren soll, statt mit einem statischen API-Key oder geteilten Secret zu arbeiten. Der Aufwand ist überschaubar, aber real: ein Entra-Tenant mit aktivierter Agenten-Identitätsplattform, ein passend berechtigtes Blueprint, Docker/Docker-Compose für den Sidecar-Container, und initial ein per Privileged Identity Management befristet aktivierter Global-Administrator-Zugang für das Setup. Wer diesen Weg geht, bekommt dafür etwas, das ein reiner API-Key nie liefert: Der Claude-Lauf erscheint als eigenständige, auditierbare Identität im Entra-Sign-in-Log, lässt sich per Conditional Access blockieren, in Access Packages fristbegrenzt berechtigen und über ID Protection auf Risikosignale überwachen - dieselbe Governance-Tiefe, die Microsoft für eigene Copilot-Agenten anbietet. Wie granular Berechtigungen für parallel arbeitende Claude-Instanzen ohnehin schon innerhalb von Claude Code gedacht sind, zeigt der Permissions-Abschnitt zu Claude Code Agent Teams - Entra Agent ID verlagert diese Frage eine Ebene höher, auf die Identität gegenüber Microsoft-Ressourcen.

Der zweite Hebel betrifft nicht den Agenten, sondern die Ressource: Wer eigene MCP-Server im Unternehmen betreibt, an die Claude-Instanzen, Copilot-Agenten oder beide andocken, sollte diese MCP-Server unabhängig vom aufrufenden Framework als Entra-Anwendung registrieren und ihre Berechtigungen exponieren. Erst dann werden sie zu einer Ressource, die Conditional Access als Audience kennt und schützen kann - für einen Copilot-Studio-Agenten wie für eine Claude-Instanz gleichermaßen. Ergänzend dazu haben wir beschrieben, wie sich MCP-Server zusätzlich über eine Gateway-Schicht governen lassen - als zweite, von der Entra-Registrierung unabhängige Kontrollebene. Die Governance liegt dann an der Tür, durch die jeder Agent muss, nicht am Agenten selbst - ein Muster, das sich mit der Zero-Trust-Referenzarchitektur deckt, die wir für selbst gehostete Agenten bereits beschrieben haben (Zero Trust für KI-Agenten). Wer diese Architektur in einer bestehenden Azure-Umgebung verankern will, findet den Ausgangspunkt meist in der Netzwerk- und Identitätsgrundlage der eigenen Azure-Umgebung.

Lizenz- und Rollout-Realität (Stand: August 2026)

Wer Entra Agent ID einführen will, sollte die Lizenzlage nüchtern prüfen, bevor er sie in eine Governance-Roadmap einplant. Agent ID selbst - Blueprint anlegen, Agenten-Identitäten erzeugen - steht allen Entra-Kunden offen. Die sicherheits- und governance-relevanten Fähigkeiten sind daran gekoppelt, dass eine Microsoft-Agent-365-Lizenz je Nutzer im Tenant vorhanden ist; Agent 365 ist in Microsoft 365 E7 enthalten und als Zusatzlizenz zu E5/A5/Business Premium beziehungsweise zur Kombination aus Defender-Suite und Purview-Suite verfügbar. Konkret gilt laut Microsoft Learn: Conditional Access für Agenten braucht Entra ID P1 oder P2 und zusätzlich eine Agent-365-Lizenz je Nutzer - wobei Microsoft ausdrücklich anmerkt: „Enforcement of Agent 365 licensing is coming soon”, die technische Durchsetzung der Lizenzpflicht war zum Recherchezeitpunkt (August 2026) noch nicht scharf geschaltet. Entra-ID-Governance-Funktionen für Agenten (Access Packages, Sponsor- und Lifecycle-Workflows) verlangen entweder Microsoft 365 E7 oder Agent 365 kombiniert mit mindestens Entra ID P1 oder Microsoft 365 E3. Netzwerkkontrollen für Agenten setzen zusätzlich Microsoft Entra Internet Access voraus, Teil von Global Secure Access. Und ID Protection für Agenten wird laut Microsoft Learn ebenfalls in Kürze eine Agent-365-Lizenz voraussetzen, ist zum Recherchezeitpunkt aber noch nicht daran gebunden.

Für den deutschen Mittelstand heißt das: Die Governance-Fähigkeiten sind kein Bestandteil eines vorhandenen Entra-ID-P1/P2-Vertrags, sondern erfordern eine bewusste zusätzliche Lizenzentscheidung - und die Durchsetzung dieser Lizenzpflicht war im August 2026 noch im Rollout. Klären Sie diesen Punkt vor Budgetzusagen mit Ihrem Microsoft-Partner.

Häufige Fragen zu Entra Agent ID

Ist Microsoft Entra Agent ID allgemein verfügbar?

Microsoft Learn nennt dafür weder ein GA-Datum noch ein Preview-Kennzeichen. Dokumentiert ist, dass Agent ID allen Entra-Kunden offensteht („Agent ID is available for all Microsoft Entra customers”); die vollen Sicherheits- und Governance-Funktionen setzen zusätzlich eine Microsoft-Agent-365-Lizenz voraus (abgerufen am 25.08.2026). Einzelfunktionen wie „agent’s user accounts” in Conditional Access oder die Agent-Risk-Bedingung sind weiterhin als Preview gekennzeichnet.

Was ist der technische Unterschied zwischen einer Agenten-Identität und einem klassischen Service Principal?

Beide sind Service Principals, aber eine Agenten-Identität trägt einen „agent”-Subtyp und verwaltet keine eigenen Credentials. Das übergeordnete Blueprint hält alle Credentials und beschafft Tokens stellvertretend (Impersonationsmodell). Das Verhältnis Blueprint zu Agenten-Identität ist 1:n, eine klassische Anwendung steht 1:1 zu ihrem Service Principal.

Kann ich Conditional Access auf eine Claude-Instanz mit MCP-Zugriff anwenden?

Nur indirekt, und nur wenn die angesprochene Ressource als Entra-Anwendung registriert ist, etwa ein selbst gehosteter MCP-Server. Die Claude-Instanz selbst braucht dafür eine Entra-Identität über das Sidecar- oder Federation-Pattern der Drittanbieter-Integration; eine native Anbindung liefert Anthropic derzeit nicht. Greift Claude über einen statischen API-Key zu, bleibt dieser Zugriff für Conditional Access unsichtbar.

Welche Rollen kann ich einer Agenten-Identität überhaupt zuweisen?

Nur aus einer von Microsoft festgelegten Liste niedriger privilegierter Rollen - darunter AI Administrator, die drei Purview-Workload-Content-Rollen und Security Reader. Global Administrator, Privileged Role Administrator, User Administrator und benutzerdefinierte Rollen sind für Agenten gesperrt, ebenso die Mitgliedschaft in rollen-fähigen Gruppen.

Was kostet Entra Agent ID?

Agent ID selbst ist kostenlos nutzbar - in jedem Entra-Tenant, ohne Zusatzlizenz. Die Governance- und Sicherheitsfunktionen setzen zusätzlich eine Microsoft-Agent-365-Lizenz je Nutzer voraus, kombiniert mit mindestens Entra ID P1. Die technische Durchsetzung dieser Lizenzpflicht war laut Microsoft Learn im August 2026 noch nicht vollständig scharf geschaltet.

Fazit

Entra Agent ID löst ein Problem, das mit autonom handelnden KI-Agenten unausweichlich wird: Eine geteilte Identität lässt sich weder sauber prüfen noch gezielt entziehen. Das Blueprint-Modell, das eigene Conditional-Access-Verhalten für Subject und Audience und die klare Trennung von Owner, Sponsor und Manager bilden zusammen die technische Grundlage dafür, dass „wer ist für diesen Agenten verantwortlich” eine Frage mit erzwingbarer Antwort wird - nicht nur eine Zeile im Organigramm. Für Organisationen, die neben Copilot auch Claude-Instanzen mit MCP-Zugriff betreiben, gilt: Diese Governance-Tiefe lässt sich über Sidecar- oder Federation-Integration erreichen, ist aber kein Standardfeature dieser Werkzeuge - sie erfordert eigene Integrationsarbeit und eine bewusste Lizenzentscheidung für Agent 365. Wer diese Investition scheut, sollte zumindest den günstigeren Hebel ziehen: eigene MCP-Server konsequent als Entra-Anwendungen registrieren, damit sie überhaupt als schützbare Ressource sichtbar werden - unabhängig davon, welcher Agent am anderen Ende anklopft.

Quellen (Stand: August 2026, Abruf 20.08.2026):