Agent Gateway no Google Cloud: O Contorno de Gerenciamento Externo para Agentes de IA que Faltava nas Empresas

Agent Gateway no Google Cloud: O Contorno de Gerenciamento Externo para Agentes de IA que Faltava nas Empresas

Prólogo: "9 segundos para o desastre"

Recentemente, um agente de IA para desenvolvimento de código (Cursor, baseado no modelo Anthropic Claude Opus 4.6) recebeu uma tarefa e a executou de forma literal demais. Em 9 segundos, ele destruiu o banco de dados de uma empresa, juntamente com seus backups. Ao ser questionado sobre o ocorrido, o agente respondeu: "Eu violei cada princípio que me foi dado". Este incidente ocorreu na startup PocketOS.

Exatamente essa frase é um veredito para toda uma classe de soluções arquitetônicas. O agente não mentiu: ele violou suas próprias instruções, incorporadas no prompt do sistema. Isso significa uma coisa: não se pode confiar nas restrições internas do modelo como único mecanismo de segurança. É o mesmo erro lógico de confiar em um estagiário com a instrução "não faça nada destrutivo" sem quaisquer restrições técnicas no nível da infraestrutura. É necessário um contorno de gerenciamento externo. E é exatamente isso que o Google Cloud implementou na forma do Agent Gateway.

O que é o Agent Gateway?

A maioria das descrições do Agent Gateway se resume à formulação "um proxy inteligente para agentes de IA". Isso é verdade, mas incompleto. O Agent Gateway é um componente de rede da Gemini Enterprise Agent Platform. Ele garante a segurança e o gerenciamento das conexões para todas as interações de agentes: entre usuários e agentes, entre agentes e ferramentas, e entre os próprios agentes.

A palavra-chave aqui é componente de rede. O Agent Gateway opera no nível da infraestrutura de rede, fora do ciclo de raciocínio do modelo. Isso significa que ele não pede ao agente para "verificar a política primeiro", mas intercepta a chamada antes mesmo que ela atinja o destino. O Agent Gateway atua como um ponto de aplicação de políticas em tempo de execução, interceptando chamadas para ferramentas ou outros agentes para garantir a conformidade com as políticas de controle de acesso e suportar a inspeção de chamadas de ferramentas através do Model Armor.

Essa separação é crítica. Se o Agent Gateway tivesse sido implantado no incidente com o banco de dados destruído, o agente simplesmente não teria conseguido enviar fisicamente a solicitação destrutiva, não porque "mudou de ideia" (operando sob restrições de políticas de segurança), mas porque o gateway o teria bloqueado no nível da rede.

Posição no Ecossistema: Pilar "Govern"

Para entender corretamente o Agent Gateway, é preciso primeiro compreender a arquitetura geral da Gemini Enterprise Agent Platform. A plataforma é organizada em torno de quatro áreas-chave: Build, Scale, Govern e Optimize. O Agent Gateway faz parte da área Govern e é o ponto central de aplicação de políticas para gerenciar todas as chamadas de ferramentas de agentes, gerenciar autenticação e aplicar políticas de segurança.

A interação é esquematizada da seguinte forma:

• Build — ADK, Agent Studio, Agent Garden (criamos agentes)
• Scale — Agent Runtime, Sessions, Memory Bank (lançamos e escalamos)
• Govern — Agent Identity, Agent Registry, Agent Gateway, Policies (gerenciamos e protegemos)
• Optimize — Observability, Evaluation, Example Store (melhoramos)

O Agent Gateway está posicionado em "Govern" porque sua tarefa é garantir que o agente opere apenas dentro dos limites permitidos.

Quatro Integrações que Tornam o Gateway Inteligente

O Agent Gateway não opera no "vácuo". Sua força real reside na integração profunda com outros componentes da plataforma:

1. Agent Registry O Agent Registry é uma biblioteca central de agentes e ferramentas aprovados, incluindo servidores MCP de terceiros. O Agent Gateway acessa os metadados do registro para aplicar políticas de acesso detalhadas. Na prática, isso significa que um agente não pode se conectar "arbitrariamente" a uma nova ferramenta ou servidor MCP. Se um recurso não estiver registrado no registry, o acesso a ele será bloqueado por padrão.

