Quatro Superfícies de Contenção, Um Diagrama: O Stack de Agentes Acaba de Ser Desenhado

Na semana de 21 a 27 de abril de 2026, quatro superfícies distintas de controle de agentes ganharam implementações de referência dentro da mesma janela de terça a sexta. O Engineers’ Codex publicou um tour pelas primitivas de sandbox para IA. Arpit Bhayani argumentou que bancos de dados não foram desenhados para tráfego de agentes e propôs um padrão defensivo. A Anthropic lançou Memory para Claude Agents em ambientes corporativos, com Netflix e Rakuten como primeiros adotantes. A HashiCorp lançou Vault 2.0, com federação de identidade de workload, SCIM e SPIFFE.

Nenhum coordenou com o outro. Ainda assim, os lançamentos se alinham como quatro andares do mesmo edifício.

Quem acompanha governança de agentes há algum tempo já sabe o que contenção significa em uma camada isolada. Já escrevemos sobre o padrão de contenção no nível do sistema operacional. Já escrevemos sobre agentes que ignoram a própria memória. Já escrevemos sobre por que modelos de permissão funcionam 40% das vezes. O que esta semana tornou impossível ignorar é que esses três textos não são ensaios independentes. São três fatias de um mesmo diagrama. E o diagrama agora tem quatro andares.

Esta é uma revisão arquitetural de 30 minutos que o time de plataforma deveria rodar ainda esta semana.

Andar 1: Computação

O andar de computação decide o que o processo de um agente pode tocar quando executa código. O tour do Engineers’ Codex catalogou as primitivas em produção: gVisor, o kernel em espaço de usuário que a Anthropic usa no Claude para web; microVMs Firecracker, que o Vercel Sandbox inicia em cerca de 125ms; Bubblewrap, que a Anthropic usa no Claude Code CLI nas estações de trabalho dos desenvolvedores; e cgroups e namespaces do Linux, a maquinaria que sustenta os containers há mais de uma década.

O trade-off entre essas primitivas é o mesmo que times de infraestrutura discutem desde que o Docker foi lançado: velocidade contra força de isolamento. Bubblewrap é leve e rápido; compartilha o kernel do host. O gVisor adiciona uma camada de tradução de syscalls. O Firecracker adiciona uma fronteira de virtualização por hardware. A escolha não é sobre qual é a melhor. A escolha é sobre o que o agente está autorizado a fazer quando algo dá errado, e quanto a superfície do “errado” pode se alargar.

O padrão que o ensaio sobre contenção descreveu no nível do sistema operacional vale aqui também. Você move a confiança de por-ação para por-ambiente. Para de pedir aprovação humana a cada comando. Define a fronteira e deixa o agente operar.

Isso entrega o primeiro andar. Não é o edifício.

Andar 2: Dados

O texto de Arpit Bhayani, Databases Were Not Designed for This, é o que torna concreto o segundo andar. O argumento: bancos de dados foram construídos para tráfego de aplicação, em que um número pequeno de serviços emite consultas com formatos previsíveis. Agentes não se comportam assim. Emitem milhares de consultas variantes, geradas em tempo de execução, frequentemente sem que o código que as chama tenha passado por revisão humana. Tratar o banco como substrato passivo é como se descobre, às duas da manhã, que um agente disparou um DELETE que não tinha o direito de disparar.

O padrão de banco defensivo proposto por Bhayani é uma pilha de práticas pequenas e tediosas que se compõem:

Roles específicas por agente, com o princípio de menor privilégio aplicado por schema, tabela e coluna.
Tagueamento de contexto em consultas, em que toda query do agente embute o ID do agente, o ID da tarefa e a etapa de raciocínio como comentário SQL. O DBA passa a responder “quem emitiu isso” sem garimpar logs de aplicação.
Soft delete em tudo, com uma coluna deleted_by que captura a identidade do agente e a razão. Nada de hard delete a partir do código do agente.
Chaves de idempotência em toda escrita, para que retentativas não produzam duplicatas e para que trilhas de auditoria possam colapsá-las de maneira limpa.
Pools de conexão dedicados por classe de agente, para que um loop descontrolado em um agente não esgote o pool usado por humanos ou outros sistemas.

Nenhuma dessas é uma técnica nova de banco de dados. O que é novo é tratá-las como infraestrutura obrigatória, não como item desejável. Contenção de computação sem contenção de dados é um sandbox com porta dos fundos. O agente não escapa do sandbox; o DELETE dele não precisa escapar.

Andar 3: Conhecimento

O andar de conhecimento é aquilo que um agente lembra entre sessões e quem governa o que é lembrado. O lançamento do Memory para Claude Agents em ambientes corporativos pela Anthropic é a primeira implementação de referência desse andar com controles que um time de plataforma consegue de fato apontar.

As escolhas de design importam:

