Seu agente de IA tem acesso root ao seu PC. Você sabia disso?

Quando você roda o Claude Code, o Codex ou o Copilot CLI no seu terminal, o agente opera com as mesmas permissões que o seu usuário. Ele lê seus arquivos, instala pacotes, executa scripts arbitrários e, se quiser, faz um rm -rf na sua home. A maioria dos devs simplesmente aceita isso porque “confia na IA”. Mas confiança não é um modelo de segurança.

O Docker percebeu esse buraco e lançou o Docker Sandboxes (CLI: sbx), uma ferramenta que joga cada agente de IA dentro de uma microVM descartável, com kernel próprio, filesystem isolado e daemon Docker independente. Tudo isso sem precisar do Docker Desktop rodando.

Eu testei, fuçei a arquitetura e vou contar por que isso muda a forma como a gente trabalha com agentes de código.

O problema real: containers não bastam

“Mas eu já rodo meu agente num container Docker!” Sim, e isso é melhor que nada. Só que containers compartilham o kernel do host. Uma vulnerabilidade de escape de container (e elas existem, vide CVE-2024-21626 do runc) pode dar acesso total à máquina host.

Para código que você escreveu, isso é aceitável. Você confia no que está rodando. Agora imagina um agente autônomo que:

• Baixa dependências de registros públicos
• Executa código gerado por um LLM que pode alucinar comandos destrutivos
• Roda com root dentro do container
• Pode spawnar novos containers internamente

O modelo de ameaça é completamente diferente. Você não sabe o que o agente vai fazer. Ele pode tentar montar o Docker socket do host, acessar credenciais em variáveis de ambiente, ou fazer requests para serviços internos da sua rede.

Containers isolam processos. MicroVMs isolam kernels inteiros. Essa é a diferença fundamental.

Como o Docker Sandboxes funciona por dentro

Cada sandbox é uma microVM leve com:

O ponto mais interessante da arquitetura é que o Docker não usou o Firecracker (o VMM da AWS que roda o Lambda). Por quê? Firecracker depende exclusivamente do KVM, que só existe no Linux. A base de usuários do Docker está pesadamente no macOS e no Windows.

Então a equipe do Docker construiu um VMM proprietário do zero. Um codebase único que integra nativamente com:

• Apple Hypervisor.framework no macOS
• Windows Hypervisor Platform (WHP) no Windows
• KVM no Linux

Isso significa que o sbx funciona em qualquer sistema operacional sem gambiarras.

Boot em milissegundos

Uma microVM do Docker Sandboxes sobe em aproximadamente 125ms com menos de 5 MiB de overhead de memória. Para comparação:

O sweet spot aqui é claro: isolamento no nível de VM com performance quase de container.

Na prática: o sbx CLI

O sbx é uma CLI standalone. Você não precisa do Docker Desktop instalado. Instala via Homebrew no macOS, via WinGet no Windows:

# macOS
brew install docker/tap/sbx

# Windows
winget install -h Docker.sbx

Depois de instalar, faz login com sua conta Docker:

sbx login

E pronto. Para rodar o Claude Code dentro de uma sandbox:

sbx run claude

Isso cria uma microVM, clona seu repositório para dentro dela e inicia o Claude Code com acesso apenas ao filesystem da sandbox. Quando o agente terminar, você descarta tudo.

Comandos essenciais

# Listar sandboxes ativas
sbx ls

# Rodar agente numa branch específica (cria worktree)
sbx run claude --branch feature/nova-api

# Executar comando dentro de uma sandbox
sbx exec minha-sandbox -- ls -la /workspace

# Parar e remover
sbx stop minha-sandbox
sbx rm minha-sandbox

# Dashboard interativo (mostra CPU, RAM em tempo real)
sbx

Rodar sbx sem argumentos abre um dashboard interativo no terminal que mostra todas as sandboxes com uso de CPU e memória em tempo real. Dali você pode attach em agentes, abrir shells e gerenciar políticas de rede.

Políticas de rede: o firewall do seu agente

Na primeira vez que você roda o sbx, ele pergunta qual política de rede usar. São três níveis:

Open: tudo liberado, sem restrições. Bom para testes rápidos.

Balanced (recomendado): default-deny com allowlists curadas. Libera automaticamente:

• APIs de IA (api.anthropic.com, api.openai.com)
• Registros de pacotes (npmjs.org, pypi.org, crates.io)
• Repositórios de código (github.com, gitlab.com)
• Registros Docker (registry-1.docker.io)
• Provedores de cloud (AWS, GCP, Azure)

Locked Down: tudo bloqueado. Você libera domínio por domínio.

# Ver políticas atuais
sbx policy ls

# Liberar um domínio específico
sbx policy allow network registry.npmjs.org

# Resetar configuração de rede
sbx policy reset

O proxy de rede no host faz três coisas cruciais:

1. Bloqueia acesso ao localhost do host (o agente não alcança seus serviços locais)
2. Injeta headers de autenticação sem expor credenciais ao agente
3. Aplica regras de allow/deny por domínio e porta

Isso resolve um problema sério: quando o Claude Code precisa acessar a API da Anthropic, ele precisa de um token. Com o sbx, você configura o secret uma vez e o proxy injeta o header. O agente nunca vê a chave.

# Configurar secret do GitHub (injetado automaticamente)
sbx secret set -g github -t "$(gh auth token)"

Agentes suportados

O sbx suporta oito agentes nativamente:

E se seu agente favorito não está na lista, o modo Shell permite rodar qualquer coisa:

sbx run shell
# Dentro da sandbox, instale e rode o que quiser

Git integration: branch mode vs direct mode

O sbx oferece dois modos de trabalho com Git:

Direct Mode (padrão): o agente edita o working directory e commita direto no repositório. Simples, mas o agente tem acesso ao histórico completo do Git.

