Entra Agent ID: KI-Agenten richtig absichern

Das Wichtigste in Kürze:

• Entra Agent ID bildet KI-Agenten als eigene Identitätsklasse in Entra ID ab. Vier neue Objekttypen bilden die Grundlage,
• Jede Agentidentität kann einem menschlichen Sponsor zugewiesen werden, der über Lebenszyklus und Zugriff entscheidet.
• Berechtigungen laufen über Zugriffspakete mit Genehmigungsworkflow und Ablaufdatum statt über dauerhafte Application Permissions.

Ihr kennt das sicher aus dem eigenen Tenant: Unter den Enterprise Applications liegen App-Registrierungen, die niemand mehr zuordnen kann. Irgendwann hat mal jemand aus der Fachabteilung eine angelegt, weil ein Automatisierungs-Tool auf SharePoint oder Exchange zugreifen musste. Die Berechtigungen? Application Permissions, tenantweit gültig, ohne Ablaufdatum. In Access Reviews tauchen sie nicht auf, und ein Verantwortlicher ist nirgends hinterlegt.

Mit den KI-Agenten aus Copilot Studio oder Microsoft Foundry wiederholt sich dieses Muster gerade – nur deutlich schneller. So ein Agent ist in einer Stunde gebaut. Er braucht Zugriff auf Postfächer oder SharePoint-Bibliotheken, bekommt eine App-Registrierung mit den üblichen Application Permissions und läuft von da an vor sich hin. Auch dann noch, wenn die Kollegin oder der Kollege, der ihn gebaut hat, das Unternehmen längst verlassen hat. Benachrichtigt wird niemand.

Microsoft hat mit Entra Agent ID ein Framework vorgelegt, das genau an dieser Stelle ansetzt. Allgemein verfügbar ist es seit Mai 2026. Grund genug, sich das Ganze mal näher anzusehen.

Was ist Entra Agent ID?

Entra Agent ID ist ein Identitäts- und Sicherheitsframework innerhalb von Microsoft Entra, das KI-Agenten als eigene Identitätsklasse im Verzeichnis führt. Agenten laufen damit nicht mehr über klassische App-Registrierungen und Service Principals, sondern bekommen dedizierte Verzeichnisobjekte – mit eigenem Lebenszyklus, eigenen Berechtigungen und einer zugewiesenen verantwortlichen Person.

Konkret kommen vier neue Objekttypen dazu:

• Agent Identity Blueprint – die Schablone, in der Berechtigungen und Policies definiert werden. Alles, was hier steht, vererbt sich an die abgeleiteten Agenten.
• Agent Identity Blueprint Principal – das Gegenstück zum Blueprint in einem fremden Tenant. In Multi-Tenant-Szenarien wird er im Zielmandanten verankert und darf dort Agent Identities erzeugen.
• Agent Identity – der einzelne Agent als Verzeichnisobjekt.
• Agent User – ein optionales Benutzerobjekt pro Agent Identity, für den Fall, dass der Agent im Benutzerkontext agieren soll.

Authentifiziert wird über OAuth 2.0, unterstützt werden außerdem das Model Context Protocol (MCP) und Agent-to-Agent-Kommunikation (A2A). Wer tiefer einsteigen will, findet die vollständige Doku in der Microsoft-Learn-Übersicht zu Entra Agent ID; die Governance-Mechanismen sind unter „Verwalten von Agentidentitäten" im Detail beschrieben.

Das Sponsor-Konzept

Jede Agent Identity lässt sich einem menschlichen Sponsor zuweisen. Dieser Sponsor entscheidet über Lebenszyklus und Zugriff der Identität: Er genehmigt Berechtigungsanfragen, verlängert oder beendet Zuweisungen und kann den Agenten bei Bedarf deaktivieren.

Verlässt der Sponsor die Organisation, geht das Sponsoring automatisch an die vorgesetzte Person über. Lifecycle Workflows informieren beide Seiten vorab über die Änderung. Die laufende Verwaltung passiert im Portal „Mein Konto" – dort können Sponsoren und Besitzer Agenten aktivieren oder deaktivieren und einsehen, worauf zugegriffen wurde.

