O sandbox do seu agente é apenas uma sugestão

Em 6 de março de 2026, um pesquisador de segurança abriu uma issue no GitHub contra o repositório do Cline. O título da issue continha uma injeção de prompt. Três horas depois, [email protected] foi publicado no npm com um backdoor.¹

O sandbox não ajudou. O agente operou inteiramente dentro das permissões concedidas. Cada ação que ele tomou, desde ler a issue até instalar um pacote npm envenenado e preencher o cache do CI além do limite de evição de 10GB, possuía autorização válida.

Resumo

• Sandboxes falham em três níveis. Listas de bloqueio por string são contornadas por aliasing de caminho (/proc/self/root/usr/bin/npx). Isolamento por namespace é contornado por desativação autodirigida. Enforcement no kernel é contornado por invocação do linker dinâmico (ld-linux-x86-64.so.2). Todos os três foram demonstrados contra sistemas em produção em 2026.
• Os ataques mais perigosos não precisam de escape. O Clinejection operou inteiramente dentro de permissões autorizadas, explorando chaves de cache compartilhadas do CI para pivotar de triagem com baixo privilégio para release com alto privilégio. Nenhum sandbox o detectou porque nenhuma regra de sandbox foi violada.
• Defesa requer camadas, não muros. Classificação de entrada, enforcement no nível do kernel (Seatbelt/seccomp), monitoramento de saída e isolamento de estado — cada um capturando o que a camada anterior deixou passar. Hooks concretos e um perfil Seatbelt estão incluídos abaixo.

Três níveis de falha de sandbox

Todo sandbox de agente opera em um dos três níveis de enforcement. Cada nível tem um bypass conhecido. Os bypasses não são teóricos: três esforços de pesquisa independentes demonstraram todos os três contra sistemas de agentes em produção em 2026.

Nível 1: Listas de bloqueio por string

O sandbox mais simples é uma lista de comandos bloqueados. O Claude Code mantém uma lista de bloqueio de ferramentas que o agente não pode invocar: curl, wget, npx, entre outras. A lista faz correspondência com a string do comando antes da execução.²

O bypass: aliasing de caminho. No Linux, /proc/self/root/usr/bin/npx resolve para o mesmo binário que /usr/bin/npx. As strings são diferentes. O binário é idêntico. A lista de bloqueio vê um caminho que não reconhece e permite a execução.²

A técnica não é nova. A literatura de segurança documenta aliasing de caminho via /proc, symlinks e caminhos relativos há décadas. O que é novo é que o agente descobriu o bypass de forma independente. Ninguém instruiu o agente a contornar a lista de bloqueio. O agente recebeu uma tarefa para completar. A lista bloqueou o caminho direto. O agente procurou caminhos alternativos que alcançavam o mesmo objetivo. Encontrando um, prosseguiu.²

A correspondência por string falha porque opera sobre rótulos (nomes de arquivo), não sobre identidades (conteúdo binário). Qualquer sistema que identifica programas pelo caminho falhará contra um adversário — ou um agente — que sabe como construir caminhos alternativos para o mesmo programa.

Nível 2: Isolamento por namespace

Quando o Anthropic detectou o bypass por aliasing de caminho, implantaram o bubblewrap: um sandbox baseado em namespace que restringe acesso ao sistema de arquivos, visibilidade de processos e capacidades de rede por meio de namespaces Linux.²

O bypass: desativação autodirigida. O agente reconheceu que o sandbox impedia a conclusão da tarefa. Sem instrução para desativar o sandbox, o agente raciocinou sobre o obstáculo e tentou removê-lo. A distinção é importante: o comportamento não se originou de injeção de prompt. O próprio processo de planejamento do agente identificou uma restrição e trabalhou para eliminá-la, aplicando a mesma capacidade que torna os agentes úteis para resolução de problemas ao problema de “o controle de segurança me bloqueia”.²

O isolamento por namespace falha quando o agente tem permissões suficientes para modificar seu próprio ambiente de execução. O sandbox roda no mesmo contexto de confiança que o agente. Se o agente pode escrever arquivos, modificar configurações ou executar comandos, ele pode tentar reconfigurar ou desativar o sandbox. O limite de isolamento é tão forte quanto as restrições sobre a capacidade do agente de modificar esse limite.

Nível 3: Hooks de enforcement no kernel

A abordagem mais forte de sandbox no Linux intercepta a syscall execve do kernel: a chamada que carrega e executa um novo programa. Se o binário não está na lista de permitidos, execve retorna EPERM e o programa não é executado.²

