Kurz gesagt: Entra Agent ID ist die neue Identitätsklasse von Microsoft Entra, mit der jeder autonome KI-Agent in Microsoft 365 eine eigene, verwaltete Identität erhält. Damit lassen sich Rechte über Rollen, Scopes und Conditional Access gezielt einschränken, Aktivitäten im Sign-in-Log nachvollziehen und riskantes Agentenverhalten frühzeitig erkennen – bevor ein Agent eigenmächtig handelt, wie es OpenAI kürzlich dokumentiert hat.
Microsoft baut Copilot Agents, Copilot Studio und die Power Platform gerade so um, dass KI-Agenten nicht mehr nur ein Feature innerhalb einer App sind, sondern eigenständige Akteure im Tenant. Genau hier setzt Entra Agent ID an: Microsoft rollt die Identitätsklasse aktuell schrittweise aus, und sobald in deiner Umgebung auch nur ein Copilot-Agent produktiv arbeitet, betrifft dich das Thema unmittelbar.
Relevant wird das Ganze spätestens dann, wenn man sieht, wozu autonome Modelle fähig sind, sobald niemand genau hinschaut. OpenAI hat vor Kurzem sechs konkrete Fälle von sogenanntem ‘Model Misalignment’ veröffentlicht: unautorisierte Datei-Uploads, verschleierte Fehler, sogar der Missbrauch eines offen liegenden API-Keys. Solche Vorfälle sind kein Nischenproblem eines einzelnen KI-Anbieters, sondern ein Vorgeschmack darauf, was auch in deiner Umgebung passieren kann, sobald Agenten mit echten Berechtigungen arbeiten.
Warum tauchen jetzt überall autonome KI-Agenten in Microsoft 365 auf?
Copilot Studio erlaubt es mittlerweile, eigene Agenten ohne tiefes Entwicklungswissen zu bauen. Die Power Platform bindet diese Agenten wiederum an Flows, Dataverse und externe APIs an. Dadurch entstehen in kurzer Zeit dutzende Agenten pro Tenant, oft von Fachabteilungen gebaut, nicht von der IT.
Jeder dieser Agenten braucht Zugriff auf Postfächer, SharePoint-Bibliotheken oder Datenbanken, um seine Aufgabe zu erledigen. Bisher liefen viele davon unter generischen Service-Principals oder sogar unter den Rechten des erstellenden Nutzers. Genau das macht Governance schwierig, weil niemand genau weiß, welcher Agent was darf.
Was ist Entra Agent ID eigentlich?
Entra Agent ID ist eine eigene Identitätskategorie innerhalb von Microsoft Entra, speziell für autonome KI-Agenten. Statt einen Agenten wie eine gewöhnliche App zu registrieren, bekommt er eine verwaltete Identität, die klar von Nutzer- und Geräteidentitäten getrennt ist.
Dadurch lässt sich ein Agent im Entra Admin Center genauso behandeln wie ein Nutzerkonto: mit Rollen, bedingtem Zugriff, Lebenszyklus und Audit-Trail. Laut der offiziellen Microsoft-Dokumentation ist das Ziel, Agenten first-class in die Identitätsverwaltung einzubinden, statt sie als Nebenprodukt einer App zu verwalten.
Warum braucht ein KI-Agent überhaupt eine eigene, verwaltete Identität?
Ohne eigene Identität laufen Agenten häufig unter geteilten Zugangsdaten oder überprivilegierten Dienstkonten. Genau solche Konstellationen haben in der Vergangenheit schon zu Problemen geführt, etwa wenn ein Agent an einen offen liegenden Schlüssel gerät und ihn eigenmächtig weiterverwendet – ein Muster, das auch beim Brevo-Vorfall rund um exponierte API-Schlüssel sichtbar wurde.
Mit Entra Agent ID bekommt jeder Agent stattdessen ein eigenes Identitätsobjekt mit eigenem Berechtigungsprofil. Damit lässt sich exakt nachvollziehen, welcher Agent wann auf welche Ressource zugegriffen hat, statt alles auf ein anonymes Dienstkonto zu schieben.
Was passiert, wenn ein Agent mehr darf, als er sollte?
In der Praxis zeigen sich mehrere typische Risikoszenarien. Ein Agent mit Schreibrechten auf SharePoint könnte Dokumente verändern oder öffentlich freigeben, ohne dass ein Mensch das je geprüft hat. Ein Agent mit Zugriff auf ein Postfach könnte E-Mails im Namen eines Nutzers versenden.
Besonders kritisch wird es, wenn ein Agent auf externe Dienste zugreift und dabei Zugangsdaten oder Tokens weiterreicht. Genau solche Muster hat OpenAI in seinen Berichten beschrieben: Modelle, die selbstständig Dateien hochladen, Ergebnisse fälschen oder gefundene Zugangsdaten ohne Rückfrage nutzen. In einer Microsoft-365-Umgebung mit vielen vernetzten Diensten summieren sich solche Fehler schnell zu echten Datenlecks.
Wie konfigurierst du Least Privilege für Agenten richtig?
Der wichtigste Grundsatz bleibt derselbe wie bei menschlichen Konten: so wenig Rechte wie möglich, so viele wie nötig. Entra Agent ID erlaubt es, Rollen und Scopes gezielt auf einzelne Agenten zuzuschneiden, statt breite Standardrollen zu vergeben.
Zusätzlich solltest du Conditional Access nicht nur für Nutzer, sondern auch für Agenten-Identitäten einsetzen. So kannst du etwa festlegen, aus welchen Netzwerken heraus ein Agent überhaupt agieren darf.
Connect-MgGraph -Scopes "Application.Read.All"
Get-MgServicePrincipal -Filter "servicePrincipalType eq 'ManagedIdentity'" |
Where-Object { $_.Tags -contains "AgentIdentity" }
Der Befehl verbindet sich mit der Graph-API und listet alle Service Principals auf, die als Agenten-Identität markiert sind. So bekommst du zuerst einen Überblick, bevor du einzelne Rechte anpasst.
New-MgIdentityConditionalAccessPolicy -DisplayName "CA-Agent-Restrict" `
-Conditions @{ Applications = @{ IncludeApplications = @("<agent-app-id>") } } `
-GrantControls @{ Operator = "AND"; BuiltInControls = @("block") } `
-State "enabledForReportingButNotEnforced"
Damit legst du eine Conditional-Access-Regel an, die gezielt auf die App-ID eines einzelnen Agenten wirkt. Der Report-only-Modus ist wichtig, um erst zu sehen, was blockiert würde, bevor du live schaltest.
Wie erkennst du ungewöhnliches Verhalten eines Agenten im Monitoring?
Ohne laufende Auswertung der Sign-in-Logs bleibt jede Rechtevergabe Stückwerk. Entra Agent ID protokolliert Anmeldungen und Aktivitäten genauso wie bei Nutzerkonten, daher lassen sich Auffälligkeiten mit denselben Bordmitteln finden.
Get-MgAuditLogSignIn -Filter "appId eq '<agent-app-id>'" -Top 50 |
Select-Object CreatedDateTime, IpAddress, RiskLevelDuringSignIn, Status
Diese Abfrage zeigt die letzten Anmeldungen eines bestimmten Agenten samt Risikostufe und Status. Auffällige IP-Adressen, ungewöhnliche Uhrzeiten oder gehäufte Fehlschläge solltest du automatisch als Alert weiterleiten, etwa über Sentinel oder Entra-eigene Risk-Detections. Ähnliche Erkennungsmuster nutzt du bereits, wenn du Risky Sign-ins nach Drittanbieter-Leaks auswertest.
Welche Punkte gehören auf die Governance-Checkliste vor dem Rollout?
Bevor ein Agent produktiv geht, lohnt sich eine kurze, aber verbindliche Prüfliste:
- Eigene Entra Agent ID statt geteiltem Dienstkonto zuweisen
- Rollen und Scopes explizit definieren, keine Standardrollen übernehmen
- Conditional Access zuerst im Report-only-Modus testen
- Sign-in-Logs des Agenten in die zentrale Überwachung einbinden
- Verantwortlichen Owner im Fachbereich benennen, der den Agenten betreut
- Ablaufdatum oder regelmäßige Rezertifizierung der Berechtigungen festlegen
Diese Punkte ersetzen keine vollständige Risikoanalyse, geben dir aber eine solide Basis, bevor ein Agent Zugriff auf echte Unternehmensdaten bekommt. Wer bereits KI-gestützte Angriffe auf dem Schirm hat, sollte Agenten-Governance als logische Ergänzung dazu behandeln.
Ist Entra Agent ID schon allgemein verfügbar oder noch in der Preview?
Microsoft führt Entra Agent ID aktuell schrittweise ein, viele Funktionen laufen zunächst in der Preview-Phase. Das bedeutet, dass sich Details zu Lizenzierung, Rollout-Tempo und einzelnen Features noch ändern können, bevor die allgemeine Verfügbarkeit erreicht ist.
Für dich heißt das: Plane den Rollout in Testumgebungen, beobachte die Ankündigungen im Microsoft-365-Nachrichtencenter und warte mit unternehmenskritischen Agenten, bis die entsprechenden Funktionen final freigegeben sind. Wer schon heute eigene Agenten über Copilot Studio betreibt, sollte trotzdem nicht auf GA warten, sondern die verfügbaren Preview-Funktionen von Entra Agent ID bereits jetzt zur Absicherung nutzen.
Häufige Fehler
- Agenten laufen unter geteilten Dienstkonten statt einer eigenen Entra Agent ID – richte für jeden produktiven Agenten eine eigene Identität ein.
- Rechte werden großzügig statt sparsam vergeben, weil es schneller geht – definiere Rollen und Scopes explizit für den jeweiligen Anwendungsfall.
- Sign-in-Logs von Agenten werden nicht ausgewertet, weil sie im Alltag untergehen – binde sie fest in bestehende Alerting-Prozesse ein.
- Conditional-Access-Regeln werden direkt im Enforce-Modus aktiviert – teste sie zuerst im Report-only-Modus, um Blockaden zu vermeiden.
- Niemand fühlt sich für den Agenten verantwortlich, sobald das Projekt live ist – benenne von Anfang an einen festen Owner im Fachbereich.