Das mag nach Verwaltungsaufwand klingen, löst aber ein sehr reales Problem. Ohne benannten Verantwortlichen kann schlicht niemand beurteilen, ob ein Agent eine bestimmte Berechtigung überhaupt noch braucht. Wer schon einmal versucht hat, verwaiste Service Principals aufzuräumen, weiß, wie mühsam das ist.

Berechtigungen über Zugriffspakete

Agent Identities starten mit eingeschränkten Rechten. Sie erben delegierte OAuth-2-Scopes vom übergeordneten Blueprint – alles, was darüber hinausgeht, läuft über das Entitlement Management, also über Zugriffspakete. Darin können Sicherheitsgruppen-Mitgliedschaften stecken, Anwendungs-OAuth-Berechtigungen inklusive Graph Application Permissions oder auch Entra-Rollen.

An so ein Paket kommt der Agent auf drei Wegen: Die Agent Identity fordert es programmatisch selbst an, der Sponsor beantragt es in ihrem Namen, oder ein Administrator weist es direkt zu.

Der Ablauf selbst ist derselbe wie bei Benutzern. Rückt das Enddatum einer Zuweisung näher, bekommt der Sponsor eine Benachrichtigung und kann eine Verlängerung beantragen – das startet einen neuen Genehmigungszyklus. Reagiert niemand, endet die Zuweisung automatisch und der Zugriff ist weg.

Das ist der eigentliche Gewinn: Agentenberechtigungen bekommen damit zum ersten Mal ein Ablaufdatum, einen Genehmigungsworkflow und eine Rezertifizierung. Bei klassischen Application Permissions gab es all das schlicht nicht.

Wichtig für die Übergangsphase: Solange bestehende Agenten noch keine Entra Agent IDs nutzen, braucht es zusätzlich eine Zuweisungsrichtlinie mit der Option „Alle Service Principals". Sonst laufen die bisherigen Automatisierungen komplett an der neuen Governance vorbei.

Conditional Access für Agenten

Zugriffspakete bestimmen also, worauf ein Agent zugreifen darf. Die Frage, unter welchen Bedingungen das passieren darf, beantwortet Conditional Access. Die Richtlinien bewerten Kontext und Risiko des Agenten – inklusive des Identitätsrisikos aus Entra ID Protection –, bevor Zugriff gewährt wird.

An dieser Stelle zahlt sich der Blueprint aus: Conditional-Access-Policies lassen sich auf Blueprint-Ebene hinterlegen, und alle daraus erstellten Agent Identities erben sie automatisch. Eine Policy pro Agententyp lässt sich skalieren, eine Policy für jeden einzelnen Agenten nicht. Bei zehn Agenten mag das noch egal sein, bei hundert nicht mehr. Sämtliche Authentifizierungs- und Aktivitätsvorgänge werden übrigens protokolliert.

Wo Agentidentitäten automatisch entstehen

Ein Punkt, der leicht untergeht: Agentidentitäten muss niemand manuell anlegen. Microsoft Foundry erzeugt beim ersten Agenten in einem Projekt automatisch einen Standard-Blueprint samt Standard-Agent-Identity. Beim Veröffentlichen entsteht ein eigener Blueprint mit eigener Identität. Copilot Studio lässt sich genauso konfigurieren, und auch App Service und Azure Functions können die Plattform nutzen.

Praktisch, aber es bedeutet eben auch: Sobald irgendwo im Unternehmen ein Foundry-Projekt existiert, sind Agentidentitäten im Verzeichnis. Wer den Bestand nicht regelmäßig prüft, hat schnell wieder dieselbe Intransparenz wie bei den unkontrollierten App-Registrierungen, nur mit anderen Objekttypen.

Auch Agenten abseits der Microsoft-Welt lassen sich einbinden. Plattformen wie AWS Bedrock oder n8n werden über das Entra ID Auth SDK (Sidecar) oder Workload Identity Federation integriert.

Lizenzierung

Entra Agent ID selbst steht allen Entra-Kunden zur Verfügung. Die Sicherheitsfeatures für Agenten – also Conditional Access, Identity Protection und Governance – setzen allerdings Microsoft Agent 365 voraus. Agent 365 steckt in Microsoft 365 E7 und ist als Add-on für E5, A5 oder Business Premium erhältlich. Für die Governance-Funktionen kommt zusätzlich mindestens Entra ID P1 beziehungsweise Microsoft 365 E3 dazu.

Tipps zur Umsetzung

