Identität von KI-Agenten – Übersicht

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

Im Gegensatz zu Dienstkonten werden Agentenidentitä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. Für Google Cloud generierte Zugriffstokens werden kryptografisch an die eindeutigen X.509-Zertifikate des Agenten gebunden, um den Token-Diebstahl zu verhindern.

Wenn Agent Identity mit Agent Gateway und Gemini Enterprise verwendet wird, werden die Anmeldedaten des Endnutzers, z. B. die von Gemini Enterprise-Connectors bereitgestellten, vom Authentifizierungsmanager verschlüsselt und am Gateway entschlüsselt. So wird sichergestellt, dass der Agent niemals auf die unverschlüsselten Anmeldedaten zugreifen kann.

Die folgenden Dienste unterstützen Agent Identity:

Authentifizierungsmodelle

Zur Authentifizierung mit verschiedenen Tools und Diensten unterstützt Agent Identity mehrere Authentifizierungsmodelle. Das von einem Agenten verwendete Modell hängt von der von der Zielressource angebotenen Authentifizierungsmethode und davon ab, ob der Agent in eigener Verantwortung oder im Namen eines Endnutzers handelt.

Entscheidungsbefugnis Authentifizierungsmethode Zielressource Anwendungsfall und Lösung
Vom Nutzer delegierte Entscheidungsbefugnis OAuth 2.0 (3-legged) (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 3-legged-OAuth-Authentifizierungsanbieter im Authentifizierungsmanager für die Identität von Agenten , um die Nutzereinwilligung und Tokens zu verwalten. Weitere Informationen finden Sie unter Mit 3-legged-OAuth und Authentifizierungsmanager authentifizieren.
Eigene Entscheidungsbefugnis des Agenten Cloudbasierte Identität (Agent Identity) Google Cloud -Dienste Wenn ein Agent, der auf Google Cloud gehostet wird, mit seiner eigenen Identität auf andere Google Cloud Dienste zugreifen muss. Weitere Informationen finden Sie unter Mit der eigenen Identität eines Agenten authentifizieren.
OAuth 2.0 (2-legged) (Vorschau) Externe Tools und Dienste Empfohlen für die Machine-to-Machine-Authentifizierung mit externen Diensten, die OAuth unterstützen. Sie konfigurieren einen 2-legged-OAuth Authentifizierungsanbieter im Authentifizierungsmanager für die Identität von Agenten, um Clientanmeldedaten und Zugriffstokens zu verarbeiten. Weitere Informationen finden Sie unter Mit 2-legged-OAuth und Authentifizierungsmanager 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 Authentifizierungsanbieter für API-Schlüssel im Authentifizierungsmanager für die Identität von Agenten, um die Schlüssel sicher zu speichern und zu verwalten. Weitere Informationen finden Sie unter Mit API-Schlüssel und Authentifizierungsmanager 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 Authentifizierungsmanager authentifizieren.

Kernkomponenten

Agent Identity umfasst mehrere Schlüsselkomponenten, die zusammen für eine sichere Authentifizierung und Autorisierung sorgen.

SPIFFE-basierte Identität

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

Die Identität hat folgendes 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 Agentenidentität in einer IAM-Zulassungsrichtlinie verwendet wird, hat die Hauptkonto-ID folgendes Format:

principal://TRUST_DOMAIN/resources/SERVICE/RESOURCE_PATH

Beispiele:

  • Agent Runtime: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 IDs verwenden Folgendes:

  • TRUST_DOMAIN: Die Vertrauensdomain 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, auf der der Agent gehostet wird.

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

Anmeldedaten des KI-Agenten

Anmeldedaten des Agenten 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 bereitgestellt und auf dem Agenten verwaltet, um eine stärkere Authentifizierung zu unterstützen.

Standardmäßig verwenden Agentenidentitäten gegenseitiges TLS (mTLS) mit X.509-Zertifikaten, wenn sie direkt mit Google Cloud APIs kommunizieren. Wenn Agenten über das Agent Gateway interagieren, verwenden sie auch Demonstrating Proof of Possession (DPoP) und erstellen so doppelt gebundene Anmeldedaten für die End-to-End-Sicherheit. Diese doppelte Bindung bedeutet, dass sich Agenten mit mTLS für den Erstanbieterzugriff auf das Gateway authentifizieren und DPoP für Interaktionen außerhalb des Gateways verwenden.

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

Der Authentifizierungsmanager für die Identität von Agenten ist ein zentraler Tresor für Anmeldedaten und ein Authentifizierungsbroker, der die Authentifizierung ausgehender Tools für Ihre Agenten vereinfacht. So können sich Agenten mit einem API-Schlüssel oder einer OAuth-Client-ID und einem OAuth-Client-Secret authentifizieren oder im Namen eines Nutzers über die OAuth-Delegierung mit Zugriffstokens für Endnutzer. Im Authentifizierungsmanager konfigurieren Sie Authentifizierungsanbieter, die den Authentifizierungstyp und die Anmeldedaten für bestimmte Drittanbieteranwendungen definieren.

Der Zugriff auf den Authentifizierungsmanager für die Identität von Agenten wird von IAM gesteuert und der Agent authentifiziert sich mit seiner eigenen Agenten-SPIFFE-ID beim Authentifizierungsmanager. Alle Zugriffsereignisse von Endnutzern können auch der SPIFFE-ID des Agenten zugeordnet werden, was die Governance vereinfacht.

Der Authentifizierungsmanager für die Identität von Agenten automatisiert den Abruf von OAuth-Anmeldedaten, z. B. das Öffnen eines Dialogfelds für die Nutzeranmeldung und -einwilligung. Außerdem bietet er Einblick in den Zugriff von Endnutzern und ermöglicht den Widerruf des Zugriffs, was die Governance für vom Nutzer delegierte Berechtigungen verbessert.

Weitere Informationen finden Sie in der Übersicht zum Authentifizierungsmanager für die Identität von Agenten.

Sicherheit und Governance

Agent Identity 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. Außerdem ist es in die Audit-Protokollierung integriert, um die Verantwortlichkeit zu gewährleisten und klare Audit-Logs bereitzustellen, sowohl wenn der Agent selbst handelt als auch wenn er im Namen eines Endnutzers handelt.

  • Kontextsensitiver Zugriff: Standardmäßig trägt eine von Google verwaltete Richtlinie für den kontextsensitiven Zugriff dazu bei, die Anmeldedaten des Agenten zu schützen, indem sie die mTLS- und DPoP-Token- Bindung erzwingt. So wird sichergestellt, dass an Zertifikate gebundene Tokens nicht außerhalb ihrer vertrauenswürdigen Laufzeitumgebung wiedergegeben werden können.
  • IAM-Integration:Unterstützung für standardmäßige IAM-Zulassungs- und -Ablehnungsrichtlinien.
  • Principal Access Boundary (PAB) : Eine PAB beschränkt die Ressourcen, auf die ein Agent zugreifen kann, unabhängig von anderen Berechtigungen.
  • VPC Service Controls: Unterstützung für die Verwendung von Agentenidentitäten (Vorschau) in Regeln für ein- und ausgehenden Traffic, um den Zugriff auf Ressourcen zu ermöglichen, die durch einen Dienstperimeter geschützt sind.

Funktionsweise von Agent Identity

Agent Identity authentifiziert und autorisiert Agentenaktionen über einen Workflow, der die Sicherheit verbessern soll:

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

Vorteile von Agent Identity

Agent Identity verbessert die Sicherheit im Vergleich zu Standarddienstkonten.

  • Starke Isolation:Im Gegensatz zu Dienstkonten werden Agentenidentitä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.
  • Sicherheit von Anmeldedaten:Standardmäßige Richtlinien für den kontextsensitiven Zugriff machen gebundene Tokens nicht wiederholbar und schützen so vor Token-Diebstahl und Kontoübernahme. Wenn Agent Identity mit Agent Gateway und Gemini Enterprise verwendet wird, werden die Anmeldedaten des Endnutzers, z. B. die von Gemini Enterprise-Connectors bereitgestellten, vom Authentifizierungsmanager verschlüsselt und am Gateway entschlüsselt. So wird sichergestellt, dass der Agent niemals auf die unverschlüsselten Anmeldedaten zugreifen kann.
  • Ansatz der geringsten Berechtigung:Bietet Identitäten pro Agent statt gemeinsam genutzter Dienstkonten, um Agenten mit zu vielen Berechtigungen zu vermeiden.
  • Weniger Aufwand:Automatisiert komplexe OAuth-Abläufe und verwaltet API-Schlüssel für eine einfachere Tool-Integration.
  • Verbesserte Beobachtbarkeit:Bietet klare Audit-Logs. Wenn ein Agent im Namen eines Nutzers handelt, werden in den Logs sowohl die Identität des Agenten als auch die des Nutzers angezeigt.

Beschränkungen

  • Alte Cloud Storage-Bucket-Rollen:Sie können Agentenidentitäten keine alten Bucket-Rollen zuweisen (z. B. storage.legacyBucketReader).

Nächste Schritte