- Início
- The Thinking Wire
- A lista permitida é uma alegação até alguém testá-la no fio
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
- Liste toda carga de trabalho de agente que roda com acesso parcial à rede. Foi nessa configuração que a Perplexity mediu os bypasses.
- 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.
- 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.
- 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.
- 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
- Perplexity. “Escaping SPACE: Part I.” Setembro de 2026.
- Docker. “From Dockerfile to Kit: the Docker Sandboxes Kit Specification.” Setembro de 2026.
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