Agentidentitätskonzepte in Microsoft Foundry

Eine agent-Identität ist ein spezieller Identitätstyp in Microsoft Entra ID, der speziell für KI-Agents entwickelt wurde. Es bietet ein standardisiertes Framework für die Steuerung, Authentifizierung und Autorisierung von KI-Agents in Microsoft-Dienste. Dieses Framework ermöglicht Agents den sicheren Zugriff auf Ressourcen, die Interaktion mit Benutzern und die Kommunikation mit anderen Systemen.

Microsoft Foundry stellt agentidentitäten während des gesamten Agentlebenszyklus automatisch fest und verwaltet sie. Diese Integration vereinfacht die Berechtigungsverwaltung bei gleichzeitiger Aufrechterhaltung von Sicherheit und Auditierbarkeit, da Agents von der Entwicklung zur Produktion wechseln.

In diesem Artikel wird erläutert, wie Agentidentitäten mit Microsoft Entra ID Objekten zusammenhängen, wie Foundry sie verwendet, wenn ein Agent Tools aufruft, und wie Sie den Zugriff mit den geringsten Rechten mit Azure rollenbasierten Zugriffssteuerung (RBAC) anwenden.

Voraussetzungen

Informationen zu Gießerei-spezifischen RBAC-Rollen und -Bereichen finden Sie unter Azure rollenbasierte Zugriffssteuerung in Foundry.

Funktionsweise von Agentidentitäten in Foundry

Foundry verwendet Microsoft Entra ID Agentidentitäten, um zwei verwandte Anforderungen zu unterstützen:

  • Verwaltung und Governance: Bieten Sie Administratoren eine konsistente Möglichkeit, Agenten zu inventarisieren, Richtlinien anzuwenden und Aktivitäten zu überwachen.
  • Tool-Authentifizierung: Zulassen, dass ein Agent sich bei nachgeschalteten Systemen authentifiziert (z. B. Azure Storage), ohne geheime Schlüssel in Eingabeaufforderungen, Code oder Verbindungszeichenfolgen einzubetten.

Auf hoher Ebene führt Foundry folgende Aktionen aus:

  1. Provisiert einen Agenten-Identitäts-Blueprint und eine oder mehrere Agentenidentitäten in Microsoft Entra ID.
  2. Weist der Agentidentität RBAC-Rollen (oder andere Berechtigungsmodelle, je nach Zielsystem) zu.
  3. Wenn der Agent ein Tool aufruft, fordert Foundry ein Zugriffstoken für den nachgeschalteten Dienst an und verwendet dieses Token zum Authentifizieren des Toolaufrufs.

Laufzeittokenaustausch

Wenn ein Agent ein Tool aufruft, erfolgt automatisch ein mehrstufiger OAuth 2.0-Tokenaustausch zwischen Agentdienst, Microsoft Entra ID und der downstream-Ressource. Entwickler verwalten keine Token direkt – Der Agentdienst behandelt den gesamten Austausch.