Branch Mode: cria um worktree isolado dentro de .sbx/:

sbx run claude --branch feature/refactor-auth

O worktree fica em .sbx/-worktrees//. O agente trabalha na branch sem tocar na sua branch atual. Quando terminar, você faz merge normalmente.

Dica: adicione .sbx/ ao seu .gitignore.

Sandbox Kits: infraestrutura como código para agentes

Sandbox Kits são specs em YAML que declaram tudo que uma sandbox precisa: ferramentas, variáveis de ambiente, credenciais, domínios de rede permitidos, arquivos injetados e comandos de startup.

# .sandbox-kit.yaml
name: backend-api
tools:
  - node@22
  - pnpm@9
  - docker-compose
env:
  DATABASE_URL: "postgresql://localhost:5432/dev"
  NODE_ENV: "development"
secrets:
  - github
  - npm
network:
  policy: balanced
  allow:
    - api.stripe.com:443
    - sentry.io:443
files:
  - source: ./config/dev.env
    target: /workspace/.env
startup:
  - pnpm install
  - docker-compose up -d postgres redis

Aplica com:

sbx run claude --kit .sandbox-kit.yaml

Isso é ouro para times. Você versiona o kit junto com o repositório e todo mundo (humano ou agente) roda no mesmo ambiente.

Quando usar Docker Sandboxes (e quando não usar)

Use quando:

• Agentes autônomos executam código que você não revisou
• O agente precisa de root (instalar pacotes, rodar containers)
• Você quer isolar credenciais do agente
• Múltiplos agentes rodam em paralelo no mesmo host
• Compliance exige isolamento de kernel (SOC2, HIPAA)

Não precisa quando:

• Você está usando o agente apenas para chat/perguntas (sem execução de código)
• O ambiente já é descartável (CI/CD efêmero)
• Overhead de ~125ms no boot importa (raro, mas possível em loops muito apertados)

Comparação com alternativas

O ecossistema de sandboxing para agentes de IA cresceu rápido em 2026. Veja como as opções se comparam:

O diferencial do Docker é claro: cross-platform com suporte nativo a agentes populares. Se você está no macOS (e a maioria dos devs está), Firecracker e gVisor nem são opção.

O elefante na sala: é proprietário

Sim, o VMM do Docker Sandboxes é closed-source. Isso incomoda? Deveria incomodar um pouco. Você está confiando a camada de isolamento de segurança a um componente que não pode ser auditado pela comunidade.

Por outro lado, o Docker tem um track record de décadas em infraestrutura de containers e a alternativa (rodar agentes sem sandbox nenhuma) é objetivamente pior.

Se você está em ambiente regulado e precisa de auditabilidade total, Firecracker + Linux é o caminho. Para o dev que quer proteger sua máquina de trabalho no dia a dia, o sbx resolve com praticidade.

Configurando memória e recursos

Por padrão, o sbx aloca 50% da RAM do host para a sandbox. Você pode customizar:

# Alocar 16GB de RAM para a sandbox
sbx run claude --memory 16g

# Limitar CPUs
sbx run claude --cpus 4

Para projetos grandes (monorepos, builds pesados), vale aumentar a memória. Para tarefas simples de code review, o padrão funciona bem.

Um fluxo real: PR review com sandbox

Vou mostrar como fica um fluxo prático de code review usando o Claude Code dentro de uma sandbox:

# 1. Cria sandbox na branch do PR
sbx run claude --branch feature/auth-refactor

# 2. Dentro da sandbox, o Claude:
#    - Lê o código
#    - Roda os testes
#    - Sugere mudanças
#    - Commita na branch

# 3. Fora da sandbox, você revisa e mergeia
git checkout feature/auth-refactor
git log --oneline -5
# Looks good? Merge.
git checkout main && git merge feature/auth-refactor

# 4. Descarta a sandbox
sbx rm minha-sandbox

O agente fez tudo que precisava sem nunca tocar no seu working directory principal. Se ele tivesse destruído algo, só a sandbox morreria.

Dicas de segurança para quem já usa sbx

Mesmo com microVM, existem boas práticas que valem a pena:

1. Use Balanced como política de rede padrão. O modo Open existe para conveniência, não para produção.
2. Nunca passe secrets como variáveis de ambiente. Use sbx secret set e deixe o proxy injetar.
3. Crie Sandbox Kits por projeto. Versione o .sandbox-kit.yaml junto com o código. Novos membros do time (e novos agentes) recebem o mesmo ambiente.
4. Use branch mode para PRs. O --branch cria um worktree isolado. Se o agente quebrar algo, sua branch principal fica intacta.
5. Monitore pelo dashboard. O sbx sem argumentos mostra CPU e RAM em tempo real. Se uma sandbox estiver consumindo demais, mate sem culpa: ela é descartável.
6. Revise antes de mergear. Sandbox não substitui code review. O agente pode gerar código funcional mas inseguro. A sandbox protege sua máquina, não sua codebase.

O futuro dos agentes é confinado

Toda semana aparece uma notícia nova de agente de IA que fez algo inesperado: deletou arquivos, fez requests para URLs maliciosas, instalou pacotes comprometidos. Com a adoção crescendo (o Claude Code já roda em milhões de terminais), a pergunta não é se um incidente sério vai acontecer, mas quando.

Docker Sandboxes não é a única solução, mas é a mais prática para quem já vive no ecossistema Docker. O sbx funciona no seu Mac, no seu Windows, não precisa de Docker Desktop, e em 125ms você tem uma VM completa pronta para o agente fazer o que quiser sem risco.

Se você está rodando agentes de IA sem sandbox, pelo menos agora você sabe que não precisa ser assim.

Fonte de inspiração: Docker Sandboxes (docker.com)