Microsoft Entra Agent ID ist eine dedizierte Identitätsschicht für KI-Agenten, aktuell in öffentlicher Preview, die jedem Agenten eine eigene Identität in Microsoft Entra zuweist. Agenten unterliegen damit denselben Conditional-Access-Richtlinien, Identity-Governance-Workflows und Risikoerkennungssystemen wie menschliche Nutzer. Vorgestellt auf der RSAC 2026, bildet es das Identitätsfundament von Microsoft Agent 365 und ist die erste große Cloud-IAM-Plattform, die einen eigenen Identitätstyp speziell für autonome KI-Agenten einführt, statt sie in Service-Accounts oder Managed Identities zu pressen.
Der Unterschied klingt technisch, ist aber fundamental. Service-Accounts wurden für vorhersagbare, vorprogrammierte Integrationen entworfen. KI-Agenten sind autonom, nicht-deterministisch und können Sub-Agenten erzeugen. Einen Service-Account auf einen KI-Agenten zu kleben ist wie einem autonomen Fuhrpark einen einzelnen Führerschein auszustellen und zu hoffen, dass der Papierkram reicht.
Warum bestehende Identitätsmodelle versagen
Der 2026 Microsoft Digital Defense Report zeigt: 97% aller Organisationen hatten im vergangenen Jahr einen Identitäts- oder Netzwerkzugriffs-Vorfall, bei 70% davon war KI-Aktivität beteiligt. Die Ursache liegt auf der Hand: Die meisten Unternehmen authentifizieren ihre KI-Agenten mit statischen API-Schlüsseln oder geteilten Zugangsdaten, die nie für autonome Systeme gedacht waren.
Ein Service-Account geht davon aus, dass eine Identität einer Anwendung zugeordnet ist, die einen vorhersagbaren Satz von Operationen ausführt. Ein KI-Agent verarbeitet um 9:00 Uhr eine Kundenrückerstattung, analysiert um 9:01 Uhr Finanzdaten und startet um 9:02 Uhr drei Sub-Agenten für parallele Aufgaben. Jeder dieser Sub-Agenten braucht eigene, eingeschränkte Zugriffsrechte. Statische Credentials können das nicht abbilden. Service Principals in Entra ID kommen näher, aber ihnen fehlen agentenspezifische Metadaten, Discovery-Mechanismen und die Verhaltenssignale, die erkennen, wann ein Agent vom Kurs abweicht.
Die CSA/Strata-Umfrage unter 285 Sicherheitsexperten ergab: Nur 18% der Security-Verantwortlichen sind sich sicher, dass ihr aktuelles IAM Agent-Identitäten bewältigen kann. Die anderen 82% wissen, dass etwas nicht stimmt. Entra Agent ID ist Microsofts Antwort darauf, wie die Lösung aussehen sollte.
Die drei Probleme, die Agent ID löst
Traditionelle IAM-Frameworks scheitern bei Agenten in drei konkreten Bereichen. Agent-Identitäten sind nicht persistent wie Nutzer-Identitäten (Agenten werden ständig gestartet und beendet). Agent-Berechtigungen können nicht statisch sein (derselbe Agent braucht je nach Aufgabe unterschiedlichen Zugriff). Und Agent-Risiken lassen sich nicht wie Nutzer-Risiken bewerten (man kann einem Python-Prozess keine MFA-Abfrage schicken).
Entra Agent ID adressiert jeden dieser Punkte: kurzlebige, aber nachverfolgbare Identitäten, Just-in-Time-Token mit eingeschränktem Geltungsbereich und verhaltensbasierte Anomalieerkennung statt interaktiver Authentifizierungsabfragen.
Wie Entra Agent ID unter der Haube funktioniert
Entra Agent ID führt einen neuen Identitätstyp in Microsoft Entra ein, der neben Nutzern, Gruppen und Workload-Identitäten existiert. Jeder Agent, der über Microsoft Foundry, Copilot Studio oder einen Agent-365-Ökosystempartner registriert wird, erhält ein eigenes Agent-Identity-Objekt mit eindeutigem Identifikator, zugehörigen Metadaten (Fähigkeiten, Aufgaben, Protokolle) und einer Verknüpfung zum verantwortlichen Menschen oder Team.
Agent-Autodiscovery
Eines der schwierigsten Probleme bei der Agent-Governance ist das Auffinden bereits existierender Agenten. Microsoft hat vor dem Launch von Agent 365 über 500.000 Agenten in der eigenen Organisation entdeckt. Die meisten Unternehmen haben ein ähnliches Problem: Teams erstellen Agenten schneller, als die IT sie erfassen kann.
Entra Agent ID enthält einen Autodiscovery-Mechanismus, der den gesamten Tenant nach Agenten auf unterstützten Plattformen scannt und sie automatisch registriert. Entdeckte Agenten erscheinen in einem zentralen Register, wo Admins ihre Fähigkeiten prüfen, Verantwortliche zuweisen und Governance-Richtlinien anwenden können. Das ist kein optionales Inventar-Management. Es ist die Voraussetzung für alles Weitere: Was man nicht sieht, kann man nicht steuern.
Just-in-Time-Token mit eingeschränktem Geltungsbereich
Agent-Identitäten nutzen ein Least-Privilege-Modell, bei dem Agenten Just-in-Time-Token für exakt die Ressourcen anfordern, die sie benötigen. Das unterscheidet sich von Service-Accounts, die typischerweise breite, dauerhafte Zugangsdaten besitzen. Ein Agent, der ein Kundensupport-Ticket bearbeitet, bekommt ein Token mit Zugriff auf das CRM und das Ticketsystem, gültig für die Dauer dieser Aufgabe, und sonst nichts.
Wenn die Aufgabe abgeschlossen ist, läuft das Token ab. Wenn eine neue Aufgabe andere Ressourcen erfordert, fordert der Agent ein neues Token mit anderen Geltungsbereichen an. Erzeugt der Agent einen Sub-Agenten, erhält dieser eine eigene Identität und ein eigenes Token, wodurch eine nachverfolgbare Delegationskette entsteht. Das ist die Granularität, die die NIST Zero Trust Architecture fordert, die aber die meisten Organisationen für Non-Human Identities nie erreicht haben.
Conditional Access für Agenten
Die Conditional-Access-Engine bewertet Agent-Zugriffsanfragen jetzt mit agentenspezifischer Logik. Sie behandelt Agenten als vollwertige Identitäten und wendet dasselbe Richtlinien-Framework an: kontextbezogene Empfehlungen, phasenweise Einführung und automatisierte Least-Privilege-Durchsetzung, aber angepasst an das tatsächliche Verhalten von Agenten.
In der Praxis können Richtlinien etwa so aussehen: “Agenten, die auf Finanzdaten zugreifen, müssen von genehmigter Infrastruktur stammen, innerhalb der Geschäftszeiten arbeiten und nur auf Auslösung durch einen autorisierten Menschen reagieren.” Die Policy-Engine bewertet den Agentenkontext (wem gehört er, auf welcher Plattform läuft er, worauf will er zugreifen) und Risikosignale (verhält sich dieser Agent anders als üblich?), bevor sie Zugriff gewährt oder verweigert.
Microsoft hat zudem Microsoft-verwaltete Richtlinien eingeführt, die risikoreichen Agent-Zugriff automatisch als Basis blockieren. Organisationen können eigene Richtlinien darüber hinaus konfigurieren.
Entra ID Protection für Agent-Anomalien
Entra ID Protection, das bereits anomale menschliche Anmeldungen erkennt (unbekannte Standorte, unmögliche Reisen, geleakte Zugangsdaten), erstreckt sich jetzt auf Agent-Identitäten. Das System erstellt Verhaltensbaselines für jeden Agenten: auf welche Ressourcen er normalerweise zugreift, wie häufig, zu welchen Zeiten und in welchen Mustern.
Wenn ein Agent von seiner Baseline abweicht, etwa wenn ein Kundenservice-Agent plötzlich um 3 Uhr nachts HR-Datenbanken abfragt, markiert Entra ID Protection die Anomalie und löst risikobasierte Richtlinien aus. Je nach Konfiguration kann das bedeuten: zusätzliche Autorisierung durch den menschlichen Verantwortlichen, Drosselung des Agent-Zugriffs oder vollständige Quarantäne des Agenten.
Dieser verhaltensbasierte Ansatz ist notwendig, weil Agenten auf interaktive Authentifizierungsabfragen nicht reagieren können. Man kann einen API-Aufruf nicht nach einem zweiten Faktor fragen. Stattdessen beobachtet das System, was Agenten tun, und reagiert, wenn das Verhalten nicht mehr den Erwartungen entspricht. Das Sicherheitsmodell ähnelt eher EDR (Endpoint Detection and Response) als traditionellem IAM.
Wie Risikosignale fließen
Agent-Risikosignale fließen in dieselbe Conditional-Access-Engine, die auch Nutzerrisiken verarbeitet. Sicherheitsteams können Richtlinien konfigurieren, die Agent-Risiko mit anderen Bedingungen kombinieren: “Wenn das Agent-Risiko hoch ist UND die Zielressource als sensibel eingestuft ist, Zugriff blockieren und das Security Operations Center benachrichtigen.” Diese Integration bedeutet, dass Agent-Sicherheit keinen separaten Monitoring-Stack erfordert. Sie greift auf Microsoft Defender und Purview zurück, genau wie die Nutzersicherheit es bereits tut.
Was das für Unternehmen bedeutet, die bereits Agenten betreiben
Wer Microsoft Entra ID für Identity Governance nutzt, erweitert es auf Agenten durch Konfiguration, nicht durch einen Plattformwechsel. Die Agent-Identity-Objekte leben im selben Verzeichnis, nutzen dieselbe Policy-Engine und erzeugen Audit-Logs im selben Format. Das Security-Team kennt die Werkzeuge bereits.
Die schwierigere Frage ist, ob der Microsoft-zentrische Scope eine Einschränkung darstellt. Entra Agent ID unterstützt aktuell Agenten aus Microsoft Foundry, Copilot Studio und Agent-365-Ökosystempartnern wie Adobe, Databricks, SAP, ServiceNow und Workday. Wer Agenten auf LangChain, CrewAI oder eigenen Frameworks betreibt, muss sie über die Entra-Identity-Platform-APIs integrieren oder einen Drittanbieter wie Oasis Security oder Aembit einsetzen.
Für Unternehmen im DACH-Raum kommt ein zusätzlicher Aspekt hinzu: Die DSGVO verlangt nachweisbare Zugriffskontrolle für automatisierte Systeme, die personenbezogene Daten verarbeiten. Entra Agent ID liefert die Audit-Trails, die Datenschutzbeauftragte für Artikel-30-Verzeichnisse benötigen. Und mit dem EU AI Act, der ab August 2026 durchgesetzt wird, brauchen Hochrisiko-KI-Systeme dokumentierte Governance-Prozesse. Eine zentralisierte Agent-Identitätsschicht ist dafür praktisch Pflicht.
Preview-Einschränkungen im Blick behalten
Entra Agent ID ist in der Preview, nicht GA. Microsofts Dokumentation weist ausdrücklich darauf hin, dass das Produkt “vor der Veröffentlichung wesentlich geändert werden kann.” Wichtige Einschränkungen:
- Agent 365 GA am 1. Mai 2026. Die Timeline von Entra Agent ID ist daran gekoppelt. Produktiv-Governance nicht auf Preview-APIs aufbauen.
- Partnerökosystem-Abdeckung variiert. Nicht alle Partner unterstützen den vollen Identitäts-Lebenszyklus. Den Integrationsstatus des eigenen Anbieters prüfen.
- Verhaltensbaselines brauchen Zeit. Entra ID Protection benötigt Beobachtungsdaten, bevor es Anomalien melden kann. Neue Agent-Deployments haben eine blinde Phase.
- Multi-Cloud-Lücken bestehen fort. Agenten, die über Azure, AWS und GCP hinweg arbeiten, erfordern zusätzliche Identity-Federation-Arbeit.
Die Wettbewerbssituation
Microsoft ist nicht der einzige Anbieter, der an Agent-Identity-Infrastruktur baut. Oasis Security bietet eine plattformunabhängige Agent-Governance-Schicht. Aembit spezialisiert sich auf Workload-to-Workload-Identität. Geordie AI baut eine Steuerungsschicht speziell für Agent-Security-Governance. Und Googles Agent2Agent-Protokoll enthält Identity-Konzepte, ist aber stärker auf Interoperabilität als auf Governance ausgerichtet.
Was Microsoft mitbringt, haben die anderen nicht: die installierte Basis. Mit 400 Millionen monatlich aktiven kommerziellen Nutzern auf Microsoft 365 und Entra ID, das bereits menschliche Identitäten verwaltet, eliminiert die Erweiterung auf Agenten das Problem “noch ein Identity-Provider.” Für Organisationen im Microsoft-Ökosystem ist das der Weg des geringsten Widerstands. Für alle anderen bleibt die Frage, ob ein einzelner Anbieter alle Agent-Identitäten verwalten sollte, oder ob ein plattformübergreifender Ansatz sinnvoller ist.
Häufig gestellte Fragen
Was ist Microsoft Entra Agent ID?
Microsoft Entra Agent ID ist eine dedizierte Identitätsschicht innerhalb von Microsoft Entra, die KI-Agenten eigene Identitäten zuweist und sie in dieselben Conditional-Access-, Identity-Governance- und Risikoerkennungs-Workflows einbindet wie menschliche Nutzer. Es befindet sich aktuell in der öffentlichen Preview und bildet das Identitätsfundament von Microsoft Agent 365.
Wie funktioniert Conditional Access für KI-Agenten in Entra Agent ID?
Conditional Access bewertet Agent-Zugriffsanfragen mit agentenspezifischer Logik und berücksichtigt den Kontext: wem gehört der Agent, auf welcher Plattform läuft er und worauf will er zugreifen. Richtlinien können Bedingungen wie genehmigte Infrastruktur, Geschäftszeiten und autorisierte menschliche Auslöser durchsetzen. Microsoft-verwaltete Richtlinien blockieren automatisch risikoreichen Agent-Zugriff als Baseline.
Funktioniert Entra Agent ID mit Nicht-Microsoft-KI-Agent-Frameworks?
Entra Agent ID unterstützt nativ Agenten aus Microsoft Foundry, Copilot Studio und Agent-365-Ökosystempartnern wie Adobe, Databricks, SAP, ServiceNow und Workday. Agenten auf LangChain, CrewAI oder eigenen Frameworks müssen über die Entra-Identity-Platform-APIs integriert werden oder einen Drittanbieter für Agent-Identität nutzen.
Wann wird Microsoft Entra Agent ID allgemein verfügbar sein?
Entra Agent ID befindet sich seit März 2026 in der öffentlichen Preview. Die Timeline ist an Microsoft Agent 365 gekoppelt, das am 1. Mai 2026 allgemein verfügbar wird. Microsoft weist darauf hin, dass das Preview-Produkt vor der Veröffentlichung wesentlich geändert werden kann.
Ist Entra Agent ID relevant für die DSGVO- und EU-AI-Act-Compliance?
Ja. Die DSGVO verlangt nachweisbare Zugriffskontrolle für automatisierte Systeme, die personenbezogene Daten verarbeiten. Entra Agent ID liefert die nötigen Audit-Trails. Mit dem EU AI Act, der ab August 2026 durchgesetzt wird, brauchen Hochrisiko-KI-Systeme dokumentierte Governance-Prozesse, wofür eine zentralisierte Agent-Identitätsschicht praktisch Pflicht ist.