Identität von KI-Agenten – Übersicht

Agent Identity bietet eine stark bestätigte, kryptografische Identität für jeden KI-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. Bei Agent Identity 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.

Agent Identity arbeitet mit Agent Registry und Agent Gateway zusammen, um KI-Agenten zu schützen und zu verwalten. Agent Identity stellt kryptografische Identitäten bereit und verwaltet Anmeldedaten, Agent Registry katalogisiert die Tools und Ziele in Ihrer Umgebung und Agent Gateway setzt Zugriffsrichtlinien durch und prüft den Netzwerkverkehr, wenn Agents diese Ziele aufrufen.

Wenn die Agentenidentität mit dem Agent Gateway und Gemini Enterprise verwendet wird, werden Endnutzeranmeldedaten, z. B. solche, die von Gemini Enterprise-Connectors bereitgestellt werden, vom Authentifizierungsmanager 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) 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 KI-Agenten, um die Nutzereinwilligung und Tokens zu verwalten. Weitere Informationen finden Sie unter Mit dreibeinigem OAuth und dem Auth-Manager authentifizieren.
Eigene Autorität des KI-Agenten 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 (zweibeinig) Externe Tools und Dienste Empfohlen für die Maschine-zu-Maschine-Authentifizierung 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 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 KI-Agenten wird basierend auf dem SPIFFE-Standard ein eindeutiger Identitätsstring oder eine SPIFFE-ID 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 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 (Organisation): principal://agents.global.org-123456789012.system.id.goog/resources/aiplatform/projects/9876543210/locations/us-central1/reasoningEngines/my-test-agent
  • Vertex AI Agent Engine (Projekt ohne Organisation): principal://agents.global.proj-9876543210.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 für Ihre Ressourcenhierarchie:
    • Für Projekte in einer Organisation: agents.global.org-ORGANIZATION_ID.system.id.goog
    • Für Projekte ohne Organisation: agents.global.proj-PROJECT_NUMBER.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.

Lebenszyklus von Identitäten und Berechtigungen

Sie müssen die IAM-Bindungen für Ihre Agentenidentitäten verwalten. Wenn Sie einen Agent löschen, werden die IAM-Bindungen, die auf sein Hauptkonto verweisen, nicht entfernt. Diese Bindungen bleiben in Ihren Richtlinien als inaktive Zuweisungen erhalten und müssen manuell entfernt werden, wenn Sie einen Agent außer Betrieb nehmen.

Die Identität eines Agents wird aus der ID der Ressource abgeleitet, auf der er gehostet wird, z. B. der reasoningEngines-Ressourcen-ID. Wenn Sie einen Agent löschen und einen Ersatz bereitstellen, auch wenn er denselben Anzeigenamen, Code und dieselbe Konfiguration hat, erhält der neue Agent eine neue Ressourcen-ID und damit eine neue Hauptkonto-ID. Vorhandene IAM-Bindungen, die auf die vorherige Identität verwiesen haben, gelten nicht für das neue Hauptkonto. Sie müssen dem neuen Hauptkonto die erforderlichen Rollen zuweisen.

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.

Standardmäßig verwenden Agent-Identitäten gegenseitiges TLS (mTLS) mit X.509-Zertifikaten, wenn sie direkt mit Google Cloud APIs kommunizieren. Wenn Agents über das Agent Gateway interagieren, verwenden sie auch Demonstrating Proof of Possession (DPoP), wodurch doppelt gebundene Anmeldedaten für die Ende-zu-Ende-Sicherheit erstellt werden. Diese doppelte Bindung bedeutet, dass sich Agents für den Erstanbieterzugriff auf das Gateway mit mTLS authentifizieren und für Interaktionen über das Gateway hinaus DPoP verwenden.

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 und 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 Auth Manager 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.

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 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, Agent-Anmeldedaten zu schützen, indem mTLS und die Bindung von DPoP-Tokens erzwungen werden. So wird sichergestellt, dass an Zertifikate gebundene Tokens nicht außerhalb ihrer vertrauenswürdigen Laufzeitumgebung wiedergegeben 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 Perimeterschutz und Prinzipalnutzung:
    • Perimeterschutz:Sie können die Agent Identity API (agentidentity.googleapis.com) und die Agent Identity Credentials API (agentidentitycredentials.googleapis.com) einem Dienstperimeter hinzufügen, um den Zugriff auf diese APIs zu steuern. Wenn Sie diese APIs innerhalb eines Dienstperimeters verwenden möchten, müssen Clients Anfragen über die eingeschränkte VIP (restricted.googleapis.com) weiterleiten.
    • Regeln für ein- und ausgehenden Traffic:Unterstützung für die Verwendung von Agent-Identitäten als Hauptkonten 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 Identität des Agenten authentifiziert und autorisiert Agentenaktionen ü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 Google Cloud wird automatisch 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 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 kontextsensitiver Zugriff-Richtlinien machen gebundene Tokens nicht wiederholbar und schützen so vor Token-Diebstahl und Kontoübernahme. Wenn die Agentenidentität mit dem 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 Rohdaten der Anmeldedaten zugreifen kann.
  • Ansatz mit geringsten Berechtigungen:Es werden Identitäten pro Agent anstelle von freigegebenen 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