Quando o Recurso Intencional do Sandbox de Agente Vira a Saída

A maioria das fugas de sandbox é bug. Alguém acha uma falha, o fornecedor corrige, a porta fecha. A fuga mais interessante divulgada nesta primavera não é um bug. É um recurso funcionando exatamente como foi desenhado, reaproveitado como saída.

Nigel Sood, da Sonrai Security, publicou em abril de 2026 uma prova de conceito mostrando que o acesso global ao S3 embutido no interpretador de código do AWS Bedrock AgentCore pode virar um canal bidirecional de comando e controle. O sandbox está fazendo aquilo para o qual foi construído. O alcance que o torna útil é o mesmo alcance que permite a um atacante rodar um loop de C2 oculto direto por ele. Sem precisar das credenciais da execution role quando os buckets-alvo são públicos.

Este é o modo de falha que o isolamento de rede não pega, porque o canal foi autorizado de propósito.

A Porta Que Você Assinou Embaixo

O modo sandbox do AgentCore existe para deixar o código de um agente alcançar o mundo mais amplo de dados públicos no S3: datasets abertos, artefatos compartilhados, arquivos de referência. Esse alcance é um requisito real de fluxo de trabalho. Cientistas de dados puxam buckets públicos. Agentes buscam corpora de referência. Tire isso e você quebra o trabalho legítimo de boa parte dos clientes.

A PoC transforma exatamente esse alcance em arma. Sood demonstra um canal de C2 construído sobre presigned URLs, com objetos de comando e resposta numerados em sequência passando pelo S3. O atacante escreve um objeto de comando, o sandbox comprometido o lê, executa e escreve um objeto de resposta de volta. Os números de sequência mantêm a conversa ordenada. Como os buckets podem ser públicos, o sandbox nunca precisa das credenciais da execution role para participar. A fronteira que seu diagrama de rede prometia, aquela que diz “este sandbox não consegue ligar para casa”, é contornada sem um único pacote saindo por um caminho que você estava vigiando.

Não é a primeira vez que pesquisadores mostram um sandbox de agente vazando por um caminho intencional. A Sonrai aponta que o trabalho se apoia em divulgações anteriores de exfiltração via DNS, da Phantom Labs (BeyondTrust) e da Unit 42 (Palo Alto). A resolução de DNS é permitida porque agentes precisam resolver hostnames. Então os dados saíram via DNS. O alcance ao S3 é permitido porque agentes precisam de dados públicos. Então os comandos chegaram via S3. O padrão se repete: todo canal de que um agente legitimamente precisa vira um canal que um atacante pode tomar emprestado.

Por Que a Plataforma Não Pode Simplesmente Fechar

O instinto é exigir que a AWS tranque o recurso. Pré-restringir o S3 global, matar o caminho de DNS, entregar um padrão mais apertado. O problema é que a plataforma não consegue pré-restringir um recurso de que clientes reais dependem sem quebrar esses clientes.

Este é o modelo de responsabilidade compartilhada chegando aos runtimes de agentes. O provedor de nuvem protege o substrato. O cliente configura a fronteira da própria carga de trabalho. O acesso global ao S3 não é uma má configuração que a AWS deixou jogada. É uma superfície de capacidade, neutra até você decidir o que seus agentes podem tocar. A AWS não pode removê-la de forma unilateral mais do que pode remover a rede de saída só porque algumas cargas de trabalho abusam dela.

Então a fronteira se move para você. Se seus agentes não precisam de S3 público arbitrário, isso é uma política que você precisa escrever. Se precisam de alguns buckets, escopar a endpoint policy para uma allow-list nomeada é trabalho seu, não o padrão da plataforma. A contenção que o diagrama de rede sugeria nunca foi imposta pelo diagrama. Ela tem que ser imposta por uma configuração que pertence a você.

Já escrevemos sobre mover a confiança de por-ação para por-ambiente. Este é o mesmo princípio empurrado uma camada para fora: a saída permitida do ambiente é, ela mesma, uma fronteira que você define, não uma que você herda.

A Única Resposta Durável É um Muro Mais Forte

Escopar a endpoint policy fecha a porta específica. Não muda a verdade mais profunda: um container que compartilha um kernel com tudo o mais é uma fronteira fraca. Quando a próxima fuga por recurso autorizado aparecer, e ela vai aparecer, a pergunta passa a ser o que um atacante alcança depois que está dentro do sandbox.

O trabalho da Microsoft em abril de 2026 sobre endurecer o OpenClaw no AKS enquadra a resposta durável. O texto trata a CVE-2026-25253, uma vulnerabilidade em nível de container no OpenClaw, rodando a carga sob Kata Containers. O Kata embrulha cada container em uma microVM leve com seu próprio kernel convidado. O container deixa de compartilhar o kernel do host. Uma fuga de container deposita o atacante dentro de um kernel convidado, não no host. O raio de impacto para em uma fronteira reforçada por hardware em vez de escorrer por cima de co-tenants.

Esta é a diferença entre um sandbox que contém mau comportamento e um sandbox que contém uma invasão. A policy escopada de S3 estanca o canal de C2 conhecido. Uma fronteira de hipervisor faz o desconhecido deixar de importar. Os dois são complementares, não alternativas. A política estreita o que o agente pode alcançar legitimamente. A microVM garante que, quando algo ilegítimo acontecer mesmo assim, fique numa caixa que tem o próprio kernel entre ela e o seu host.

Os times que rodam agentes em produção tendem a tratar força de isolamento como um imposto de desempenho que prefeririam não pagar. Bubblewrap é rápido. Um container de kernel compartilhado inicia mais rápido que uma microVM. Até um recurso funcionando como esperado virar canal de C2, essa velocidade parece vantagem grátis. A PoC da Sonrai é o lembrete de que o imposto estava comprando algo real.

Faça Isto Agora

Três movimentos, nesta ordem.

Audite a saída que você autorizou. Para cada runtime de agente, liste o que ele pode alcançar: endpoints S3, DNS, rede de saída. Trate cada caminho autorizado como um canal de C2 em potencial e pergunte quem precisa dele. Os que ninguém consegue justificar são portas que você abriu por padrão.

Escope a endpoint policy. Onde seus agentes precisam de S3, troque o acesso global por uma allow-list de buckets nomeados. Onde não precisam, remova o alcance por inteiro. Faça o mesmo para DNS e saída de rede. A plataforma não vai estreitar isso por você, porque estreitar quebraria outra pessoa.

Mova para uma fronteira de hipervisor tudo que roda código não confiável ou gerado por modelo. Um container de kernel compartilhado é aceitável para código que você escreveu e revisou. Para código gerado por agente tocando dados reais, uma fronteira de microVM como Kata ou Firecracker é a linha que se sustenta quando o próximo recurso intencional vira saída. Mapeamos o stack completo de contenção e os níveis de contenção de bash em outros textos; o andar de runtime é onde esta fuga em particular mora.

O sandbox de agente em que você confia tem uma saída que você autorizou. A correção não é esperar a plataforma achar toda saída autorizada e fechá-la. A correção é assumir a fronteira você mesmo e construí-la forte o bastante para que a próxima saída que você não viu não alcance o seu host.

Fontes

Sonrai Security. “Global S3: Another C2 Channel for AgentCore Code Interpreters.” Abril de 2026.
Microsoft. “Hardening OpenClaw on AKS: Kata microVM Isolation.” Abril de 2026.

A Victorino ajuda times a desenhar contenção de agentes que se sustenta mesmo quando um recurso está funcionando como esperado: contato@victorino.com.br | www.victorino.com.br