Semion Vasilevitzky und Jonathan Elkabas

Im vorangegangenen Kapitel dieses Leitfadens haben wir die Unterschiede zwischen den Kernobjekten von Entra ID für nicht-menschliche Identitäten erläutert. In diesem Kapitel tauchen wir in die Welt und das Konzept der Agent-ID-Plattform ein.

Microsofts Entra Agent ID und die Agent-Identitätsplattform werden bald zu einem zentralen Thema in Diskussionen rund um Identität und Sicherheit werden. Wenn Sie mit Entra ID arbeiten – ganz gleich, ob Sie Anwendungen entwickeln, Mandanten sichern oder nach Missbrauchspfaden suchen –, werden Sie sicherlich noch viel davon hören.

Eines der Ziele dieses Leitfadens ist es, dass Sie am Ende in der Lage sind, jeden Aspekt der folgenden Abbildung zu verstehen:

Abbildung 1. Die Identitätsplattform für Agenten von Microsoft stellt Identitätskonstrukte für KI-Agenten bereit.

Warum benötigen wir die Agent-Identitätsplattform?

Der Aufstieg von KI-Agenten verändert die Arbeitsweise von Organisationen grundlegend. Die traditionellen Identitätsmodelle, die wir zuvor in diesem Leitfaden erörtert haben, wurden für menschliche Konten und deterministische Anwendungen konzipiert. KI-Agenten lassen sich nicht eindeutig einer dieser beiden Kategorien zuordnen. Sie können nach logischer Überlegung Entscheidungen treffen, lernen und sich an Veränderungen anpassen sowie sich auf unvorhersehbare Weise verhalten, ohne dass eine interaktive Anmeldung erforderlich ist.

Diese Situation machte eine neue Art von Identität erforderlich: die Identität als Akteur.

Microsoft hat die Agent-Identitätsplattform entwickelt, um diese neue Art von Identität zu verwalten und zu sichern. Die Plattform ermöglicht die Erkennung, Verwaltung, Überwachung und Sicherung von KI-Agenten-Identitäten unter Nutzung der bestehenden Funktionen von Entra ID.


Was ist eine Agentenidentität eigentlich?

Eine Agentenidentität ist ein neuer, spezieller Identitätstyp in Microsoft Entra, der speziell für KI-Agenten entwickelt wurde. Dies stellt eine entscheidende Veränderung dar: Agenten werden nicht mehr als Benutzer oder herkömmliche Dienstprinzipale behandelt, sondern als eigene Klasse von Identitäten mit eigenen Lebenszyklus-, Governance- und Authentifizierungsmodellen.

Um die Identität eines Agenten besser zu verstehen, ist es hilfreich zu wissen, woraus sich ein KI-Agent in der Praxis zusammensetzt. Die meisten Agentenarchitekturen bestehen aus mehreren Komponenten:

  • Ein Modell: das Sprachmodell, das für die Interpretation und Entscheidungsfindung zuständig ist
  • Eine Orchestrierungsschicht: die Komponente, die das logische Denken, die Planung und das Ergreifen von Maßnahmen steuert (und häufig entscheidet, welches Tool wann aufgerufen werden soll)
  • Gedächtnis: Ein Zustand, der über einzelne Schritte oder Sitzungen hinweg bestehen bleibt und es dem Agenten ermöglicht, den Kontext beizubehalten und innerhalb seines Handlungsfensters „auf dem neuesten Stand“ zu bleiben.
  • Tools: Die Schnittstellen, über die der Agent mit der Umgebung interagieren kann, wie beispielsweise APIs, SaaS-Aktionen, Skripte und Konnektoren.

Diese Komponenten sind von Bedeutung, da die tatsächliche Leistungsfähigkeit eines Agenten in Unternehmensumgebungen von den Tools abhängt, auf die er zugreifen kann, und der Zugriff auf diese Tools durch Authentifizierung und Autorisierung geregelt wird.

