Microsoft Entra Agent ID vs. Service Principals: Welche Identität sollten Ihre KI-Agenten verwenden?

Von Mirko Peters · 2026-10-26

Vergleichen Sie Microsoft Entra Agent ID und Dienstprinzipale (Service Principals). Erfahren Sie, warum KI-Agenten eigene Identitätsframeworks und Blueprint-Governance in Microsoft 365 benötigen.

Automatisch mit KI aus dem Originalbeitrag übersetzt. Englisches Original lesen

Bei der Bereitstellung autonomer KI-Worker in Microsoft 365 ist die Wahl des richtigen Identitätsmodells entscheidend. Herkömmliche Dienstprinzipale verwalten seit Langem Standard-Anwendungsworkloads, stoßen jedoch bei kurzlebigen, hochfrequenten KI-Agenten an ihre Grenzen. Microsoft Entra Agent ID führt eine eigene Architektur ein, die die Verwaltung von Anmeldeinformationen von den Berechtigungen der Agenten trennt und so zentrale Herausforderungen in Sachen Sicherheit und Nachvollziehbarkeit löst.

Das Wichtigste in Kürze

• Dienstprinzipale binden Anmeldeinformationen und Berechtigungen direkt an eine einzelne Anwendung. Dadurch sind hochfrequente, kurzlebige KI-Agenten nur schwer nachzuverfolgen und abzusichern.
• Microsoft Entra Agent ID entkoppelt Anmeldeinformationen, indem sie zentral auf einem Blueprint gespeichert werden, während einzelnen Workern eindeutige Agent-Identitäten zugewiesen werden.
• Agent-Identitäten vermeiden lokale Geheimnisse auf dem Agenten selbst und reduzieren so die potenziellen Auswirkungen erheblich, falls eine Komponente kompromittiert wird.
• Blueprints ermöglichen Administratoren, Richtlinien in großem Umfang anzuwenden, Lebenszyklusteuerungen zu verwalten und ganze Gruppen von KI-Agenten zentral zu deaktivieren.
• Verwaltete Identitäten eignen sich weiterhin ideal für in Azure gehosteten Code, während Agent IDs speziell für autonome KI-Agenten entwickelt wurden, die eigenständige Entscheidungen zur Laufzeit treffen.

Die Identitätslücke bei KI-Workern verstehen

KI-Agenten lassen sich nicht sauber in die klassischen Identitätsschemata von Unternehmen einordnen. Anders als Standardbenutzer, die sich mit Kennwörtern oder Multi-Faktor-Codes anmelden, und anders als herkömmliche Anwendungen, die auf stabile, langlaufende Dienstkonten setzen, arbeiten KI-Agenten dynamisch. Ein stark ausgelasteter automatisierter Workflow kann innerhalb eines einzigen Arbeitstags Tausende Agent-Instanzen starten und wieder beenden. Wenn sich diese kurzlebigen Agenten auf gemeinsam genutzte Dienstkonten stützen oder menschliche Anmeldeinformationen übernehmen, werden Ihre Überwachungsprotokolle schnell unzuverlässig.

Wenn um zwei Uhr nachts ein Vorfall auftritt, müssen IT-Administratoren außerdem zwei grundlegende Fragen beantworten: Welcher konkrete Agent hat diese Aktion ausgeführt, und wer ist dafür verantwortlich? Herkömmliche App-Registrierungen und gemeinsam genutzte Dienstprinzipale machen die Beantwortung dieser Fragen nahezu unmöglich, ohne nicht zusammenhängende Workloads zu beeinträchtigen. Genau diese operative Lücke hat Microsoft veranlasst, ein spezielles Framework für nicht-menschliche Worker zu entwickeln.

Service Principals vs. Agent IDs: Architekturunterschiede

