ai-jail
Melhor caso de uso: Desenvolvedor que roda agentes no modo sem confirmação e quer proteger a pasta pessoal e as credenciais.
Vantagens
- Open source, feito para agentes de código (Claude Code, Codex, opencode etc.)
- No Linux combina bubblewrap, Landlock e seccomp; no macOS usa sandbox-exec
- Projeto gravável, pasta pessoal em tmpfs e chaves e tokens fora de alcance
- Desde a v1.16 (jul/2026) não passa o socket do Docker por padrão
Desvantagens
- Projeto de uma pessoa, com comunidade pequena
- Com --docker ligado, o agente volta a ter acesso equivalente a root no host
| Custo | Gratuito (open source) |
|---|
| Facilidade | Alta |
|---|
| Segurança | Boa para o uso diário; depende de não liberar opções como --docker |
|---|
| Privacidade | Alta, roda localmente |
|---|
| Uso local | Sim |
|---|
| Uso corporativo | Possível em estações de desenvolvedor Linux/macOS |
|---|
Ponto de atenção: Snapshot e backup continuam necessários: o sandbox protege o resto do sistema, não o próprio projeto.
Sandbox nativo (Claude Code / Codex CLI)
Melhor caso de uso: Time que usa uma única ferramenta de agente e quer uma proteção padrão sem ferramenta extra.
Vantagens
- Já vem na ferramenta, sem instalar nada além de dependências do sistema
- Claude Code: Seatbelt no macOS, bubblewrap no Linux/WSL2, com isolamento de arquivos e de rede
- Codex CLI: modos read-only, workspace-write e danger-full-access, com Landlock e seccomp no Linux
Desvantagens
- No Claude Code o sandbox cobre os comandos de shell; servidores MCP e hooks ficam de fora, salvo com o sandbox-runtime (beta)
- Cada ferramenta tem regras próprias, o que complica padronizar num time que usa várias
| Custo | Incluso na ferramenta |
|---|
| Facilidade | Alta |
|---|
| Segurança | Boa para comandos de shell; confira o que fica fora do isolamento |
|---|
| Privacidade | Alta, roda localmente |
|---|
| Uso local | Sim |
|---|
| Uso corporativo | Configurável por política gerenciada nas versões corporativas |
|---|
Ponto de atenção: O modo de acesso total (danger-full-access ou pular permissões) desliga a proteção; não use fora de um ambiente descartável.
Docker / devcontainer
Melhor caso de uso: Projetos que já usam devcontainer e querem o agente no mesmo ambiente do desenvolvedor.
Vantagens
- Ambiente reproduzível e descartável, que o time já conhece
- Fácil de integrar com VS Code e com CI
Desvantagens
- Compartilha o kernel do host: falha no kernel ou no runtime pode escapar
- Montar /var/run/docker.sock dentro do container dá ao agente acesso equivalente a root no host
- Pastas montadas do host (ex.: ~/.ssh, ~/.aws) ficam expostas ao agente
| Custo | Gratuito (Docker Desktop tem licença paga para empresas grandes) |
|---|
| Facilidade | Média |
|---|
| Segurança | Boa se o container rodar sem privilégio, sem socket do Docker e com poucas pastas montadas |
|---|
| Privacidade | Alta, roda localmente |
|---|
| Uso local | Sim |
|---|
| Uso corporativo | Muito comum |
|---|
Ponto de atenção: Revise o docker-compose e o devcontainer.json: um único volume ou socket montado desfaz o isolamento.
VM descartável
Melhor caso de uso: Analisar repositório de terceiro desconhecido ou rodar agente com permissões amplas.
Vantagens
- Isolamento mais forte: kernel próprio
- Snapshot da VM inteira antes de cada sessão
Desvantagens
- Mais pesada e lenta de preparar
- Sincronizar código e credenciais de teste dá mais trabalho
| Custo | Gratuito localmente (KVM, VirtualBox) ou custo de nuvem |
|---|
| Facilidade | Baixa |
|---|
| Segurança | A mais alta das opções |
|---|
| Privacidade | Alta se local; depende do provedor se em nuvem |
|---|
| Uso local | Sim |
|---|
| Uso corporativo | Comum em times de segurança e para código não confiável |
|---|
Ponto de atenção: Não copie credenciais reais para a VM; use contas e tokens de teste.