O Padrão de Contenção: Quatro Abordagens para Sandboxing de Agentes de IA em Produção

Na segunda semana de fevereiro de 2026, quatro empresas lançaram soluções independentes para o mesmo problema. O Cursor publicou sandboxing no nível do sistema operacional para agentes de codificação. O Docker lançou sandboxes shell com isolamento de credenciais em microVMs. A Zenity publicou um artigo revisado por pares sobre detecção de intenção maliciosa dentro das ativações internas de modelos. E a Entire, fundada pelo ex-CEO do GitHub, saiu do modo stealth com US$ 60 milhões para construir infraestrutura de governança para código gerado por IA.

Nenhuma dessas empresas coordenou o lançamento. Elas convergiram.

Essa convergência revela algo importante sobre o futuro da IA em produção. A indústria reconheceu que a forma como governamos agentes de IA atualmente --- pedindo aprovação humana para cada ação --- não escala. Um novo padrão está emergindo: contenção. Deixe os agentes operarem livremente dentro de limites definidos. Mova a decisão de confiança de por-ação para por-ambiente.

O Problema: Fadiga de Aprovação

O Cursor nomeia o problema central diretamente. Quando agentes requerem aprovação humana para cada comando no terminal, os usuários inicialmente revisam cada solicitação com cuidado. Depois param. Conforme as aprovações se acumulam, especialmente ao executar múltiplos agentes em paralelo, humanos carimbam sem ler. O portão de segurança vira teatro.

Não é um problema de educação do usuário. É um problema de design. Humanos não foram construídos para manter atenção sustentada ao longo de centenas de decisões sequenciais de aprovação. Quanto mais portões você adiciona, menos cada portão vale. Em algum ponto, mais infraestrutura de segurança produz menos segurança real.

Os dados do Cursor confirmam a intuição. Agentes em sandbox --- aqueles executando dentro de contenção no nível do SO sem aprovação por comando --- param 40% menos frequentemente que agentes sem sandbox. Um terço de todas as requisições em plataformas suportadas agora roda em sandbox. Os agentes são mais produtivos porque não pausam constantemente para pedir permissão. E a segurança é melhor porque o limite é arquitetural, não comportamental.

Quatro Camadas de Contenção

O que torna este momento interessante não é que a contenção está acontecendo. É que quatro abordagens genuinamente diferentes apareceram simultaneamente, cada uma endereçando uma camada distinta da pilha de segurança.

Camada 1: Sandboxing no Nível do SO (Cursor)

O Cursor restringe o comportamento do agente no nível do sistema operacional. No macOS, isso significa Seatbelt --- o mecanismo de sandboxing do kernel da Apple, introduzido em 2007, descontinuado em 2016, e ainda usado pelo Chrome. No Linux, significa Landlock e seccomp, dois Módulos de Segurança Linux que restringem acesso ao sistema de arquivos e chamadas de sistema, respectivamente.

A implementação é precisa. Políticas do Seatbelt são geradas dinamicamente em tempo de execução, baseadas em configurações do workspace, configurações de administrador e arquivos .cursorignore. Agentes não podem escrever em .git/config, diretórios .vscode ou qualquer padrão de arquivo que o usuário tenha excluído. Podem ler e escrever livremente dentro do workspace do projeto. O limite é o projeto, não o comando.

No Linux, o Cursor usa uma abordagem de sistema de arquivos overlay. Workspaces dos usuários são mapeados em overlays onde arquivos ignorados são sobrescritos com cópias protegidas por Landlock que não podem ser lidas ou modificadas. A equipe nota que esta é a parte mais lenta da implementação Linux --- uma limitação da plataforma, não do design.

O detalhe mais revelador é como o Cursor ensinou os agentes a trabalharem dentro do sandbox. Atualizaram descrições de ferramentas shell para documentar as restrições, construíram um benchmark interno (Cursor Bench) para avaliar performance com e sem sandbox, e mudaram como os resultados do shell são renderizados para que agentes vejam qual restrição causou uma falha. O resultado: agentes se recuperam “muito mais graciosamente de falhas relacionadas ao sandbox.”

Camada 2: Isolamento por MicroVM (Docker)

O Docker Sandboxes adota uma abordagem diferente. Em vez de restringir o SO do host, cria um ambiente inteiramente separado: uma microVM leve rodando Ubuntu com Node.js 20, Python, git e ferramentas de desenvolvimento comuns pré-instaladas.