Um zu verstehen, warum Microsoft Entra Agent ID einen Paradigmenwechsel darstellt, muss man wissen, wie sie sich strukturell von einem klassischen Dienstprinzipal unterscheidet. Ein Dienstprinzipal ist eine Eins-zu-eins-Instanziierung eines Anwendungsobjekts in Ihrem Mandanten. Er enthält eigene langlebige Geheimnisse, Clientzertifikate und direkte Berechtigungszuweisungen. Für stabile, vorhersehbare Web-Apps und Hintergrunddienste hat sich dieses Modell seit Jahren bewährt.

Die Verwendung eines Standard-Dienstprinzipals für einen KI-Agenten führt jedoch zu erheblichen administrativen Reibungsverlusten:

• Wildwuchs bei Anmeldeinformationen: Jedes Mal, wenn ein automatisierter Workflow eine neue Agent-Instanz startet, hinterlässt die Erstellung eines neuen Dienstprinzipals verstreute Clientgeheimnisse in Ihrer Umgebung.
• Probleme bei der Granularität: Um einen einzelnen fehlerhaften Agenten zu deaktivieren, müssen Hunderte Dienstprinzipale durchsucht werden, wodurch das versehentliche Beenden kritischer Geschäftsprozesse droht.
• Unklare Nachvollziehbarkeit: Gemeinsam genutzte Anwendungskonten verschleiern, welche genaue Workflow-Instanz auf sensible Unternehmensdaten zugegriffen hat.

Im Gegensatz dazu führt das Agent-ID-Modell über einen administrativen Blueprint eine Eltern-Kind-Beziehung ein. Der Blueprint speichert die Authentifizierungsdaten sicher und legt die zulässigen Bereiche fest. Einzelne Agent-Identitäten tragen eindeutige Kennungen und werden dynamisch instanziiert. Die Agent-Identität selbst enthält kein Kennwort und kein Geheimnis. Ein Angreifer findet in der Laufzeitumgebung also keine Anmeldeinformationen, die er extrahieren könnte.

Die Stärke von Blueprints in der Flottenverwaltung

Die zentrale Neuerung von Microsoft Entra Agent ID ist das Blueprint-Objekt. Stellen Sie sich einen Blueprint als Hauptvorlage vor, die eine Flotte zusammengehöriger KI-Agenten steuert. Wenn Ihre Organisation beispielsweise eine Vorlage „Sales Assistant Agent“ bereitstellt, können Sie aus dieser einen Definition dynamisch regionale Instanzen für Nordamerika, Südamerika und Europa erzeugen.

Da sich diese Agenten einen gemeinsamen Blueprint teilen, erhalten Administratoren leistungsstarke Verwaltungsfunktionen, die sich mühelos skalieren lassen:

• Zentral durchgesetzte Richtlinien: Wenden Sie eine Conditional-Access-Richtlinie oder eine Einschränkung von Microsoft-Graph-Berechtigungen auf den Blueprint an, gilt sie automatisch für jede daraus erzeugte Agent-Instanz, auch für künftige.
• Der ultimative Kill Switch: Wird in einer bestimmten Agent-Klasse eine Schwachstelle entdeckt, beendet die Deaktivierung des übergeordneten Blueprints sofort die Authentifizierung für jede darunterliegende Agent-Identität im gesamten Mandanten.
• Verantwortlichkeit durch Sponsoren: Jede Agent-Identität benötigt einen namentlich benannten menschlichen Sponsor. Verlässt dieser Sponsor das Unternehmen, überträgt Microsoft Entra die Sponsorschaft automatisch auf dessen Vorgesetzten. So bleiben verwaiste KI-Workloads nicht ohne Aufsicht.

Welcher Identitätstyp in Ihre Architektur passt

Moderne Microsoft-365- und Azure-Umgebungen erfordern einen vielschichtigen Ansatz für nicht-menschliche Identitäten. Die richtige Wahl des Mechanismus verhindert Sicherheitslücken und unnötigen Verwaltungsaufwand.

Verwaltete Identitäten für in Azure gehosteten Code