Am Anfang steht immer die Bestandsaufnahme. Welche Agenten laufen bereits? Welche App-Registrierungen und Service Principals gehören dazu? Und welche der vergebenen Berechtigungen werden tatsächlich genutzt? Die Antworten liefern die Sign-in-Logs und die Berechtigungsübersicht unter Enterprise Applications.

Schaut dabei nicht nur auf Objekte, die offensichtlich als Agent erkennbar sind. Viele Copilot-Studio-Agenten laufen heute noch als gewöhnliche App-Registrierungen mit Namen wie „PowerApp_xyz" oder dem Default-Namen des Projekts. Filtert in den Enterprise Applications nach Application Permissions, die auf Microsoft Graph, Exchange Online oder SharePoint Online zugreifen, und gleicht die Ergebnisse mit den Sign-in-Logs der letzten 30 Tage ab. Was sich dort nicht zeigt, wird entweder nicht genutzt oder authentifiziert sich über einen Weg, der nicht geloggt wird – beides Fälle, die geklärt werden müssen.

Beim Blueprint-Design hat es sich bewährt, nach Risiko und Einsatzzweck zu gruppieren und nicht nach Abteilung – schlicht weil Conditional-Access-Policies und Zugriffspakete am Blueprint hängen. Ein Agent, der nur eine SharePoint-Liste befüllt, gehört in einen anderen Blueprint als einer, der Postfächer liest und Daten in Drittsysteme schreibt. Drei bis fünf Blueprints reichen für die meisten Organisationen aus. Beispiel: ein Blueprint für lesende Agenten ohne externe Datenflüsse, einer für Agenten mit Schreibzugriff auf Collaboration-Workloads, einer für Agenten mit Zugriff auf Exchange oder personenbezogene Daten. Wer mehr braucht, fügt später welche hinzu – weniger Blueprints am Anfang heißt weniger Policies, die gepflegt werden müssen.

Für die Sponsoren-Zuweisung braucht es eine klare Regel, die auch bei Personalwechseln funktioniert. Ein guter Weg ist, nicht den User zu benennen, der den Agenten gebaut hat, sondern den fachlichen Verantwortlichen des Prozesses, den der Agent abbildet. Wenn der HR-Agent Bewerbungen verarbeitet, ist der Sponsor jemand aus der HR-Leitung, nicht der Power-User, der den Agent in Copilot Studio zusammengebaut hat.

Bei den Zugriffspaketen solltet ihr lieber granular starten und später erweitern. Schnürt nicht ein Paket mit allen Berechtigungen, die ein Agententyp jemals brauchen könnte, sondern trennt nach Ressource. Ein Paket für SharePoint-Zugriff, ein separates für Exchange, ein drittes für externe APIs über Custom Connectors. So lässt sich bei einer erneuten Bewertung gezielt entscheiden, welcher Zugriff noch benötigt wird, statt das gesamte Bundle durchzuwinken oder abzulehnen. Setzt die Ablaufdaten auf 90 oder 180 Tage. Das erzwingt regelmäßige Reviews, ohne dass der operative Betrieb alle paar Wochen unterbrochen wird.

Für die Übergangsphase, in der Alt- und Neu-Modell parallel existieren, lohnt sich ein Migrationstag im Kalender. Nehmt euch die Ergebnisse der Bestandsaufnahme, priorisiert nach Risikoklasse und migriert die kritischsten Agenten zuerst auf Agent Identities. Die übrigen können zunächst über die Zuweisungsrichtlinie „Alle Service Principals" in die Governance eingebunden werden, bis sie ebenfalls umgestellt sind. Lasst die alten App-Registrierungen nicht parallel weiterlaufen – sonst habt ihr für denselben Agenten zwei Identitäten im Verzeichnis und wisst bald nicht mehr, welche davon aktiv genutzt wird.

Und schließlich die Bestandsüberwachung im laufenden Betrieb. Wie zuvor bereits beschrieben, entstehen Agentidentitäten auch automatisch. Richtet eine regelmäßige Prüfung ein – etwa monatlich – die neue Agent Identities und Blueprints im Verzeichnis identifiziert und gegen eure Blueprint-Struktur abgleicht. Neue Objekte ohne zugewiesenen Sponsor oder mit Standard-Berechtigungen aus der automatischen Erstellung fallen so auf, bevor sie in Vergessenheit geraten.