Modo YOLO sem entregar meu computador a um agente de IA

Um contêiner de desenvolvimento convencional é útil para empacotar dependências, mas não constitui automaticamente uma barreira de segurança robusta.

O atalho mais comum é montar o socket do Docker do host dentro do contêiner para que uma ferramenta possa criar e executar outros contêineres. Na prática, isso dá à ferramenta controle sobre o daemon do Docker no host. No caso de um agente autônomo, essa abordagem compromete boa parte do isolamento pretendido.

O recurso Docker Sandboxes adota outra abordagem. Cada sandbox é executada dentro de uma microVM com ambiente Linux, sistema de arquivos, rede e Docker Engine próprios.

Nesse ambiente, o agente pode:

• instalar pacotes com sudo
• criar imagens
• iniciar contêineres
• executar o Docker Compose
• modificar o próprio ambiente de desenvolvimento

Tudo isso sem que o agente tenha acesso ao daemon do Docker no host nem a arquivos fora do espaço de trabalho que decidi compartilhar.

A proposta não é impedir que o agente cause qualquer dano. É fazer com que o alcance de eventuais danos seja menor e mais fácil de entender.

O recurso Docker Sandboxes oferece duas formas úteis de compartilhar um projeto.

Modo direto

O projeto é montado com permissão de leitura e gravação. As alterações feitas pelo agente aparecem imediatamente na minha cópia de trabalho local. Uso esse modo no desenvolvimento do dia a dia porque o agente e eu podemos trabalhar nos mesmos arquivos.

A contrapartida é clara: o repositório continua ao alcance do agente.

Modo clone

O modo clone oferece uma barreira mais robusta para trabalhar com agentes que ainda não testei, fazer experimentos destrutivos ou executar tarefas em paralelo. O repositório do host é montado em modo somente leitura, enquanto o agente trabalha em um clone privado dentro da sandbox. As alterações só são incorporadas à cópia de trabalho local quando eu as trago de volta explicitamente.

O modo clone protege o repositório contra alterações, não contra inspeção. Os arquivos do repositório, inclusive aqueles ignorados pelo Git, ainda podem ficar visíveis por meio da montagem somente leitura. Por isso, os segredos devem permanecer fora do espaço de trabalho.

Uma sandbox vazia resolve o problema do isolamento, mas não o da configuração.

Eu não queria que toda sessão nova começasse com uma longa explicação sobre quais bibliotecas nativas o projeto requer, quais versões das ferramentas o build exige ou como configurar o ambiente de modelos locais.

O recurso Docker Sandboxes oferece configurações de projeto reutilizáveis chamadas kits. O kit do meu projeto registra as ferramentas e o ambiente de que o agente precisa, incluindo:

• dependências nativas de compilação
• ferramentas de desenvolvimento Rust
• dependências para testes em navegadores
• variáveis de ambiente
• o acesso à rede necessário durante a configuração

A configuração exata importa menos do que o princípio: o conhecimento necessário para preparar o ambiente fica registrado junto ao projeto, em vez de precisar ser reconstruído de memória.

Um agente de IA pode esboçar um spec.yaml específico para o projeto inspecionando o repositório e perguntando sobre o que não consegue deduzir: pacotes do sistema, comandos de build e teste, serviços em segundo plano, acesso à rede, portas e credenciais gerenciadas pelo host.

Em uma aplicação web, isso pode incluir o Playwright e um navegador headless dentro da sandbox, permitindo que o agente renderize páginas, execute testes de ponta a ponta e faça capturas de tela para revisão visual. Se o agente e o modelo escolhidos aceitarem imagens como entrada, o agente também poderá analisar essas capturas. Ainda assim, o arquivo gerado precisa ser revisado e validado com sbx kit validate.

Também serve como histórico de problemas e soluções

A primeira versão do kit era bem menor. O kit cresceu sempre que a realidade contrariou alguma suposição.

Uma das versões substituía a variável PATH, em vez de acrescentar novos caminhos a ela. Isso removia caminhos adicionados pelo runtime da sandbox e impedia que o agente de programação iniciasse corretamente.

Outra versão definia RUSTFLAGS globalmente. Sem querer, isso substituía uma flag específica do projeto, usada na CI para excluir testes que fazem requisições reais a provedores de modelos.

