Entra Agent ID: Jeder Agent hat jetzt eine Identität — berechtigt ist er damit nicht

Seit Mai 2026 taucht im Entra Admin Center für jeden neuen Copilot-Studio-Agenten eine eigene Identität auf — automatisch, ohne dass jemand etwas einschaltet, und ohne Opt-out. Für Admins wirkt das erstmal wie ein Machtzuwachs: „Endlich hat jeder Agent ein eigenes Konto, dann berechtige ich pro Agent, wer auf Jira, SharePoint oder ServiceNow darf — wie bei einem Service-Account.”

Das ist die Erwartung. Und sie stimmt nur zur Hälfte. Wer sie ungeprüft übernimmt, baut sich ein falsches Sicherheitsmodell. Räumen wir das auf.

1. Das Problem: „eigene Identität” wird mit „eigener Berechtigung” verwechselt

Die Microsoft Entra Agent ID ist seit Mai 2026 GA. Konkret heißt das: Legst du in Copilot Studio einen neuen Agenten an, entsteht im Verzeichnis ein Identitätsobjekt für genau diesen Agenten. Bindest du im Agenten einen Connector ein — sagen wir den zertifizierten Jira-Connector — und published ihn, erscheinen dessen Berechtigungen als API-Permissions an der Agent-Identität.

Der naheliegende, aber falsche Reflex: „Also entziehe ich dem Agenten in Entra die Jira-Permission, dann darf er kein Jira mehr.” Oder: „Ich weise Agent A die SharePoint-Rechte zu, Agent B nicht — feingranulare Steuerung, direkt im Entra.” Genau das funktioniert so nicht, und das ist der Kern dieses Artikels.

2. Was man zuerst sieht

Zwei Stellen zeigen dir die neue Identität:

Copilot Studio → Settings → Advanced → Metadata: dort steht die GUID als „Entra Agent ID”.
Entra Admin Center → eigene Agent-identities-Ansicht („All Agents”). Jeder Agent liegt hier als eigener Eintrag.

Wie ein Copilot-Studio-Agent als Service Principal mit Subtyp „Agent" im Verzeichnis erscheint — und warum die Token-Ausstellung bei Microsoft liegt

Nach dem Publish siehst du an dieser Identität die Connector-Berechtigungen als Scopes — je nach Konfiguration z. B.:

Operations.Execute.All — der ganze Connector auf Tool-Ebene,
einzelne Operation-Scopes — nur die tatsächlich genutzten Aktionen,
Azure API Connections Runtime.All — als Fallback.

Das sieht aus wie eine klassische App-Registration mit API-Permissions. Und genau dieser Anblick verführt zum Fehlschluss.

3. Was technisch wirklich passiert

Die Identität ist ein Service Principal mit Subtyp „Agent”. Kein komplett neuer Objekttyp — die Doku sagt wörtlich „Microsoft Entra service principals with an ‘Agent’ subtype”. Jede dieser Identitäten wird als Kind eines Microsoft-eigenen „Blueprint Principal” angelegt. Die Token-Ausstellung läuft über Federated Identity Credentials, die Microsoft kontrolliert — niemand im Tenant, auch kein Global Admin, kann selbst Tokens für die Agent-Identität ausstellen. Du besitzt die Identität also nicht in dem Sinn, wie du einen Service-Account besitzt.

Und jetzt der entscheidende Satz, fast wörtlich aus der Governance-Doku:

Die Scopes beschreiben, was ein Agent tun soll — nicht, was er darf. Was er zur Laufzeit darf, entscheiden Advanced Connector Policies (ACP) und DLP im Moment der Ausführung.

Die Scopes an der Agent-Identität sind also eine Spiegelung der Publish-Konfiguration, kein Berechtigungsschalter. Die eigentliche Authentifizierung gegenüber Jira, SharePoint & Co. läuft weiterhin über die Power-Platform-Connector-Runtime — mit den bekannten Connections / Connection References (Maker- oder Benutzer-OAuth). Jeder einzelne Call wird von der Connector-Plattform vermittelt und erneut gegen ACP + DLP geprüft. Selbst wer die Agent-Identität stehlen würde, könnte damit nicht direkt Graph, Outlook oder Jira aufrufen — die Connector-Ebene sitzt dazwischen.

Wenn dir das bekannt vorkommt: Es ist dieselbe Denkschule wie bei Copilot Agents richtig erden — die Quelle und die Guardrails entscheiden, nicht die schöne Fassade. Und anders als bei einer echten Managed Identity, wo du der Zielressource per RBAC eine Rolle zuweist, ist die Agent-ID kein Punkt, an dem du Zugriff zuweist.