Der Austausch verläuft über vier Stufen:

  • Blueprint-Authentifizierung: Der Agentendienst präsentiert die OAuth-Anmeldeinformationen des Blueprints an Microsoft Entra ID. Dies beweist, dass der Agentdienst berechtigt ist, im Namen des Blueprints und seiner Agentidentitäten zu handeln.

  • Agent-Identitätstokenausstellung: Microsoft Entra ID überprüft die Blueprint-Anmeldeinformationen und gibt ein Token für die spezifische Agentidentität aus. Dieses Token unterscheidet sich von menschlichen Benutzer- oder verwalteten Identitätstoken – er identifiziert den Agent als unabhängiger Akteur im Verzeichnis.

  • Scoped-Tokenanforderung: Der Agent-Dienst stellt das Agentidentitätstoken an Microsoft Entra ID und fordert ein neues Zugriffstoken an, das auf die audience des nachgeschalteten Diensts ausgerichtet ist. Die Zielgruppe ist der OAuth-Ressourcenbezeichner für den Zieldienst (z. B. https://storage.azure.com für Azure Storage).

  • Authentifizierter Toolaufruf: Der Agentdienst übergibt das bereichsbezogene Zugriffstoken an den MCP-Server oder A2A-Endpunkt. Die downstream-Ressource überprüft das Token und überprüft die RBAC-Rollenzuweisungen der Agentidentität, bevor der Zugriff gewährt oder verweigert wird.

In der folgenden Tabelle sind allgemeine Zielgruppenwerte für globale Azure Dienste aufgeführt:

Nachgeschalteter Dienst Zielgruppenwert
Azure Storage https://storage.azure.com
Azure Logic Apps https://logic.azure.com
Azure Cosmos DB https://cosmos.azure.com
Microsoft Graph https://graph.microsoft.com
Azure Key Vault https://vault.azure.net

Wichtig

Ein falscher Zielgruppenwert verursacht Authentifizierungsfehler, auch wenn RBAC-Rollen ordnungsgemäß zugewiesen sind. Die Benutzergruppe muss mit dem Ressourcenbezeichner des downstream-Diensts übereinstimmen, nicht mit der URL des MCP-Servers selbst.

In diesem Artikel verwendete Begriffe

Begriff Was dies bedeutet in Der Gießerei
Agentidentität Ein Microsoft Entra ID Dienstprinzipal, der den Agent zur Laufzeit darstellt.
Agenten-Identitätsentwurf Ein Microsoft Entra ID-Objekt, das eine Klasse von Agentidentitäten steuert und für Lebenszyklusvorgänge verwendet wird.
agentIdentityId Der Bezeichner, den Sie beim Zuweisen von Berechtigungen zur Agentenidentität verwenden.
Publikum Der Ressourcenbezeichner für den nachgeschalteten Dienst, für den das Token vorgesehen ist (z. B https://storage.azure.com. ).

Schlüsselkonzepte

Das Agent ID-Plattform-Framework führt formale Agent-Identitäten und Agent-Identitätsvorlagen in Microsoft Entra ID ein, um KI-Agenten darzustellen. Sie können dieses Framework verwenden, um sicher mit KI-Agents zu kommunizieren. Dieses Framework ermöglicht es diesen KI-Agents auch, sicher mit Webdiensten, anderen KI-Agents und verschiedenen Systemen zu kommunizieren.

Hinweis

Das Microsoft Entra-Agent-ID Framework befindet sich derzeit in der Vorschau. Features und APIs können sich vor der allgemeinen Verfügbarkeit ändern.

Agentidentität

Eine Agentidentität ist ein spezieller Dienstprinzipal in Microsoft Entra ID. Es stellt eine Identität dar, die der Blueprint für die Agentenidentität erstellt hat und autorisiert ist, die Identität zu wechseln.

Sicherheitsvorteile

Agentidentitäten helfen bei der Bewältigung spezifischer Sicherheitsprobleme, die KI-Agents darstellen:

  • Unterscheiden Sie Vorgänge, die KI-Agents von Vorgängen ausführen, die Mitarbeiter-, Kunden- oder Workloadidentitäten ausführen.
  • Ermöglichen Sie KI-Agenten, angemessenen Zugriff über Systeme hinweg zu erhalten.
  • Verhindern Sie, dass KI-Agents Zugriff auf kritische Sicherheitsrollen und -systeme erhalten.
  • Skalieren Sie die Identitätsverwaltung auf eine große Anzahl von KI-Agents, die schnell erstellt und zerstört werden können.

Authentifizierungsfunktionen

Agentidentitäten unterstützen zwei Schlüsselauthentifizierungsszenarien:

  • Betreuter Zugriff (delegierter Zugriff oder Im-Auftrag-von-Fluss): Der Agent arbeitet im Namen eines menschlichen Benutzers und nutzt den Im-Auftrag-von-Fluss (OAuth 2.0). Der Benutzer authentifiziert sich zuerst bei der Anwendung, und die Anwendung übergibt das Token des Benutzers an den Agentdienst. Der Agentdienst wechselt dann dieses Token für ein Token, das sowohl die Agentidentität als auch die delegierten Berechtigungen des Benutzers enthält. Dieser Ansatz bedeutet, dass der Agent nur auf Ressourcen zugreifen kann, denen der Benutzer zugestimmt hat und für den er autorisiert ist.
  • Unbeaufsichtigter (nur Anwendungsablauf): Der Agent agiert unter seiner eigenen Autorität und verwendet den OAuth 2.0-Clientanmeldeinformationsfluss. Der Agentendienst authentifiziert den Blueprint bei Microsoft Entra ID, ruft ein Token für die Agentidentität ab und fordert ein spezifisches Zugriffstoken für die nachgelagerte Ressource an. Der Zugriff des Agents wird vollständig durch eigene RBAC-Rollenzuweisungen, Microsoft Graph Berechtigungen auf App-Ebene oder andere Autorisierungsrichtlinien gesteuert – kein menschlichen Benutzer ist beteiligt.

Agenten-Identitätsentwurf

Ein Plan für Agentenidentitäten dient als wiederverwendbare, steuernde Vorlage, aus der alle zugehörigen Agentenidentitäten erstellt werden. Es entspricht einer Art, Typ oder Klasse von Agents. Sie fungiert als Verwaltungsobjekt für alle Agentidentitätsinstanzen dieser Klasse.

Blueprint-Funktionen

Die Agentidentitäts-Entwürfe dienen drei wesentlichen Zwecken:

Typklassifizierung: Der Blueprint richtet die Kategorie des Agents ein, z. B. "Contoso-Vertriebsmitarbeiter". Diese Klassifizierung ermöglicht Administratoren Folgendes:

  • Wenden Sie Richtlinien für bedingten Zugriff auf alle Agents dieses Typs an.
  • Deaktivieren oder widerrufen Sie Berechtigungen für alle Agents dieser Art.
  • Prüfen und Verwalten von Agents in großem Maßstab durch konsistente, vorlagenbasierte Kontrollen.

Identitätserstellungsstelle: Dienste, die Agentidentitäten erstellen, verwenden den Blueprint zur Authentifizierung. Blueprints verfügen über OAuth-Anmeldeinformationen, die Dienste verwenden, um Token von Microsoft Entra ID zum Erstellen, Aktualisieren oder Löschen von Agentidentitäten abzurufen. Zu diesen Anmeldeinformationen gehören Clientgeheimnisse, Zertifikate oder Verbundanmeldeinformationen wie verwaltete Identitäten.

Laufzeitauthentifizierungsplattform: Der Hostingdienst verwendet den Blueprint während der Laufzeitauthentifizierung. Der Dienst fordert ein Zugriffstoken mithilfe der OAuth-Anmeldeinformationen des Blueprints an. Anschließend wird dieses Token an Microsoft Entra ID präsentiert, um ein Token für eine der Agentenidentitäten zu erhalten.

Blueprint-Metadaten

Beispielsweise kann eine Organisation einen KI-Agent namens "Contoso Sales Agent" verwenden. Der Blueprint definiert Informationen wie:

  • Der Name des Agenttyps: "Contoso-Vertriebsmitarbeiter".
  • Der Herausgeber oder die Organisation, der für den Blueprint verantwortlich ist: "Contoso".
  • Die Rollen, die der Agent ausführen kann: "Vertriebsmanager" oder "Vertriebsmitarbeiter".
  • Microsoft Graph Berechtigungen oder delegierte Bereiche: "Den Kalender des angemeldeten Benutzers lesen".

Verbundidentitätszugangsdaten

Die OAuth-Anmeldeinformationen des Blueprints bestimmen, wie der Agent Service sich während des Laufzeit-Token-Austauschs bei Microsoft Entra ID authentifiziert. Blueprints unterstützen drei Anmeldedatentypen:

Anmeldedatentyp Funktionsweise Abwägungen
Geheimer Clientschlüssel Ein gemeinsames geheimes Kennwort, das in der Entra ID-Registrierung des Blueprints gespeichert ist. Am einfachsten zu konfigurieren, erfordert jedoch eine manuelle Drehung und einen sicheren Speicher.
Zertifikat Ein X.509-Zertifikat, das für die assertionsbasierte Authentifizierung verwendet wird. Stärker als Clientgeheimnisse, erfordert jedoch die Verwaltung des Lebenszyklus von Zertifikaten.
Verbundberechtigungsnachweis (verwaltete Identität) Eine Vertrauensstellung zwischen dem Blueprint und einer verwalteten Identität oder einem Dienstprinzipal. Im Blueprint wird kein Geheimnis gespeichert. Empfohlen für die Produktion. Azure verwaltet die Drehung der Anmeldeinformationen automatisch.

Die Option für föderierte Anmeldedaten ist für Foundry am relevantesten. Wenn Foundry einen Blueprint für eine Agentenidentität für Ihr Projekt bereitstellt, richtet der Blueprint eine Vertrauensstellung mit der verwalteten Identität des Projekts ein. Die Authentifizierungskette funktioniert wie folgt:

  • Der Blueprint der Agentenidentität hat eine Verbundanmeldeinformationen-Vertrauensbeziehung mit der verwalteten Identität des Projekts.
  • Zur Laufzeit verwendet der Agentdienst die verwaltete Identität, um den Blueprint für Microsoft Entra ID zu authentifizieren. Es ist kein geheimer Clientschlüssel oder kein Zertifikat erforderlich.
  • Entra ID überprüft die Verbundanmeldeinformationen und gibt ein Token für die Identität des Agenten (Dienstprinzipal) aus.
  • Das Agent-Identitätstoken wird dann für ein bereichsbezogenes Zugriffstoken ausgetauscht, das auf die Zielgruppe der nachgelagerten Ressource ausgerichtet ist.

Diese Kette wurde entwickelt, um gespeicherte geheime Schlüssel in der Blaupausenkonfiguration zu beseitigen. Azure verwaltet die Rotation von Anmeldeinformationen über die Infrastruktur der verwalteten Identität, und jede Ebene – verwaltete Identität, Agentidentität und Downstream-Ressource – hat unabhängige Rollen mit den geringsten Berechtigungen zugewiesen bekommen. Einige Toolkonfigurationen machen die vom Projekt verwaltete Identität jedoch weiterhin als Authentifizierungsoption verfügbar.

Hinweis

Die verwaltete Identität authentifiziert den blueprint bei Entra ID. Er greift nicht direkt auf die downstream-Ressource zu. Die Agentidentität , nicht die verwaltete Identität, ist der Prinzipal, der RBAC-Rollenzuweisungen für die Zielressource erfordert.

Gießereiintegration

Foundry wird automatisch in Microsoft Entra-Agent-ID integriert, indem Identitäten während des gesamten Lebenszyklus der Agententwicklung erstellt und verwaltet werden. Wenn Sie Ihren ersten Agent in einem Foundry-Projekt erstellen, stellt das System einen Standard-Agent-Identitäts-Blueprint und eine Standard-Agent-Identität für Ihr Projekt bereit.

Gemeinsame Projektidentität

Alle nicht veröffentlichten oder entwicklungsinternen Agents innerhalb desselben Projekts teilen eine gemeinsame Identität. Dieses Design vereinfacht die Berechtigungsverwaltung, da unveröffentlichte Agents in der Regel dieselben Zugriffsmuster und Berechtigungskonfigurationen erfordern. Der Ansatz für gemeinsame Identität bietet folgende Vorteile:

  • Vereinfachte Verwaltung: Administratoren können Berechtigungen für alle Agenten in der Entwicklung innerhalb eines Projekts zentral verwalten.
  • Reduzierte Identitätsvermehrung: Die Verwendung einer einzelnen Identität pro Projekt verhindert die unnötige Erstellung von Identitäten während früher Experimente.
  • Entwicklerautonomie: Nachdem die freigegebene Identität konfiguriert wurde, können Entwickler unabhängig voneinander Agents erstellen und testen, ohne wiederholt neue Berechtigungen zu konfigurieren.

Um den Blueprint für die geteilte Agentenidentität und die Agentenidentität zu finden, gehen Sie im Azure-Portal zu Ihrem Foundry-Projekt. Wählen Sie im Bereich "Übersicht " die JSON-Ansicht aus. Wählen Sie die neueste API-Version aus, um die Identitäten anzuzeigen und zu kopieren.

Screenshot der JSON-Ansicht im Azure-Portal, das einen Agentidentitäts-Blueprint und Agentidentitätsdetails für ein Foundry-Projekt zeigt.

Unterschiedliche Agentidentität

Wenn die Berechtigungen, Auditierbarkeit oder Lebenszyklusanforderungen eines Agents von den Projektstandardeinstellungen abweichen, sollten Sie ein Upgrade auf eine unterschiedliche Identität durchführen. Durch das Veröffentlichen eines Agents wird automatisch ein spezieller Agentenidentitätsentwurf und eine Agentenidentität erstellt. Beide sind an die Agentanwendungsressource gebunden. Diese eindeutige Identität stellt die Systembefugnis des Agenten für den Zugriff auf seine eigenen Ressourcen dar.

Häufige Szenarien, die unterschiedliche Identitäten erfordern, umfassen:

  • Agents sind für Integrationstests bereit.
  • Agenten, die für den Produktionsverbrauch vorbereitet sind.
  • Agenten, die eindeutige Berechtigungsschemata erfordern.
  • Agents, die unabhängige Prüfpfade benötigen.

Um den eindeutigen Agent-Identitäts-Blueprint und die Agentidentität zu finden, wechseln Sie im Azure-Portal zu Ihrer Agentanwendungsressource. Wählen Sie im Bereich "Übersicht " die JSON-Ansicht aus. Wählen Sie die neueste API-Version aus, um die Identitäten anzuzeigen und zu kopieren.

Automatisierungs- und Bereitstellungstools

Bereitstellungstools wie die Azure Developer CLI (azd) bieten eine eingeschränkte Automatisierung für Agentidentitätsberechtigungen:

  • Development: azd weist automatisch Azure KI-Benutzer der freigegebenen Projekt-Agent-Identität für unveröffentlichte Agents zu.
  • Produktion: Veröffentlichte Agents erhalten unterschiedliche Identitäten, die manuelle Rollenzuweisungen erfordern

azd konfiguriert keine Containerregistrierungs-, Application Insights- oder benutzerdefinierten Ressourcenberechtigungen. Informationen zu Produktionsbereitstellungen und den vollständigen Berechtigungsanforderungen für gehostete Agents finden Sie unter Referenz zu Berechtigungen für gehostete Agents.

Toolauthentifizierung

Agents greifen mithilfe von Agentidentitäten für die Authentifizierung auf Remoteressourcen und -tools zu. Der Authentifizierungsmechanismus unterscheidet sich je nach Veröffentlichungsstatus des Agents:

  • Nicht veröffentlichte Agenten: Authentifizieren Sie sich mit der Agentenidentität des freigegebenen Projekts.
  • Veröffentlichte Agents: Authentifizieren Sie sich mithilfe der eindeutigen Agentenidentität, die der Agenten-Anwendung zugeordnet ist.

Wenn Sie einen Agent veröffentlichen, müssen Sie RBAC-Berechtigungen der neuen Agent-Identität für alle Ressourcen zuweisen, auf die der Agent zugreifen muss. Durch diese Neuzuweisung wird sichergestellt, dass der veröffentlichte Agent den geeigneten Zugriff aufrecht erhält, während er unter seiner eindeutigen Identität arbeitet.

Berechtigungen für die Agentenidentität zuweisen

Die Agentidentität ist ein Dienstprinzipal in Microsoft Entra ID. Sie weisen ihm RBAC-Rollen auf die gleiche Weise zu, wie Sie Rollen anderen Dienstprinzipalen oder verwalteten Identitäten zuweisen. Verwenden Sie die agentIdentityId aus der JSON-Ansicht Ihres Projekts oder Ihrer Agentenanwendung als Zuweisungsempfänger.

Um beispielsweise einer Agentenidentität Lese-/Schreibzugriff auf ein Speicherkonto zu gewähren, weisen Sie die Rolle Storage Blob Data Contributor auf der Ebene des Speicherkontos zu.

az role assignment create \
    --assignee "<agentIdentityId>" \
    --role "Storage Blob Data Contributor" \
    --scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>"

So überprüfen Sie die Aufgabe:

az role assignment list \
    --assignee "<agentIdentityId>" \
    --scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>" \
    --output table

Allgemeine Rollenzuweisungen für Agenttools:

Werkzeugszenario Erforderliche Rolle Zielbereich
MCP-Server, der Blobs liest/schreibt Beitragender zu Speicher-Blob-Daten Speicherkonto
MCP-Server, der Logik-Apps auslöst Logic Apps Standard-Operator (Vorschau) Logik-App-Ressource
A2A-Tool, das Cosmos DB abfragt Cosmos DB Integrierter Datenleser Cosmos DB-Konto

Wichtig

Wenn Sie einen Agenten veröffentlichen, erhält er eine neue eindeutige agentIdentityId. Wiederholen Sie diese Rollenzuweisungen für die neue Identität. Die freigegebenen Projektidentitätsrollen werden nicht an die Identität des veröffentlichten Agents übertragen.

Tipp

Ausführliche Informationen zu allen Berechtigungen, die an der Bereitstellung gehosteter Agents beteiligt sind, einschließlich Azure Container Registry, Anwendungseinblicke und RBAC-Konfigurationen mit mehreren Ressourcen, finden Sie unter Hosted-Agent-Berechtigungsreferenz.

Unterstützte Tools

Derzeit sind die Tools, die die Authentifizierung mit einer Agentidentität unterstützen:

  • Model Context Protocol (MCP): Verwenden Sie die Identität Ihres Agents, um sich mit MCP-Servern zu authentifizieren, die die Agentidentitätsauthentifizierung (Vorschau) unterstützen. Ausführliche Informationen finden Sie unter Model Context Protocol und MCP-Serverauthentifizierung.
  • Agent-zu-Agent (A2A):Aktivieren Sie die sichere Kommunikation zwischen Agents mithilfe von Agentidentitäten (Vorschau). Ausführliche Informationen finden Sie unter Agent-zu-Agent-Tool und Agent2Agent (A2A)-Authentifizierung.

Andere Tools und Integrationen verwenden möglicherweise unterschiedliche Authentifizierungsmethoden (z. B. schlüsselbasierte Authentifizierung oder OAuth-Identitätspassthrough). Verwenden Sie die Tooldokumentation, um die unterstützte Authentifizierung zu bestätigen.

Konfigurieren von Toolverbindungen

Um einen MCP-Server oder A2A-Endpunkt mit Agenten-Identitätsauthentifizierung zu verbinden, erstellen Sie eine Projektverbindung, die den Authentifizierungstyp und das Zielpublikum für den Downstream-Dienst angibt. Der Authentifizierungstyp hängt vom Tool ab:

Tooltyp Authentifizierungs-Typwert Verbindungskategorie
MCP-Server AgenticIdentityToken RemoteTool
A2A-Endpunkt AgenticIdentity RemoteA2A

Wenn der Agent das Tool aufruft, verwendet der Agentdienst die Agentidentität, um ein Zugriffstoken abzurufen, das auf den Zielgruppenwert festgelegt ist, und übergibt dieses Token dann zur Authentifizierung an den Toolendpunkt.

Schrittweise Anleitungen zur Konfiguration finden Sie unter:

Sicherheitsüberlegungen

Agentidentitäten helfen Ihnen dabei, Risiken zu reduzieren, indem die Notwendigkeit entfernt wird, langlebige Anmeldeinformationen in Agentkonfigurationen einzubetten. Verwenden Sie diese Methoden, um den Zugriff auf ein geringes Berechtigungsniveau und prüfbar zu halten:

  • Weisen Sie nur die Berechtigungen zu, die der Agent für seine Toolaktionen benötigt. Bevorzugen Sie schmale Bereiche (Ressourcen- oder Ressourcengruppe) gegenüber dem abonnementweiten Zugriff.
  • Behandeln Sie die freigegebene Projektidentität als einen größeren Einschlagsradius. Wenn ein Agent strengere Kontrollen oder separate Überwachung benötigt, veröffentlichen Sie sie, damit sie eine eindeutige Identität erhält, und weisen Sie dieser neuen Identität Rollen zu.
  • Überprüfen und protokollieren Sie den Zugriff auf Nicht-Microsoft Tools und Server. Wenn ein Toolaufruf Microsoft-Dienste verlässt, sind die Datenverarbeitung und -aufbewahrung vom externen Anbieter abhängig.

Einschränkungen

  • Nur einige Tools unterstützen derzeit die Agentidentitätsauthentifizierung. Überprüfen Sie die Tooldokumentation für die unterstützte Authentifizierung.
  • Das Veröffentlichen eines Agents ändert, welche Identität für Toolaufrufe verwendet wird (freigegebene Projektidentität und unterschiedliche Agentidentität). Planen Sie die Neuzuweisung von Rollen bei der Veröffentlichung.

Häufige Probleme

Diese Probleme verursachen häufig Fehler bei der Toolauthentifizierung bei der Verwendung von Agentidentitäten:

  • Rollen, die der falschen Identität zugewiesen sind: Bestätigen Sie, dass Sie Berechtigungen für die aktuelle Identität erteilt haben, die vom Agent verwendet wird (freigegebene Projektidentität für nicht veröffentlichte Agents, unterschiedliche Identität für veröffentlichte Agents).
  • Fehlende Rollenzuweisungen: Stellen Sie sicher, dass die Agentidentität über die erforderliche RBAC-Rolle für die Zielressource verfügt. Informationen zu Foundry-Rollen und -Bereichen finden Sie unter Azure rollenbasierte Zugriffssteuerung in Foundry.
  • Incorrect audience: Stellen Sie sicher, dass die Benutzergruppe mit dem von Ihnen aufgerufenen downstreamen Dienst übereinstimmt (z. B. https://storage.azure.com für Azure Storage).

Toolspezifische Problembehandlung finden Sie in der Tooldokumentation:

Verwalten von Agentidentitäten

Agentidentitäten bleiben erhalten, solange die zugeordnete Gießerei-Projekt- oder Agentanwendungsressource vorhanden ist. Wenn Sie ein Foundry-Projekt löschen, werden der zugeordnete Agentenidentitätsentwurf und die gemeinsame Agentenidentität entfernt. Veröffentlichte Agents verfügen über einen eigenen Identitätslebenszyklus, der an die Agentenanwendungsressource gebunden ist. Das Löschen der Agentanwendung führt zur Entfernung ihrer eigenen Identität.

Sie können alle Agentidentitäten in Ihrem Mandanten im Microsoft Entra Admin Center anzeigen und verwalten. Melden Sie sich beim Microsoft Entra Admin Center an und navigieren Sie zu Entra ID>Agent ID>Alle Agentenidentitäten, um einen Bestand aller Agenten in Ihrem Mandanten anzuzeigen, einschließlich Foundry-Agenten, Microsoft Copilot Studio-Agenten und anderer.

Screenshot des Microsoft Entra Admin Center, das die Registerkarte für Agentidentitäten mit einer Übersicht aller Agenten im Mandanten anzeigt.

In dieser Umgebung können Sie integrierte Sicherheitssteuerelemente aktivieren, einschließlich:

  • Bedingter Zugriff: Anwenden von Zugriffsrichtlinien auf Agentidentitäten.
  • Identitätsschutz: Überwachen und Schützen von Agentidentitäten vor Bedrohungen.
  • Netzwerkzugriff: Steuern des netzwerkbasierten Zugriffs für Agents.
  • Governance: Verwaltung von Ablaufdaten, Besitzern und Sponsoren für Agentenidentitäten.

Weitere Informationen zu Microsoft Entra-Agent-ID Features finden Sie in der Dokumentation Microsoft Entra.