Identität von KI-Agenten – Übersicht

Agent Identity bietet jedem Agenten eine stark bestätigte kryptografische Identität, die auf dem SPIFFE-Standard basiert. Mit der Agent-Identität kann sich Ihr Agent sicher bei MCP-Servern, Cloud-Ressourcen, Endpunkten und anderen Agenten authentifizieren und entweder in seinem eigenen Namen oder im Namen eines Endnutzers handeln. Bei der Agent-Identität werden die eigenen Anmeldedaten des Agents und der Authentifizierungsmanager für die Identität von KI-Agenten verwendet. Mit dem Auth-Manager können Sie Auth-Anbieter erstellen und verwalten. Das sind die spezifischen Konfigurationen, die zum Abrufen, Verwalten und Sichern von API-Schlüsseln, OAuth-Client-IDs, OAuth-Clientschlüsseln und delegierten OAuth-Tokens für Endnutzer verwendet werden.

Im Gegensatz zu Dienstkonten werden Agent-Identitäten standardmäßig nicht von mehreren Arbeitslasten gemeinsam genutzt, können nicht imitiert werden und ermöglichen es Entwicklern nicht, Dienstkontoschlüssel mit langer Gültigkeitsdauer zu generieren. Für Google Cloudgenerierte Zugriffstokens sind kryptografisch an die eindeutigen X.509-Zertifikate des Agenten gebunden, um Token-Diebstahl zu verhindern.

Wenn die Agent-Identität mit dem Agent Gateway und Gemini Enterprise verwendet wird, werden die Anmeldedaten der Endnutzer, z. B. die von Gemini Enterprise-Connectors bereitgestellten Anmeldedaten, vom Auth-Manager verschlüsselt und am Gateway entschlüsselt. So wird sichergestellt, dass der Agent niemals auf die Rohanmeldedaten zugreifen kann.

Die folgenden Dienste unterstützen die Agent-Identität:

Authentifizierungsmodelle

Für die Authentifizierung bei verschiedenen Tools und Diensten unterstützt die Agent-Identität mehrere Authentifizierungsmodelle. Welches Modell ein Agent verwendet, hängt von der Authentifizierungsmethode ab, die von der Zielressource angeboten wird, und davon, ob der Agent in eigener Verantwortung oder im Namen eines Endnutzers handelt.

Entscheidungsbefugnis Authentifizierungsmethode Zielressource Anwendungsfall und Lösung
Vom Nutzer delegierte Berechtigung OAuth 2.0 (dreibeinig) (Vorschau) Externe Tools und Dienste Wenn ein Agent im Namen eines bestimmten Nutzers handelt (z. B. um auf die Jira-Aufgaben oder GitHub-Repositories eines Nutzers zuzugreifen). Sie konfigurieren einen OAuth-Anbieter mit 3-legged-Authentifizierung im Authentifizierungsmanager für die Identität von KI-Agenten, um die Nutzereinwilligung und Tokens zu verwalten. Weitere Informationen finden Sie unter Mit dreibeinigem OAuth und dem Auth-Manager authentifizieren.
Eigene Befugnisse des Agents Cloudbasierte Identität (Agentenidentität) Google Cloud -Dienste Wenn ein auf Google Cloud gehosteter Agent mit seiner eigenen Identität auf andere Google Cloud -Dienste zugreifen muss. Weitere Informationen finden Sie unter Mit der Identität des Agents authentifizieren.
OAuth 2.0 (2-legged) (Vorschau) Externe Tools und Dienste Empfohlen für die Authentifizierung zwischen Maschinen mit externen Diensten, die OAuth unterstützen. Sie konfigurieren einen 2-legged-OAuth-Authentifizierungsanbieter im Agent Identity-Authentifizierungsmanager, um Clientanmeldedaten und Zugriffstokens zu verarbeiten. Weitere Informationen finden Sie unter Mit 2-legged OAuth mit dem Auth-Manager authentifizieren.
API-Schlüssel (Vorschau) Externe Tools und Dienste Für externe Dienste, die einen kryptografischen Schlüssel oder ein Passwort zur Authentifizierung erfordern. Sie konfigurieren einen API-Schlüssel-Authentifizierungsanbieter im Agent Identity-Authentifizierungsmanager, um die Schlüssel sicher zu speichern und zu verwalten. Weitere Informationen finden Sie unter Mit API-Schlüssel und Auth Manager authentifizieren.
HTTP-Basisauthentifizierung Externe Tools und Dienste Verwendet Passwörter im Klartext. Diese Methode wird nicht empfohlen. Sie können Passwörter ähnlich wie API-Schlüssel speichern. Weitere Informationen finden Sie unter Mit API-Schlüssel und Auth Manager authentifizieren.

