O Perímetro do Agente Ficou Específico: Regras por Atributo MCP e Gravação de Sessão

Em maio mapeamos a convergência dos fornecedores de contenção: um conjunto de fornecedores de segurança construindo perímetros conscientes de agentes sem coordenar entre si, todos apontando para a mesma direção. Aquele texto argumentou que o padrão era real e direcional. Ainda não conseguia apontar para um campo de configuração. No início de julho de 2026, consegue. O VPC Service Controls do Google agora aceita identidades de agente como principals IAM dentro de regras de ingresso e egresso. A HashiCorp levou o Boundary à versão 1.0 com gravação de sessão. A abstração virou uma opção que você habilita.

A convergência está resolvida, então não é aqui que vamos reargumentá-la. O que importa agora é uma divisão que não estava visível em maio. A governança de agentes está se bifurcando em duas camadas que exigem controles separados. A camada de identidade responde quem é o agente. A camada de rede responde para onde os dados dele podem fluir. Já escrevemos sobre identidade de rede como o sandbox do agente; os lançamentos de julho transformam essa tese em dois pontos de aplicação distintos, e agora você precisa dos dois. IAM sozinho não impede que um agente injetado exfiltre dados para um webhook externo. As credenciais do agente são válidas. O problema é o destino.

A camada de identidade virou endereçável no perímetro

Historicamente, o VPC Service Controls envolvia um conjunto de recursos do Google Cloud em uma fronteira e controlava quais principals podiam cruzá-la. A atualização de julho permite que uma identidade de agente seja um desses principals, seja como identidade única, seja como PrincipalSet, dentro de regras de ingresso e egresso. Parece incremental. Não é.

A consequência é a revogação no perímetro de rede. Antes, se um agente fosse comprometido, a alavanca mais rápida era o IAM: remover as roles dele e torcer para que todo sistema downstream reverificasse as permissões antes de o agente terminar a tarefa em curso. Agora dá para retirar um agente comprometido no próprio perímetro. A fronteira para de reconhecê-lo como autorizado a cruzar, independentemente do que o IAM ainda diga no meio da execução. Para uma identidade não humana capaz de emitir milhares de operações por minuto, a diferença entre “permissões revogadas, propagando” e “bloqueado no muro” é a diferença entre um incidente e um quase acidente.

O Mercado Libre resumiu a leitura operacional com clareza. “O VPC Service Controls serve como uma camada essencial e fundamental, garantindo que todos os nossos dados permaneçam protegidos”, disse Juan Pablo Boschi. Fundamental é a palavra certa. O perímetro é onde você quer a última linha, porque ela não depende de todos os serviços downstream se comportarem corretamente sob pressão.

A camada de rede agora lê atributos MCP

A segunda primitiva é a que muda como você escreve política. O VPC Service Controls consegue aplicar acesso condicional sobre atributos MCP: mcp.toolName, mcp.method e mcp.tool.isReadOnly, entre outros. A política deixa de ser “este agente pode alcançar o Workspace”. Passa a ser “este agente pode alcançar o Workspace com métodos somente-leitura, e qualquer envio de e-mail é negado na fronteira”.

Leia essa política contra o OWASP LLM Top-10 e o valor fica concreto. Injeção indireta de prompt (ASI01) e uso indevido de ferramentas (ASI02 e ASI08) compartilham o mesmo formato de falha: as próprias credenciais do agente são usadas para fazer algo que o operador nunca pretendeu, porque um documento envenenado ou uma entrada forjada mandou fazer. O IAM diz que o agente pode chamar a ferramenta. O firewall diz que o caminho de rede está aberto. Ambos estão corretos e ambos são inúteis contra essa classe de ataque, porque o atacante está montado numa identidade legítima cruzando um caminho legítimo. As regras por atributo MCP dão o ponto de aplicação que faltava. O VPC-SC bloqueia o destino mesmo quando o IAM e o firewall permitiriam. Conceda a leitura, negue a escrita, no perímetro, atrelado ao método MCP específico e não à identidade genérica.

Esta é a resposta de exfiltração que a convergência de maio apontava sem nomear. Um agente injetado que tenta fazer POST dos seus dados para um endpoint externo passa por credenciais válidas sem esforço. O que o detém é uma regra dizendo que o egresso desta identidade tem formato apenas de leitura.

Gravação de sessão chegou para identidades não humanas

A terceira primitiva vem da HashiCorp. O Boundary 1.0 traz gravação de sessão RDP: captura e replay de cada ação interativa dentro de uma sessão. Segundo o anúncio, a versão também estabelece um roteiro rumo a autorização efêmera, fluxos on-behalf-of e reavaliação contínua de acesso durante a sessão, não apenas no início dela.

O enquadramento que a HashiCorp usa é a parte que sustenta tudo. Autenticar-uma-vez não funciona para agentes. O controle de acesso humano assume que uma pessoa faz login, executa trabalho delimitado e faz logout, e que reverificá-la constantemente seria fricção com pouco retorno. Um agente inverte cada uma dessas premissas. Ele pode rodar por horas, mudar de tarefa no meio da sessão e tomar, no minuto cinquenta, uma ação que nada tem a ver com aquilo para que foi autorizado no minuto um. A reavaliação contínua para de tratar o login como a decisão de segurança e passa a tratar cada ação como uma. A gravação de sessão é a companheira de auditoria disso: quando um agente faz algo inesperado, você dá replay no que exatamente aconteceu em vez de reconstruir a partir de logs espalhados.

Gravação e reavaliação contínua ficam do lado de identidade e sessão da bifurcação. As regras MCP do VPC-SC ficam do lado de rede. Um time que instala uma e não a outra tem um controle real, porém parcial. Você pode saber com precisão o que o agente fez e ainda assim ter deixado os dados dele saírem, ou pode bloquear o egresso e não ter replay de como o agente chegou lá.

Faça isto agora

Escolha um agente de produção que toque dados sensíveis e rode uma verificação de duas colunas ainda esta semana.

Coluna um, a camada de rede. Alguma regra de perímetro se atrela ao que o agente faz, além de quem ele é? Se a sua política de egresso é somente por identidade, um agente injetado com credenciais válidas exfiltra e nada o barra no muro. Escreva uma regra por atributo MCP para esse agente: permita os métodos de leitura que ele realmente precisa, negue escritas e envios no perímetro. Se você roda no Google Cloud, isso agora é uma regra de ingresso ou egresso do VPC-SC com o agente como principal. Se você roda em outro lugar, nomeie o ponto de aplicação equivalente e confirme que ele existe antes de assumir que existe.

Coluna dois, a camada de identidade e sessão. Você consegue revogar esse agente no perímetro, além do IAM? Consegue dar replay em uma sessão inteira depois do fato? O acesso é reavaliado durante a sessão ou apenas na autenticação? Se a resposta à última for “só no login”, você está confiando em uma identidade não humana do jeito que confiaria em uma pessoa, e as premissas não se transferem.

É provável que você encontre uma coluna forte e a outra vazia. Esse é o estado normal em julho de 2026, e é corrigível agora que os dois lados deixaram de ser diagrama de arquitetura e viraram configuração. Os fornecedores desenharam o perímetro. Habilitá-lo é a sua jogada.

Fontes

Google Cloud. “Securing agentic AI: what’s new in VPC Service Controls.” Julho de 2026.
HashiCorp. “Boundary 1.0 releases with RDP session recording and improved management.” Julho de 2026.

A Victorino ajuda organizações de engenharia a construir perímetros de agente nas camadas de identidade e de rede, para que um agente comprometido seja barrado no muro, não apenas no IAM: contato@victorino.com.br | www.victorino.com.br