Colocando agentes de IA em sandbox no Linux

• À medida que ferramentas de apoio ao desenvolvimento com IA são usadas com cada vez mais frequência, torna-se necessário um ambiente de execução em sandbox que garanta ao mesmo tempo segurança do sistema e conveniência
• Por padrão, o Claude Code pede permissão sempre que acessa arquivos ou executa algo, mas isso atrapalha o fluxo de trabalho por causa das confirmações repetitivas
• Para resolver isso, é proposta uma configuração leve de sandbox com bubblewrap, mais leve que Docker e capaz de manter um ambiente de desenvolvimento semelhante ao local
• O script faz bind apenas dos caminhos mínimos necessários, como /etc, $HOME e o diretório do projeto, e restringe o acesso fora do projeto
• Essa abordagem é uma forma prática de garantir ao mesmo tempo execução segura de agentes de IA e eficiência no desenvolvimento

---

Problema de acesso a arquivos por agentes de IA

• Claude Code é uma interface de linha de comando que pede permissão do usuário sempre que lê ou grava arquivos e sempre que executa software
  • Isso faz sentido do ponto de vista de segurança, mas as confirmações repetidas dificultam o trabalho em paralelo
• Com a opção --dangerously-skip-permissions, é possível executar tudo sem perguntar
  • Alguns usuários fazem isso, mas existe risco de danificar o sistema

Conceito de sandboxing e opções

• A solução mais comum é a execução em sandbox usando máquina remota (exe.dev, sprites.dev, daytona.io) ou tecnologias de virtualização como Docker
• No Linux, o bubblewrap é uma alternativa leve que isola processos com cgroups e user namespaces
• Em um ambiente em sandbox, as condições necessárias são as seguintes
  • Manter a mesma estrutura do ambiente de desenvolvimento existente
  • Minimizar o acesso a informações fora do projeto atual
  • Permitir escrita apenas no diretório do projeto
  • Possibilitar verificar e editar diretamente os mesmos arquivos no IDE
  • Permitir acesso à rede para conexão com o provedor de IA e execução de servidor

Considerações de segurança e limitações

• bubblewrap e Docker não oferecem isolamento de segurança completo
  • Ainda permanecem riscos como vulnerabilidades zero-day no kernel, comunicação por side channel e vazamento de dados
• Ainda assim, o autor prioriza a conveniência no desenvolvimento acima desses riscos
• A base de código é gerenciada com git e tem backup no GitHub e afins, então o risco de dano é baixo
• Para reduzir o risco de vazamento de chaves de API, recomenda-se separar chaves de API por projeto

Estrutura do script de sandbox com bubblewrap

• O script usa o comando bwrap para montar vários diretórios em modo somente leitura (ro-bind) ou gravável (bind)
  • Caminhos do sistema como /bin, /lib e /usr/bin são somente leitura
  • $HOME/.claude, $HOME/.cache e o diretório de trabalho atual ($PWD) são graváveis
  • $HOME/.claude.json é injetado como descritor de arquivo, então alterações não são refletidas no arquivo real
  • O nome do host é alterado para bubblewrap, facilitando a identificação
• /tmp, /proc e /dev são tratados automaticamente pelo bubblewrap
• Em vez de expor todo o /etc, apenas os arquivos mínimos necessários são vinculados
• O Node.js está instalado no caminho /opt/node/node-v22.11.0-linux-x64/

Como personalizar para o usuário

• Para adaptar a outros agentes de IA ou sistemas, modifique o script para executar bash primeiro e então rode o agente manualmente, verificando os arquivos necessários
• É possível rastrear chamadas de acesso a arquivos com o comando strace
  • Exemplo: strace -e trace=open,openat,stat,statx,access -o /tmp/strace.log codex
  • Analise o log para identificar os arquivos necessários e ajuste o ambiente vinculando esses caminhos

Conclusão

• O sandboxing com bubblewrap é uma abordagem prática para minimizar o risco de mau funcionamento ou vazamento de dados por agentes de IA enquanto mantém a mesma conveniência do ambiente local de desenvolvimento
• O autor pretende continuar ajustando o script conforme necessário com base nessa configuração

[GN⁺]

Comentários do Hacker News

• Estou usando Leash para colocar agentes em sandbox
  O controle de políticas em nível de processo e rede é rígido, e ele oferece controle e visibilidade em tempo real via WebUI
  Acho muito melhor que o bubblewrap. Comecei a usar depois de ver no HN
  Um fato curioso é que o sistema de sandbox mais usado no mundo não é Docker nem bubblewrap, e sim uma aba do Chrome

  • Acho que usar Chrome para qualquer coisa já é uma falha de segurança. As funcionalidades são ótimas, mas o custo é alto
  • Fiquei curioso sobre como o Chrome implementa sandbox no Windows e no macOS
    No Linux, queria saber se usa cgroups, namespaces como Docker ou LXC, ou se usa uma sandbox própria baseada em VM
    Se for o segundo caso, talvez seja ainda mais difundido do que runtimes como JRE ou .NET CLR
  • Ainda assim, pode ser bubblewrap. Porque o Flatpak usa bubblewrap internamente