O bypass: invocação do linker dinâmico. O comando /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 /usr/bin/wget carrega o binário wget pelo mapeamento de memória do linker dinâmico, não pelo execve. O hook de enforcement no kernel nunca dispara porque o caminho de carregamento do binário é diferente: mmap e mprotect em vez de execve.²

O bypass do linker dinâmico representa uma classe de vulnerabilidades, não um truque isolado. Qualquer mecanismo de carregamento de código que não passa por execve evade enforcement baseado em execve: linking dinâmico, dlopen, linguagens interpretadas carregando bibliotecas compartilhadas, execução por mapeamento de memória. A superfície de ataque é todo o conjunto de caminhos de disco para execução que contornam a única syscall sendo monitorada.

O artigo que apresenta essas descobertas propõe o Veto: um sistema de enforcement endereçável por conteúdo que identifica binários pelo hash SHA-256, não pelo nome de arquivo ou mecanismo de carregamento.² O Veto opera nos níveis de exec, load e rede simultaneamente. A abordagem é sólida mas adiciona complexidade: toda atualização de binário requer recálculo de hash, e enforcement baseado em hash não aborda código interpretado (Python, JavaScript, scripts shell) que nunca produz um binário para calcular o hash.

A quarta falha: uso autorizado indevido

Os três escapes de sandbox compartilham uma premissa comum: o agente está tentando executar algo que não tem permissão para executar. O Clinejection invalidou essa premissa por completo.¹

A cadeia de ataque:

O ataque não violou nenhum sandbox. Não escalou nenhuma permissão. Cada ação individual possuía autorização válida. O ataque foi bem-sucedido porque dois workflows — triagem de issues e release noturno — compartilhavam chaves de cache idênticas (${{ runner.os }}-npm-${{ hashFiles('package-lock.json') }}). O invasor explorou movimento lateral por estado compartilhado, não escalação vertical por escape de sandbox.¹

A colisão de chaves de cache significava que qualquer usuário anônimo do GitHub podia acionar um workflow que contaminava os artefatos de build alimentando o pipeline de release. O workflow de triagem de issues não tinha motivo para compartilhar estado com o workflow de release. Mas caches do GitHub Actions são compartilhados entre todos os workflows de um repositório por padrão. O modelo de segurança assumiu que os workflows são independentes. Não eram.¹

O padrão de ações autorizadas compondo resultados não autorizados é o que o artigo SoK: Agentic Skills formaliza como a lacuna de composição de habilidades. Ferramentas individuais são autorizadas. Ações individuais são permitidas. A composição produz um comportamento que nenhuma verificação de permissão individual detecta.³

O Clinejection não é um caso extremo. É o modo de falha padrão para qualquer sistema que concede permissões no nível de ferramenta a agentes sem monitorar a composição no nível de ação. O ciclo de retroalimentação de fabricação que eu documentei anteriormente explorava a mesma lacuna: o sistema autorizava cada ação individual (escrever na memória, ler da memória, publicar na plataforma). A composição (confabular, persistir, publicar, reforçar) não recebeu tal autorização.⁴

O que o ataque precisou

O ataque foi bem-sucedido por causa de quatro condições, cada uma mapeando para uma camada de defesa da pilha de visibilidade de agentes:⁸

1. Entrada não confiável processada como confiável. O título da issue veio de qualquer usuário anônimo do GitHub. O Claude Code o processou com a mesma autoridade de uma instrução de mantenedor. Defesa: classificação de fonte de entrada.

2. Permissões de ferramentas excessivamente amplas. O workflow de triagem concedia acesso ao Bash. A tarefa de triagem requeria apenas acesso Read aos metadados da issue e acesso Write para adicionar labels. A tarefa não precisava de Bash, mas o acesso ao Bash habilitou o comando npm install. Defesa: concessão de ferramentas com privilégio mínimo.

3. Estado compartilhado entre limites de confiança. A correção é uma linha em cada arquivo de workflow:

# Before: shared key (vulnerable)
key: ${{ runner.os }}-npm-${{ hashFiles('package-lock.json') }}

# After: workflow-scoped key
key: ${{ runner.os }}-npm-triage-${{ hashFiles('package-lock.json') }}

Defesa: chaves de cache separadas, isolamento de workflows.

1. Sem monitoramento de saída. O comando npm install realizou requisições de rede de saída para buscar o pacote malicioso. Nenhum monitoramento detectou o tráfego de saída inesperado de um workflow de triagem. Defesa: registro de requisições de saída, listas de domínios permitidos.

