Identität von Agent 365

Agent 365 verwendet die Microsoft Entra-Agent-ID, um jeden Agenten mit einer eigenen Agentenidentität darzustellen. Eine Agentenidentität ist ein Microsoft Entra Service Principal mit servicePrincipalType gesetzt auf ServiceIdentity und @odata.type gesetzt auf #microsoft.graph.agentIdentity. Administratoren verwalten Agentenidentitäten mit denselben Tenant-Kontrollen, die auch anderswo in Microsoft Entra verwendet werden, einschließlich bedingtem Zugriff, Berechtigungen und Einwilligungen sowie Lebenszyklusoperationen.

Identitätsobjekte

Drei Objekte bilden das Modell. Nicht jeder Agent nutzt alle drei.

Objekt Description
Agentenidentitätsentwurf Eine Vorlage in Microsoft Entra ID, die eine Art von Agent definiert. Es enthält die Zugangsdaten, die deklarierten und vererbbaren Berechtigungen, den verifizierten Publisher und alle App-Rollen. Ein Bauplan kann viele Agentenidentitäten erzeugen. Für Hintergrundinformationen darüber, wie Anwendungen in Microsoft Entra registriert werden, siehe Registrieren einer Anwendung bei der Microsoft Identity Platform.
Agentidentität Das Konto, das ein einzelner Agent betreibt. Es hat eigene Objekt-ID, Anzeigename, Sponsor und Berechtigungszuweisungen.
Benutzerkonto des Agenten Ein optionales zweites Konto, das nur erstellt wird, wenn der Agent ein Microsoft Entra-Benutzerkonto benötigt. Es kann Lizenzen und Microsoft 365-Ressourcen wie ein Postfach speichern. Nur für Mieter verfügbar, die am Frontier-Vorschauprogramm teilnehmen. Eine Agentenidentität hat null oder ein Benutzerkonto des Agenten, und das Benutzerkonto jedes Agenten gehört genau einer Agentenidentität.

Beziehung zwischen Blaupause-zu-Agenten

Innerhalb eines Mieters besteht eine Standard-Anwendungsregistrierung typischerweise in einer Eins-zu-eins-Beziehung zu seinem Dienstprinzipal. Das Agentenmodell ist eins zu vielen: Ein Bauplan kann mit vielen Agentenidentitäten innerhalb eines Mieters verknüpft werden.

Jede Agentenidentität erbt Protokolleigenschaften vom Blueprint und kann eigene nachgelagerte Berechtigungen enthalten. Da Agenten derselben Art einen Blueprint teilen, kann ein Administrator eine Conditional Access Policy anwenden, eine Berechtigung widerrufen oder jeden Agenten dieser Art in einer Operation deaktivieren.

Agentenidentitäten sind Einzelmieter und können nur Token in dem Tenant ausgestellt werden, in dem sie erstellt wurden. Baupläne können multitenant sein. So wird ein veröffentlichter Agent zu einem Kunden-Tenant hinzugefügt, der dann aus dem Blueprint eigene tenant-lokale Agentenidentitäten erstellt.

Credentials

Ein Agent authentifiziert sich mit seiner eigenen Agenten-Identität, aber die Identität selbst speichert keine Zugangsdaten. Du konfigurierst die Zugangsdaten auf dem Blueprint, und der Blueprint nutzt diese, um Token für die aus diesem Blueprint erstellten Agentenidentitäten zu erhalten.

Unterstützte Zugangsdaten im Bauplan:

  • Verbundidentitätszugangsdaten
  • Zertifikate und kryptografische Schlüssel
  • Client-Geheimnisse

Für Agenten, die auf Azure laufen, kann man den Blueprint an eine Azure-verwaltete Identität federieren, sodass kein Geheimnis auf dem Blueprint gespeichert wird.

Blueprint-Zugangsdaten werden von jeder Agentenidentität geteilt, die aus diesem Blueprint erstellt wird. Behandle jeden Blueprint als Credential-Grenze und gruppiere nur Identitäten, die Zugangsdaten und geerbte Basisberechtigungen sicher teilen können.

