A lista permitida é uma alegação até alguém testá-la no fio

TV
Thiago Victorino
7 min de leitura
A lista permitida é uma alegação até alguém testá-la no fio

No red team que a Perplexity rodou contra o próprio sandbox de agentes, nenhuma fuga da VM para o host foi observada em 108 execuções. No mesmo exercício, antes da correção, o bypass da política de rede funcionou em 11 de 54 execuções com rede parcial. Nas 54 execuções sem rede nenhuma, funcionou em zero.

Havia duas fronteiras em teste. A parede de computação resistiu em todas as tentativas. A regra de rede, a lista de hosts que o agente pode alcançar, cedeu em cerca de uma execução a cada cinco sempre que estava ligada.

A Perplexity também testou dez plataformas de terceiros, sem agentes de LLM, e escreveu que encontrou pelo menos um bypass de política de rede em oito das dez plataformas testadas.

Minha leitura dos dois resultados juntos é direta. Uma allowlist de rede é uma declaração de intenção até alguém testá-la no fio.

O que o red team mediu

A fonte é Escaping SPACE: Part I. Já tratamos do próprio SPACE em julho e não vamos repetir a arquitetura aqui. O material novo são os dados do ataque.

Quatro modelos identificaram vulnerabilidades na implementação do confinamento de rede: Claude Opus 5.0, GPT-5.6 Cyber, GPT-5.6 Sol e Kimi K3. Outros dois, Fable e GPT-6 Astra, se recusaram a executar as tarefas.

A lição que a Perplexity tira diz respeito a como a regra era aplicada: usar apenas o endereço IP de destino, no host, para decidir se uma conexão é permitida é insuficiente. Um arquivo de política não mostra qual checagem está por trás dele. O arquivo lista hosts. O código de enforcement decide o que conta como correspondência. Minha leitura é que a fraqueza mora nesse código, e não na lista.

Os números vêm com ressalvas. A página não tem autor nem data de publicação, e as referências internas a colocam depois de 10 de setembro de 2026. A Perplexity vende o SPACE e relata a própria correção, então é parte interessada. Cada célula do teste rodou três vezes, o que faz de 11 em 54 uma amostra pequena. Os autores acrescentam a própria cautela, e ela vale também para as 108 execuções limpas: a ausência de uma fuga observada não prova isolamento.

Mesmo com esses limites, o formato do resultado é difícil de descartar. A camada de computação resistiu. A camada escrita como lista de destinos permitidos foi onde os bypasses aconteceram.

Oito de dez, e o que os fornecedores responderam

A rodada com terceiros aconteceu entre 31 de agosto e 1º de setembro de 2026 e não envolveu agentes de LLM. Nenhum modelo improvisou para atravessar essas plataformas. Os bypasses saíram de testes convencionais.

A Perplexity nomeia publicamente nove das dez plataformas, e sete dessas nove tiveram bypass. A Tabela 3 registra as respostas dos fornecedores em 10 de setembro:

  • Vercel: “Known limitation: Documented domain-fronting behavior.”
  • Modal: “Known limitation: Not classified by the vendor as a vulnerability.”
  • microsandbox: corrigido na v0.6.18, com o modo estrito desligado por padrão.

Esses status são de 10 de setembro e podem ter mudado. Mesmo assim, dizem algo útil sobre onde cai a responsabilidade.

A entrada da Vercel diz que o comportamento está documentado. A da Modal diz que ele não é classificado como vulnerabilidade. Minha leitura: quando um fornecedor chama isso de limitação conhecida, quem configurou uma allowlist naquela plataforma passa a ser dono da decisão de aceitá-lo. Para um desenvolvedor rodando um build, uma peculiaridade documentada de saída de rede pode ser tolerável. Para um agente que lê entrada não confiável e escreve as próprias chamadas de rede, a mesma peculiaridade pode virar o caminho de uma exfiltração. Descrevemos esse formato antes, em Quando o Recurso Intencional do Sandbox de Agente Vira a Saída.

A entrada da microsandbox levanta outra questão operacional. A tabela junta a correção ao modo estrito desligado por padrão e não diz se a correção depende dele. Se depender, o número da versão, sozinho, não diz o que o seu ambiente aplica. Alguém precisa ler a configuração.

Em agosto escrevemos que um bounty é um preço sobre a confiança na contenção. Uma tabela de bypasses é o outro lado desse preço: a lista dos lugares onde essa confiança ainda não foi conquistada.