O modelo de segurança é elegante em sua simplicidade. O agente só consegue ver o diretório de workspace que você monta --- não seu diretório home, não seus arquivos de sistema, nada mais. Chaves de API nunca são armazenadas dentro do sandbox. Em vez disso, o proxy de rede do Docker intercepta chamadas de API de saída e injeta credenciais no momento da requisição. O agente usa um valor sentinela (echo proxy-managed) que o proxy substitui pela chave real. O segredo real nunca existe no ambiente do agente.

Dentro do sandbox, o agente roda com modo bypassPermissions. Sem aprovação por comando. Liberdade completa dentro do limite. Se algo der errado, você executa docker sandbox rm e começa do zero.

O Docker posiciona o shell sandbox como um runtime de propósito geral para qualquer coisa que rode em Linux e se comunique com APIs de IA: Claude Code, Codex, GitHub Copilot, OpenCode, Kiro, entre outros.

Camada 3: Detecção por Sonda de Ativação (Zenity)

A abordagem da Zenity é fundamentalmente diferente do Cursor e do Docker. Eles não estão restringindo o comportamento do agente. Estão detectando intenção maliciosa dentro do próprio modelo.

O sistema executa prompts através do Llama-3.1-8B-Instruct, extrai ativações das camadas internas e as alimenta em uma sonda de regressão logística leve que pontua maliciosidade. A descoberta-chave é que modelos de linguagem representam internamente se um conteúdo é prejudicial, mesmo quando não recusam ou sinalizam na saída de texto. Usar o mesmo modelo como juiz (Llama-Judge) consistentemente teve desempenho inferior à sonda de ativação --- o modelo compreende conteúdo malicioso, mas tem dificuldade em articular essa compreensão.

Os resultados são notáveis, particularmente em ameaças agênticas. Injeções de prompt embutidas em resultados de ferramentas --- não entradas do usuário, mas dados retornados por ferramentas --- são uma categoria que guardrails existentes (Prompt-Guard, Llama-Guard) sequer conseguem avaliar. Marcam N/A. A sonda da Zenity alcança 99,2% de recall nessa categoria. Em jailbreaks, pontuam 71,2% versus 28,9% do Llama-Guard.

A metodologia é rigorosa. A Zenity usa avaliação Leave-One-Dataset-Out (LODO), onde conjuntos de dados inteiros são excluídos do treinamento para testar desempenho real fora da distribuição. O código, datasets de benchmark e artigo são todos publicamente disponíveis.

A limitação é a taxa de falso positivo de 6,8% em requisições benignas. Em sistemas de agentes de alta vazão, uma em cada quinze operações legítimas sendo sinalizada cria fricção operacional.

Camada 4: Governança por Checkpoints (Entire)

A Entire não previne ações ruins nem detecta intenção maliciosa. Ela registra o raciocínio.

Thomas Dohmke passou quase quatro anos como CEO do GitHub e liderou o Copilot até se tornar a ferramenta de codificação com IA mais usada do mundo. Sua tese é direta: a cadeia de ferramentas de desenvolvimento --- controle de versão, revisão de código, CI/CD --- foi projetada para humanos escrevendo código. Quando agentes de IA são os principais produtores de código, a cadeia precisa ser reconstruída.

O primeiro produto da Entire, Checkpoints, é uma ferramenta CLI open-source que registra as instruções e o raciocínio por trás do código gerado por IA. Quando um agente escreve código, o Checkpoints captura o prompt, a cadeia de raciocínio e o contexto que levou a cada mudança. Esse contexto viaja com o código, tornando pull requests geradas por IA auditáveis de uma forma que mensagens de commit sozinhas não conseguem.

A empresa captou US$ 60 milhões a uma avaliação de US$ 300 milhões --- o que a investidora líder Felicis chamou de o maior investimento seed da história para uma startup de ferramentas para desenvolvedores. A lista de investidores inclui M12 da Microsoft, Jerry Yang (cofundador do Yahoo), Garry Tan (CEO da Y Combinator), Olivier Pomel (CEO do Datadog) e figuras da comunidade de desenvolvedores como Gergely Orosz e Theo Browne.

A Taxonomia de Contenção

Essas quatro abordagens formam uma taxonomia, não uma competição. Cada uma endereça contenção em um nível diferente:

Camada	Abordagem	O Que Faz	Provedor
SO	Restrição de syscalls + filesystem	Impede agentes de acessar recursos fora do limite	Cursor
VM	MicroVM isolada + proxy de credenciais	Impede agentes de ver segredos ou escapar do ambiente	Docker
Modelo	Sondas de ativação internas	Detecta intenção maliciosa antes que se torne ação	Zenity
Processo	Trilha de auditoria de raciocínio	Registra por que mudanças foram feitas para revisão e conformidade	Entire

A taxonomia sugere que infraestrutura madura de agentes vai empilhar múltiplas abordagens de contenção. Um agente pode rodar dentro de uma microVM Docker (Camada 2), com restrições no nível do SO dentro da VM (Camada 1), monitorado por sondas de ativação (Camada 3) e com todo raciocínio registrado pelo Checkpoints (Camada 4).

Isso é defesa em profundidade --- o mesmo princípio que governou segurança de infraestrutura por décadas, agora aplicado a agentes de IA.

O Que Isso Significa para Empresas

A implicação prática é que a transição de “aprovar cada ação” para “definir o limite” está acontecendo agora. Não é teórica. Quatro empresas a implementaram em uma semana.

Para equipes executando agentes de IA em produção, três perguntas se tornam urgentes:

Primeiro, qual é seu limite de confiança? Hoje, a maioria das organizações define confiança por-ação: aprove este comando, permita esta escrita de arquivo, autorize esta chamada de API. O padrão de contenção move isso para por-ambiente: defina o limite uma vez, deixe o agente operar livremente dentro dele.

Segundo, qual camada você precisa? Nem toda carga de trabalho requer cada camada. Agentes de desenvolvimento interno podem precisar de sandboxing no nível do SO e governança por checkpoints. Agentes voltados para clientes podem precisar de isolamento por VM e detecção por sonda de ativação. O perfil de risco determina a pilha.

Terceiro, quem é responsável pelo limite? Contenção é infraestrutura. Alguém precisa definir, manter e auditar os limites. No modelo do Cursor, é uma combinação de configurações do workspace, configuração de administrador e arquivos .cursorignore. No modelo do Docker, é a configuração do sandbox. Esses limites são artefatos de governança tão concretos quanto políticas IAM e exigem o mesmo rigor operacional.

O Paradoxo da Produtividade

A descoberta contraintuitiva em tudo isso é que contenção torna agentes mais produtivos, não menos. A redução de 40% nas paradas do Cursor é o dado mais claro, mas o princípio é visível em todas as quatro abordagens.

Quando agentes conhecem seus limites, não desperdiçam ciclos negociando permissões. Quando credenciais são gerenciadas pelo ambiente, agentes não precisam de fluxos complexos de autenticação. Quando raciocínio é registrado automaticamente, agentes não precisam gerar mensagens de commit explicativas. E quando sondas de ativação cuidam da detecção de ameaças, os próprios mecanismos de segurança do agente não precisam ser tão conservadores.

Restrições habilitam velocidade. Não é um princípio novo em engenharia de software --- sabemos desde os anos 1960 que programação estruturada (restrições deliberadas no fluxo de controle) produz software melhor mais rápido. Mas aplicá-lo a agentes de IA é novo, e os dados estão começando a confirmar o que o princípio prediz.

Olhando para Frente

A equipe do Cursor descreve interesse futuro em “agentes nativos de sandbox treinados nas restrições de seu ambiente” --- agentes que não apenas toleram seus limites, mas são projetados em torno deles.

Dohmke da Entire traça a analogia com a manufatura: “Assim como quando empresas automotivas substituíram o sistema de produção tradicional e artesanal pela linha de montagem móvel, devemos agora reimaginar o ciclo de vida do desenvolvimento de software para um mundo onde máquinas são os principais produtores de código.”

Ambas as visões apontam na mesma direção. O padrão de contenção não é um compromisso temporário entre autonomia e controle. É a fundação arquitetural de como agentes de IA em produção vão operar. As empresas que construírem sua infraestrutura de contenção agora poderão escalar suas implantações de agentes. As que dependerem de fadiga de aprovação, não.

Quatro empresas. Quatro camadas. Uma semana. O padrão de contenção está se tornando o padrão de produção.

Fontes: Cursor Blog | Docker Blog | Zenity Labs (arxiv) | DevOps.com sobre Entire

Contato: contato@victorino.com.br | www.victorino.com.br