4. Die naheliegende, aber falsche Lösung

Falsch: „Ich steuere den Agent-Zugriff, indem ich in Entra die API-Permissions der Agent-Identität anpasse — hinzufüge, entziehe, pro Agent verteile.”

Warum das nicht trägt:

Die Permissions entstehen beim Publish aus der Connector-Konfiguration des Agenten. Sie sind Ergebnis, nicht Stellschraube.
Sie werden nur von der Connector-Runtime honoriert und können Governance nicht umgehen — DLP und ACP gewinnen immer.
Custom Connectors, MCP-Server und REST-API-Tools erzeugen gar keine solchen Scopes auf der Agent-ID. Bindest du Jira als Custom Connector ein statt über den zertifizierten Connector, siehst du diese Sichtbarkeit überhaupt nicht — dein „Steuerungspunkt” wäre schlicht leer.
Und der Klassiker: Conditional Access auf der Agent-Identität greift zur Laufzeit heute nur, wenn der Agent im Kanal Microsoft Teams läuft. In anderen Kanälen siehst du die Scopes, aber die CA-Auswertung findet nicht statt. Ein CA-Policy, auf das du dich außerhalb Teams verlässt, ist eine trügerische Sicherheit.

5. Die belastbare Lösung: an den richtigen Stellen steuern

Der Zugriff eines Agenten wird an drei Ebenen wirklich bestimmt — keine davon ist „Rechte an der Entra-Identität zuweisen”:

Connector-Konfiguration + Publish. Was der Agent nutzen darf, legst du fest, indem du den Connector im Agenten konfigurierst und published. Zugriff entziehen = Connector aus dem Agenten entfernen und neu publishen. Danach verschwindet der Scope.
DLP-Policies und Advanced Connector Policies (ACP). Das sind die echten Laufzeit-Guardrails. Willst du „Jira nur lesend” oder „diesen Connector in dieser Umgebung gar nicht”, setzt du das hier — nicht an der Agent-ID.
Connections / Connection References. Die eigentliche Auth zum Zielsystem. Wer die Connection besitzt und mit welchen Rechten sie am Zielsystem hängt, bleibt der bestimmende Faktor.

Was die Agent-ID dir zusätzlich bringt — und das ist der echte Gewinn:

Sichtbarkeit ohne PPAC. Entra-/Security-Admins sehen die Connector-Berechtigungen eines Agenten direkt im Entra Admin Center, ohne das Power Platform Admin Center zu öffnen.
Audit & Sign-in-Logs. Authentifizierungen der Agenten tauchen in Entra als „AI agents” auf — nachvollziehbar wie andere Sign-ins.
Conditional Access — im Teams-Kanal. Weil die Scopes echte API-Permissions sind, kannst du sie mit CA targeten (Netzwerkstandort, Gerätecompliance, Risk vor Token-Ausstellung). Nur eben heute mit Wirkung ausschließlich in Teams.
Lifecycle. Löschst du den Agenten in Copilot Studio, wird die zugehörige Identität mitgelöscht — keine verwaisten Principals. Der Ersteller wird als „Sponsor” eingetragen (eingeschränkte Rechte, nicht Voll-Owner).

Die Connector-Scopes an der Agent-Identität sind Sichtbarkeit — autorisiert wird über die Connector-Runtime, DLP/ACP und die Connection

Hands-on: Agent-Identitäten über Microsoft Graph auslesen

Für ein Inventar aller Agent-Identitäten in deinem Tenant fragst du die Service Principals nach dem Agent-Subtyp ab. Über die Graph-CLI:

# Anmelden mit ausreichenden Directory-Read-Rechten
az login --allow-no-subscriptions

# Service Principals mit Agent-Subtyp auflisten (Graph v1.0)
az rest --method get \
  --url "https://graph.microsoft.com/v1.0/servicePrincipals?\$select=id,displayName,servicePrincipalType,tags&\$top=999" \
  --query "value[?servicePrincipalType=='ManagedIdentity' || contains(to_string(tags),'Agent')].{name:displayName,id:id,type:servicePrincipalType}" \
  -o table

Beispielhafte Ausgabe:

Name                                Id                                    Type
----------------------------------  ------------------------------------  ---------------
Reklamations-Triagierung (Agent)    5f2a...c19d                           ServicePrincipal
Onboarding-Assistent (Agent)        7b81...4e02                           ServicePrincipal

Die zugehörigen, beim Publish erteilten Connector-Permissions liest du über die OAuth2-Grants bzw. AppRoleAssignments derselben Identität:

az rest --method get \
  --url "https://graph.microsoft.com/v1.0/servicePrincipals/5f2a...c19d/appRoleAssignments" \
  -o table

Wichtig zur Einordnung: Diese Ausgabe zeigt dir, was konfiguriert wurde — sie ist Audit- und Sichtbarkeitsmaterial. Sie ist nicht der Ort, an dem du im Betrieb „mal eben” Rechte umschaltest. Dafür gehst du zu DLP/ACP und zur Connector-Konfiguration im Agenten.

Wo der Zugriff eines Agenten wirklich entschieden wird — und wo gerade nicht

6. Entscheidungs- und Diagnose-Checkliste

Bevor du dich auf die Agent-ID als Governance-Werkzeug verlässt:

Kanal prüfen. Läuft der Agent in Teams? Nur dort wird CA an der Agent-Identität zur Laufzeit durchgesetzt. Sonst: Sichtbarkeit ja, Enforcement nein.
Connector-Typ prüfen. Zertifizierter/First-Party-Connector → Scopes an der Agent-ID sichtbar. Custom Connector / MCP / REST → keine Scopes, keine CA-Kopplung.
Directory-Quota im Blick. Jede Agent-ID ist ein Directory-Objekt und zählt gegen das Tenant-Kontingent (Default 50.000, mit verifizierter Domain 300.000; nur 95 % nutzbar). Ist das Kontingent erschöpft, schlägt das Anlegen neuer Agenten fehl. Der sonst übliche Per-Blueprint-Cap von 250 gilt hier nicht — Agent-Wildwuchs ist real möglich.
Lizenz prüfen. Die Agent-ID als Fundament ist inklusive. Aber CA für Agenten und ID Protection für Agenten (neue Policy-Templates wie „Block high-risk agent identities”) brauchen Microsoft Agent 365 bzw. entsprechende Service-Plans.
Bestandsagenten. Agenten von vor Mai 2026 laufen weiter auf App-Registrations und werden migriert; die GUID bleibt erhalten, keine Downtime.
Agent-Builder ≠ Copilot Studio. M365-Agent-Builder-Agenten nutzen aktuell weder App-Registration noch Agent ID — diese Regeln gelten für Copilot-Studio-Agenten.

7. Die unbequemen Teile

Kein Opt-out. Ab Mai 2026 bekommt jeder neue Copilot-Studio-Agent zwangsweise eine Identität. Wer viele Agenten baut, produziert viele Directory-Objekte — und muss das gegen die Quota planen.
Scopes sind kein RBAC. Die verbreitete Vorstellung „Agent X darf Jira, Agent Y nicht — steuere ich rein über Entra-Rechtezuweisung” ist falsch. Steuerung passiert über Connector-Konfiguration + DLP/ACP.
CA nur in Teams. Die stärkste Governance-Zusage (Conditional Access auf der Agent-Identität) hat heute genau einen Kanal, in dem sie wirkt. Das steht in der Doku als „currently” — es wird sich vermutlich erweitern, aber verlassen kannst du dich heute nur auf Teams.
Kein Bring-your-own-Identity. Diese Identitäten sind kein frei nutzbarer Service-Account; ihre Tokens stellt Microsoft aus, nicht du.

Fazit: Die Entra Agent ID ist ein echter Fortschritt — für Sichtbarkeit, Audit und (im Teams-Kanal) Conditional Access. Sie ist kein neues, feingranulares Berechtigungssystem, das die bestehende Connector-Governance ersetzt. Wer sie als das missversteht, verlässt sich auf einen Schalter, der nichts schaltet. Die Wahrheit über den Zugriff eines Agenten steht weiterhin in seiner Connector-Konfiguration, in den Connections und in DLP/ACP — die Identität macht sie nur endlich sichtbar.

Siehe auch

Copilot Agents richtig erden — warum Quelle und Guardrails über die Qualität eines Agenten entscheiden.
Managed Identity statt Secrets — wie eine echte Entra-Identität mit RBAC-Zuweisung funktioniert (und worin sich die Agent-ID unterscheidet).
Azure App Registration Monitor — Identitäten und ihre Ablauf-/Lifecycle-Fallen im Blick behalten.

Quellen: Microsoft Learn — „Govern agents: identities overview”, „Use Microsoft Entra agent identities” (Copilot Studio), „What are agent identities” und „What’s new in Agent ID” (Microsoft Entra). Stand: August 2026. Preview-/GA-Status und der Teams-only-Hinweis können sich mit künftigen Release-Wellen ändern.