A Docker torna a autoridade comparável

Em 24 de setembro de 2026, a Docker publicou a Sandbox Kit Specification v3, sob licença Apache 2.0, anunciada por Christian Dupuis em From Dockerfile to Kit. É o lançamento de uma especificação por um fornecedor, sem dados medidos, então vale como intenção de design.

O trecho que importa para este argumento é a regra de mudança. Uma versão dentro do que foi concedido pode ser aplicada sem perguntar. Qualquer ampliação para e pergunta, e remover uma regra de negação conta como ampliação.

Essa regra transforma autoridade em algo que se declara, se versiona e se compara num diff. Uma nova versão que pede mais um host vira um evento revisável. Apagar uma regra de negação é tratado como ampliação, o que fecha uma rota silenciosa para o acúmulo de permissões.

A Docker também é direta sobre o limite da própria especificação. Sem um runtime conforme, a anotação é inerte: uma imagem e nenhum enforcement.

Coloque as duas fontes lado a lado. A especificação da Docker trata do problema da declaração: o que foi concedido, e quando a concessão mudou. A Perplexity mediu o problema do enforcement: se o tráfego fora da concessão de fato para. Uma allowlist comparável num diff, aplicada por um runtime que checa só o IP de destino no host, ainda pode vazar, e o diff não mostra nada, porque a declaração nunca mudou. Você precisa da declaração e do teste, e só o teste mostra que a declaração é verdadeira.

Um teste do lado do comprador

O teste é pequeno o bastante para rodar nesta semana, e tem duas metades que precisam estar presentes.

Linha de base. De dentro do sandbox, com exatamente a política de rede que a produção vai usar, faça uma requisição a um host da allowlist. Ela precisa funcionar. Isso prova que o próprio teste funciona. Um teste que só verifica falhas também passa quando o sandbox está sem rede nenhuma.

Host proibido. Do mesmo sandbox, com a mesma política, faça uma requisição a um host que a política não permite. Ela precisa falhar. Depois tente alcançar esse host pelas outras rotas que a documentação do fornecedor menciona. Se o fornecedor lista domain fronting como comportamento conhecido, uma dessas rotas é um host proibido alcançado através de uma fachada permitida.

Registre os dois resultados com a versão da política e a versão do runtime. Linha de base aprovada mais host proibido bloqueado é o único estado verde. Qualquer outra combinação significa que a allowlist descreve uma rede que não existe.

Dois complementos baratos aumentam o valor do teste. Rode-o sempre que o diff da política mostrar uma ampliação e sempre que o fornecedor lançar uma atualização do runtime. E onde uma carga de trabalho puder viver sem saída de rede, tire a rede: nos dados da Perplexity, as execuções sem rede registraram zero bypass em 54.

Faça isso agora

  1. Liste toda carga de trabalho de agente que roda com acesso parcial à rede. Foi nessa configuração que a Perplexity mediu os bypasses.
  2. Para cada fornecedor de sandbox, puxe a lista de limitações conhecidas e compare cada entrada com a sua allowlist. O que tocar saída de rede ganha um dono nomeado e uma aceitação por escrito, ou sai.
  3. Monte o teste de duas metades descrito acima e amarre-o a toda mudança de política e a toda atualização de runtime.
  4. Se você está adotando um formato declarativo como a especificação Kit da Docker, exija um runtime conforme antes de contar a anotação como controle, e continue rodando o teste no fio depois disso.
  5. Mova para rede zero as cargas de trabalho que não precisam de saída.

Uma allowlist que nunca foi testada é uma alegação. O teste no fio a transforma em evidência.


Fontes

A Victorino ajuda times de engenharia a transformar políticas de sandbox de agentes em controles testados e aplicados: contato@victorino.com.br | www.victorino.com.br

Todos os artigos do The Thinking Wire são escritos com o auxílio do modelo LLM Opus da Anthropic. Cada publicação passa por pesquisa multi-agente para verificar fatos e identificar contradições, seguida de revisão e aprovação humana antes da publicação. Se você encontrar alguma informação imprecisa ou deseja entrar em contato com o editorial, escreva para editorial@victorino.com.br . Sobre o The Thinking Wire →

Se isso faz sentido, vamos conversar

Ajudamos empresas a implementar IA sem perder o controle.

Agendar uma Conversa