Identität von KI-Agenten – Übersicht

Agent Identity bietet jedem KI-Agenten eine stark attestierte, kryptografische Identität, die auf dem SPIFFE-Standard basiert. Mit Agent Identity kann sich Ihr KI-Agent sicher bei MCP-Servern, Cloud-Ressourcen, Endpunkten und anderen KI-Agenten authentifizieren und entweder in seinem eigenen Namen oder im Namen eines Endnutzers agieren. Agent Identity verwendet die eigenen Anmeldedaten des KI-Agenten und den Agent Identity-Authentifizierungsmanager. Mit dem Auth Manager 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-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, langlebige Dienstkontoschlüssel zu generieren. Zugriffstokens, die für Google Cloudgeneriert werden, sind kryptografisch an die eindeutigen X.509-Zertifikate des KI-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 erzwingt Zugriffsrichtlinien und prüft den Netzwerkverkehr, wenn KI-Agenten diese Ziele aufrufen.

Die folgenden Dienste unterstützen Agent Identity:

Authentifizierungsmodelle

Für die Authentifizierung bei verschiedenen Tools und Diensten unterstützt die Agentenidentität mehrere Authentifizierungsmodelle. Das von einem Agenten verwendete Modell hängt von der Authentifizierungsmethode ab, die von der Zielressource angeboten wird, und davon, ob der Agent im eigenen Namen oder im Namen eines Endnutzers handelt.

Entscheidungsbefugnis Authentifizierungsmethode Zielressource Anwendungsfall und Lösung
Vom Nutzer delegierte Autorisierung OAuth 2.0 (dreibeinig) Externe Tools und Dienste Wenn ein Agent im Namen eines bestimmten Nutzers agiert (z. B. um auf die Jira-Aufgaben oder GitHub-Repositories eines Nutzers zuzugreifen). Sie konfigurieren einen dreibeinigen OAuth-Authentifizierungsanbieter im Agent Identity-Authentifizierungsmanager, um Nutzereinwilligungen und Tokens zu verwalten. Weitere Informationen finden Sie unter Mit dreibeinigem OAuth mit 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 eigenen Identität eines Agents bei Google Cloud authentifizieren.
Cloudbasierte Identität (OIDC-ID-Tokens) Externe Tools und Dienste Wenn ein auf Google Cloud gehosteter Agent sich bei externen Back-Ends, benutzerdefinierten APIs oder Cloud-Plattformen von Drittanbietern mit seiner eigenen Identität und der OpenID Connect (OIDC)-Identitätsföderation authentifizieren muss. Weitere Informationen finden Sie unter Bei externen Diensten mit der eigenen Identität eines Agents authentifizieren.
OAuth 2.0 (zweibeinig) Externe Tools und Dienste Empfohlen für die Machine-to-Machine-Authentifizierung mit externen Diensten, die OAuth unterstützen. Sie konfigurieren einen zweibeinigen OAuth-Authentifizierungsanbieter im Agent Identity-Authentifizierungsmanager, um Clientanmeldedaten und Zugriffstokens zu verwalten. Weitere Informationen finden Sie unter Mit 2-Legged OAuth mit Auth Manager authentifizieren.
API-Schlüssel Externe Tools und Dienste Für externe Dienste, die einen kryptografischen Schlüssel oder ein Passwort für die 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 einen API-Schlüssel speichern. Weitere Informationen finden Sie unter Mit API-Schlüssel und Auth Manager authentifizieren.

Architektur der Identitätsdelegation