Wenn Ihr eigener Code, Ihre Funktionen oder Microservices direkt in der Azure-Infrastruktur laufen, setzen Sie immer auf verwaltete Identitäten. Azure übernimmt den Lebenszyklus und die automatische Rotation der Anmeldeinformationen. Es gibt also keine Geheimnisse, um die sich Ihr Team kümmern müsste oder die versehentlich in Quellcode-Repositories landen könnten.

Dienstprinzipale für klassische Anwendungen

Verwenden Sie weiterhin Standard-Dienstprinzipale für stabile Unternehmensanwendungen, SaaS-Integrationen und langlaufende Daemon-Dienste, die dauerhafte, dedizierte Anwendungskontexte und klassische Client-Credential-Flows benötigen.

Agent-IDs für autonome KI-Agenten

Greifen Sie gezielt auf Microsoft Entra Agent ID zurück, wenn Sie KI-Agenten bereitstellen, etwa solche, die in Copilot Studio oder mit eigenen Orchestrierungs-Frameworks entwickelt wurden. Diese Agenten bewerten Situationen dynamisch, treffen autonome Entscheidungen und interagieren im Auftrag von Benutzern oder Workflows mit Microsoft-365-Daten.

Ihre Cloud-Zukunft absichern

Da autonome künstliche Intelligenz zu einer tragenden Säule der digitalen Transformation wird, ist die Verwaltung von KI-Agenten über klassische Dienstkonten eine nicht vertretbare Sicherheitsschuld. Mit Microsoft Entra Agent ID können IT-Administratoren die Geschwindigkeit und Skalierbarkeit moderner KI nutzen und dabei zugleich eine strenge Governance, nachvollziehbare Audit-Trails und konsequente Least-Privilege-Schutzmechanismen sicherstellen. Wenn Sie tiefer verstehen möchten, wie diese Mechanismen im Hintergrund funktionieren, Hören Sie sich die vollständige Folge an und beteiligen Sie sich an unserer laufenden Diskussion über die Absicherung der Microsoft-Cloud.

Häufige Fragen

Speichern Microsoft-Entra-Agent-IDs Kennwörter oder Geheimnisse lokal?

Nein. Agent-Identitäten sind bewusst so konzipiert, dass sie keine lokalen Anmeldeinformationen, Geheimnisse oder Zertifikate enthalten. Die Authentifizierung wird sicher vom übergeordneten Blueprint verwaltet. Angreifer können dadurch keine Schlüssel aus der Laufzeitumgebung des Agenten extrahieren.

Wie werden mandantenübergreifende Bereitstellungen mit Agent-Blueprints gehandhabt?

Blueprints lassen sich als mandantenübergreifende Vorlagen über Organisationen hinweg veröffentlichen. Stellt ein Kunde den Blueprint jedoch in seinem Mandanten bereit, sind die daraus entstehenden Agent-Identitäten streng auf diesen einen Mandanten beschränkt und lokal begrenzt. So bleibt der Schadensradius vollständig innerhalb Ihrer Organisationsgrenzen.

Was passiert mit einem KI-Agenten, wenn sein menschlicher Sponsor das Unternehmen verlässt?

Damit verwaiste KI-Agenten nicht unbeaufsichtigt weiterlaufen, überträgt Microsoft Entra die Sponsorschaft der Agent-Identität automatisch auf den direkten Vorgesetzten des ausscheidenden Sponsors.

Lassen sich Richtlinien für bedingten Zugriff direkt auf Agent-Identitäten anwenden?

Ja. Die Engines für bedingten Zugriff bewerten Anmeldesignale für Agent-Identitäten genauso wie für menschliche Benutzer. Wenn Sie eine Richtlinie auf eine Agent-Blaupause ausrichten, werden diese Regeln außerdem automatisch auf alle aktuellen und künftigen Agent-Instanzen angewendet, die aus dieser Vorlage erstellt werden.