Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Die Microsoft Entra-Agent-ID führt neue Identitätskonstrukte sowie neue Möglichkeiten zum Nachdenken über vorhandene Authentifizierungs- und Autorisierungsmuster ein. Um besser zu verstehen, wie diese Konstrukte zusammenpassen, ist es hilfreich, sich allgemeine KI-Agent-Bereitstellungsmuster anzusehen und wie sie der Microsoft Entra-Agent-ID zugeordnet werden.
In diesem Artikel werden allgemeine KI-Agent-Bereitstellungsmuster und ihre Zuordnung zur Microsoft Entra-Agent-ID beschrieben. Der Artikel beginnt mit einer Überprüfung der wichtigsten Identitätskonzepte, beschreibt Berechtigungen und Vertrauensgrenzen und führt dann durch allgemeine Bereitstellungsmuster.
Eine Schritt-für-Schritt-Entscheidungshilfe dazu, wie viele Blaupausen und Agentenidentitäten erstellt werden sollen, finden Sie unter Planen der Identitätsarchitektur Ihres Agenten.
Wichtige Konzepte
Die folgenden Komponenten bilden die Grundlage der Microsoft Entra-Agent-ID. Wenn Sie noch nicht vertraut sind, beginnen Sie mit den Schlüsselkonzepten der Microsoft Entra-Agent-ID , bevor Sie mit diesem Artikel fortfahren.
Identitätskonstrukte
Die folgenden Identitätskonstrukte werden in den in diesem Artikel beschriebenen Mustern verwendet:
- Agentidentitäts-Blueprint: Die Vorlage und Authentifizierungsgrundlage für eine oder mehrere Agentidentitäten. Sie enthält Anmeldeinformationen und Richtlinien, die für alle darin erstellten Agentidentitäten gelten.
- Agentenidentitäts-Blueprint-Prinzipal: Das Microsoft Entra-Objekt, das erstellt wird, wenn einem Mandanten ein Blueprint hinzugefügt wird. Tatsächlich werden Token erworben, Agentenidentitäten erstellt und im Auftrag des Blueprints in Überwachungsprotokollen angezeigt.
- Agent-Identität: Die Laufzeitidentität für einen bestimmten KI-Agent mit eigenen Berechtigungen für downstream-Ressourcen.
- Das Benutzerkonto des Agents: Ein optionales 1:1-Konto, das mit einer Agentidentität gekoppelt ist, ist nur erforderlich, wenn der Agent auf Systeme zugreifen muss, die ein Benutzerobjekt erfordern.
Berechtigungsmodelle
Berechtigungen auf Blaupausenebene und Berechtigungen auf Agentenidentitätsebene dienen verschiedenen Zwecken:
- Blueprint-Berechtigungen stellen die Mindestberechtigungen dar, die für alle Agentidentitäten freigegeben werden, die aus dem Blueprint erstellt wurden. Verwenden Sie vererbbare Berechtigungen für den Blueprint, wenn alle Agentidentitäten mit einem gemeinsamen Basisplan beginnen sollen.
- Agent-Identitätsberechtigungen stellen differenzierte Berechtigungen für einen bestimmten Agent dar. Verwenden Sie diese Berechtigungen, wenn unterschiedliche Agents im selben System unterschiedliche Zugriffe auf downstream-Ressourcen benötigen.
Weitere Informationen finden Sie unter Konfigurieren vererbbarer Berechtigungen für Blueprints und Autorisierung in der Microsoft Entra-Agent-ID.
Vertrauensgrenze
Eine Vertrauensgrenze bezieht sich auf die gemeinsame Risikooberfläche, bei der angenommen wird, dass eine einzige Kompromittierung den gesamten Umkreis beeinflusst. Agenten, die auf separaten Plattformen mit separaten Dienstkonten, Geheimnissen und Netzwerksegmenten ausgeführt werden, teilen keinen Vertrauensbereich.
Eine Vertrauensgrenze ist eine Entscheidung zur Anwendungsbedrohungsmodellierung, nicht eine, die die Microsoft Entra-Agent-ID für Sie definiert.
Bereitstellungsmuster
Die folgenden Muster basieren auf realen Bereitstellungen von Agenten. Jede beschreibt die Agentarchitektur, ihre Identitätsstruktur und relevante Überlegungen zu Berechtigungen und Governance.
Low-Code-Singleton-Agent
Ein einzelner Agent, der eine bestimmte Aufgabe unterstützt, die häufig auf einer Low-Code- oder No-Code-Plattform wie Microsoft Copilot Studio basiert. Der Agent fungiert entweder immer im Namen eines angemeldeten Benutzers (interaktiv) oder fungiert immer als sich selbst (autonom).
Struktur: Ein Blueprint → einer Agentidentität
Obwohl ein Blueprint mit einer einzigen Agent-Identität redundant erscheinen könnte, bietet der Blueprint dem Agent konsistente Richtlinien für bedingten Zugriff, Überwachung, Governance und Überwachungseinträge – die gleiche Infrastruktur, die Sie für Multi-Agent-Systeme benötigen, mit minimalem Setup.
Berechtigungen: Erteilen Sie Berechtigungen direkt für die Agentenidentität. Die vererbbaren Berechtigungen des Blueprints sind in der Regel für Singleton-Fälle nicht erforderlich.
Benutzerkonto des Agents: Nicht erforderlich, es sei denn, der Agent benötigt Zugriff auf Exchange, Teams oder ein anderes System, das ein Benutzerobjekt erfordert.
Domänenmitarbeiter (sequenzieller Multi-Agent)
Mehrere Agents arbeiten in einem eng gekoppelten, sequenziellen Workflow zusammen, um ein gemeinsames Domänenziel zu erfüllen. Die Agents verwenden in der Regel eine Codebasis, führen sie in derselben Laufzeitumgebung aus (z. B. denselben Kubernetes-Namespace oder -Container), und weisen denselben Sicherheitsstatus auf. Jeder Agent hat unterschiedliche Verantwortlichkeiten und unterschiedlichen Zugriff auf downstream-Ressourcen. Dieses Muster entspricht der sequenziellen Orchestrierung im Multi-Agent-Design.
Struktur: Ein Blueprint → mehrere Agentidentitäten (eine pro Agentrolle)
Die Verwendung eines einzelnen Blueprints ist hier angemessen, da alle Agenten dieselbe Vertrauensgrenze verwenden. Jeder Agent erhält eine eigene Agentidentität, sodass Aktionen einem bestimmten Agent in Überwachungs- und Anmeldeprotokollen zugeordnet werden können, und jeder kann unterschiedliche Berechtigungen für downstream-Ressourcen enthalten.
Beispiel: Ein Einzelhandelsproduktverwaltungssystem verfügt über drei Agenten : Lagerbestand, Produktvergleich und Lieferantenbestand. Alle drei werden im selben Kubernetes-Namespace ausgeführt und von demselben Team erstellt. Sie verwenden einen "Blueprint" mit drei Agentidentitäten, die jeweils Berechtigungen haben, die auf ihre eigenen Ressourcen beschränkt sind.
Berechtigungen: Legen Sie freigegebene Basisberechtigungen als vererbbar im Blueprint fest. Weisen Sie rollenspezifische Berechtigungen direkt jeder Agentidentität zu.
Benutzerkonto des Agents: In der Regel nicht für Domänen-Worker-Agents erforderlich.
Konkurrierender Orchestrator mit Domain-Workern
Ein Orchestrator-Agent aktiviert dynamisch verschiedene Domänenmitarbeiter basierend auf der eingehenden Aufgabe. Die Domänenmitarbeiter können auf verschiedenen Plattformen ausgeführt und von verschiedenen Teams betrieben werden sowie Vertrauensgrenzen überschreiten. Dieses Muster entspricht gleichzeitiger Orchestrierung im Multi-Agent-Design.
Struktur:
- Blueprint A → Orchestrator-Agentenidentität
- Blueprint B → Identitäten von Domain-Worker-Agenten (eine pro Rolle, grenzüberschreitende Vertrauensgruppe)
- Blueprint C → eine Arbeitsgruppe aus einem anderen Bereich, wenn sie von einem separaten Team oder Plattform betrieben wird
Da die Domänenmitarbeiter vertrauenswürdige Grenzen überschreiten – separate Laufzeiten, geheime Schlüssel oder Teams – benötigen sie separate Blueprints. Die Anmeldeinformationen des Blueprints sind auf ihre Vertrauensdomäne ausgelegt, sodass sich ein Kompromiss in einer Domäne nicht auf Peer-Agents auswirkt.
Kurzlebige Agentidentitäten: Eine Variante dieses Musters verwendet kurzlebige Agentidentitäten. Der Orchestrator erstellt zur Laufzeit eine temporäre Agent-Identität, um eine bestimmte Interaktion (z. B. die Koordination mit einem Wartungssubsystem) zu erleichtern, gewährt sie Berechtigungen, die vom Blueprint geerbt werden, und löscht die Identität, wenn die Sitzung endet. Dadurch wird der Strahlradius auf die Dauer des Vorgangs beschränkt.
Hinweis
Die Identitätserstellung des ephemeren Agents erfolgt zur Laufzeit, wodurch eine nicht-deterministische Latenz eingeführt wird. Bewerten Sie diesen Kompromiss für Latenz-sensible Szenarien.
Berechtigungen: Orchestrator und jede Domänenmitarbeitergruppe verfügen über eigene Berechtigungssätze, die auf ihre jeweiligen Blueprints und Agentidentitäten ausgelegt sind.
Benutzerkonto des Agents: In der Regel nicht auf Orchestrator- oder Domänenarbeitsebene erforderlich, es sei denn, ein bestimmter Domänenmitarbeiter muss auf eine vom Benutzerobjekt abhängige Ressource zugreifen.
Benutzerspezifische Agenten (kleines n)
Für jede Benutzer- oder Organisationseinheit wird eine separate Agent-Identität erstellt. Beispielsweise kann ein SOC-Analyst-Agent eine Instanz pro Cloudumgebung haben, oder ein Audit-Agent verfügt über eine Instanz pro Abteilung. Die Anzahl der Agentenidentitäten ist mäßig – einige Dutzend bis niedrige Hunderte – nicht einer pro Verzeichnisbenutzer.
Struktur: Ein Blueprint → einer Agentidentität pro Benutzer, Abteilung oder Umgebung
Dieses Muster ist geeignet, wenn jede Agentinstanz unterschiedliche Berechtigungen, unterschiedliche Überwachungsgrenzen oder einen unabhängigen Lebenszyklus benötigt (z. B. kann der Agent für eine Abteilung deaktiviert werden, ohne andere zu beeinträchtigen).
Berechtigungen: Jede Agentidentität enthält Berechtigungen, die auf ihre Benutzer- oder Organisationseinheit ausgerichtet sind. Vererbbare Berechtigungen aus dem Blueprint legen einen Mindestbasisplan fest, und jeder Agentidentität wird bei Bedarf zusätzliche Berechtigungen gewährt.
Benutzerkonto des Agents: Erwägen Sie, jede Agent-Identität mit dem Benutzerkonto eines Agenten zu koppeln, wenn jeder Agent als benannter Vertreter für seinen Benutzer oder seine Abteilung fungiert , z. B. ein dedizierter Vertriebsmitarbeiter, der E-Mails im Auftrag eines Territoriums empfängt.
Digitaler Mitarbeiter (vollständig autonomer Agent)
Ein vollständig autonomer Agent fungiert als digitaler Mitarbeiter und wird mit Ressourcen ausgestattet, die normalerweise für menschliche Mitarbeiter reserviert sind: ein Exchange-Postfach, eine OneDrive-Freigabe und eine Teams-Anwesenheit. Dies ist die höchste Ebene der Agentenautonomie.
Struktur: Ein Blueprint → eine Agentenidentität → ein Benutzerkonto eines Agenten
Jeder digitale Mitarbeiter erfordert das Benutzerkonto eines eigenen Agents. Die 1:1-Beziehung zwischen Agentidentität und Benutzerkonto des Agents wurde behoben. Sie können das Benutzerkonto eines Agents nicht über mehrere Agentidentitäten hinweg freigeben.
Beispiel: Ein KI-Vertriebsmitarbeiter mit einem echten Postfach, das in der globalen Adressliste aufgeführt ist, das auf E-Mails antwortet und einem menschlichen Vorgesetzten im Organigramm zugewiesen wird.
Berechtigungen: Gewähren Sie dem Benutzerkonto des Agents die spezifischen Exchange-, Teams- und OneDrive-Berechtigungen, die er benötigt. Gewähren Sie der Agentenidentität Berechtigungen auf Anwendungsebene für Systeme, für die kein Benutzerobjekt erforderlich ist. Weitere Informationen finden Sie unter Gewähren des Agentzugriffs auf Microsoft 365.
Benutzerkonto des Agents: Erforderlich. Erstellen Sie ein Benutzerkonto für jede Identität eines digitalen Arbeitsagenten.
Zu vermeidende Muster
Skalierungsreplikate benötigen keine separaten Agentidentitäten
Das Ausführen mehrerer Instanzen desselben Agentcodes (Scale-Out) erfordert keine separaten Agentidentitäten. Die horizontale Skalierung ist ein Laufzeitproblem: Der Blueprint erwirbt Token als Agentenidentität, und mehrere Instanzen des Agenten können alle gleichzeitig unter derselben Identität ausgeführt werden. Durch das Erstellen einer separaten Agent-Identität pro Replikat werden Verzeichnisobjekte und Verwaltungsaufwand ohne Überwachungs-, Zugriffssteuerungs- oder Verantwortlichkeitsvorteil hinzugefügt.
Für die Speicher- und Kontextverwaltung sind keine separaten Agentidentitäten erforderlich.
Der Agentspeicher ist in der Regel ein freigegebener Datenspeicher (z. B. Azure Cache für Redis oder Azure KI-Suche), in dem Daten zur Abrufzeit nach Sitzungs-ID gefiltert werden. Der Zugriff auf diesen Datenspeicher wird durch die Berechtigungen der Agentidentität gesteuert, nicht durch separate Identitäten pro Sitzung. Separate Agentidentitäten für die Speicherisolation fügen Komplexität ohne Sicherheitsvorteil hinzu.
Verwenden Sie keine skalierten Pro-Objekt-Agent-Identitäten im Verzeichnis.
Das Erstellen einer Agentidentität pro Besprechung, pro Dokument oder pro kurzlebigem Objekt mit hohem Volumen ist heute mit Identitäten auf Verzeichnisebene nicht praktikabel. Verwenden Sie für Szenarien mit hohem Fluss die Gemeinsamen Agent-Identitäten und verlassen Sie sich auf Sitzungs- oder Kontext-IDs auf der Anwendungsschicht, um Interaktionen zu unterscheiden.