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. Dasselbe Identitätsmodell gilt für textbasierte Eingabeaufforderungs-Agents und sprachbasierte Eingabeaufforderungs-Agents. In sprachbasierten Szenarien verwaltet Foundry die Echtzeit-VoIP-Runtime- und WebSocket-Verbindung, während die Agentidentität weiterhin nachgeschaltete Tools und Ressourcen authentifiziert.

Voraussetzungen

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

Agentenidentitäten und Blueprints

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.

Agenten-Identitätsentwurf

Ein Agent-Identitäts-Blueprint modelliert den Agent und ist das übergeordnete Objekt für die zugehörigen Agentidentitäten. Sie stellt die maßgebliche Vorlage für diese Identitäten bereit.

Die Blaupause kann auch als Anmeldestelle des Agenten dienen. Mithilfe des Autorisierungsschemas des Vorschauendpunkts AgentBlueprint erhalten Clients Token für die Agent-Blueprint-Zielgruppe, um den Agent aufzurufen. Dieser eingehende Zugriff ist vom Zugriff der Agentidentität auf downstream-Ressourcen getrennt. Siehe Agent-Blueprint-Endpunktzugriff und Konfigurieren des Agent-Blueprint-Zugriffs.

Foundry verwendet die Blaupause zum Authentifizieren von Identitätslebenszyklusvorgängen und zum Abrufen von Zugriffstoken für die zugehörigen Identitäten zur Laufzeit. Sie müssen keinen geheimen Clientschlüssel oder ein Zertifikat für diesen Ablauf konfigurieren.

Foundry stellt eine Verbundidentitäts-Anmeldeinformation für den Agentidentitäts-Blueprint für die vom Dienst verwaltete Authentifizierung bereit. Der Agentdienst verwendet ihn während des Laufzeittokenaustauschs. Informationen zum zugrunde liegenden Anmeldeinformationsmodell finden Sie unter Agent Identity Blueprint-Anmeldeinformationen.

Informationen zum zugrunde liegenden Microsoft Entra-Objekt und dessen Eigenschaften finden Sie unter Agent-Identitätsblueprints.

Agentidentität

Eine Agentidentität ist ein spezieller Dienstprinzipal in Microsoft Entra ID, der unter einem Agent-Blueprint erstellt wurde. Sie stellt eine Agentinstanz dar, wenn sie auf nachgeschaltete Ressourcen zugreift. Der übergeordnete Blueprint ist berechtigt, diese Identität anzunehmen. Zum zugrunde liegenden Objekt siehe Agentidentitäten.

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.

Wie Foundry Identitäten bereitstellt

Foundry erstellt und verwaltet Microsoft Entra Agentidentitäten während des gesamten Agent-Lebenszyklus. Im aktuellen Agent-Objektmodell stellt das Erstellen eines Agents einen eindeutigen Agent-Blueprint und die Identität für seine Standardinstanz bereit.

Eine neu erstellte Agentidentität beginnt ohne Ressourcenberechtigungen. Foundry weist ihm keine RBAC-Rollen oder andere downstream-Berechtigungen automatisch zu. Sie oder Ihr Administrator gewähren den benötigten Zugriff über das Autorisierungsmodell des Zieldiensts. Siehe Zuweisen von Berechtigungen zur Agentidentität.

Die freigegebene Projektkennung bleibt für Legacy-Agents verfügbar. Die Unterschiede zwischen Legacy-Agents, Agentanwendungen und dem aktuellen Modell finden Sie unter Migration von Agentanwendungen zum neuen Agent-Endpunkt und zur neuen Veröffentlichungserfahrung.

Wie Agents ihre Identität zur Laufzeit verwenden

Wenn ein Tool die Agentidentitätsauthentifizierung verwendet, verwendet der Agent seine Identität, um auf die downstream-Ressource zuzugreifen.

dienstverwaltete Authentifizierung für Tools

Wenn der Agent ein Tool aufruft, fordert Foundry ein Zugriffstoken für den downstream-Dienst an und verwendet dieses Token zum Authentifizieren des Toolaufrufs.

Diese Authentifizierungsmethode gilt für textbasierte und sprachbasierte Eingabeaufforderungs-Agents gleichermaßen. Sprachbasierte Agenten verwenden dieselbe Agentenidentität, um Toolaufrufe zu authentifizieren, während Foundry die Echtzeit-Sprachsitzung und die Voice Live-Verbindung verwaltet.

Laufzeittokenaustausch

