Visão geral das políticas do IAM

É possível criar políticas de permissão e de negação do IAM que o Gateway de Agente usa para controlar com segurança a comunicação agêntica entre seus agentes e outros serviços, incluindo outros agentes, servidores MCP e endpoints. O Gateway de Agente usa o Identity-Aware Proxy (IAP) para aplicar as políticas. O IAP também aplica a segurança de autenticação e autorização de identidade do agente de ponta a ponta.

Para criar uma política do IAM para o Gateway de Agente, consulte Criar políticas do IAM.

Também é possível criar um limite de acesso de principal (PAB, na sigla em inglês) na identidade do agente. O Gateway de Agente pode usar o IAP para aplicar políticas de limite de acesso de principal.

Ativar o gateway de agente

Para usar políticas de comunicação agêntica, é necessário configurar o Gateway de Agente.

Recomendamos que você configure o Gateway de Agente no modo de teste (DRY_RUN) em um ambiente de preparo para verificar se as políticas estão funcionando conforme o esperado. No modo de teste, a IAP registra comunicações de agentes não permitidas nos registros de auditoria do Cloud, mas não as bloqueia.

Quando você tiver certeza de que as políticas estão funcionando corretamente, atualize a configuração do Gateway de Agente para definir o modo restrito como ENFORCE. Nesse modo, as comunicações de agentes que violam a política são proibidas, e as comunicações com o recurso são bloqueadas.

Componentes da política

As políticas têm os seguintes componentes:

• Agentes: nas políticas de permissão do IAM, os agentes de origem são definidos pela identidade deles (a identidade do agente que inicia a comunicação com um serviço). Para saber como diferentes tipos de agentes recebem identidades, consulte Identidade do agente. As identidades do agente são representadas por identificadores principais que contêm a identidade formatada em SPIFFE do agente, por exemplo, principal://agents.global.org-.... Os identificadores de agente no formato URN (como urn:agent:...) são usados apenas para pesquisa de inventário e catálogo e não são usados em vinculações de políticas do IAM. Quando você usa a CLI gcloud para configurar a política do IAM, o principal do agente é o membro a quem você concede acesso.

  Os agentes do Gemini Enterprise e as instâncias do Agent Runtime recebem automaticamente uma identidade de agente e são registrados no Agent Registry.

• Recurso do Agent Registry: o serviço do Agent Registry em que você está concedendo ou negando acesso. Nas políticas de permissão e negação do IAM, os serviços do Agent Registry são chamados de recursos. O recurso pode ser um registro inteiro em um projeto ou um serviço individual, que pode ser um servidor MCP, um agente ou um endpoint.

  Os serviços individuais precisam ser registrados no Agent Registry antes de serem referenciados em uma política do IAM. Esse registro é validado no momento da vinculação (quando a vinculação de política é criada ou atualizada). Se você fizer referência a um serviço que não está registrado, a criação da política vai falhar imediatamente com um erro de entidade solicitada não encontrada (NOT_FOUND).

  Ao configurar políticas usando a CLI gcloud ou o Terraform, os recursos de destino são especificados pelos caminhos ou IDs gerados pelo registro (usando flags como --agent, --endpoint ou --mcp-server), em vez dos identificadores URN lógicos. Em tempo de execução, o gateway de segurança corresponde aos destinos de tráfego pelo nome de host exato, em vez de usar URNs.

  Se você regionalizar os registros de agentes, a política de permissão do IAM será aplicada apenas aos recursos na região do registro.

• Papel: as políticas de comunicação de agente sempre concedem o papel de egressor protegido pelo IAP (roles/iap.egressor) no recurso de serviço.

• Condição: é possível configurar uma condição na política de permissão do IAM para restringir ainda mais o que o agente pode acessar. No console doCloud de Confiance , use o Criador de condições para criar uma condição selecionando elementos da UI. Como alternativa, use o Editor de condições para inserir condições mais complexas como expressões da Common Expression Language (CEL).

  A tabela a seguir lista os nomes de atributos que podem ser usados para construir expressões CEL. Como o estilo de acesso direto ao campo (como request.mcp.toolName) não é compatível, use a função api.getAttribute() para recuperar o valor de cada atributo.

  Para mais informações sobre como configurar políticas de permissão com condições, consulte Configurar políticas de agente do IAM.

  Nome do atributo	Descrição e exemplo de CEL
  mcp.toolName	Nome da ferramenta específica que está sendo chamada. Por exemplo: request.mcp.toolName == 'GetCalendarEvents'
  iap.googleapis.com/mcp.resourceName	Nome do recurso que está sendo acessado. Por exemplo: api.getAttribute('iap.googleapis.com/mcp.resourceName', '') == 'my-resource'
  iap.googleapis.com/mcp.promptName	Nome do comando em uso. Por exemplo: api.getAttribute('iap.googleapis.com/mcp.promptName', '') == 'my-prompt'
  mcp.method	A operação específica do MCP (por exemplo, tools/call, resources/read).
  iap.googleapis.com/mcp.tool.isReadOnly iap.googleapis.com/mcp.tool.isDestructive iap.googleapis.com/mcp.tool.isIdempotent iap.googleapis.com/mcp.tool.isOpenWorld	Flags booleanas que indicam o tipo de operação. Por exemplo: api.getAttribute('iap.googleapis.com/mcp.tool.isReadOnly', false) == true
  request.auth.type	Enumeração que indica o protocolo (por exemplo, "MCP").

Criar políticas

Na página Políticas do console Cloud de Confiance , crie políticas de permissão e de negação do IAM que o Gateway de Agente usa para governar comunicações agênticas.

Na CLI gcloud, é possível configurar políticas de permissão e negação do IAM que o Gateway de Agente usa para controlar as comunicações com agentes.

Políticas no console do Cloud de Confiance

Para criar políticas do IAM usando o console do Cloud de Confiance , consulte Configurar políticas do IAM.

Políticas na CLI gcloud

Para criar políticas do IAM usando a CLI gcloud, consulte Configurar políticas do IAM.

Autenticação e autorização de ponta a ponta

O IAP e o acesso baseado no contexto fornecem autenticação e autorização de identidade do agente padrão de ponta a ponta usando os seguintes protocolos:

• TLS mútuo (mTLS)
• Demonstração de prova de posse (DPoP)

As identidades de agente são provisionadas com um certificado X.509 e um token vinculado a certificado. O IAP exige que as identidades de agente usem TLS mútuo (mTLS) para autenticar o Gateway de Agente. Quando o gateway permite que o agente faça saída e acesse APIs Cloud de Confiance , servidores do MCP, outros agentes e endpoints, o agente tenta acessar fora do limite do mTLS. Para ajudar a proteger a comunicação, o Acesso baseado no contexto aplica uma política gerenciada pelo Google. A política exige que o DPoP valide o token vinculado ao certificado que está vinculado à identidade do agente. Para saber mais sobre como o acesso baseado no contexto oferece segurança mTLS e DPoP de ponta a ponta, consulte Segurança do agente de acesso baseado no contexto.

A seguir