Panoramica di Agent Identity

Agent Identity fornisce un'identità crittografica fortemente attestata per ogni agente, basata sullo standard SPIFFE. Con l'identità dell'agente, l'agente può autenticarsi in modo sicuro su server MCP, risorse cloud, endpoint e altri agenti, agendo per proprio conto o per conto di un utente finale. Agent Identity utilizza la credenziale dell'agente e il gestore di autenticazione di Agent Identity. Puoi utilizzare il gestore di autenticazione per creare e gestire i provider di autenticazione, ovvero le configurazioni specifiche utilizzate per acquisire, gestire e proteggere le chiavi API, gli ID client OAuth, i client secret OAuth e i token OAuth degli utenti finali delegati.

A differenza dei service account, le identità degli agenti non sono condivise da più workload per impostazione predefinita, non possono essere impersonate e non consentono agli sviluppatori di generare chiavi dei account di servizio di lunga durata. I token di accesso generati per Google Cloud sono associati in modo crittografico ai certificati X.509 univoci dell'agente per impedire il furto di token.

Agent Identity funziona con Agent Registry e Agent Gateway per contribuire a proteggere e gestire gli agenti AI. Agent Identity esegue il provisioning delle identità crittografiche e gestisce le credenziali, Agent Registry cataloga gli strumenti e le destinazioni nel tuo ambiente e Agent Gateway applica le policy di accesso e ispeziona il traffico di rete quando gli agenti chiamano queste destinazioni.

I seguenti servizi supportano l'identità dell'agente:

Modelli di autenticazione

Per l'autenticazione con vari strumenti e servizi, l'identità dell'agente supporta diversi modelli di autenticazione. Il modello utilizzato da un agente dipende dal metodo di autenticazione offerto dalla risorsa di destinazione e dal fatto che l'agente agisca per conto proprio o per conto di un utente finale.

Autorità Metodo di autenticazione Risorsa target Caso d'uso e soluzione
Autorità delegata dall'utente OAuth 2.0 (a tre vie) Strumenti e servizi esterni Quando un agente agisce per conto di un utente specifico (ad esempio, per accedere alle attività Jira o ai repository GitHub di un utente). Configuri un provider di autenticazione OAuth a tre vie nel gestore di autenticazione di Agent Identity per gestire il consenso dell'utente e i token. Per saperne di più, consulta Autenticati utilizzando OAuth a tre vie con Auth Manager.
Autorità dell'agente Identità basata su cloud (Agent Identity) ServiziGoogle Cloud Quando un agente ospitato su Google Cloud deve accedere ad altri servizi Google Cloud utilizzando la propria identità. Per saperne di più, consulta Autenticati in Google Cloud utilizzando l'identità di un agente.
Identità basata su cloud (token ID OIDC) Strumenti e servizi esterni Quando un agente ospitato su Google Cloud deve autenticarsi su backend esterni, API personalizzate o piattaforme cloud di terze parti utilizzando la propria identità e la federazione delle identità OpenID Connect (OIDC). Per saperne di più, consulta Esegui l'autenticazione ai servizi esterni utilizzando l'identità di un agente.
OAuth 2.0 (a due vie) Strumenti e servizi esterni Consigliato per l'autenticazione da macchina a macchina con servizi esterni che supportano OAuth. Configura un provider di autenticazione OAuth a due fattori nel gestore di autenticazione di Agent Identity per gestire le credenziali client e i token di accesso. Per saperne di più, consulta Autenticati utilizzando OAuth 2-legged con il gestore di autenticazione.
Chiave API Strumenti e servizi esterni Per i servizi esterni che richiedono una chiave di crittografia o una password per l'autenticazione. Configura un provider di autenticazione con chiave API nel gestore di autenticazione di Agent Identity per archiviare e gestire le chiavi in modo sicuro. Per saperne di più, consulta Autenticati utilizzando la chiave API con Auth Manager.
Autorizzazione di base HTTP Strumenti e servizi esterni Utilizza password in testo non crittografato. Questo metodo non è consigliato. Puoi archiviare le password in modo simile a una chiave API. Per saperne di più, consulta Autenticati utilizzando la chiave API con Auth Manager.

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 l'operazione, autenticata tramite OAuth 2.0 standard o OpenID Connect (OIDC) 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à di ingresso, runtime e uscita.

Per saperne di più su come la piattaforma valuta e propaga ogni livello di identità attraverso i confini di attendibilità, consulta Architettura di delega dell'identità.

Componenti principali

L'identità dell'agente prevede diversi componenti chiave che, insieme, contribuiscono a fornire autenticazione e autorizzazione sicure.

Identità basata su SPIFFE

A ogni agente viene assegnata una stringa di identità univoca, o ID SPIFFE, in base allo standard SPIFFE. Questa identità è fortemente attestata, legata al ciclo di vita dell'agente e mappata direttamente all'URI della risorsa in cui è ospitato l'agente.

