Runtime de agentes de IA no GCP: os controles que a maioria das implementações esquece

A maior parte das implementações de agentes de IA em GCP que revisamos trata o runtime do agente como mais um serviço de aplicação: uma service account, algumas roles de IAM, e o resto herdado da VPC do projeto. O problema é que um agente não se comporta como um serviço de aplicação — ele decide dinamicamente quais ferramentas chamar, quais dados ler e para onde escrever, muitas vezes com base em texto que veio de fora da organização.

Isso muda o que precisa ser controlado. Um serviço tradicional tem um conjunto fixo de chamadas de saída, conhecido em tempo de design. Um agente com acesso a ferramentas externas — busca na web, execução de código, integrações via MCP — tem uma superfície de egress que só se define em tempo de execução. Sem um perímetro de rede que restrinja esse egress, qualquer ferramenta que o agente decida invocar (inclusive uma injetada por prompt injection) tem caminho livre para exfiltrar dado.

O controle mais direto continua sendo VPC Service Controls em volta dos perímetros que hospedam o runtime do agente e os dados que ele acessa — não como camada opcional, mas como requisito de design desde o primeiro deploy. Junto com isso, constraints de Org Policy que limitem quais APIs e quais destinos de rede o projeto do agente pode alcançar reduzem a superfície antes mesmo de qualquer detecção entrar em ação.

O segundo ponto que costuma faltar é visibilidade sobre integrações de ferramentas não catalogadas — o que a comunidade vem chamando de 'shadow tool integration'. Um agente que ganha acesso a uma nova ferramenta via configuração de um pipeline de CI, sem passar por revisão de segurança, é funcionalmente equivalente a uma nova identidade com escopo desconhecido. O inventário de ferramentas conectadas ao agente precisa ser tratado com o mesmo rigor que aplicamos a service accounts: listado, revisado e com dono definido.

Prevenção de exfiltração de dado nesse contexto não é só DLP na saída — é DLP combinado com o perímetro de rede e com constraints de organização atuando juntos, porque um agente comprometido por injection não necessariamente aciona uma regra de DLP se o dado sair por um canal que o time nunca modelou como saída.

O padrão que aplicamos em assessments recentes: mapear o runtime do agente como um perímetro próprio dentro do VPC Service Controls, restringir egress por Org Policy ao conjunto mínimo de destinos necessários, e manter o catálogo de ferramentas conectadas como artefato revisável — não como configuração solta em um repositório de agente.