Identität von KI-Agenten – Übersicht

Die Agent-Identitä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, entweder in seinem eigenen Namen oder im Namen eines Endnutzers. Die Agent-Identität verwendet die eigenen Anmeldedaten des Agenten und den Agent Identity-Authentifizierungsmanager. 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-Clientgeheimnissen 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, vom Auth-Manager verschlüsselt und am Gateway entschlüsselt. So wird sichergestellt, dass der Agent niemals auf die Rohdaten der Anmeldedaten 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 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, konfigurieren Sie einen 3-legged-OAuth-Authentifizierungsanbieter im Auth Manager für die Agent-Identität, um die Einwilligung und die Tokens der Nutzer zu verwalten. Weitere Informationen finden Sie unter Mit 3-legged-OAuth über den 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 zur Authentifizierung einen kryptografischen Schlüssel oder ein Passwort erfordern. Sie konfigurieren einen API-Schlüssel-Authentifizierungsanbieter im Authentifizierungsmanager für Agent-Identitäten, 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 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 Agents 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

Mit den Anmeldedaten des Agenten wird die Identität des Agenten kryptografisch nachgewiesen. Das System unterstützt X.509-Zertifikate und Google Cloud Zugriffstokens. Ein X.509-Zertifikat wird automatisch auf dem Agenten 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 Anmeldedaten-Tresor, 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 Identität von Agenten unterliegt IAM. Der Agent verwendet seine eigene SPIFFE-ID, um sich beim Authentifizierungsmanager zu authentifizieren. Alle Endnutzer-Zugriffsereignisse werden auch der SPIFFE-ID des Agenten 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.

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 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, die Anmeldedaten der Agentenidentität zu schützen. Über das Agent Gateway hinaus erzwingt die Richtlinie den nachweisbaren Besitz (Demonstrable Proof of Possession, DPoP), indem das Zugriffstoken des Agenten authentifiziert wird. Außerdem wird durch die Richtlinie erzwungen, dass für den Zugriff auf das Agent Gateway mTLS verwendet wird. So wird sichergestellt, dass zertifikatgebundene 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:

  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 Google Cloudhält es automatisch auf dem neuesten Stand, 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 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 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 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.
  • Sicherheit von Anmeldedaten: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 Endnutzeranmeldedaten, z. B. solche, die von Gemini Enterprise-Connectors bereitgestellt werden, vom Auth Manager verschlüsselt und am Gateway entschlüsselt. So kann der Agent niemals auf die Rohanmeldedaten zugreifen.
  • 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.
  • Verbesserte Beobachtbarkeit:Es werden klare Audit-Logs bereitgestellt. Wenn ein Agent im Namen eines Nutzers handelt, werden sowohl die Identität des Agenten als auch die des Nutzers in den Logs 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