Architettura di delega dell'identità

Per applicare i limiti di attendibilità tra utenti umani, workload autonomi e strumenti esterni senza fare affidamento sulla simulazione dell'identità dei account di servizio, Agent Identity utilizza un framework di delega a tre identità. Questo framework separa e coordina tre contesti di identità distinti nel tuo ambiente:

  • Identità utente: l'identità dell'utente finale che avvia la richiesta, autenticata tramite OAuth 2.0 o OpenID Connect (OIDC) standard con Google Identity o un provider di identità (IdP) della forza lavoro federato.
  • Identità dell'agente: l'identità SPIFFE univoca e attestata crittograficamente dell'agente di cui è stato eseguito il deployment e il certificato X.509 con provisioning automatico, che rappresenta l'agente che agisce in base alla propria autorità.
  • Identità delegata: il contesto di autorità combinato quando l'agente agisce per conto dell'utente umano che ha avviato l'azione utilizzando credenziali OAuth 3-legged (3LO) con ambito gestite dal gestore di autenticazione di Agent Identity.

Il seguente diagramma illustra l'interazione tra l'identità utente, l'identità dell'agente e l'identità delegata attraverso i confini di attendibilità in entrata, di runtime e in uscita:

Diagramma dell'architettura di delega dell'identità che mappa l'identità utente, l'identità dell'agente e l'identità delegata attraverso i confini di attendibilità in entrata, runtime e in uscita.

In questa architettura, l'identità utente stabilisce il contesto del chiamante durante l'ingresso, l'identità dell'agente autentica il workload all'interno del confine di runtime e l'identità delegata combina entrambe le autorità quando l'agente accede ai servizi downstream per conto dell'utente.

Come si propagano le identità attraverso i confini di attendibilità

Man mano che una richiesta si sposta attraverso questi confini di attendibilità, la piattaforma valuta e propaga ogni livello di identità:

  1. Confine di ingresso da client ad agente (identità utente): l'utente umano si autentica nell'applicazione client utilizzando un token OAuth 2.0 o OIDC. Quando il traffico entra tramite Agent Gateway (in modalità di ingresso CLIENT_TO_AGENT), le policy di autorizzazione associate ad Agent Gateway verificano l'identità dell'utente per confermare che l'utente è autorizzato a richiamare l'agente di destinazione e inoltrare il contesto utente verificato al runtime.
  2. Agent Runtime e brokering delle credenziali (Agent Identity): all'interno dell'ambiente di runtime isolato, l'agente opera con la propria Agent Identity SPIFFE con un certificato X.509 di 24 ore con rotazione automatica. Quando l'agente ha bisogno di credenziali per gli strumenti downstream, si autentica nel gestore di autenticazione di Agent Identity utilizzando la propria identità di agente.
  3. Percorso di uscita autonomo (identità dell'agente): quando l'agente chiama le API Google Cloud o gli endpoint machine-to-machine con la propria autorità, si autentica utilizzando token associati a certificati applicati da mutual TLS (mTLS) e Demonstrating Proof of Possession (DPoP), token ID OIDC o credenziali OAuth a due vie (2LO) dal gestore di autenticazione. Le policy di autorizzazione e negazione IAM, le policy sul confine di accesso dell'entità (PAB) e le policy di accesso sensibile al contesto valutano la richiesta rigorosamente in base all'identità dell'agente.
  4. Percorso in uscita delegato dall'utente (identità delegata): quando l'agente chiama server Model Context Protocol (MCP) con ambito utente o API di terze parti per conto dell'utente umano, il gestore dell'autenticazione intermedia un token utente 3LO con consenso che rappresenta l'identità delegata. Le chiamate in uscita sono regolate sia dalle policy in uscita dell'agente sia dalle autorizzazioni e dagli ambiti OAuth approvati dell'utente delegante. Gli audit log registrano sia l'identità dell'agente sia quella dell'utente.

Confronto dei livelli di identità

La tabella seguente riassume il modo in cui i tre livelli di identità regolano l'accesso e l'auditability:

Livello di identità Tipo di entità e credenziale Confine di attendibilità e applicazione delle policy Attribuzione degli audit log
Identità utente Utente finale che avvia l'operazione (Account Google o entità di Workforce Identity) autenticato con un token OAuth 2.0 o OIDC. Da client ad agente (traffico in entrata): le policy di autorizzazione di Agent Gateway verificano se l'utente può richiamare l'agente e avviare una sessione. Registra l'identità dell'utente umano come chiamante che richiama l'endpoint dell'agente.
Agent Identity Workload dell'agente autonomo (entità dell'identità dell'agente) autenticato con un certificato SPIFFE X.509 (mTLS e DPoP), un token ID OIDC o una credenziale 2LO o una chiave API dal gestore dell'autenticazione. Da agente a ovunque (traffico in uscita): le policy di autorizzazione, negazione, confine di accesso dell'entità e accesso sensibile al contesto di IAM applicano le Google Cloud risorse, i provider di autenticazione e gli endpoint esterni che l'agente può raggiungere con la propria autorità. Registra l'entità SPIFFE univoca dell'agente come identità attiva.
Identità delegata Identità dell'agente che agisce per conto dell'utente umano consenziente (Account Google o entità Workforce Identity) utilizzando un token di accesso 3LO con ambito gestito dal gestore di autenticazione di Agent Identity. Da agente a qualsiasi destinazione (traffico in uscita): applica l'intersezione del privilegio minimo. La chiamata deve soddisfare sia le policy di governance in uscita dell'agente sia le autorizzazioni e gli ambiti OAuth approvati dell'utente delegante. Registra la doppia attribuzione, acquisendo sia l'identità SPIFFE dell'agente sia l'utente umano delegante.

Passaggi successivi