Esses problemas poderiam ter ficado perdidos no histórico do shell ou em anotações pessoais. Em vez disso, hoje as correções acompanham a configuração e ajudam a explicar por que ela é assim.

Esse é o verdadeiro valor do kit. Ele não se limita a instalar software. Ele transforma o conhecimento sobre o ambiente em código do projeto, que pode ser revisado, versionado e aprimorado.

No desenvolvimento do dia a dia, crio uma sandbox nomeada usando o kit do projeto:

# Outros agentes compatíveis: claude, gemini e opencode.
sbx run codex \
  --name aitopus \
  --kit ./sandbox/aitopus/

Esse comando usa a montagem direta do projeto, portanto as edições do agente aparecem na minha árvore de trabalho.

Quando preciso de uma barreira mais robusta, posso criar uma sandbox separada no modo clone:

sbx run --clone --no-share-skills codex \
  --name aitopus-review \
  --kit ./sandbox/aitopus/

A configuração inicial pode ser demorada, pois o ambiente inclui toolchains nativas, binários de navegadores e dependências de compilação. A vantagem é que o estado da sandbox e os caches de compilação persistem entre as sessões.

Depois da configuração inicial, posso me reconectar à sandbox nomeada em vez de reconstruir o ambiente do zero.

Um agente de programação ainda precisa da internet. Talvez precise acessar o provedor do modelo, registros de pacotes, repositórios de código-fonte e artefatos de release.

Em sessões mais sensíveis, começo com uma política de rede restritiva e libero apenas os serviços necessários para o agente e para o build.

O proxy de credenciais do Docker Sandboxes permite manter as credenciais compatíveis no host e incluí-las apenas nas requisições aprovadas. Isso é preferível a copiar uma chave de API de longa duração para a sandbox e depois esquecer onde ela foi armazenada.

Os controles de rede ainda têm limitações. Um serviço autorizado pode receber informações que o agente enviar a ele. Restringir os destinos reduz a exposição; isso não significa que toda requisição de saída seja apropriada.

Uma sandbox limita o acesso, mas não garante que o código esteja correto. Reviso o trabalho do agente como revisaria uma pull request de origem não confiável.

• Correção do código. O agente ainda pode introduzir uma dependência vulnerável, interpretar um requisito de maneira equivocada ou produzir código que passa nos testes, mas contraria o design pretendido.
• Efeitos no host. No modo direto, o agente pode modificar mais do que os arquivos de código-fonte comuns. Hooks do Git, workflows de CI, tarefas da IDE, scripts de build e configurações do agente podem executar código posteriormente no host.
• Alterações no repositório. O modo clone impede gravações diretas na cópia de trabalho do host, mas tudo o que for trazido de volta ainda precisa ser revisado.
• Plataformas-alvo. Uma sandbox Linux é um ambiente de trabalho mais seguro e consistente, não uma prova de que a aplicação final funciona corretamente em todas as plataformas-alvo.

As solicitações de permissão são úteis quando não existe uma barreira mais robusta. Mas não substituem uma barreira bem projetada.

Dentro de uma microVM dedicada, o agente pode trabalhar com ampla liberdade. Pode instalar compiladores, modificar pacotes, criar contêineres e passar por um ciclo completo de depuração sem esperar pela minha aprovação depois de cada comando.

Opto por dar ao agente acesso ao repositório do projeto. Não dou acesso ao daemon do Docker no host, a arquivos não relacionados ao projeto nem acesso irrestrito ao restante da minha máquina.

Essa abordagem não é apenas mais segura. Ela também aumenta a produtividade.

Gasto menos energia aprovando ações rotineiras, menos tempo corrigindo toolchains locais e menos espaço nos prompts para explicar o ambiente de desenvolvimento. O agente ganha liberdade suficiente para trabalhar; eu fico com um limite claro e verificável.

O mesmo princípio se aplica à IA local: escolher onde o processamento acontece, decidir quais informações podem atravessar a barreira e manter todo o resto sob controle local.

Essa é a versão do modo YOLO com a qual me sinto confortável:

não a confiança cega em um agente, mas a tranquilidade de saber que escolhi onde as consequências dos erros dele podem recair.

Observação: os kits do Docker Sandboxes ainda são experimentais. Consulte a documentação atual antes de depender de comandos ou campos de configuração específicos em um fluxo de trabalho de produção.