Agenten können autonom sein und unabhängig agieren. Nach dem Auslösen eines Ereignisses oder einer ausdrücklichen Anweisung eines Benutzers können sie in einem delegierten Szenario im Namen des Benutzers handeln oder dynamisch erstellt und gelöscht werden, um eine bestimmte Aufgabe auszuführen.

Unabhängig davon benötigt der Agent zur Laufzeit eine Identität, mit der er sich authentifizieren, Token anfordern, Richtlinien anwenden und Prüfprotokolle erstellen kann.


Lernen Sie die Hauptakteure kennen: Die zentralen Agent-ID-Objekte

Bevor wir uns damit befassen, wie Agenten sich authentifizieren, Berechtigungen übernehmen oder an delegierten Abläufen teilnehmen, müssen wir die wichtigsten Objekte verstehen, aus denen sich dieses Modell zusammensetzt.

Hinweis: Die Microsoft Agent Identity Platform befindet sich noch in der Vorschauphase, sodass einige der hier beschriebenen Vorgänge möglicherweise nicht funktionieren oder sich im Laufe der Zeit ändern können. Zum Zeitpunkt der Veröffentlichung dieses Artikels sind viele Funktionen über das Entra-Portal noch nicht verfügbar und können nur über die MS Graph-Beta-Endpunkte ausgeführt werden.


Entwurf für die Identitätsdefinition eines Agenten

Eine Agent-Identitätsvorlage ist die grundlegende Vorlage, auf deren Basis Agent-Identitäten erstellt werden. Sie definiert eine Klasse von Agenten und baut auf dem Anwendungsregistrierungsobjekt auf. Die Vorlage speichert die gemeinsame Konfiguration für alle davon abgeleiteten Agent-Identitäten, einschließlich Authentifizierungsmethoden, geerbter Berechtigungen und weiterer Kerneinstellungen.

Microsoft definiert vier Hauptzwecke für Identitätsvorlagen für Agenten:

  • Blueprints dienen als Vorlagen: Alle aus demselben Blueprint erstellten Agentenidentitäten erben dessen gemeinsame Eigenschaften, darunter Beschreibung, Rollen, Herausgeber sowie alle optionalen Claims, die den Zugriffstoken hinzugefügt wurden.
  • Blueprints können Agentenidentitäten erstellen: Jeder Blueprint verfügt über die integrierte AgentIdentity.CreateAsManager Berechtigung, die es ermöglicht, Agent-Identitäten bereitzustellen, zu aktualisieren und zu entfernen. Diese Berechtigung wird standardmäßig zugewiesen und kann derzeit nicht widerrufen werden. (Glauben Sie uns, wir haben es versucht.)
  • Blueprints verwalten Anmeldedaten: Agenten-Identitäten verwalten ihre Anmeldedaten nicht selbst. Stattdessen greifen sie auf die in ihrem Blueprint konfigurierten Anmeldedaten zurück. Zu den unterstützten Anmeldedatentypen gehören Anmeldedaten für Verbundidentitäten, Zertifikate und Client-Geheimnisse.
  • Blueprints dienen als logische Container: Richtlinien und bestimmte Konfigurationen, die auf Blueprint-Ebene angewendet werden, wirken sich automatisch auf alle daraus erstellten Agentenidentitäten aus. Wird der Blueprint beispielsweise einer policy für den bedingten Zugriff hinzugefügt, policy diese policy alle zugehörigen Agentenidentitäten policy . Durch das Deaktivieren eines Blueprints werden auch alle daraus abgeleiteten Agentenidentitäten deaktiviert.
Abbildung 2. Der Entwurf bildet die Grundlage für die Erstellung von Agentenidentitäten.

Die Plattform für Agentenidentitäten führt ein einheitliches Modell für Verwaltungsrollen ein, das sowohl für Blueprints als auch für die daraus abgeleiteten Agentenidentitäten gilt. Es definiert drei Rollen: Eigentümer, Sponsor und Manager.

