In den vergangenen Tagen habe ich die neue Vorschau von Microsoft Entra Agent ID in mehreren Tenants getestet. Seit einiger Zeit war absehbar, dass autonome Agenten, die in Copilot Studio oder Azure AI Foundry entstehen und anschließend in Microsoft 365 oder Azure laufen, ein neues Governance-Problem mit sich bringen. Mit klassischen Service Principals oder App-Registrierungen haben solche Agenten wenig gemein. Sie arbeiten selbstständig, entscheiden, greifen auf Daten zu und stoßen Workflows an. Beim Thema Identität landete man bisher trotzdem meist in einem Durcheinander aus App-Registrierungen. Entra Agent ID gibt Agenten nun eine eigene, im Verzeichnis sichtbare Identität – und darauf haben viele Admins lange gewartet.

Microsoft Entra Agent ID macht Agenten im Verzeichnis sichtbar

Microsoft hat Entra Agent ID auf der Build 2025 vorgestellt, derzeit ist die Funktion als Public Preview verfügbar. Agenten aus Copilot Studio oder Azure AI Foundry bekommen damit automatisch eine eigene Identität in Entra ID. Im Entra Admin Center findet man sie unter „Enterprise-Anwendungen“, wo eine neue Ansicht die Agenten beider Plattformen gesondert auflistet. Agenten lassen sich so genauso inventarisieren, überwachen und absichern wie andere Identitäten.

Das ist deshalb wichtig, weil Agenten in kurzer Zeit zu echten Akteuren im Tenant werden. Sie sind längst mehr als Hilfsprogramme: Sie erhalten Berechtigungen, verändern Daten und hängen nicht selten an kritischen Prozessen. Least Privilege, Lifecycle-Management und Ownership lassen sich auf diese nicht-menschlichen Akteure nur übertragen, wenn ihre Identitäten sauber zugeordnet sind.

Bei Agenten-Identitäten klafft bisher eine Governance-Lücke

Agent ID führt das Konzept der Workload-Identitäten konsequent weiter (Übersicht zu Workload-Identitäten). App-Registrierungen und verwaltete Identitäten nutzen wir für Anwendungen schon seit Jahren. Bei Agenten fehlen dagegen oft die einfachsten Antworten. Wer hat den Agenten angelegt? Gibt es im Unternehmen überhaupt noch jemanden, dem er gehört? Welche Berechtigungen hat er mit der Zeit angesammelt, und braucht er die wirklich alle?

In vielen Umgebungen, die ich kenne, liegt die Governance von Agenten weit unter dem Niveau, das für menschliche Benutzer oder klassische Apps selbstverständlich ist. Agenten-Identitäten führen ein Schattendasein, tauchen kaum in einem Inventar auf, und niemand hat geklärt, was passiert, wenn der Betreiber das Unternehmen verlässt. Mit Microsoft Entra Agent ID lässt sich das jetzt deutlich strenger regeln:

  • Agenten und deren Eigentümer*innen erfassen
  • Verantwortlichkeiten eindeutig zuordnen (Sponsor-Konzept)
  • Lifecycle-Prozesse einführen (z. B. Entzug nach Projektende)
  • Conditional Access direkt auf Agenten anwenden
  • Berechtigungen nach dem Least-Privilege-Prinzip kontrollieren

Wie Workload-Identitäten grundsätzlich funktionieren und wie man sie absichert, habe ich im Beitrag Workload-Identitäten in Entra ID: Managed Identities vs. App-Registrierungen beschrieben.

Admins bekommen erstmals ein Inventar ihrer Agenten

Die Vorschau von Entra Agent ID bringt im Entra Admin Center zum ersten Mal eine zusammengeführte Übersicht. Unter „Enterprise-Anwendungen“ → „Agenten“ ist sofort zu erkennen, welche Agenten aus Copilot Studio und Azure AI Foundry im Tenant vorhanden sind. Neben technischen Details zeigt die Ansicht vor allem, wer den Agenten ursprünglich erstellt hat und – sofern eingetragen – wer als Sponsor*in verantwortlich ist.

