Visão geral da identidade do agente

A identidade do agente fornece uma identidade criptográfica e fortemente atestada para cada agente com base no padrão SPIFFE. Com a identidade do agente, ele pode se autenticar com segurança em servidores MCP, recursos da nuvem, endpoints e outros agentes, agindo em nome próprio ou de um usuário final. A Identidade do agente usa a própria credencial do agente e o gerenciador de autenticação da Identidade do agente. Você pode usar o gerenciador de autenticação para criar e gerenciar provedores de autenticação, que são as configurações específicas usadas para adquirir, gerenciar e proteger chaves de API, IDs e segredos de clientes OAuth e tokens OAuth delegados do usuário final.

Ao contrário das contas de serviço, as identidades de agente não são compartilhadas por várias cargas de trabalho por padrão, não podem ser representadas e não permitem que os desenvolvedores gerem chaves de conta de serviço de longa duração. Os tokens de acesso gerados para Cloud de Confiance são vinculados criptograficamente aos certificados X.509 exclusivos do agente para evitar o roubo de tokens.

A Identidade do Agente funciona com o Registro de Agente e o Gateway de Agente para ajudar a proteger e governar agentes de IA. A Identidade do agente provisiona identidades criptográficas e gerencia credenciais, o Agent Registry cataloga as ferramentas e os destinos no seu ambiente, e o Gateway de Agente aplica políticas de acesso e inspeciona o tráfego de rede quando os agentes chamam esses destinos.

Quando a identidade do agente é usada com o gateway de agente e o Gemini Enterprise, as credenciais do usuário final, como as provisionadas pelos conectores do Gemini Enterprise, são criptografadas pelo gerenciador de autenticação e descriptografadas no gateway, garantindo que o agente nunca acesse a credencial bruta.

Os seguintes serviços são compatíveis com a identidade do agente:

Modelos de autenticação

Para autenticar com várias ferramentas e serviços, a identidade do agente é compatível com vários modelos de autenticação. O modelo usado por um agente depende do método de autenticação oferecido pelo recurso de destino e se o agente age por conta própria ou em nome de um usuário final.

Autoridade Método de autenticação Recurso de destino Caso de uso e solução
Autoridade delegada pelo usuário OAuth 2.0 (três etapas) Ferramentas e serviços externos Quando um agente age em nome de um usuário específico (por exemplo, para acessar as tarefas do Jira ou os repositórios do GitHub de um usuário). Configure um provedor de autenticação OAuth de três etapas no gerenciador de autenticação de identidade do agente para gerenciar o consentimento do usuário e os tokens. Para mais informações, consulte Autenticar usando o OAuth de três etapas com o gerenciador de autenticação.
Autoridade do agente Identidade baseada na nuvem (identidade do agente) Serviços doCloud de Confiance Quando um agente hospedado no Cloud de Confiance precisa acessar outros serviços do Cloud de Confiance usando a própria identidade. Para mais informações, consulte Autenticar usando a própria identidade de um agente.
OAuth 2.0 (duas etapas) Ferramentas e serviços externos Recomendado para autenticação de máquina para máquina com serviços externos que aceitam OAuth. Você configura um provedor de autenticação OAuth de duas pernas no gerenciador de autenticação de identidade do agente para processar credenciais do cliente e tokens de acesso. Para mais informações, consulte Autenticar usando o OAuth de duas etapas com o gerenciador de autenticação.
Chave de API Ferramentas e serviços externos Para serviços externos que exigem uma chave criptográfica ou senha para autenticação. Você configura um provedor de autenticação de chave de API no gerenciador de autenticação de identidade do agente para armazenar e gerenciar as chaves com segurança. Para mais informações, consulte Autenticar usando chave de API com gerenciador de autenticação.
Autenticação HTTP básica Ferramentas e serviços externos Usa senhas de texto simples. Esse método não é recomendado. É possível armazenar senhas de maneira semelhante à chave de API. Para mais informações, consulte Autenticar usando uma chave de API com o gerenciador de autenticação.

Principais componentes

A identidade do agente envolve vários componentes principais que, juntos, ajudam a fornecer autenticação e autorização seguras.

Identidade baseada em SPIFFE