Der Eigentümer fungiert als technischer Administrator. Dies ist die Rolle mit den weitreichendsten Berechtigungen in diesem Modell, die Konfigurationen vornehmen und Eigenschaften ändern kann. Zu den Funktionen gehören unter anderem die Aktualisierung anderer Eigentümer oder Sponsoren, die Verwaltung von Anmeldedaten, die Änderung von Konfigurationen sowie die Wiederherstellung vorläufig gelöschter Identitäten.

Eigentümer können Agenten deaktivieren, löschen und wieder aktivieren. Im Grunde genommen ist der Eigentümer der Administrator der Identität. Obwohl sie über weitreichende Befugnisse verfügen, ist die Zuweisung eines Eigentümers bei der Erstellung einer Agent-Identitätsvorlage nicht zwingend erforderlich.

Eigentümer können Benutzer oder Dienstprinzipale sein; diese Rolle sollte jedoch auf vertrauenswürdige IT-Administratoren oder Dienstprinzipale beschränkt werden, die ausdrücklich den Lebenszyklus und die Konfiguration des Agenten verwalten müssen.

Der Sponsor ist der Geschäftsinhaber eines Agenten und für den Lebenszyklus des Agenten verantwortlich. Sponsoren können Agenten löschen oder deaktivieren, unter Angabe von Gründen Zugriffspakete für diese beantragen und lebenszyklusbezogene Eigenschaften verwalten. Sie kennen den Zweck des Agenten und können überprüfen, ob dessen Verhalten den Erwartungen entspricht, insbesondere im Rahmen von Sicherheitsuntersuchungen. Im Gegensatz zu Eigentümern verfügen Sponsoren über eingeschränkte Berechtigungen. Sie können Agenten nicht wieder aktivieren, keine neuen Sponsoren oder Eigentümer hinzufügen und keine Authentifizierungseinstellungen ändern.

Bei der Erstellung einer Agent-Identitätsvorlage muss mindestens ein Sponsor angegeben werden. Diese Rolle kann Benutzern, Service-Principals oder Gruppen zugewiesen werden. Sie sollte einer Person übertragen werden, die den Zweck des Agenten kennt.

Die Rolle des Managers wird erst dann wirklich verständlich sein, wenn wir den Agenten-Benutzer vorstellen; wir werden daher gleich noch einmal darauf zurückkommen.

Zusammenfassend lässt sich also sagen: Wenn Sie eine Gruppe ähnlicher Agenten verwalten möchten, beispielsweise verkaufsorientierte Agenten, bietet ein einziger Blueprint eine zentralisierte Möglichkeit, diese zu definieren und zu steuern. Jede aus dem Blueprint erstellte Agentenidentität übernimmt automatisch einen Teil der gemeinsamen Konfiguration, während Sie bei Bedarf weiterhin einzelne Agentenidentitäten verwalten können.


Agent, Identität, Blueprint, Prinzipal

Ein „Agent Identity Blueprint Principal“ ist die mandantenspezifische Darstellung eines Agent-Identitäts-Blueprints. Er basiert auf dem Service-Principal-Objekt, und es kann mehrere Principals geben, die denselben Agent-Identitäts-Blueprint repräsentieren – jeweils eines in jedem einzelnen Mandanten. Mit anderen Worten: Es handelt sich um die Instanz des Agent-Identitäts-Blueprints innerhalb des Mandanten.

Laut Microsoft erfüllen Blueprint-Dienstprinzipale zwei wesentliche Funktionen:

  • Token-Ausstellung: Bei Token-Anfragen bezieht sich der OID-Claim (Objekt-ID) innerhalb eines Tokens auf den Blueprint-Prinzipal und identifiziert damit den Prinzipal, der die Anfrage gestellt hat.
  • Protokollierung von Prüfvorgängen: In den Prüfprotokollen werden die vom Blueprint durchgeführten Vorgänge (wie beispielsweise die Erstellung einer Agentenidentität) als Aktionen angezeigt, die unter der Objekt-ID des Blueprint-Prinzipals ausgeführt wurden.
Abbildung 3: Die Prinzipale des Agent-Identitäts-Blueprints repräsentieren das Blueprint mandantenübergreifend.

Identität des Agenten

