É possível criar políticas de acesso unificado (UAPs, na sigla em inglês) do Identity and Access Management (IAM) para ajudar a governar com segurança a comunicação entre principais do agente e recursos de destino, como agentes de destino, servidores MCP e endpoints. Essas políticas estão vinculadas ao projeto que contém suas instâncias do Gateway de Agente.
O Gateway de Agente usa o Identity-Aware Proxy (IAP) para avaliar e aplicar as UAPs.
O IAP também se integra ao acesso baseado no contexto para fornecer autenticação e autorização de identidade do agente de ponta a ponta.
Para configurar UAPs para o gateway de agente, consulte Configurar UAPs 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.
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 agênticas que violam a política são
proibidas e a comunicação com o recurso é bloqueada.
Visão geral das UAPs
As UAPs controlam se um ou mais principais de agente podem acessar um ou mais recursos de destino. As UAPs estendem o modelo de política do IAM ao oferecer suporte a várias regras em uma única política. Ao contrário das políticas de permissão e de negação do IAM, cada regra em uma UAP pode ter um efeito de permissão e um efeito de negação. Saiba mais sobre os tipos de políticas do IAM.
As regras também contêm condições expressas na Common Expression Language (CEL). As condições atuam como o principal mecanismo para controlar o acesso a recursos pós-gateway. A aplicação de UAPs com o Gateway de Agente e o IAP oferece controle comportamental estrito sobre os agentes implantados em toda a empresa. É possível representar casos de uso de governança de agentes refinados do mundo real em uma única política.
Uma política típica contém pelo menos duas regras distintas:
- Regra de permissão:as regras de permissão têm um efeito de permissão que permite que os principais agentes acessem operações específicas e seguras, como realizar uma operação de leitura em uma ferramenta para buscar dados de rastreamento ou visualizar entradas de registro.
- Regra de negação:as regras de negação têm um efeito de negação que impede o agente de executar ações indesejadas, como realizar uma operação de exclusão ou atualização não comandada em um recurso crítico.
Por exemplo, considere um agente de suporte ao cliente automatizado que precisa interagir com ferramentas internas que têm acesso privilegiado a um banco de dados de clientes. O administrador configura um gateway de agente com o IAP para aplicar UAPs do IAM. O administrador pode configurar uma UAP com uma regra de permissão que autoriza o principal do agente a ler tíquetes de suporte e uma regra de negação que impede o principal do agente de excluir ou atualizar registros do banco de dados.
Ao usar UAPs que contêm regras de permissão e negação, as organizações podem implantar uma única política de compliance corporativo diretamente na infraestrutura em nuvem subjacente para restringir o comportamento do agente.
Práticas recomendadas
Siga estas práticas recomendadas ao configurar políticas de saída do agente:
- Use o modo de teste:implante políticas novas ou modificadas no modo de teste primeiro para garantir que a política funcione conforme o esperado, sem bloquear o tráfego de agentes ativos.
- Aplique o princípio de privilégio mínimo:conceda apenas as permissões necessárias. Use nomes ou caminhos específicos de ferramentas em condições CEL em vez de curingas.
- Use regras de negação para proteções:use regras de negação explícitas para implementar proteções críticas, como o bloqueio de ferramentas destrutivas em endpoints de produção. Usar regras de negação para guardrails é eficaz porque elas substituem as regras de permissão.
- Faça auditorias regulares:revise periodicamente os registros dos Registros de auditoria do Cloud e as configurações de política para verificar se eles estão em conformidade com as políticas de segurança da sua organização.
Componentes da UAP
As UAPs contêm uma ou mais regras. As regras têm os seguintes componentes:
Principais do agente
Nos UAPs do IAM, você define um ou mais principais do agente. Os principais do agente são os membros a quem você concede
acesso. Você especifica os agentes pela identidade deles, que é a identidade do agente que inicia a comunicação com um recurso.
Para mais informações sobre 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-...).
É possível especificar uma matriz de identidades de agentes individuais ou uma matriz de conjuntos de principais.
As identidades de agente integradas são provisionadas em serviços do Cloud de Confiance , como o Agent Runtime (mecanismo de raciocínio), o Gemini Enterprise (Discovery Engine) e os serviços do Cloud Run configurados com a identidade do agente. Esses principais do agente têm o formato principal://TRUST_DOMAIN/AGENT_UNIQUE_IDENTIFIER, em que o identificador representa o caminho do recurso do agente no serviço de hospedagem.
Também é possível especificar agentes usando identificadores principais da federação de identidade da carga de trabalho.
Efeito da regra
O efeito da regra define se ela permite ou não que os principais do agente acessem um recurso.
Recursos de destino
As UAPs do IAM gerenciam o acesso dos principais do agente aos recursos de destino. Os recursos de destino são aqueles que os principais do agente estão tentando acessar. Os recursos de destino são especificados nas condições da regra. Os recursos de destino podem ser registrados ou não registrados.
Recursos registrados
Os recursos registrados são aqueles que estão em um registro do Agent Registry.
Os recursos registrados incluem o seguinte:
- Registros: todos os registros de agentes em um projeto.
- Servidores MCP: servidores MCP registrados em um registro de agentes.
- Agentes: agentes registrados em um registro de agentes. Agentes individuais podem ser especificados individualmente pela identidade deles. Um grupo de agentes pode ser especificado por um identificador de conjunto principal.
- Endpoints: endpoints registrados em um registro de agente.
Os serviços individuais podem ser registrados no Agent Registry. Se você regionalizar os registros de agentes e a regra gerenciar o acesso aos recursos registrados, as UAPs serão aplicadas apenas aos recursos na região do registro.
Recursos não registrados
Recursos não registrados são aqueles que não estão registrados em um registro de agente. Para conceder ou negar acesso a recursos não registrados nas suas regras UAP, especifique os recursos não registrados nas condições da regra usando expressões da Common Expression Language (CEL) que contêm atributos de host e caminho não registrados.
Condições
Nas regras de UAP, use expressões da Common Expression Language (CEL)
no bloco conditions para definir o escopo do recurso de destino
e os critérios de acesso refinado:
Escopo do recurso de destino: identifica quais recursos de destino a regra governa. Em arquivos de política formatados em JSON, você especifica atributos de destino, como
destination.agent_registry.mcp_server.nameoudestination.unregistered.host. No console do Cloud de Confiance , selecionar destinos em Recursos de destino adiciona automaticamente esses critérios de recurso à expressão de condição da regra.Critérios de acesso: use uma expressão booleana para determinar quando e sob quais restrições o efeito da regra é aplicado. Por exemplo, é possível restringir o acesso com base em nomes de ferramentas, status somente leitura, métodos HTTP ou prefixos de caminho usando atributos da CEL da UAP. O efeito da regra (permitir ou negar) só entra em vigor quando toda a expressão CEL é avaliada como
true.
Na CLI gcloud e na API REST, você especifica essas expressões CEL no campo conditions da definição de regra.
No console do Cloud de Confiance , é possível configurar regras padrão usando o Criador de condições ou escrever expressões CEL personalizadas diretamente no Editor de condições.
Permissões
No IAP V2 com UAPs do IAM, a permissão
iap.googleapis.com/resources.egressViaIAP é sempre concedida no
recurso de destino. Na CLI gcloud e na API REST, especifique a
permissão no campo operation.permissions do arquivo de política.
Opções de criação de políticas
Na página Políticas do console do Cloud de Confiance , é possível criar UAPs do IAM. Recomendamos que você crie apenas UAPs (políticas do IAM v3).
Na CLI gcloud e na API REST, é possível configurar UAPs do IAM criando primeiro um arquivo formatado em JSON. Recomendamos que você crie apenas UAPs.
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 mais informações sobre como o acesso baseado no contexto usa mTLS e DPoP, consulte Segurança do agente do acesso baseado no contexto.
Atributos da CEL do UAP
Nas UAPs, é possível definir condições com expressões condicionais. As expressões podem conter várias subexpressões. O tipo de recurso de destino usado em cada subcondição relacional determina quais atributos podem ser usados.
Por exemplo, na condição a seguir, na subexpressão destination.unregistered.path.startsWith('/v1/statements'), o tipo de recurso é um destino não registrado, o atributo é destination.unregistered.path e startsWith() é a função CEL.
destination.unregistered.host == 'finance.example.com' &&
destination.unregistered.path.startsWith('/v1/statements')
Os atributos descritos na tabela a seguir estão disponíveis para cada tipo de recurso:
| Tipo de recurso de destino | Atributo | Detalhes | ||||||
|---|---|---|---|---|---|---|---|---|
Agent Registry |
destination.is_registered |
|
||||||
destination.agent_registry.resource_type |
|
|||||||
destination.agent_registry.location |
|
|||||||
destination.agent_registry.project_id |
|
|||||||
Agente |
destination.agent_registry.agent.name |
|
||||||
Servidor MCP |
destination.agent_registry.mcp_server.name |
|
||||||
destination.agent_registry.mcp_server.method |
|
|||||||
destination.agent_registry.mcp_server.tool.name |
|
|||||||
destination.agent_registry.mcp_server.tool.annotations.read_only_hint
|
|
|||||||
destination.agent_registry.mcp_server.tool.annotations.destructive_hint
|
|
|||||||
destination.agent_registry.mcp_server.tool.annotations.idempotent_hint
|
|
|||||||
destination.agent_registry.mcp_server.tool.annotations.open_world_hint
|
|
|||||||
destination.agent_registry.mcp_server.prompt.name |
|
|||||||
destination.agent_registry.mcp_server.resource.name |
|
|||||||
Endpoint |
destination.agent_registry.endpoint.name |
|
||||||
Destino não registrado |
destination.unregistered.host |
|
||||||
destination.unregistered.path |
|
|||||||
destination.unregistered.method |
|
A seguir
Codelab: proteger aplicativos de IA agêntica entre nuvens
Saiba como proteger seus aplicativos agênticos no codelab "Proteção de aplicativos de IA agêntica entre nuvens".