2. Agent Identity O Agent Identity é uma persona única e rastreável para cada agente que interage com o Google Cloud. O Agent Gateway usa esses identificadores como principals para tomar decisões de autorização. Os identificadores de agentes são protegidos por padrão pelo Context-Aware Access, que fornece autenticação criptográfica ponta a ponta usando mTLS e DPoP. Ao serem implantados, os agentes devem ser configurados com um Agent Identity — um identificador exclusivo no formato SPIFFE, que serve como uma alternativa granular às contas de serviço genéricas. Suportado diretamente no IAM, ele permite que os administradores atribuam permissões específicas (por exemplo, para buckets do Cloud Storage ou conjuntos de dados do BigQuery) diretamente ao agente.

3. Agent Platform Policies O Agent Gateway fornece autorização delegada às políticas da Agent Platform, como IAM, Semantic Governance e Model Armor, permitindo a implementação de conjuntos ricos de medidas de segurança e gerenciamento de agentes.

4. Agent Observability O Agent Gateway gera telemetria de observabilidade para todas as interações de agentes no nível da rede e a exporta para o Agent Observability para fornecer uma compreensão completa das ações dos agentes.

Dois Modos de Operação: Ingress e Egress

Arquiteturalmente, o Agent Gateway opera em dois modos que cobrem diferentes vetores de ameaça:

• Client-to-Agent (Ingress) Este modo é usado para proteger as comunicações entre clientes (como Cursor, Claude Code, Gemini CLI) e agentes, bem como ferramentas executadas no Google Cloud. Neste modo, o Agent Gateway atua como um frontend para o agente e permite controlar quais clientes podem acessar os agentes e quais políticas de segurança são aplicadas a essas interações. Esta é a proteção contra ameaças de entrada: prompt injection de clientes não confiáveis, acesso não autorizado a agentes, conteúdo malicioso de sistemas externos.

• Agent-to-Anywhere (Egress) Este modo é usado para proteger as comunicações entre agentes executados no Google Cloud e servidores, agentes, ferramentas ou APIs que operam em qualquer lugar. O Agent Gateway aplica permissões de acesso e proteções para agentes que precisam interagir com servidores MCP — tanto os criados pela própria organização quanto servidores remotos de terceiros. Esta é a proteção contra ameaças de saída: o agente não poderá acessar ferramentas não autorizadas, executar operações proibidas ou vazar dados para sistemas externos. É o modo Egress que teria protegido contra o incidente de destruição do banco de dados.

Sistema de Controle de Acesso: IAP + IAM + Model Armor

Esta é a parte mais tecnicamente rica. Vamos analisar como as camadas de controle são construídas:

• Identity-Aware Proxy como Núcleo de Autorização O Identity-Aware Proxy atua como o nível padrão de aplicação de políticas para o Agent Gateway. Ele usa o IAM para verificar o identificador do agente e verifica as permissões atribuídas antes de permitir chamadas para outros agentes ou ferramentas. O IAP está habilitado por padrão para o Agent Gateway, embora possa ser executado em modo audit-only (dry-run). Na prática, isso significa que você pode executar o gateway em modo "suave" — todas as solicitações passam, mas cada infrator é registrado nos logs. Assim que você tiver certeza da correção das políticas, mude para o modo "rígido" — tudo sem permissão explícita será bloqueado.

• Políticas IAM Granulares É possível conceder e negar acesso a servidores MCP e ferramentas para agentes ou clientes individuais com base no nome da ferramenta e se a ferramenta é somente leitura ou leitura-escrita. As permissões podem ser concedidas no nível da organização, pasta ou projeto. Esta é exatamente a granularidade que faltava: não apenas "permitir/negar acesso a um serviço", mas "permitir apenas operações de leitura para uma ferramenta específica".

• Model Armor: Proteção contra Prompt Injection O Model Armor (opcional) pode ser usado para controlar o tráfego de saída: garantir que o agente "não vaze" dados sensíveis ou não seja exposto a ataques de prompt injection. Quando usado no modo Ingress, protege os agentes contra ataques de entrada ou conteúdo malicioso de clientes.

Regionalidade e Requisitos de Implantação

Alguns detalhes práticos importantes:

O Agent Gateway é regional em seu escopo. Cada gateway gerencia interações de agentes dentro do projeto em que é implantado. Os agentes devem ser implantados no mesmo projeto e região que o gateway, e também registrados na mesma região.

Ambos os modos (Ingress e Egress) são suportados para Agent Runtime. Apenas o modo Egress é suportado para Gemini Enterprise.

Configuração via YAML

A implantação via gcloud é minimalista — o Agent Gateway é configurado declarativamente:

yaml
name: AGENT_GATEWAY_NAME
protocols:
  - MCP
googleManaged:
  governedAccessPath: AGENT_TO_ANYWHERE
registries:
  - //agentregistry.googleapis.com/projects/PROJECT_ID/locations/REGION

Após a criação do Agent Gateway, ele serve como o ponto de conexão principal para rotear o tráfego de agentes em seu projeto e região selecionada. Você pode usar este endpoint para estabelecer canais de comunicação seguros, criptografados e autenticados entre agentes e seus destinos.

Conexão com VPC via Private Service Connect

Para agentes que precisam de acesso a recursos na rede interna, o Agent Gateway suporta configuração de conexão VPC via Private Service Connect network attachment. O tamanho mínimo da sub-rede para o network attachment é /28. O DNS peering também é suportado para resolução de nomes dentro das redes VPC de destino.

Limitações

Nenhuma tecnologia é perfeita, e é importante conhecer as limitações:

• As condições de autorização baseadas em atributos de protocolos de agentes são suportadas apenas para o Model Context Protocol (MCP). Outros protocolos de agentes não são suportados.
• Para Gemini Enterprise, o modo Client-to-Agent não é suportado.
• O Agent Gateway não suporta VPC Service Controls.

O que isso significa para nós na prática:

• Se você usa protocolos A2A ou REST, condições granulares por atributos de protocolo não estão disponíveis no momento — apenas controle IAM no nível do identificador do agente.
• Se você está construindo uma arquitetura com VPC Service Controls como a principal ferramenta de isolamento — você precisará usar custom organization policy constraints em vez de VPC SC.

A funcionalidade está em Private Preview, ou seja, disponível mediante solicitação. Para obter acesso ao Agent Gateway com Agent Runtime, é necessário preencher um formulário de solicitação de acesso.

Ou seja, para usar a combinação Agent Gateway e Agent Runtime, é preciso acessar uma página especial de solicitação (access request page) e preencher um formulário de solicitação para incluir o projeto Google Cloud em uma "lista branca" (allowlist).

Por que isso é mais importante do que parece?

Vamos olhar a situação de forma mais ampla. Estamos passando por uma era fundamentalmente nova na TI-segurança: da proteção do código à proteção das intenções.

Firewalls tradicionais e WAFs operam com assinaturas e regras no nível de bytes. Mas o que fazer com uma solicitação que é sintaticamente correta, passa por todas as verificações de autenticação e autorização, mas é semanticamente destrutiva?

DELETE FROM users WHERE 1=1 — este é um SQL válido. Seu perigo é determinado não pelo formato, mas pela intenção.

O Agent Gateway é a primeira ferramenta empresarial de um grande provedor de nuvem que opera precisamente no nível semântico dos protocolos de agentes. Ele entende a diferença entre chamar uma ferramenta com acesso de leitura e acesso de escrita, sabe verificar o contexto da solicitação através do Model Armor e tomar decisões com base em políticas semânticas, e não apenas em assinaturas de bytes.

Isso significa uma mudança no modelo de segurança: de "o que o agente tem permissão para fazer" para "o que o agente está tentando fazer agora".

Matriz: O que o Agent Gateway Protege

Conclusão

Se você está construindo agentes de IA em produção hoje e se limita apenas às instruções no prompt do sistema como mecanismo de restrição — você está construindo um sistema com um único ponto de falha. E esse ponto de falha é o próprio modelo, que pode cometer erros, ser hackeado via prompt injection ou simplesmente "mudar de ideia" em uma situação imprevista.

O Agent Gateway, juntamente com o Model Armor, protege todas as interações de agentes, aplica políticas em tempo de execução e ajuda a se defender contra ameaças, garantindo a conformidade das operações com os requisitos.

A arquitetura empresarial correta para agentes de IA é a seguinte: você desenvolve um agente sem precisar pensar em primitivas de rede e segurança (essa é uma tarefa para a equipe de segurança, não para os desenvolvedores), registra-o no Agent Registry, define políticas IAM com os privilégios mínimos necessários, e o implanta com roteamento através do Agent Gateway. A plataforma cuida de todo o resto.

Essa é a mesma ideia do princípio de privilégio mínimo (least privilege) na segurança clássica — apenas adaptada para o mundo dos agentes, que agem autonomamente e podem tomar decisões que você não previu.

E para aqueles que desejam estudar a documentação oficial: https://docs.cloud.google.com/gemini-enterprise-agent-platform/govern/gateways/agent-gateway-overview