Um Vertrauensgrenzen für menschliche Nutzer, autonome Arbeitslasten und externe Tools durchzusetzen, ohne sich auf die Identitätsübernahme von Dienstkonten zu verlassen, verwendet Agent Identity ein Delegierungsframework mit drei Identitäten. Dieses Framework trennt und koordiniert drei verschiedene Identitätskontexte in Ihrer Umgebung:

  • Nutzeridentität: Die Identität des initiierenden Endnutzers, authentifiziert über Standard-OAuth 2.0 oder OpenID Connect (OIDC) mit Google Identity oder einem föderierten Mitarbeiteridentitätsanbieter (IdP).
  • Agentenidentität: Die eindeutige, kryptografisch attestierte SPIFFE-Identität des bereitgestellten Agenten und das automatisch bereitgestellte X.509-Zertifikat, das den Agenten darstellt, der in eigener Verantwortung handelt.
  • Delegierte Identität: Der kombinierte Berechtigungskontext, wenn der Agent im Namen des initiierenden menschlichen Nutzers mit eingeschränkten 3-Legged-OAuth-Anmeldedaten (3LO) agiert, die vom Agent Identity-Authentifizierungsmanager vermittelt werden.

Das folgende Diagramm veranschaulicht, wie die Nutzeridentität, die Agentenidentität und die delegierte Identität über die Vertrauensgrenzen für eingehenden Traffic, Laufzeit und ausgehenden Traffic hinweg interagieren:

Architekturdiagramm zur Identitätsdelegation, das die Nutzeridentität, die Agentenidentität und die delegierte Identität über die Vertrauensgrenzen für eingehenden Traffic, Laufzeit und ausgehenden Traffic hinweg darstellt.

Weitere Informationen dazu, wie die Plattform die einzelnen Identitätsebenen über Vertrauensgrenzen hinweg auswertet und weitergibt, finden Sie unter Architektur der Identitätsdelegation.

Kernkomponenten

Die Agentenidentität umfasst mehrere wichtige Komponenten, die zusammen eine sichere Authentifizierung und Autorisierung ermöglichen.

SPIFFE-basierte Identität

Jedem KI-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 KI-Agenten gebunden und direkt dem Ressourcen-URI zugeordnet, unter dem der KI-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 Hauptkontokennung 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 Kennungen 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 Agenten hostet.

Da der Agent selbst das Hauptkonto ist, gewähren Sie dieser Kennung direkt Berechtigungen, 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. Durch das Löschen eines KI-Agenten werden die IAM-Bindungen, die auf das Hauptkonto verweisen, nicht entfernt. Diese Bindungen bleiben in Ihren Richtlinien als inaktive Gewährungen erhalten und müssen im Rahmen der Außerbetriebnahme eines Agents manuell entfernt werden.

Die Identität eines KI-Agenten wird von der ID der Ressource abgeleitet, die ihn hostet, z. B. der Ressourcen-ID reasoningEngines. Wenn Sie einen Agenten löschen und einen Ersatz bereitstellen, auch mit demselben Anzeigenamen, Code und derselben Konfiguration, erhält der neue Agent eine neue Ressourcen-ID und somit 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

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

Diese X.509-Zertifikate sind mit einer von Google verwalteten Root-Zertifizierungsstelle (CA) verknüpft. Sie können die öffentlichen Standard-CA-Zertifikate unter den folgenden Endpunkten aufrufen:

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

Agent Identity-Authentifizierungsmanager

Der Agent Identity-Authentifizierungsmanager ist ein zentraler Anmeldedatenspeicher und Authentifizierungsbroker, der die Authentifizierung von ausgehenden Tools für Ihre KI-Agenten vereinfacht. Damit können sich Agenten mit einem API-Schlüssel oder einer OAuth-Client-ID und einem Secret authentifizieren oder im Namen eines Nutzers über die OAuth-Delegierung mit Endnutzer-Zugriffstokens. Im Auth Manager konfigurieren Sie Authentifizierungsanbieter, die den Authentifizierungstyp und die Anmeldedaten für bestimmte Drittanbieteranwendungen definieren.

Der Zugriff auf den Agent Identity-Authentifizierungsmanager unterliegt IAM. Der Agent verwendet seine eigene Agent SPIFFE ID, um sich beim Authentifizierungsmanager zu authentifizieren. Alle Zugriffsereignisse von Endnutzern können auch der SPIFFE-ID des Agents zugeordnet werden, was eine einfache Governance ermöglicht.