Eine Agentenidentität ist eine besondere Art von Dienstprinzipal, die einen KI-Agenten zur Laufzeit repräsentiert. Es handelt sich dabei um das eigentliche Konto, das der Agent zur Authentifizierung und für den Zugriff auf Dienste und Ressourcen verwendet.

Agentenidentitäten werden auf der Grundlage einer Vorlage für Agentenidentitäten erstellt und übernehmen deren Konfiguration sowie Anmeldedaten. Zur Authentifizierung stützen sie sich auf ihre Vorlage, die im Namen der Agentenidentität Token abruft.

Trotz dieser Abhängigkeit bleibt jede Agentenidentität ein eigenständiges Identitätsobjekt im Verzeichnis; ihr können Berechtigungen und Rollen zugewiesen, sie kann unabhängig verwaltet, einzeln deaktiviert und getrennt von ihrem Blueprint verwaltet werden.

Agentenidentitäten folgen demselben oben beschriebenen Modell für administrative Rollen (Eigentümer und Sponsor). Wie bei den Blaupausen für Agentenidentitäten ist für die Erstellung einer Agentenidentität mindestens ein Sponsor erforderlich, während die Zuweisung eines Eigentümers optional ist.

Eine erwähnenswerte Einschränkung besteht darin, dass Sie derzeit bis zu 250 Agentenidentitäten pro Agentenidentitätsvorlage erstellen können (ja, wir haben es ausprobiert). Dies ist bei der Konzeption groß angelegter Agentenarchitekturen unbedingt zu berücksichtigen.

Wenn wir also unserem Schema die Identitäten der Agenten hinzufügen, sieht es wie folgt aus:

Abbildung 4: Aus jeder Vorlage für eine Agentenidentität können bis zu 250 Agentenidentitäten erstellt werden.

Agent-Benutzer

Ein Agentenbenutzer ist ein spezieller Benutzertyp, der es einer Agentenidentität ermöglicht, auf Dienste zuzugreifen, für die ein Objekt vom Typ „Benutzer“ erforderlich ist, wie beispielsweise ein Postfach oder eine Chat-Oberfläche. Die Verwaltung eines Agentenbenutzers erfolgt ähnlich wie die Verwaltung eines menschlichen Benutzers, und die Erstellung eines solchen Benutzers ist je nach den Anforderungen Ihrer Organisation optional.

Pro Agentenidentität kann nur ein Agentenbenutzer existieren. Jeder Agentenbenutzer muss bei seiner Erstellung mit einer einzigen Agentenidentität verknüpft werden, und diese Verknüpfung ist unveränderlich. Der Agentenbenutzer verfügt jedoch über eigene eindeutige Kennungen, die von der übergeordneten Identität getrennt sind, sowie über eigene Berechtigungen und Rollen.

Um einen Agentenbenutzer anzulegen, müssen dem Identitäts-Blueprint des Agenten bestimmte Berechtigungen erteilt werden, die standardmäßig nicht aktiviert sind.

Agent-Benutzer können Sicherheitsgruppen – mit Ausnahme von Gruppen, denen Rollen zugewiesen werden können – sowie Verwaltungseinheiten hinzugefügt werden. In gewisser Hinsicht lassen sie sich ähnlich wie menschliche Benutzer verwalten, allerdings mit einigen wesentlichen Einschränkungen.

Beispielsweise kann das Passwort eines Agentenbenutzers nicht zurückgesetzt werden, da sich der Agentenbenutzer nicht eigenständig authentifiziert. Seine Authentifizierung hängt von der Identität des übergeordneten Agenten ab.

Agent-Benutzer können sich zudem nicht interaktiv anmelden, und laut der Dokumentation von Microsoft können ihnen keine privilegierten Administratorrollen zugewiesen werden. (Unsere Beobachtungen stimmen jedoch nicht vollständig mit dieser letzten Aussage überein; darauf werden wir im nächsten Kapitel näher eingehen.)

Um auf das Verwaltungsroll Modell zurückzukommen: Bei der Verwendung von Agenten wird neben den Eigentümern und Sponsoren eine weitere Rolle eingeführt: die des Managers.