L'identità segue questo formato:

spiffe://TRUST_DOMAIN/resources/SERVICE/RESOURCE_PATH

Ad esempio:

  • spiffe://agents.global.org-123456789012.system.id.goog/resources/aiplatform/projects/9876543210/locations/us-central1/reasoningEngines/my-test-agent

Quando un'identità dell'agente viene utilizzata in una policy di autorizzazione IAM, l'identificatore dell'entità segue questo formato:

principal://TRUST_DOMAIN/resources/SERVICE/RESOURCE_PATH

Esempi:

  • Vertex AI Agent Engine (organizzazione): principal://agents.global.org-123456789012.system.id.goog/resources/aiplatform/projects/9876543210/locations/us-central1/reasoningEngines/my-test-agent
  • Vertex AI Agent Engine (progetto senza organizzazione): 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

Gli identificatori utilizzano quanto segue:

  • TRUST_DOMAIN: il dominio di attendibilità della gerarchia delle risorse:
    • Per i progetti di un'organizzazione: agents.global.org-ORGANIZATION_ID.system.id.goog
    • Per i progetti senza un'organizzazione: agents.global.proj-PROJECT_NUMBER.system.id.goog
  • SERVICE: il nome breve del servizio Google Cloud (ad esempio, aiplatform o discoveryengine).
  • RESOURCE_PATH: il percorso completo della risorsa che ospita l'agente.

Poiché l'agente stesso è l'entità, concedi le autorizzazioni direttamente a questo identificatore per controllare a quali risorse può accedere l'agente.

Ciclo di vita di identità e autorizzazioni

Devi gestire le associazioni IAM per le identità degli agenti. L'eliminazione di un agente non rimuove le associazioni IAM che fanno riferimento alla sua entità. Queste associazioni rimangono nelle policy come concessioni inattive e devi rimuoverle manualmente nell'ambito della disattivazione di un agente.

L'identità di un agente deriva dall'ID della risorsa che lo ospita, ad esempio l'ID risorsa reasoningEngines. Se elimini un agente ed esegui il deployment di un sostituto, anche con lo stesso nome visualizzato, codice e configurazione, il nuovo agente riceve un nuovo ID risorsa e, di conseguenza, un nuovo identificatore di entità. Le associazioni IAM esistenti che facevano riferimento all'identità precedente non si applicano alla nuova entità. Devi concedere i ruoli richiesti alla nuova entità.

Credenziali dell'agente

Le credenziali dell'agente forniscono una prova crittografica dell'identità di un agente. Il sistema supporta i certificati X.509, i token di accesso Google Cloud e i token ID OIDC. Un certificato X.509 viene sottoposto a provisioning automatico e gestito sull'agente per supportare un'autenticazione più efficace.

Questi certificati X.509 sono collegati a un'autorità di certificazione (CA) radice gestita da Google. Puoi visualizzare i certificati CA predefiniti pubblici nei seguenti endpoint:

Per impostazione predefinita, le identità degli agenti utilizzano mutual TLS (mTLS) con certificati X.509 quando comunicano direttamente con le API Google Cloud . Quando gli agenti interagiscono tramite l'Agent Gateway, utilizzano anche la dimostrazione della prova di possesso (DPoP), creando credenziali con doppio vincolo per la sicurezza end-to-end. Questo doppio binding significa che gli agenti eseguono l'autenticazione utilizzando mTLS per l'accesso proprietario al gateway e utilizzano DPoP per le interazioni oltre il gateway.

gestore di autenticazione di Agent Identity

Il gestore di autenticazione di Agent Identity è un archivio di credenziali centralizzato e un broker di autenticazione che semplifica l'autenticazione degli strumenti in uscita per i tuoi agenti. Consente agli agenti di autenticarsi utilizzando una chiave API o un ID client OAuth e un secret oppure per conto di un utente tramite la delega OAuth utilizzando i token di accesso dell'utente finale. All'interno del gestore di autenticazione, configuri i provider di autenticazione che definiscono il tipo di autenticazione e le credenziali per applicazioni di terze parti specifiche.

L'accesso al gestore di autenticazione di Agent Identity è regolato da IAM e l'agente utilizza il proprio ID SPIFFE dell'agente per autenticarsi nel gestore di autenticazione. Tutti gli eventi di accesso degli utenti finali sono inoltre attribuibili allo SPIFFE ID dell'agente, il che consente una governance semplice.

Il gestore di autenticazione di Agent Identity automatizza l'acquisizione delle credenziali OAuth, ad esempio aprendo una finestra di dialogo per l'accesso e il consenso dell'utente. Inoltre, offre visibilità sull'accesso degli utenti finali e consente la revoca dell'accesso, garantendo una migliore governance delle autorizzazioni delegate dagli utenti.