Agentenidentitäten authentifizieren sich nicht mit Passwörtern, SMS, Passschlüsseln oder Authentifikator-Apps, daher gilt Multifaktor-Authentifizierung nicht für sie. Regeln Sie sie stattdessen mit Conditional Access Policies.

Benutzerkonto des Agenten

Einige Agenten müssen auf Systeme zugreifen, die ein Microsoft Entra-Benutzerkonto benötigen. In solchen Fällen kannst du dem Agenten ein zweites Konto geben und ihn im Verzeichnis als KI-Agent markieren.

Durch die Verwendung eines Benutzerkontos und der entsprechenden Lizenzen kann ein Agent ein Postfach und OneDrive-Speicher haben, im Verzeichnis und in Organisationsmetadaten erscheinen und über Teams, Outlook, Word-Kommentare und E-Mails erreicht werden.

Fügen Sie nur dann ein Benutzerkonto hinzu, wenn der Agent eines verlangt. Agenten, die nur Telemetrie- und Anrufwerkzeuge aussenden, benötigen in der Regel keine.

Important

Agenten mit eigenem Benutzerkonto stehen nur Mietern zur Verfügung, die am Frontier-Vorschauprogramm teilnehmen.

Berechtigungen und Laufzeitfluss

Ein Agent kann in drei Ausführungsmodi laufen. Der Modus bestimmt, für wen der Agent handelt, welches Token-Subjekt im Downstream-Aufruf erscheint und welche Berechtigungen und Zustimmung erforderlich sind:

Ausführungsmodus Description
S2S (Service-to-Service) Der Agent läuft ohne Benutzerkontext und fungiert als eigene Agentenidentität. Nutzen Sie diesen Modus für geplante Aufgaben, Überwachung und Hintergrundverarbeitung. Es verwendet Anwendungsberechtigungen und die Agentenidentität ist das Token-Subjekt. Für das zugrunde liegende OAuth-Muster siehe OAuth 2.0 Client Credentials Grant.
OBO (im Namen von) Der Agent erhält den Kontext eines angemeldeten menschlichen Nutzers und handelt für diesen Nutzer. Verwenden Sie diesen Modus, wenn der Zugriff von der Identität oder den Berechtigungen des Nutzers abhängt. Es verwendet delegierte Berechtigungen; Der Benutzer ist das Token-Subjekt und die Agentenidentität ist der Akteur. Für Implementierungsdetails siehe OAuth 2.0 On-Behalf-Of Flow.
Agentischer Nutzer Der Agent arbeitet mit seinem eigenen Microsoft Entra-Benutzerkonto und fungiert als dieses Konto. Dieser Modus benötigt das Frontier-Vorschauprogramm und wird verwendet, wenn der Agent Benutzerressourcen oder benutzerbasierte Microsoft 365-Erlebnisse benötigt, wie etwa ein Postfach, eine Teams-Präsenz oder Interaktionen zwischen Word und Outlook. Das Benutzerkonto des Agenten ist der amtierende Nutzer, während die Agentenidentität weiterhin die Registered Agent 365-Identität bleibt.

Zum Beispiel verwendet die nächtliche Hintergrundverarbeitung üblicherweise S2S; eine benutzerspezifische Aktion im Chat verwendet OBO; und das Lesen des eigenen Postfachs eines Agenten verwendet Agentic-User. Das Berechtigungsmodell und der Laufzeitmodus sind miteinander verbunden, aber sie sind keine austauschbaren Begriffe: Wählen Sie zuerst den Modus, dann bestätigen Sie die von der nachgelagerten Ressource erforderlichen Anwendungs- oder delegierten Berechtigungen und Einwilligungen.

