Identität von KI-Agenten – Übersicht

Die KI-Agentenidentität bietet eine stark bestätigte kryptografische Identität für jeden Agenten, 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. Für die Identität von Agenten werden die eigenen Anmeldedaten des Agents und der Authentifizierungsmanager für die Identität von 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 Kundenservicemitarbeiters gebunden, um den Diebstahl von Tokens zu verhindern.

Wenn die Agent-Identität mit Agent Gateway und Gemini Enterprise verwendet wird, werden Endnutzeranmeldedaten, z. B. solche, die von Gemini Enterprise-Connectors bereitgestellt werden, 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:

Gemini Enterprise Agent Platform Runtime (Agent Runtime)
Gemini Enterprise (Vorschau)

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 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 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 3-beinigen OAuth-Authentifizierungsanbieter im Authentifizierungsmanager für die Agent-Identität, 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 (Agent-Identitä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 Anbieter für die zweibeinige OAuth-Authentifizierung im Authentifizierungsmanager für Agent-Identitäten, 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 ein eindeutiger Identitätsstring oder eine SPIFFE-ID basierend auf dem SPIFFE-Standard zugewiesen. Diese Identität wird stark bestätigt, ist an den Lebenszyklus des Agenten gebunden und wird direkt dem Ressourcen-URI zugeordnet, auf dem der Agent gehostet wird.

Die Identität hat dieses 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:

Agent Platform 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 der Prinzipal ist, gewähren 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 Agents. 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 Anmeldedatenspeicher, der zum Schutz von Anmeldedaten entwickelt wurde. Damit können sich Kundenservicemitarbeiter mit einem API-Schlüssel oder einer OAuth-Client-ID und einem ‑Schlüssel 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 Agent-Identität unterliegt IAM, und der Agent verwendet seine eigene Agent-SPIFFE-ID, um sich beim Authentifizierungsmanager zu authentifizieren. Alle Zugriffsereignisse für Endnutzer werden auch der SPIFFE-ID des Agents zugeordnet, was die Verwaltung erleichtert.

Der Agent Identity-Authentifizierungsmanager automatisiert den Abruf 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.

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 erweiterte Sicherheitsfunktionen und Governance sorgt. Die Funktion ist auch in Audit-Logs integriert, um die Verantwortlichkeit zu gewährleisten und klare Audit-Logs bereitzustellen, sowohl wenn der Agent selbstständig 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 erzwingt die Richtlinie den Demonstrable Proof of Possession (DPoP), 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 erhöhen soll:

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 automatisch aktualisiert, um die Sicherheit zu gewährleisten. Google Cloud
Anmeldedaten abrufen: Die Methode, mit der Agents 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 Agenten gebunden, um einen Tokendiebstahl zu verhindern. Weitere Informationen finden Sie unter Sicherheit und Governance.
- Auf externe Tools zugreifen: Der Agent verwendet den Authentifizierungsmanager für die Agentenidentität, 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 KI-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 Richtlinien für kontextsensitiven Zugriff 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, vom Auth-Manager verschlüsselt und am Gateway entschlüsselt. So wird sichergestellt, dass der Agent niemals auf die Rohdaten der Anmeldedaten 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.