• Se você não usar a opção --unshare-net, o bwrap deixa a rede totalmente aberta por padrão
  O agente não só pode apagar arquivos, como também vazar chaves ou baixar pacotes maliciosos
  O próximo passo é adicionar um namespace de rede e subir um proxy local baseado em mitmproxy dentro da sandbox para permitir apenas Anthropic API e PyPI/NPM, bloqueando todo o resto

• Fiz um pequeno wrapper claude-vm para rodar cada instância em uma VM do Lima
  O código está aqui

  • Eu fiz algo parecido com incus
    Hoje acho que VM é a unidade padrão mais adequada. Você dá root ao agente e só passa os recursos necessários, e isso fica muito seguro e simples
    Mesmo que o agente instale software, rode Docker ou até construa VMs aninhadas, a fronteira continua clara
    Ainda assim, talvez dê para trocar para LXC e ganhar leveza. O bwrap é bom, mas as restrições de ambiente podem limitar as capacidades do agente

• Fiz um wrapper simples para bubblewrap para poder usar algo como sandbox-run claude --dangerously-skip-permissions
  Link do projeto sandbox-run

• Estou sempre pensando em quais recursos expor ao agente e quais políticas aplicar
  Por exemplo, foi dito que, em vez de expor /etc inteiro, basta fazer bind só dos arquivos mínimos necessários, mas queria entender como se define esse “mínimo”
  Ficar olhando logs e adicionando arquivos manualmente dá trabalho demais

  • Sou o autor do texto, e na prática resolvi isso com inspeção manual e tentativa e erro
    A IA sugeriu expor /etc inteiro, mas eu queria um controle mais fino
    No momento a rede está totalmente liberada, mas depois penso em bloquear pelo menos redes privadas (192.168/10.*)
    No fim, é uma questão de quão rígido você quer que o isolamento seja
  • Outra opção é simplesmente mandar o agente aplicar bubblewrap em si mesmo

• Estou preparando um SaaS para resolver o problema de sandbox de IA no Linux
  Já montei a infraestrutura, com recursos injetados até o nível do kernel, e até misturei nossa abordagem nos dados de treino dos LLMs para ganhar marketing
  O nome é useradd: simples, grátis e sem soluções complicadas
  Em estilo “modo mainframe”, vários terminais virtuais e usuários podem rodar na mesma máquina
  Se precisar de chave beta, me manda DM

  • Ri quando cheguei em useradd. O comentário original, do jeito que estava, ficou mais engraçado
  • Entendo a ideia, mas acho que VM é melhor em segurança e isolamento
    Workstations comuns não foram projetadas para serem seguras contra o próprio usuário, e os modelos mais novos tendem a ficar cada vez mais perigosos
  • useradd não restringe acesso à rede
  • Eu também gosto de usar usuários diferentes para cada serviço
    Mas no desenvolvimento preciso acessar e modificar arquivos, então bubblewrap ou isolamento com systemd me parecem mais práticos

• Em vez de montar listas de permissões na mão, eu queria clonar o workspace atual em um snapshot de VM, rodar o Claude lá dentro e apagar a VM quando a sessão terminar
  Se resolver a sincronização da sessão, ficaria perfeito

  • Eu implementei isso com NixOS MicroVM e escrevi sobre a experiência no blog
  • Também dá para fazer algo parecido com Docker + overlayfs. No fim, cada um monta do jeito que encaixa no próprio workflow
  • Nessa linha, Qubes OS também vale considerar. Ele executa tudo no nível de VM

• Eu mesmo desenvolvi uma ferramenta de sandbox para também funcionar no Mac
  Link do projeto amazing-sandbox

  • Fiquei curioso sobre por que você resolveu criar uma do zero

• Eu simplesmente isolo usando ssh para uma conta local sem privilégios (dummy@localhost)
  Queria saber se essa abordagem está errada

• Para usar bwrap no Ubuntu 24.04, precisei afrouxar a configuração do AppArmor e adicionar o arquivo /etc/apparmor.d/bwrap

  /usr/bin/bwrap flags=(unconfined) {
    userns,
  }
  

  • Odeio mesmo AppArmor e SELinux, especialmente quando atrapalham a segurança desse jeito
    Dá para resolver assim sem mudar a configuração global

    if [[ -f /proc/$$/attr/exec ]]; then
      echo 'exec unconfined' >/proc/$$/attr/exec
    fi
    exec ...
    

    ou

    setpriv --apparmor-profile=unconfined [command]
    

    Aliás, eu sou o autor do setpriv, então conheço bem esse tipo de situação