Bevor Sie einen Modus implementieren, bestätigen Sie, dass Ihre vollständige Konfiguration die Operation unterstützt:

  1. Geben Sie an, als wen der Agent für die Operation agieren muss: seine Agentenidentität, einen angemeldeten Benutzer oder sein eigenes Benutzerkonto.
  2. Bestätigen Sie, dass der gewählte Modus diesen Kontokontext und den von der Ziel-API oder -ressource erforderlichen Berechtigungstyp unterstützt.
  3. Erteile die erforderlichen Umfangsbereiche und Zustimmung und erfülle dann alle zusätzlichen Voraussetzungen, wie Lizenzen oder eine bereitgestellte Benutzerressource.

Wenn eine Anforderung vom gewählten Modus nicht unterstützt wird, wählen Sie einen anderen Modus oder eine andere Operation. Für Microsoft Graph-Scopes siehe die Microsoft Graph-Berechtigungsreferenz.

Sobald Sie wissen, welche Berechtigungen der Agent benötigt, entscheiden Sie, wo Sie diese zuweisen. Deklarieren Sie gemeinsame Baseline-Berechtigungen auf dem Blueprint, sodass jede daraus erstellte Agentenidentität diese erbt, und weisen Sie Berechtigungen direkt einer Agentenidentität zu, wenn der Zugriff spezifisch für diesen Agenten ist. Azure rollenbasierte Zugriffskontrolle (RBAC) ist eine Ausnahme: Blueprints können keine Azure RBAC-Rollen halten, daher werden diese Rollen direkt jeder Agentenidentität zugewiesen. Agentenidentitäten können auch Microsoft Entra-integrierte Rollen enthalten.

Important

Das Deklarieren von Berechtigungen auf einem Blueprint gewährt sie nicht. Ein Administrator muss entweder dem Blueprint-Hauptmann oder den Identitäten einzelner Vertreter zustimmen.

Jede Agentenidentität und jede Agentenidentitäts-Blaupause erfordert mindestens einen Sponsor: den Unternehmensvertreter, der für den Zweck und Lebenszyklus des Agenten verantwortlich ist. Sponsoren könnten gebeten werden zu entscheiden, ob ein Agent behalten oder deaktiviert werden soll, und Sicherheitsteams könnten den Sponsor nutzen, um während eines Vorfalls eine verantwortungsbewusste Person zu kontaktieren.

Anmelde- und Auditprotokolle unterscheiden zwischen dem Blueprint, der Agentenidentität und dem Benutzerkonto des Agenten. Ein Gutachter kann die Quelle der Zugangsdaten, die Amtsidentität und das Token-Subjekt identifizieren. Bei S2S-Operationen ist die Agentenidentität das Token-Subjekt. Bei OBO-Operationen ist der angemeldete Benutzer das Subjekt und die Agentenidentität der Akteur.

Was Sie konfigurieren

Wenn man einen Agenten in Agent 365 bringt, registriert man einen Agenten-Identitätsblueprint in Microsoft Entra und erstellt daraus Agentenidentitäten. Die make-a365-agent Fähigkeit führt beide Schritte auf dem Standard-Agentenpfad durch. Auf dem KI-Teamkameradenpfad make-ai-teammate führt er sie aus. Siehe Quickstart: Verbinden Sie einen bestehenden Agenten mit Agent 365.

Entscheiden Sie sich vor Beginn über folgende Punkte:

Artikel Description
Wie viele Baupläne Verwenden Sie pro Zugangsgrenze einen Blueprint. Verwende separate Blueprints für Agenten, die keine Zugangsdaten und geerbten Basisberechtigungen sicher teilen können.
Welches Erlaubnismodell Anwendungsberechtigungen, delegierte Berechtigungen oder beides.
Ob der Agent ein Benutzerkonto benötigt Nur wenn es ein Postfach, eine Präsenz in Teams oder ein Profil im Organisationsverzeichnis erfordert.
Wer sind die Sponsoren Jeder Bauplan und jede Agentenidentität benötigt mindestens einen Sponsor, der ein Nutzer oder eine Gruppe sein kann.

Verwandte Inhalte

  • Last updated on