Kernkomponenten

Die Agent-Identität umfasst mehrere Schlüsselkomponenten, die zusammen für eine sichere Authentifizierung und Autorisierung sorgen.

SPIFFE-basierte Identität

Jedem Agent wird basierend auf dem SPIFFE-Standard ein eindeutiger Identitätsstring oder eine SPIFFE-ID zugewiesen. Diese Identität ist stark beglaubigt, an den Lebenszyklus des Agenten gebunden und wird direkt dem Ressourcen-URI zugeordnet, auf dem der Agent gehostet wird.

Die Identität hat das folgende Format:

spiffe://TRUST_DOMAIN/resources/SERVICE/RESOURCE_PATH

Beispiel:

  • spiffe://agents.global.org-123456789012.system.id.goog/resources/aiplatform/projects/9876543210/locations/us-central1/reasoningEngines/my-test-agent

Wenn eine Agent-Identität in einer IAM-Zulassungsrichtlinie verwendet wird, hat die Hauptkonto-ID das folgende Format:

principal://TRUST_DOMAIN/resources/SERVICE/RESOURCE_PATH

Beispiele:

  • Vertex AI Agent Engine:principal://agents.global.org-123456789012.system.id.goog/resources/aiplatform/projects/9876543210/locations/us-central1/reasoningEngines/my-test-agent
  • Gemini Enterprise:principal://agents.global.org-123456789012.system.id.goog/resources/discoveryengine/projects/9876543210/locations/global/collections/default_collection/engines/my-test-agent

Die Kennzeichnungen verwenden Folgendes:

  • TRUST_DOMAIN: Die Vertrauensdomäne Ihrer Organisation, z. B. agents.global.org-123456789012.system.id.goog.
  • SERVICE: Der Kurzname des Google Cloud -Dienstes (z. B. aiplatform oder discoveryengine).
  • RESOURCE_PATH: Der vollständige Pfad zur Ressource, die den Agent hostet.

Da der Agent selbst das Hauptkonto ist, erteilen Sie Berechtigungen direkt für diese Kennung, um zu steuern, auf welche Ressourcen der Agent zugreifen kann.

Anmeldedaten des KI-Agenten

Agent-Anmeldedaten liefern einen kryptografischen Nachweis der Identität eines Agenten. Das System unterstützt X.509-Zertifikate und Google Cloud Zugriffstokens. Ein X.509-Zertifikat wird automatisch auf dem Agent bereitgestellt und verwaltet, um eine stärkere Authentifizierung zu unterstützen.

Authentifizierungsmanager für die Identität von KI-Agenten

Der Authentifizierungsmanager für die Identität von KI-Agenten ist ein zentralisierter Anmeldedatenspeicher und Authentifizierungsbroker, der die ausgehende Tool-Authentifizierung für Ihre KI-Agenten vereinfacht. Damit können sich Kundenservicemitarbeiter mit einem API-Schlüssel oder einer OAuth-Client-ID und einem ‑geheimnis authentifizieren oder im Namen eines Nutzers über die OAuth-Delegierung mit Endnutzer-Zugriffstokens. Im Auth-Manager konfigurieren Sie Auth-Anbieter, die den Authentifizierungstyp und die Anmeldedaten für bestimmte Drittanbieteranwendungen definieren.

Der Zugriff auf den Authentifizierungsmanager für die Identität von KI-Agenten wird durch IAM geregelt. Der KI-Agent verwendet seine eigene SPIFFE-ID, um sich beim Authentifizierungsmanager zu authentifizieren. Alle Endnutzer-Zugriffsereignisse werden auch der SPIFFE-ID des Agents zugeordnet, was die Verwaltung erleichtert.

Der Agent Identity-Authentifizierungsmanager automatisiert die Erfassung von OAuth-Anmeldedaten, z. B. durch Öffnen eines Dialogfelds für die Nutzeranmeldung und ‑einwilligung. Außerdem erhalten Sie Einblick in den Endnutzerzugriff und können den Zugriff widerrufen, um die von Nutzern delegierten Berechtigungen besser zu verwalten.

Weitere Informationen finden Sie in der Übersicht über den Agent Identity Auth Manager.

Sicherheit und Governance