Ein Manager ist ein Benutzer, der für den Agentenbenutzer verantwortlich ist, so wie ein echter Manager einen menschlichen Mitarbeiter beaufsichtigt. Diese Rolle gilt speziell für Agentenbenutzer und ermöglicht es, im Namen des Agentenbenutzers Zugriffspakete anzufordern und dessen tägliche betriebliche Anforderungen zu verwalten. Es handelt sich um die Rolle mit den geringsten Berechtigungen im Modell; sie kann keine Agenten ändern oder löschen.

Nach diesen Ausführungen und nach eingehender Auseinandersetzung mit Vererbung, Untertypen und der Struktur von Service-Principals folgt hier nun das endgültige Baumdiagramm des neu eingeführten Agent-ID-Modells:

Abbildung 5. Ein Agent-Benutzer gewährt einer einzelnen Agent-Identität Zugriff auf Dienste.

Agententypen im UI-Portal

Nachdem wir nun diese grundlegenden Definitionen behandelt haben, können wir einen Blick auf die Übersichtsseite der Benutzeroberfläche werfen, die Microsoft ursprünglich als Teil der Beta-Version der Agent-ID-Funktion veröffentlicht hat.

Obwohl diese Ansicht offenbar nicht mehr im Portal angezeigt wird (oder zumindest vorerst ausgeblendet wurde), ist sie dennoch nützlich, da sie verdeutlicht, wie Microsoft ursprünglich die verschiedenen Agententypen dargestellt hat und wie sich der Übergang vom älteren, auf Service-Principals basierenden Modell zum neueren Agent-ID-Modell in der Benutzeroberfläche widerspiegelte.

Abbildung 6. Die definierten Agentenarten werden in der Benutzeroberfläche der ursprünglichen Agentenidentitätsplattform angezeigt.

Die am einfachsten zu verstehende Kategorie ist Agenten ohne Identität, die mit den zuvor besprochenen Agenteninstanzen übereinstimmen: jenen, die ohne zugehörige Agentenidentität erstellt wurden, d. h. Has agent ID ist falsch.

Als Nächstes beziehen sich „Agentenidentitäten (ohne Benutzer) “ auf tatsächliche Agentenidentitäten im Mandanten. Auch wenn diese nicht als Agenteninstanzen registriert sind, werden sie dennoch in dieser Kategorie erfasst.

Die Kategorie „Agentenidentitäten (mit Benutzer) “ gibt die Anzahl der Agentenbenutzer im Mandanten wieder. Jeder Agentenbenutzer wird hier aufgeführt, wobei eine strikte 1:1-Beziehung zu seiner übergeordneten Agentenidentität besteht.

Schließlich bezieht sich der Begriff „Agent mit Dienstprinzipalen“ auf Agenten, die vor der Einführung des Agent-ID-Modells erstellt wurden. Diese Agenten arbeiten weiterhin nach dem Dienstprinzipal-Modell. Es ist zu erwarten, dass diese Kategorie im Laufe der Zeit schrumpfen wird, da die Agenten auf das neue Agent-ID-Modell umgestellt werden.


Übungsaufgabe: Beginnen Sie mit der Erstellung Ihrer eigenen Agenten-ID

Manchmal lernt man am besten, indem man einfach loslegt und es ausprobiert. Da Sie nun die Struktur des Agent-ID-Modells verstanden haben, sind Sie bereit für unseren ersten Übungs-Checkpoint.
Legen Sie los und beginnen Sie mit der Erstellung einer Agent-ID.


Entdecken Sie den Leitfaden

Einleitung: Entra ID Agent-Identitätsangriffe verstehen und verhindern: Ein umfassender Leitfaden
Lernen Sie die Identitäten des Entra ID-Agenten kennen (übrigens: Es handelt sich dabei nicht um Personen)
Die Taxonomie der Workload-Identitäten in Entra ID: Unternehmensanwendungen, Service-Principals und andere Formen organisierter Verwirrung
Praxis-Checkpunkt 1: Erstellen einer Agent-ID mit MS Graph