A memória é baseada em sistema de arquivos, não em um vetor opaco. Dá para listar. Dá para usar grep. Dá para exportar.
O sistema expõe uma API programática, ou seja, mutações de memória podem ser controladas por política da mesma forma que mudanças em IAM.
Permissões são escopadas por agente, por projeto, por usuário. Não é um blob compartilhado.
A trilha de auditoria suporta rollback e redação. Se um agente memorizou um dado pessoal de cliente que jamais deveria ter armazenado, dá para provar, dá para provar quem viu e dá para remover.

Netflix e Rakuten são citadas como primeiras adotantes. O ponto relevante não é que dois logos grandes adotaram. O ponto relevante é que o departamento de compras corporativo agora tem um produto de governança de memória para comprar. A conversa sobre se governança de memória de agentes é real terminou.

Argumentamos o modo de falha entre conveniência e governança no início deste mês: agentes ignoram o sistema governado de memória se um arquivo plano for mais barato. Memória como superfície de primeira classe, exportável e auditada é o que fecha essa lacuna, mas apenas se a plataforma fizer do caminho governado o caminho padrão. Construir o andar de conhecimento e deixar um atalho de arquivo plano ao lado dele apenas reconstrói o viés de conveniência um andar acima.

Andar 4: Identidade

O quarto andar é o que a maioria dos times trata por último e descobre tarde demais. Quem é o agente e como o resto da infraestrutura sabe?

O HashiCorp Vault 2.0, lançado nesta semana sob o modelo de versionamento da IBM, transforma identidade em andar, não em pensamento posterior. A mudança principal é a federação de identidade de workload: o agente não carrega credenciais estáticas. Ele apresenta uma identidade de workload, o Vault a verifica contra uma fonte federada de confiança, e credenciais de curta duração são emitidas para a operação específica. SCIM passa a ser padrão para provisionamento. SPIFFE é suportado como envelope de identidade. A plataforma se compromete com ciclos de suporte de dois anos, o tipo de cadência que times corporativos de segurança planejam em torno.

Credenciais estáticas no código do agente são o equivalente, em segurança, a deixar a chave embaixo do tapete. Todo time que opera agentes em produção tem, em algum lugar, uma conta de serviço cuja credencial é rotacionada raramente, se é rotacionada. Federação remove o segredo. O agente é a identidade; a credencial é um artefato transitório derivado dessa identidade no momento do uso.

Isso importa porque os outros três andares são inúteis sem este. Contenção de computação, contenção de dados e contenção de conhecimento assumem que “o agente” é uma entidade estável e identificada. Se a identidade do agente for um token de API de longa duração compartilhado entre três serviços, você não tem quatro andares. Tem um andar com três escadas para fora.

Rode Esta Revisão Arquitetural Esta Semana

Bloqueie 30 minutos com o time de plataforma. Leve o diagrama. Caminhe pelos quatro andares:

Computação. Onde os agentes executam código? Nomeie a primitiva. Se a resposta for “no mesmo container da aplicação”, você não tem andar de computação; tem um problema de cohabitação. Se a resposta for “deixamos o modelo rodar comandos de shell em um laptop de desenvolvedor sem sandbox”, o andar de computação está no laptop do dono.

Dados. Escolha um banco de produção. Rode SHOW GRANTS para a role do agente. Se ela tem DROP em qualquer coisa, anote. Olhe as últimas 1000 consultas da role do agente. Estão tagueadas? Dá para saber qual tarefa as emitiu? Se uma consulta deu errado, dá para encontrar o raciocínio que a produziu? Se as respostas forem não, o andar de dados está faltando.

Conhecimento. O que cada agente lembra entre sessões e quem pode ler? Dá para exportar? Dá para redigir? Se a resposta for “usamos a memória padrão do framework”, o andar de conhecimento está delegado a um fornecedor e provavelmente não é auditado.

Identidade. Pegue as credenciais de um agente. São estáticas? Quando foi a última rotação? Quem mais as tem? Se a credencial é um segredo de longa duração, o andar de identidade é o equivalente a “confiar na rede”.

É provável que pelo menos dois andares não estejam construídos. Isso é normal. O que não é aceitável é operar sem saber quais andares estão faltando. Os quatro lançamentos desta semana não são pitch de fornecedor. São lista de inventário. A arquitetura foi desenhada. O que resta é olhar para o próprio edifício e responder, com honestidade, quantos andares estão de pé.

Os times que vencerão os próximos dois anos de operação de agentes não são os com agentes mais autônomos. São os com agentes autônomos rodando dentro de um edifício de quatro andares.

Fontes

What Every Dev Should Know About AI Sandboxes — Engineers’ Codex, abril de 2026.
Databases Were Not Designed for This — Arpit Bhayani, abril de 2026.
Anthropic Launches Memory in Claude Agents for Enterprise — TestingCatalog, abril de 2026.
HashiCorp Vault 2.0 Identity Federation — InfoQ, abril de 2026.

A Victorino ajuda organizações de engenharia a desenhar arquitetura de contenção de agentes nas camadas de computação, dados, conhecimento e identidade: contato@victorino.com.br | www.victorino.com.br