Der Agent Identity-Authentifizierungsmanager automatisiert die Erfassung von OAuth-Anmeldedaten, z. B. durch das Öffnen eines Dialogfelds für die Nutzeranmeldung und -einwilligung. Außerdem bietet es Einblick in den Zugriff von Endnutzern und ermöglicht den Widerruf des Zugriffs, was eine bessere Kontrolle über die von Nutzern delegierten Berechtigungen ermöglicht.

Weitere Informationen finden Sie in der Übersicht über den Agent Identity-Authentifizierungsmanager.

Sicherheit und Governance

Agent Identity ist vollständig in die Richtliniensysteme von Google wie IAM, Principal Access Boundary (PAB) und VPC Service Controls eingebunden, was für mehr Sicherheit und Governance sorgt. Außerdem ist es in Audit-Logging eingebunden, um die Verantwortlichkeit zu gewährleisten und klare Audit-Logs bereitzustellen, sowohl wenn der KI-Agent als er selbst 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 DPoP-Tokenbindung erzwungen werden. So wird sichergestellt, dass zertifikatsgebundene 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 Principal Access Boundary-Richtlinie schränkt die Ressourcen ein, auf die ein Agent zugreifen kann, unabhängig von anderen Berechtigungen, die der Agent hat. Principal Access Boundary-Richtlinien, die auf die Agentenidentität angewendet werden, werden im Rahmen von ausgehenden Aufrufen ausgewertet. Agentenidentitäten, die Principal Access Boundary-Richtlinien unterliegen, können nur auf die in diesen Richtlinien angegebenen Ressourcen zugreifen. Der Agent ist also strikt auf seine zugewiesene Grenze beschränkt.
  • VPC Service Controls: Unterstützung für Perimeterschutz und Hauptkontonutzung:
    • 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 von Agent Identity

Die Agentenidentität authentifiziert und autorisiert Agentenaktionen über einen Workflow, der die Sicherheit verbessern soll:

  1. Identitätszuweisung: Wenn Sie einen Agenten 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 Cloudaktualisiert es automatisch, um die Sicherheit aufrechtzuerhalten.
  2. Anmeldedatenerfassung: Die Methode, mit der Agenten Anmeldedaten erfassen, 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: Um sich direkt bei einem externen Dienst mit seiner eigenen Identität zu authentifizieren, fordert der Agent ein OIDC-ID-Token an. Um gespeicherte Anmeldedaten (z. B. API-Schlüssel oder OAuth-Tokens) von einem Authentifizierungsanbieter abzurufen, verwendet der Agent den Agent Identity-Authentifizierungsmanager, der sowohl die vom Nutzer delegierte Autorisierung als auch die eigene Autorisierung des Agenten unterstützt.

Vorteile von Agent Identity

Die Agentenidentitä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 tragen so zum Schutz vor Token-Diebstahl und Kontoübernahme bei.
  • Ansatz der geringsten Berechtigung: Es werden Identitäten pro Agent anstelle von freigegebenen Dienstkonten bereitgestellt, um Agenten mit zu vielen Berechtigungen zu vermeiden.
  • Weniger Reibung: Komplexe OAuth-Abläufe werden automatisiert und API-Schlüssel werden verwaltet, um die Toolintegration zu vereinfachen.
  • Verbesserte Beobachtbarkeit: Es werden klare Audit-Logs bereitgestellt. Wenn ein Agent im Namen eines Nutzers handelt, enthalten die Logs sowohl die Identität des Agenten als auch die des Nutzers.

Beschränkungen

  • Legacy-Bucket-Rollen für Cloud Storage: Sie können Agent-Identitäten keine Legacy-Bucket-Rollen zuweisen (z. B. storage.legacyBucketReader).

Nächste Schritte