Cada agente recebe uma string de identidade exclusiva, ou ID do SPIFFE, com base no padrão SPIFFE. Essa identidade é fortemente atestada, vinculada ao ciclo de vida do agente e mapeada diretamente para o URI do recurso em que o agente está hospedado.

A identidade segue este formato:

spiffe://TRUST_DOMAIN/resources/SERVICE/RESOURCE_PATH

Exemplo:

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

Quando uma identidade de agente é usada em uma política de permissão do IAM, o identificador principal segue este formato:

principal://TRUST_DOMAIN/resources/SERVICE/RESOURCE_PATH

Exemplos:

  • Vertex AI Agent Engine (organização): principal://agents.global.org-123456789012.system.id.goog/resources/aiplatform/projects/9876543210/locations/us-central1/reasoningEngines/my-test-agent
  • Vertex AI Agent Engine (projeto sem uma organização): 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

Os identificadores usam o seguinte:

  • TRUST_DOMAIN: o domínio de confiança da sua hierarquia de recursos:
    • Para projetos em uma organização: agents.global.org-ORGANIZATION_ID.system.id.goog
    • Para projetos sem uma organização: agents.global.proj-PROJECT_NUMBER.system.id.goog
  • SERVICE: o nome abreviado do serviço Cloud de Confiance (por exemplo, aiplatform ou discoveryengine).
  • RESOURCE_PATH: o caminho completo para o recurso que hospeda o agente.

Como o próprio agente é o principal, você concede permissões diretamente a esse identificador para controlar quais recursos o agente pode acessar.

Ciclo de vida de identidade e permissão

Você precisa gerenciar as vinculações do IAM para as identidades do agente. A exclusão de um agente não remove as vinculações do IAM que referenciam a entidade principal dele. Essas vinculações permanecem nas suas políticas como concessões inativas, e você precisa removê-las manualmente como parte da desativação de um agente.

A identidade de um agente é derivada do ID do recurso que o hospeda, como o ID do recurso reasoningEngines. Se você excluir um agente e implantar um substituto, mesmo com o mesmo nome de exibição, código e configuração, o novo agente vai receber um novo ID de recurso e, portanto, um novo identificador principal. As vinculações do IAM que faziam referência à identidade anterior não se aplicam ao novo principal. Você precisa conceder os papéis necessários ao novo principal.

Credenciais do agente

As credenciais do agente fornecem prova criptográfica da identidade dele. O sistema aceita certificados X.509 e tokens de acesso Cloud de Confiance . Um certificado X.509 é provisionado e gerenciado automaticamente no agente para oferecer suporte a uma autenticação mais forte.

Por padrão, as identidades do agente usam TLS mútuo (mTLS) com certificados X.509 ao se comunicar diretamente com as APIs do Cloud de Confiance . Quando os agentes interagem no Agent Gateway, eles também usam a Demonstração de prova de posse (DPoP, na sigla em inglês), criando credenciais de vinculação dupla para segurança de ponta a ponta. Essa vinculação dupla significa que os agentes se autenticam usando mTLS para acesso de terceiros ao gateway e usam DPoP para interações além do gateway.

Gerenciador de autenticação de identidade do agente

O gerenciador de autenticação de identidade do agente é um cofre de credenciais centralizado e um broker de autenticação que simplifica a autenticação de ferramentas de saída para seus agentes. Ele permite que os agentes se autentiquem usando uma chave de API ou um ID e segredo do cliente OAuth ou em nome de um usuário por delegação do OAuth usando tokens de acesso do usuário final. No gerenciador de autenticação, você configura provedores que definem o tipo de autenticação e as credenciais de aplicativos específicos de terceiros.

O acesso ao gerenciador de autenticação de identidade do agente é regido pelo IAM, e o agente usa o próprio ID SPIFFE para se autenticar no gerenciador de autenticação. Todos os eventos de acesso do usuário final também são atribuíveis ao ID SPIFFE do agente, permitindo uma governança fácil.

O gerenciador de autenticação de identidade do agente automatiza a aquisição de credenciais do OAuth, como abrir uma caixa de diálogo para consentimento e login do usuário. Ele também oferece visibilidade do acesso do usuário final e permite a revogação do acesso, garantindo uma governança melhor das permissões delegadas pelo usuário.