Die Agent-Identität ist vollständig in die Richtliniensysteme von Google wie IAM, Principal Access Boundary (PAB) und VPC Service Controls integriert, was für mehr Sicherheit und Governance sorgt. Die Funktion ist auch in die Audit-Logs integriert, um die Rechenschaftspflicht zu gewährleisten und klare Audit-Logs bereitzustellen, sowohl wenn der Agent selbst agiert als auch wenn er im Namen eines Endnutzers agiert.

  • Kontextsensitiver Zugriff:Standardmäßig trägt eine von Google verwaltete Richtlinie für den kontextsensitiven Zugriff dazu bei, Anmeldedaten für die Agent-Identität zu schützen. Über das Agent Gateway hinaus wird durch die Richtlinie die Demonstration of Proof of Possession (DPoP) erzwungen, indem das Zugriffstoken des Agents authentifiziert wird. Die Richtlinie erzwingt auch, dass mTLS für den Zugriff auf das Agent Gateway verwendet wird. So wird sichergestellt, dass an Zertifikate gebundene Tokens nur in der vorgesehenen, vertrauenswürdigen Laufzeitumgebung verwendet werden können.
  • IAM-Integration:Unterstützung von standardmäßigen IAM-Zulassungs- und ‑Ablehnungsrichtlinien.
  • Principal Access Boundary (PAB): Eine PAB schränkt die Ressourcen ein, auf die ein Agent zugreifen kann, unabhängig von anderen Berechtigungen.
  • VPC Service Controls:Unterstützung für die Verwendung von Agent-Identitäten (Vorabversion) in Regeln für ein- und ausgehenden Traffic, um den Zugriff auf Ressourcen zu ermöglichen, die durch einen Dienstperimeter geschützt sind.

Funktionsweise der Agentenidentität

Die Agent-Identität authentifiziert und autorisiert Agent-Aktionen über einen Workflow, der die Sicherheit verbessern soll:

  1. Identitätszuweisung: Wenn Sie einen Agent bereitstellen,weist Google Cloudihm eine eindeutige SPIFFE-Identität und ein X.509-Zertifikat zu. Jedes X.509-Zertifikat ist 24 Stunden lang gültig und wird von Google Cloudautomatisch aktualisiert, um die Sicherheit zu gewährleisten.
  2. Abrufen von Anmeldedaten: Die Methode, mit der KI-Agenten Anmeldedaten abrufen, hängt davon ab, worauf sie zugreifen möchten. Hier einige Beispiele:
    • Auf Google Cloud Dienste zugreifen: Der Agent fordert ein gebundenes Zugriffstoken an. Dieses Token ist kryptografisch an das eindeutige X.509-Zertifikat des Agents gebunden, um Token-Diebstahl zu verhindern. Weitere Informationen finden Sie unter Sicherheit und Governance.
    • Auf externe Tools zugreifen: Der Agent verwendet den Authentifizierungsmanager für die Identität von KI-Agenten, um die erforderlichen Anmeldedaten (z. B. API-Schlüssel oder OAuth-Tokens) von einem Authentifizierungsanbieter abzurufen. Der Auth-Manager unterstützt sowohl die vom Nutzer delegierte Berechtigung als auch die eigene Berechtigung des Kundenservicemitarbeiters.

Vorteile der Agentenidentität

Die Agent-Identität bietet mehr Sicherheit als Standarddienstkonten.

  • Starke Isolation:Im Gegensatz zu Dienstkonten werden Agent-Identitäten standardmäßig nicht von mehreren Arbeitslasten gemeinsam genutzt, können nicht imitiert werden und ermöglichen es Entwicklern nicht, langlebige Dienstkontoschlüssel zu generieren.
  • Anmeldedatensicherheit:Standardmäßige kontextsensitiver Zugriff-Richtlinien machen gebundene Tokens nicht wiederholbar und schützen so vor Token-Diebstahl und Kontoübernahme. Wenn die Agent-Identität mit dem Agent Gateway und Gemini Enterprise verwendet wird, werden die Anmeldedaten des Endnutzers, z. B. die von Gemini Enterprise-Connectors bereitgestellten Anmeldedaten, vom Auth-Manager verschlüsselt und am Gateway entschlüsselt. So wird sichergestellt, dass der Agent niemals auf die Rohanmeldedaten zugreifen kann.
  • Ansatz mit minimalen Berechtigungen:Es werden Identitäten pro Agent anstelle von gemeinsam genutzten Dienstkonten bereitgestellt, um Agenten mit zu vielen Berechtigungen zu vermeiden.
  • Weniger Aufwand:Komplexe OAuth-Abläufe werden automatisiert und API-Schlüssel verwaltet, um die Toolintegration zu vereinfachen.
  • Bessere Beobachtbarkeit:Es werden übersichtliche Audit-Logs bereitgestellt. Wenn ein Agent im Namen eines Nutzers handelt, werden in den Protokollen sowohl die Identität des Agents als auch die des Nutzers angezeigt.

Beschränkungen

  • Alte Cloud Storage-Bucket-Rollen:Sie können Agent-Identitäten keine alten Bucket-Rollen zuweisen, z. B. storage.legacyBucketReader.

Nächste Schritte