Bei dienstverwalteten Toolaufrufen, die die Agentidentitätsauthentifizierung verwenden, erfolgt automatisch ein mehrstufiger OAuth 2.0-Tokenaustausch zwischen Agent Service, Microsoft Entra ID und der downstream-Ressource. Der Agentdienst übernimmt den Austausch.

Der Austausch verläuft über vier Stufen:

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

  2. Agent-Identitätstokenausstellung: Microsoft Entra ID überprüft die Blueprint-Anmeldeinformationen und gibt ein Token für die spezifische Agentidentität aus. Dieses Token ist verschieden von menschlichen Benutzer- oder verwalteten Identitätstoken – es identifiziert den Agenten als unabhängigen Akteur im Verzeichnis.

  3. Bereichsbezogene Tokenanforderung: Der Agent Service legt das Agent‑Identitätstoken erneut bei Microsoft Entra ID vor und fordert ein neues Zugriffstoken an, das auf die Zielgruppe Downstream‑Dienstes ausgerichtet ist. Die Zielgruppe ist der OAuth-Ressourcenbezeichner für den Zieldienst (z. B. https://storage.azure.com für Azure Storage).

  4. 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.

Die Audience identifiziert die Ressource, die das Token akzeptiert, was nicht unbedingt die URL des Toolendpunkts ist. Die Authentifizierung für jene Ressource gewährt nicht selbst Zugriff. Informationen zu Verbindungseinstellungen und Benutzergruppenkonfiguration finden Sie unter MCP-Serverauthentifizierung und A2A-Authentifizierung.

Tokenabruf im Code des gehosteten Agenten

Für gehostete Agents ermöglicht der Tokendienst Ihrem Code standardmäßig das Abrufen von Token für die Identität der aktuellen Agentinstanz. Die projektverwaltete Identität ist für Ihren Hosted-Agent-Code nicht verfügbar. Informationen zur Identitätsauswahl, zum Verhalten von Azure Identity und zum Vertrag für die Tokenanforderung finden Sie unter Referenz zum Dienst für gehostete Agent-Token.

Berechtigungen und Zugriffsgrenzen

Die Authentifizierung weist den Agenten gegenüber dem nachgelagerten Dienst aus. Das Autorisierungsmodell des Diensts bestimmt, was diese Identität tun kann.

Reiner Anwendungszugriff und delegierter Zugriff

Das Zugriffsmodell bestimmt, wessen Berechtigung einen Tool-Aufruf steuert:

  • Zugriff nur für Anwendungen: Der Agent handelt in eigenem Namen, ohne einen angemeldeten Benutzer. Der Zugriff hängt von den Rollen, Anwendungsberechtigungen oder anderen Autorisierungsrichtlinien ab, die seiner Identität zugewiesen wurden.
  • Delegierter Zugriff: Der Agent fungiert im Auftrag des angemeldeten Benutzers. Der Agent benötigt eine Autorisierung für die angeforderten delegierten Berechtigungen, und der Benutzer benötigt Zugriff auf die Ressource.

Informationen zum delegierten Akteurmodell und den Zustimmungsanforderungen finden Sie unter Benutzerdelegierung für Tools und Microsoft Entra Zustimmung für delegierten Zugriff.

Zuweisen von Berechtigungen zur Agent-Identität

Der nachgeschaltete Dienst bestimmt, wie er den Zugriff autorisiert:

Autorisierungsmechanismus Wie Zugriff gewährt wird
Azure RBAC Azure-Rollenzuweisungen gewähren der Identität Berechtigungen in einem Azure-Ressourcenbereich. Siehe Azure Übersicht über das RBAC.
Dienstspezifische Rollen der Datenebene Der Dienst gewährt Zugriff über eigene Rollenzuweisungen, z. B. Azure Cosmos DB Datenebenenrollen. Dies sind nicht Azure RBAC-Rollenzuweisungen.
Anwendungsberechtigungen oder App-Rollen Eine API erteilt der Identitätsanwendung Berechtigungen auf Anwendungsebene für den Zugriff ohne einen angemeldeten Benutzer, sofern unterstützt. Siehe Berechtigungen und Zustimmung in Microsoft Entra ID.
Ressourcenspezifische Autorisierungsrichtlinien Der Zieldienst wendet seine eigenen Zugriffsrichtlinien oder Berechtigungsprüfungen auf die authentifizierte Identität an. Befolgen Sie die Hinweise zur Autorisierung dieses Diensts.

Ein Dienst kann mehrere Autorisierungsebenen erfordern. Wenn ein Tool die Agentidentitätsauthentifizierung verwendet, gewähren Sie zugriff auf die Agentidentität. Einige Toolsverbindungen verwenden stattdessen eine vom Projekt verwaltete Identitätsauthentifizierung, und in diesem Fall wird der verwalteten Identität des Projekts Zugriff gewährt.

Wenden Sie das Least-Privilege-Prinzip auf die Identität an, die für jeden Toolaufruf verwendet wird. Für Azure RBAC bevorzugen Sie einen Ressourcen- oder Ressourcengruppenbereich gegenüber dem abonnementweiten Zugriff, wenn er die Anforderungen des Agents erfüllt.

Beispielsweise benötigt ein Agent, der über die nur-Anwendungsauthentifizierung auf Azure Storage Blobs zugreift, eine geeignete Azure RBAC-Rolle für die Speicherressource. Ein Agent, der Azure Cosmos DB abfragt, kann stattdessen eine dienstspezifische Datenebenenrolle benötigen. Diese Autorisierungsmechanismen sind getrennt, obwohl beide die Agentidentität autorisieren.

Verwenden Sie für Azure RBAC-Zuweisungsprozeduren die Objekt-ID der Agentidentität, die für den Toolaufruf als Zuweisungsempfänger verwendet wird. Siehe Azure-Rollen mit der Azure CLI zuweisen. Informationen zur Autorisierung von Cosmos DB-Datenebenen finden Sie unter Konfigurieren der rollenbasierten Zugriffssteuerung für Azure Cosmos DB.

Informationen zu Berechtigungen, die für die Bereitstellung von gehosteten Agents erforderlich sind, einschließlich Azure Container Registry und Application Insights, finden Sie unter Referenz zu Berechtigungen für gehostete Agents.

Unterstützte Tools

Tools können eine Agentidentität für den reinen Anwendungszugriff oder als Akteur in einem delegierten Aufruf verwenden. Die Unterstützung für einen Zugriffstyp impliziert keine Unterstützung für den anderen. In der folgenden Tabelle werden unterstützte Integrationen und Links zu ihren Authentifizierungsleitfäden zusammengefasst.

Tool oder Integration Verwendung und Anleitung zur Agentidentität
Agent-zu-Agent-Kommunikation (A2A) Nur-Anwendungszugriff mit der Identität des anrufden Agents oder delegiertem Zugriff, wenn das Ziel es unterstützt. Siehe A2A-Authentifizierung.
Azure Databricks Genie MCP Zugriff im Auftrag des Benutzers mit AgentOnBehalfOfUser. Siehe unterstützte delegierte Ziele und Bereiche.
Azure DevOps MCP Zugriff im Auftrag des Benutzers. Siehe Konfigurieren der Microsoft Entra-Benutzerdelegierung.
Fabric IQ-Datenagent Zugriff im Auftrag des Benutzers, einschließlich Verbindungen zu privaten Arbeitsbereichsendpunkten.
Fabric IQ Ontologie Zugriff im Namen des Benutzers auf Ontologieelemente.
Fabric IQ Power BI Semantikmodell Zugriff auf semantische Modelle im Auftrag des Benutzers.
Foundry IQ Im Auftrag des Benutzers mit plattformverwalteter Quellautorisierung. Siehe Foundry IQ Quellenautorisierung.
Foundry MCP Zugriff im Auftrag des Benutzers Siehe unterstützte delegierte Ziele und Bereiche.
Microsoft Dataverse Zugriff im Auftrag des Nutzers. Siehe unterstützte delegierte Ziele und Scopes.
Modellkontextprotokoll (MCP) Nur Anwendungszugriff auf Server, die Agentidentitätstoken akzeptieren, oder delegierter Zugriff, sofern unterstützt. Siehe Einrichten der MCP-Serverauthentifizierung.
Sentinel Data Exploration, Graph, Knowledge Objects und Memory Zugriff im Auftrag des Benutzers Siehe unterstützte delegierte Ziele und Bereiche.
Work IQ Calendar, Copilot, Mail, OneDrive, SharePoint, Teams, Benutzer und Word Zugriff im Auftrag des Benutzers Informationen zu unterstützten delegierten Zielen und Scopes.
Work IQ MCP Zugriff im Auftrag des Benutzers mit AgentOnBehalfOfUser. Reiner Anwendungszugriff und UserEntraToken werden nicht unterstützt.

Die Agentidentität, die im Auftrag des Benutzers fungiert, befindet sich in der Vorschau und erfordert den Zugriff auf den Agent-Blueprint-Endpunkt. Informationen zu Endpunktanforderungen, unterstützten Authentifizierungstypen, delegierten Gültigkeitsbereichen und Einwilligung finden Sie unter Konfigurieren der Benutzerdelegierung für Tools.

Andere Tools und Integrationen können unterschiedliche Identitäten oder Authentifizierungsmethoden verwenden. Prüfen Sie die Unterstützung in der Dokumentation des Tools. Die Authentifizierung über eine projektverwaltete Identität und eine separate OAuth-Anmeldung stellen für sich genommen keine Authentifizierung der Agentidentität her.

Die Agentidentitätsauthentifizierung ändert die Datenverarbeitungs- oder Aufbewahrungsrichtlinien eines externen Toolanbieters nicht. Aufrufe von Nicht-Microsoft-Tools können Daten außerhalb von Microsoft-Diensten senden. Überprüfen und protokollieren Sie diesen Zugang gemäß den Richtlinien Ihrer Organisation.

Identitätsverwaltung und -governance

Im aktuellen Agent-Objektmodell verfügt jeder Agent über einen eigenen Agent-Blueprint und eine Standardinstanzidentität bei der Erstellung.

Foundry-Agent-Identitäten werden im mandantenweiten Bestand im Microsoft Entra Admin Center zusammen mit Identitäten aus Microsoft Copilot Studio und anderen Diensten angezeigt. Dieses Inventar ermöglicht Administratoren die Verwaltung von Agents über Dienste hinweg und nicht nur innerhalb eines Foundry-Projekts.

Mithilfe von Identitäten pro Agent können Sie Berechtigungen und Audit-Aktivitäten auf einzelne Agents festlegen. Legacy-Agents, die eine Projektidentität gemeinsam nutzen, weisen diese Trennung auf Identitätsebene nicht auf; siehe den Migrationsleitfaden.

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: Verwalten Sie Ablauf, Besitzer und Sponsoren für Agent-Identitäten.

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

Geteilte Projektidentitäten und Agent-Anwendungen

Foundry stellt weiterhin einen freigegebenen Agent-Blueprint und eine Agentidentität auf Projektebene bereit. Legacy-Agents ohne eindeutige Identität verwenden diese gemeinsame Identität. Neu erstellte Agents erhalten stattdessen ihre eigene Blueprint- und Standardinstanzidentität.

Durch die Migration von einer veralteten gemeinsamen Projektidentität oder Agentanwendung zum aktuellen Agentobjektmodell wird die Agentidentität geändert. Weisen Sie der neuen Identität die erforderlichen nachgeschalteten Berechtigungen zu; vorhandene Rollenzuweisungen werden nicht übertragen. Siehe Migrieren von Agentanwendungen zum neuen Agent-Endpunkt und zur neuen Agent-Endpunkt- und Veröffentlichungserfahrung.

Bei Legacy-Identitäten entfernt das Löschen des Foundry-Projekts den freigegebenen Agent-Blueprint und die Identität. Durch das Löschen einer Legacy-Agent-Anwendung wird die eigenständige Identität dieser Anwendung entfernt.

Bei älteren Bereitstellungen weist die Azure Developer CLI (azd) foundry User der freigegebenen Projekt-Agent-Identität aus Gründen der Kompatibilität automatisch zu. Für das Standardszenario für gehostete Agent ist diese Zuordnung nicht erforderlich. Legacy-Agentanwendungen verfügen über unterschiedliche Identitäten, die separate manuelle Rollenzuweisungen erfordern.

Wichtig

Die Foundry-RBAC-Rollen wurden kürzlich umbenannt. Foundry User, Foundry Owner, Foundry Account Owner und Foundry Project Manager wurden zuvor Azure KI-Benutzer, Azure KI-Besitzer, Azure KI-Kontobesitzer und Azure AI Project Manager benannt. Möglicherweise werden die vorherigen Namen an einigen Stellen weiterhin angezeigt, während der Umbenennungsrollout ausgeführt wird. Die Rollen-IDs und Kernberechtigungen bleiben durch die Umbenennung unverändert.

Die Rollenzuweisung der freigegebenen Identität gewährt keine Berechtigungen für Azure Container Registry, Application Insights oder benutzerdefinierte Ressourcen. Informationen zu den ressourcenspezifischen Berechtigungen, die von gehosteten Agents benötigt werden, finden Sie unter Referenz zu Berechtigungen für gehostete Agents.

Verwandte Inhalte

  • Zuletzt aktualisiert um