Para mais informações, consulte a Visão geral do gerenciador de autenticação de identidade do agente.

Segurança e governança

A identidade do agente é totalmente integrada aos sistemas de políticas do Google, como IAM, limite de acesso de principal (PAB) e VPC Service Controls, que permitem maior segurança e governança. Ele também se integra ao registro de auditoria para garantir a responsabilidade e fornecer registros de auditoria claros quando o agente está agindo por conta própria e quando está agindo em nome de um usuário final.

  • Acesso Baseado no Contexto:por padrão, uma política de Acesso Baseado no Contexto gerenciada pelo Google ajuda a proteger as credenciais do agente ao aplicar a vinculação de tokens mTLS e DPoP. Essa abordagem garante que os tokens vinculados a certificados não possam ser reproduzidos fora do ambiente de execução confiável.
  • Integração do IAM:suporte a políticas de permissão e negação padrão do IAM.
  • Limite de acesso principal (PAB): um PAB limita os recursos que um agente pode acessar, independente de outras permissões.
  • VPC Service Controls:suporte para proteção de perímetro e uso principal:
    • Proteção de perímetro:adicione a API Agent Identity (agentidentity.googleapis.com) e a API Agent Identity Credentials (agentidentitycredentials.googleapis.com) a um perímetro de serviço para controlar o acesso a essas APIs. Para usar essas APIs em um perímetro de serviço, os clientes precisam rotear as solicitações pelo VIP restrito (restricted.googleapis.com).
    • Regras de entrada e saída:suporte para usar identidades de agente como principais em regras de entrada e saída para permitir o acesso a recursos protegidos por um perímetro de serviço.

Como funciona a identidade do agente

A identidade do agente autentica e autoriza as ações do agente usando um fluxo de trabalho projetado para ajudar a melhorar a segurança:

  1. Atribuição de identidade: quando você implanta um agente,o Cloud de Confiance atribui a ele uma identidade SPIFFE exclusiva e um certificado X.509. Cada certificado X.509 é válido por 24 horas e Cloud de Confiance é atualizado automaticamente para manter a segurança.
  2. Aquisição de credenciais: o método usado pelos agentes para adquirir credenciais depende do que eles estão tentando acessar. Confira alguns exemplos:
    • Acessar Cloud de Confiance serviços: o agente solicita um token de acesso vinculado. Esse token é criptograficamente vinculado ao certificado X.509 exclusivo do agente para ajudar a evitar o roubo de tokens. Para mais informações, consulte Segurança e governança.
    • Acessar ferramentas externas: o agente usa o gerenciador de autenticação de identidade do agente para recuperar as credenciais necessárias (como chaves de API ou tokens OAuth) de um provedor de autenticação. O gerenciador de autenticação é compatível com a autoridade delegada pelo usuário e a autoridade própria do agente.

Benefícios da identidade do agente

A identidade do agente melhora a segurança em relação às contas de serviço padrão.

  • Isolamento forte:ao contrário das contas de serviço, as identidades do agente não são compartilhadas por várias cargas de trabalho por padrão, não podem ser personificadas e não permitem que os desenvolvedores gerem chaves de conta de serviço de longa duração.
  • Segurança de credenciais:as políticas de Acesso baseado no contexto padrão tornam os tokens vinculados não reproduzíveis, ajudando a proteger contra roubo de tokens e invasão de conta. Quando a identidade do agente é usada com o gateway do agente e o Gemini Enterprise, as credenciais do usuário final, como as provisionadas pelos conectores do Gemini Enterprise, são criptografadas pelo gerenciador de autenticação e descriptografadas no gateway. Isso garante que o agente nunca acesse a credencial bruta.
  • Abordagem de privilégio mínimo:fornece identidades por agente em vez de contas de serviço compartilhadas para eliminar agentes com permissões excessivas.
  • Redução de atrito:automatiza fluxos complexos do OAuth e gerencia chaves de API para uma integração mais simples de ferramentas.
  • Observabilidade aprimorada:fornece registros de auditoria claros. Quando um agente age em nome de um usuário, os registros mostram as identidades do agente e do usuário.

Limitações

  • Papéis legados do bucket do Cloud Storage:não é possível conceder papéis legados do bucket às identidades do agente (por exemplo, storage.legacyBucketReader).

A seguir