Per saperne di più, consulta la panoramica del gestore di autenticazione di Agent Identity.

Sicurezza e governance

Agent Identity è completamente integrata con i sistemi di policy di Google come IAM, Confine di accesso dell'entità (PAB) e Controlli di servizio VPC, che consentono una maggiore sicurezza e governance. Inoltre, si integra con l'audit logging per garantire la responsabilità e fornire audit log chiari sia quando l'agente agisce per conto proprio sia quando agisce per conto di un utente finale.

  • Accesso sensibile al contesto: per impostazione predefinita, una policy di accesso sensibile al contesto gestita da Google aiuta a proteggere le credenziali dell'agente applicando l'associazione di token mTLS e DPoP. Questo approccio garantisce che i token associati ai certificati non possano essere riprodotti al di fuori del loro ambiente di runtime attendibile.
  • Integrazione di IAM: supporto delle policy di autorizzazione e di negazione IAM standard.
  • Confine di accesso dell'entità (PAB): una policy sul confine di accesso dell'entità limita le risorse a cui un agente può accedere, indipendentemente dalle altre autorizzazioni di cui dispone. Le policy sul confine di accesso dell'entità applicate all'identità dell'agente vengono valutate nell'ambito delle chiamate in uscita (egress). Le identità degli agenti soggette alle policy sul confine di accesso dell'entità sono idonee ad accedere solo alle risorse specificate in queste policy, isolando rigorosamente l'agente nel confine designato.
  • Controlli di servizio VPC: supporto per la protezione del perimetro e l'utilizzo delle entità:
    • Protezione del perimetro: puoi aggiungere l'API Agent Identity (agentidentity.googleapis.com) e l'API Agent Identity Credentials (agentidentitycredentials.googleapis.com) a un perimetro di servizio per controllare l'accesso a queste API. Per utilizzare queste API all'interno di un perimetro di servizio, i client devono instradare le richieste tramite il VIP limitato (restricted.googleapis.com).
    • Regole in entrata e in uscita: supporto per l'utilizzo delle identità degli agenti come entità nelle regole in entrata e in uscita per consentire l'accesso alle risorse protette da un perimetro di servizio.

Come funziona Agent Identity

Agent Identity autentica e autorizza le azioni degli agenti tramite un flusso di lavoro progettato per contribuire a migliorare la sicurezza:

  1. Assegnazione dell'identità: quando esegui il deployment di un agente, Google Cloud gli assegna un'identità SPIFFE univoca e un certificato X.509. Ogni certificato X.509 è valido per 24 ore e Google Cloud lo mantiene aggiornato automaticamente per garantire la sicurezza.
  2. Acquisizione delle credenziali: il metodo utilizzato dagli agenti per acquisire le credenziali dipende da ciò a cui tentano di accedere. Di seguito sono riportati alcuni esempi:
    • Accedi ai servizi Google Cloud : l'agente richiede un token di accesso associato. Questo token è associato in modo crittografico al certificato X.509 univoco dell'agente per contribuire a prevenire il furto di token. Per maggiori informazioni, consulta Sicurezza e governance.
    • Accedi a strumenti esterni: per autenticarsi direttamente in un servizio esterno utilizzando la propria identità, l'agente richiede un token ID OIDC. Per recuperare le credenziali archiviate (come chiavi API o token OAuth) da un provider di autenticazione, l'agente utilizza il gestore di autenticazione di Agent Identity, che supporta sia l'autorità delegata dall'utente sia l'autorità dell'agente.

Vantaggi di Agent Identity

L'identità dell'agente migliora la sicurezza rispetto ai service account standard.

  • Isolamento efficace: a differenza dei service account, le identità degli agenti non sono condivise da più workload per impostazione predefinita, non possono essere utilizzate per la simulazione dell'identità e non consentono agli sviluppatori di generare chiavi dei account di servizio di lunga durata.
  • Sicurezza delle credenziali: le policy di accesso sensibile al contesto predefinite rendono i token associati non riproducibili, contribuendo a proteggere dal furto di token e dal takeover dell'account.
  • Approccio con privilegi minimi: fornisce identità per agente anziché service account condivisi per eliminare gli agenti con autorizzazioni eccessive.
  • Attrito ridotto: automatizza i flussi OAuth complessi e gestisce le chiavi API per un'integrazione più semplice degli strumenti.
  • Migliore osservabilità: fornisce audit log chiari. Quando un agente agisce per conto di un utente, i log mostrano le identità sia dell'agente che dell'utente.

Limitazioni

  • Ruoli dei bucket legacy di Cloud Storage: non puoi concedere alle identità degli agenti i ruoli dei bucket legacy (ad esempio storage.legacyBucketReader).

Passaggi successivi