Por que segurança baseada em permissões é insuficiente

Todo sandbox e sistema de permissões discutido até agora opera no mesmo modelo: definir o que o agente pode fazer e verificar cada ação contra a definição. O modelo tem três fraquezas estruturais.

Permissões são concedidas a ferramentas, não a composições. O agente pode usar Bash. O agente pode usar web-fetch. O agente pode usar file-write. Cada permissão é individualmente razoável. Mas Bash + web-fetch + file-write, compostos em sequência, é uma primitiva de exfiltração. Nenhuma verificação de permissão no nível de ferramenta captura a composição. O ataque de exfiltração silenciosa opera inteiramente dentro das permissões de ferramentas concedidas.⁵

Agentes otimizam ao redor de restrições. A pesquisa de escape de sandbox demonstra que agentes tratam controles de segurança como obstáculos, não como limites. Quando a lista de bloqueio bloqueou um caminho, o agente encontrou um caminho alternativo. Quando o isolamento por namespace bloqueou o acesso, o agente tentou desativar o isolamento. O comportamento não é malícia. É a mesma resolução de problemas orientada a objetivos que torna os agentes úteis. Um agente instruído a “completar a tarefa” tratará um controle de segurança que impede a conclusão da tarefa como um problema a resolver.²

O escopo da permissão sobrevive ao contexto que a concedeu. O workflow de triagem de issues do Cline concedeu ao Claude Code acesso ao Bash para o propósito de triar issues. Esse mesmo acesso ao Bash foi suficiente para instalar pacotes npm arbitrários, executar scripts de preinstall e manipular o cache do GitHub Actions. Os mantenedores delimitaram a permissão a um propósito, mas não às ações que esse propósito requer. Permissões delimitadas por propósito requerem um mapeamento de “triar issues” para “ler metadados da issue, classificar, adicionar labels” que exclui “instalar pacotes de fontes não confiáveis”. Nenhum framework de agentes mainstream fornece esse mapeamento.¹

O projeto mcp-firewall aborda o problema de granularidade de permissões implementando políticas no nível de chamada de ferramenta em vez do nível de disponibilidade de ferramenta.⁶ Em vez de “o agente pode usar Bash”, a política especifica “o agente pode usar Bash para executar comandos git no diretório do projeto”. A melhoria de granularidade é significativa, mas insuficiente sozinha: o comando npm install do Clinejection pareceria uma etapa legítima de build para uma política de chamada de ferramenta que permite operações npm.

Como é o enforcement no nível do kernel

A pesquisa de escape de sandbox propõe enforcement no nível do kernel. Meu sistema em produção implementa uma versão disso usando o Seatbelt do macOS (sandbox-exec), um framework de controle de acesso obrigatório no nível do kernel que restringe toda a árvore de processos gerada pelo agente.⁷

A arquitetura difere do bubblewrap de três formas:

Enforcement na árvore de processos. As restrições do Seatbelt se aplicam ao processo do agente e a todo processo filho que ele gera. Se o agente executa bash -c "python3 script.py", o processo Python herda o perfil Seatbelt do processo bash, que o herdou do processo do agente. A restrição se propaga independentemente do mecanismo de geração de processos.⁷

Regras de bloqueio no nível de caminho. O perfil bloqueia acesso de leitura e escrita a caminhos específicos do sistema de arquivos: ~/.ssh, ~/.gnupg, ~/.aws, qualquer arquivo .env e um arquivo de credenciais. O bloqueio opera na camada VFS do kernel, não na camada de correspondência por string. /proc/self/root/home/user/.ssh/id_rsa resolve pelo VFS para o mesmo inode que ~/.ssh/id_rsa, e o perfil Seatbelt bloqueia o acesso ao inode, não à string do caminho.⁷

Imutável da perspectiva do agente. O perfil Seatbelt é carregado pelo sistema de hooks na inicialização do agente. O agente não pode modificar o sistema de hooks porque hooks são lidos do settings.json na inicialização do CLI, antes de o agente receber controle. O agente não pode desativar seu próprio sandbox pela mesma razão que você não pode deletar o boot loader de dentro do sistema operacional que ele carregou: o mecanismo de enforcement roda em um contexto de confiança mais alto do que o código que ele restringe.⁷

O perfil em si tem 20 linhas de sintaxe Seatbelt:

(version 1)
(allow default)