Wer die Agentenübersicht heute öffnet, stößt häufig auf Altlasten, auf „verwaiste“ Agenten oder auf solche, die mit viel mehr Rechten laufen als nötig. Am Anfang sollte deshalb eine Bestandsaufnahme stehen, bei der man auch die Ownership klärt. Dabei hilft das neue Attribut „Sponsor“, das die fachlich verantwortliche Person benennt. Microsoft setzt dieses Konzept inzwischen auch in anderen Governance-Funktionen wie Access Packages ein. Fehlen bei einem Agenten Sponsor und Besitzer, gehört er auf den Prüfstand: Wird er überhaupt noch gebraucht?

Praxis-Tipp: Agenten ohne eindeutigen Besitzer oder Sponsor stellen ein Risiko dar. In regelmäßigen Reviews spüre ich solche Identitäten auf und entferne sie anschließend oder „repatriiere“ sie – am besten automatisiert mit Access Reviews oder Lifecycle-Workflows.

Conditional Access und Least Privilege greifen schon heute bei Agenten

Obwohl die technische Umsetzung noch im Preview-Stadium steckt, kann man Agenten bereits jetzt absichern und nicht bloß inventarisieren. Conditional-Access-Richtlinien lassen sich auf Agenten-Identitäten anwenden, um etwa den Zugriff auf sensible APIs oder Daten zu regeln. Allerdings stellen sich hier andere Fragen als bei menschlichen Identitäten. Multifaktor-Authentifizierung oder standortbasierte Regeln laufen oft ins Leere, umso mehr kommt es auf strikte Rollen- und Berechtigungskonzepte an. Spannend finde ich außerdem, dass künftig Just-in-Time-Berechtigungen oder automatisierte Rezertifizierungen gezielt für Agenten möglich sein sollen. Microsoft beschreibt das im Beitrag Zero Trust für die „agentische Workforce“.

In Copilot Studio lassen sich Governance-Mechanismen schon heute umsetzen, und das sollte man auch tun. Sensible Umgebungen, Freigaberichtlinien, DLP-Regeln und ein nachvollziehbarer Veröffentlichungsprozess gehören zum Pflichtprogramm. Details dazu findet ihr im Beitrag Copilot-Studio-Governance: Risiken und Kontrollen 2024.

Jeder Agent erhält im Tenant automatisch eine eigene Identität

Im folgenden Diagramm sieht man, wie ein Agent aus Copilot Studio oder Azure AI Foundry automatisch zu seiner Identität in Entra ID kommt. Die Verknüpfung mit Besitzer und Sponsor ist direkt im Verzeichnis nachvollziehbar:

flowchart TD
    User["Benutzer erstellt Agent" ] --> CopilotStudio["Copilot Studio/Azure AI Foundry"]
    CopilotStudio --> AgentID["Agent ID in Entra ID"]
    AgentID --> Owner["Besitzer"]
    AgentID --> Sponsor["Sponsor"]
    AgentID --> EnterpriseApps["Enterprise-Anwendungen/Agenten-View"]

Abbildung: Automatische Zuordnung einer Agent ID zu Agenten aus Copilot Studio oder Azure AI Foundry samt Governance-Attributen.

Die Governance von Agenten wird jetzt zur Chefsache

Mit der Ankündigung und der Preview von Microsoft Entra Agent ID gibt es nun einen brauchbaren Einstieg, um Agenten im Tenant sichtbar zu machen und unter Kontrolle zu bringen. Gelöst ist das Governance-Problem damit noch lange nicht, im Gegenteil: Die eigentliche Arbeit beginnt erst. Admins und Fachbereiche müssen gemeinsam die Ownership festlegen, Sponsoren benennen, Berechtigungen auf das Nötigste zurückschneiden und Lifecycle-Prozesse aufbauen. Wer frühzeitig aufräumt, hat später weniger Ärger mit „wilden“ Agenten und kann Conditional Access, Zertifikatskontrolle und Monitoring gezielt einführen.

Allen, die gerade mit Agenten aus Copilot Studio oder Azure AI Foundry experimentieren, möchte ich eines mitgeben: Die neue Agent ID ist weit mehr als eine nette Dreingabe. Sie entscheidet darüber, ob diese neuen Akteure beherrschbar bleiben oder zum Governance-Albtraum werden.