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.

In dieser Architektur stellt die Nutzeridentität den Aufruferkontext während des eingehenden Traffics her, die Agent-Identität authentifiziert die Arbeitslast innerhalb der Laufzeitgrenze und die delegierte Identität kombiniert beide Berechtigungen, wenn der Agent im Namen des Nutzers auf nachgelagerte Dienste zugreift.

Wie Identitäten über Vertrauensgrenzen hinweg weitergegeben werden

Wenn eine Anfrage diese Vertrauensgrenzen überschreitet, wertet die Plattform jede Identitätsebene aus und gibt sie weiter:

  1. Eingehende Grenze zwischen Client und Agent (Nutzeridentität): Der menschliche Nutzer authentifiziert sich bei der Clientanwendung mit einem OAuth 2.0- oder OIDC-Token. Wenn Traffic über das Agent Gateway (im CLIENT_TO_AGENT-Ingress-Modus) eingeht, wird die Nutzeridentität anhand der Autorisierungsrichtlinien, die dem Agent Gateway zugeordnet sind, überprüft. So wird bestätigt, dass der Nutzer berechtigt ist, den Ziel-Agent aufzurufen, und der verifizierte Nutzerkontext wird an die Laufzeit weitergeleitet.
  2. Agent-Laufzeit und Weitergabe von Anmeldedaten (Agent-Identität): Innerhalb der isolierten Laufzeitumgebung agiert der Agent unter seiner eigenen SPIFFE-Agent-Identität mit einem automatisch rotierten 24-Stunden-X.509-Zertifikat. Wenn der Agent Anmeldedaten für nachgelagerte Tools benötigt, authentifiziert er sich mit seiner Agentenidentität beim Agent Identity-Authentifizierungsmanager.
  3. Autonomer ausgehender Pfad (Agentenidentität): Wenn der Agent Google Cloud -APIs oder Machine-to-Machine-Endpunkte in eigener Verantwortung aufruft, authentifiziert er sich mit zertifikatsgebundenen Tokens, die durch gegenseitiges TLS (mTLS) und Demonstrating Proof of Possession (DPoP), OIDC-ID-Tokens oder 2-Legged-OAuth-Anmeldedaten (2LO) vom Auth-Manager erzwungen werden. IAM-Zulassungs- und Ablehnungsrichtlinien, PAB-Richtlinien (Principal Access Boundary) und Richtlinien für kontextsensitiven Zugriff werten die Anfrage strikt anhand der Agent-Identität aus.
  4. Vom Nutzer delegierter Pfad für ausgehenden Traffic (delegierte Identität): Wenn der Agent im Namen des menschlichen Nutzers auf Nutzerebene beschränkte MCP-Server (Model Context Protocol) oder APIs von Drittanbietern aufruft, vermittelt der Auth Manager ein zugestimmtes 3LO-Nutzertoken, das die delegierte Identität darstellt. Ausgehende Aufrufe unterliegen sowohl den Richtlinien für ausgehenden Traffic des KI-Agenten als auch den Berechtigungen und genehmigten OAuth-Bereichen des delegierenden Nutzers. In den Audit-Logs werden sowohl die Identität des KI-Agenten als auch die Identität des Nutzers erfasst.

Vergleich der Identitätsebenen

In der folgenden Tabelle wird zusammengefasst, wie die drei Identitätsebenen den Zugriff und die Prüfbarkeit steuern:

Identitätsebene Hauptkonto- und Anmeldedatentyp Vertrauensgrenze und Richtlinienerzwingung Audit-Log-Attribution
Nutzeridentität Initiierender Endnutzer (Google-Konto oder Workforce Identity-Hauptkonto), der mit einem OAuth 2.0- oder OIDC-Token authentifiziert wurde. Client-zu-Agent (Ingress): Die Autorisierungsrichtlinien des Agent-Gateways prüfen, ob der Nutzer den Agent aufrufen und eine Sitzung starten kann. Protokolliert die Identität des menschlichen Nutzers als Aufrufer, der den Agenten-Endpunkt aufruft.
Identität von KI-Agenten Arbeitslast des autonomen Agenten (Agentenidentitäts-Hauptkonto), authentifiziert mit einem SPIFFE-X.509-Zertifikat (mTLS und DPoP), OIDC-ID-Token oder 2LO-Anmeldedaten oder API-Schlüssel vom Auth-Manager. Agent-to-Anywhere (ausgehend): IAM-Zulassungs-, Ablehnungs-, Principal Access Boundary- und kontextsensitive Zugriffsrichtlinien erzwingen, welche Google Cloud -Ressourcen, Authentifizierungsanbieter und externen Endpunkte der Agent selbstständig erreichen kann. Protokolliert den eindeutigen SPIFFE-Hauptkontonamen des KI-Agenten als handelnde Identität.
Delegierte Identität Agent-Identität, die im Namen des zustimmenden menschlichen Nutzers (Google-Konto oder Workforce Identity-Hauptkonto) mit einem eingeschränkten 3LO-Zugriffstoken agiert, das vom Agent Identity-Authentifizierungsmanager vermittelt wird. Agent-to-Anywhere (ausgehend): Erzwingt die Schnittmenge der geringsten Berechtigungen. Der Aufruf muss sowohl die ausgehenden Governance-Richtlinien des KI-Agenten als auch die Berechtigungen und die zugestimmten OAuth-Bereiche des delegierenden Nutzers erfüllen. Zeichnet die duale Attribution auf und erfasst sowohl die SPIFFE-Identität des KI-Agenten als auch den delegierenden menschlichen Nutzer.

Nächste Schritte