;; Block writes to credential paths
(deny file-write* (subpath "/Users/me/.ssh"))
(deny file-write* (subpath "/Users/me/.gnupg"))
(deny file-write* (subpath "/Users/me/.aws"))
(deny file-write* (subpath "/Users/me/.config/gh"))
(deny file-write* (literal "/Users/me/.env"))
(deny file-write* (regex #"/Users/me/\.env\."))
(deny file-write* (subpath "/Users/me/Library/Keychains"))

O hook envolve cada comando Bash: sandbox-exec -f claude-sandbox.sb /bin/sh command.sh. Executei o sandbox em modo dry-run (registrar violações mas não bloquear) por uma semana antes de aplicar o enforcement. 31 testes verificam que o sandbox captura tentativas de ler caminhos bloqueados, escrever neles e que operações legítimas (git, python, edição de arquivos no diretório do projeto) passam normalmente. A sobrecarga é de aproximadamente 2ms por comando.⁷

A abordagem Seatbelt aborda dois dos três níveis de escape de sandbox:

O bypass do linker dinâmico é a questão em aberto. O Seatbelt deveria bloqueá-lo porque a regra de bloqueio opera sobre acesso a arquivos, e o linker dinâmico precisa ler o arquivo binário antes de mapeá-lo na memória. Mas “deveria” não é evidência. Testar esse caminho de ataque específico contra o perfil Seatbelt é um item de verificação pendente.⁷

A pilha de defesa

Segurança eficaz de agentes não é um mecanismo único. É uma pilha em camadas onde cada camada aborda um modo de falha diferente. Nenhuma camada única é suficiente. Juntas, elas cobrem a superfície de ataque conhecida.

A pilha é ordenada por ponto de enforcement: entrada, permissão, execução, saída, estado, publicação. Cada camada captura o que a camada anterior deixou passar. A sanitização de entrada captura a injeção de prompt. Se a injeção passa, o escopo de permissões impede que o agente execute o comando injetado. Se o comando executa, o sandbox no kernel impede acesso a recursos sensíveis. Se o agente permanece dentro dos recursos autorizados, o monitoramento de saída captura os dados saindo. Se os dados permanecem dentro do sistema, o isolamento de estado impede contaminação entre workflows. Se a contaminação ocorre, o firewall de saída impede a publicação.

Nenhuma camada é perfeita. O Clinejection passaria pelo sandbox no kernel porque o ataque não violou nenhum sandbox. O ataque falharia no escopo de permissões (Bash não é necessário para triagem) ou no isolamento de estado (chaves de cache separadas). A defesa que captura o ataque depende de qual camada aborda a condição específica que o ataque explora.

Principais conclusões

Para equipes de DevOps e mantenedores de CI: - Audite cada workflow que processa entrada não confiável (issues, PRs, comentários) em busca de chaves de cache compartilhadas. Níveis de confiança diferentes requerem namespaces de cache diferentes. - Remova permissões de Bash e Write de workflows de triagem. Classificação de issues precisa de acesso Read a metadados e acesso Write para adicionar labels, nada mais.

Para desenvolvedores de agentes: - Classifique fontes de entrada antes que o agente as processe. Conteúdo de usuários anônimos recebe acesso somente Read. Código do repositório recebe o conjunto completo de permissões. - Implemente permissões delimitadas por propósito: mapeie tipos de tarefa para o conjunto mínimo de ferramentas que cada tarefa requer, não o máximo disponível.

Para equipes de segurança: - Implante enforcement no nível do kernel (Seatbelt no macOS, seccomp no Linux) como backstop atrás dos controles no nível de aplicação. A sobrecarga de 2ms é desprezível; a proteção contra aliasing de caminho e desativação de sandbox é absoluta. - Monitore a saída: uma lista de 12 domínios permitidos e registro por requisição captura exfiltração que nenhuma verificação de permissão detecta.

O que você pode implementar hoje

Três hooks que abordam os modos de falha de maior impacto:

1. Classificação de fonte de entrada (aborda o Clinejection). Antes que o agente processe qualquer entrada externa, classifique seu nível de confiança. Títulos de issues de usuários anônimos não são confiáveis. Código do repositório é confiável. Respostas de API são semi-confiáveis. A classificação determina quais ferramentas o agente pode usar ao processar essa entrada. Entrada não confiável recebe somente Read. Entrada confiável recebe o conjunto completo de permissões.

2. Bloqueio de sistema de arquivos no nível do kernel (aborda escape de sandbox). Envolva cada chamada da ferramenta Bash em sandbox-exec (macOS) ou um perfil seccomp (Linux). Bloqueie acesso a caminhos de credenciais (~/.ssh, ~/.aws, ~/.gnupg, .env). A sobrecarga é desprezível (2ms) e a proteção é absoluta: o agente não pode acessar caminhos bloqueados independentemente do comando shell que constrói, dos subprocessos que gera ou dos aliases de caminho que descobre.⁷

3. Lista de domínios permitidos para saída (aborda exfiltração silenciosa). Antes de cada requisição HTTP de saída, verifique o destino contra uma lista de domínios aprovados. Registre todas as requisições, aprovadas ou negadas. O registro cria uma trilha de auditoria; a lista de permitidos impede exfiltração para endpoints controlados pelo invasor. Uma lista de 12 domínios cobre os serviços que um agente de programação legitimamente precisa (GitHub, npm, PyPI, sites de documentação). Qualquer coisa fora da lista é suspeita por padrão.⁵

Cada hook tem de 10 a 30 linhas de script shell. Cada um dispara automaticamente em toda chamada de ferramenta relevante. Juntos, eles abordam as três classes de ataque demonstradas em 2026: injeção de prompt por entrada não confiável, escape de sandbox por manipulação de caminho e exfiltração de dados por requisições de saída autorizadas.

O invasor do Cline precisou de uma issue no GitHub e três horas. O próximo ataque usará o mesmo playbook contra um repositório que executa triagem com IA usando permissões padrão, caches compartilhados e sem monitoramento de saída. A questão não é se o seu sandbox vai aguentar. Três esforços de pesquisa independentes em 2026 provaram que não vai. A questão é o que captura o ataque quando o sandbox falha.

Perguntas frequentes

Como o Clinejection é diferente de um ataque de supply chain normal?

Ataques tradicionais de supply chain comprometem a máquina ou as credenciais de um desenvolvedor. O Clinejection comprometeu o pipeline de CI por meio do agente de IA que processa entrada de usuários não confiáveis. O invasor nunca teve acesso ao repositório, nunca comprometeu credenciais e nunca explorou uma vulnerabilidade no sistema de build. O ataque usou o agente de IA como ponte da entrada não confiável (título da issue) para a infraestrutura confiável (pipeline de release) via cache compartilhado.¹

Isso significa que triagem de issues com IA é inerentemente perigosa?

Não inerentemente, mas as configurações padrão atuais são perigosas. Executar o Claude Code com acesso ao Bash em cada issue aberta por qualquer usuário é equivalente a executar código arbitrário de contribuidores anônimos. Agentes de triagem precisam de acesso Read a metadados de issues e acesso Write para adicionar labels. Eles não precisam de Bash, web-fetch ou qualquer ferramenta que possa modificar o ambiente de build.¹

E quanto a containers e VMs para sandboxing?

Containers e VMs fornecem isolamento mais forte que sandboxes no nível de processo, mas introduzem latência (100ms+ de cold start) e complexidade (gerenciamento de imagens, montagem de volumes, configuração de rede). Para sessões interativas de agentes que invocam mais de 50 ferramentas por sessão, a latência se acumula. A abordagem no nível do kernel (Seatbelt, seccomp, Veto) fornece enforcement sem a sobrecarga porque opera dentro do modelo de processos existente.⁷

Um agente pode contornar o Seatbelt?

O Seatbelt é um framework de controle de acesso obrigatório aplicado pelo kernel do macOS. Contorná-lo requer um exploit de kernel. O agente roda em userspace. Ele não pode modificar o estado do kernel. No entanto, o Seatbelt tem um escopo mais restrito que um container completo: ele restringe acesso a arquivos e execução de processos, mas não restringe acesso à rede no mesmo grau. Combinar o Seatbelt com um monitor de saída cobre ambas as superfícies.⁷

Como isso se relaciona com o framework de segurança de agentes de IA do NIST?

Meu comentário público ao NIST argumentou que ameaças de agentes são comportamentais, não arquiteturais. As falhas de sandbox documentadas aqui reforçam esse argumento: os escapes de agentes são comportamentais (o agente raciocina sobre contornar restrições) e o ataque mais danoso (Clinejection) é inteiramente comportamental (ações autorizadas compostas em resultados não autorizados). Os frameworks existentes do NIST (CSF 2.0, SP 800-53, AI RMF) não abordam composição comportamental como uma classe de ameaça.⁹