Introdução
Chegamos na era em que código virou commodity e agora queremos acelerar o desenvolvimento. Às vezes, a parte chata é ficar falando “sim” para o nosso amigo (🤖) executar um certo comando.
Meu Objetivo
Estou embarcando agora no conceito de AI First para desenvolvimento, não colocar mais a mão no código diretamente, mas operar agentes que codem por mim. Quero investir meu tempo na especificação e na definição do problema, não na implementação manual.
Quando eu executar uma tarefa, quero poder sair para almoçar e, ao voltar, o agente já ter feito o build, executado os testes, realizado o commit e aberto a PR, tudo isso sem que eu precise ficar aprovando cada comando manualmente.
O problema: seu Agent está solto no seu sistema
Aí você pensa assim:
Vou liberar o skip-permissions para tudo e vibe-codar como se não houvesse amanhã.
E se? Ele executa aquele famoso:
sudo rm -rf /
What if?
Fim! Caos instalado.
A imagem abaixo, iniciando a iteração com o Gemini-CLI, mostra claramente: NO SANDBOX.
A solução: Docker Sandbox para AI Agents
O conceito de sandbox muita gente já conhece, é aquela "caixinha isolada" onde você pode testar, executar e até fazer alguma besteira sem afetar sua máquina principal, seu servidor ou seu ambiente real.
Só que, quando falamos de AI Agents, esse isolamento deixa de ser apenas conveniente e passa a ser essencial. Afinal, um agente autônomo pode instalar pacotes, alterar arquivos, rodar comandos destrutivos, subir serviços e até executar Docker. Fazer isso direto na sua máquina é pedir para misturar produtividade com risco. Foi exatamente para resolver esse problema que surgiram os Docker Sandboxes, ambientes isolados, pensados para deixar agentes codarem com autonomia, mas sem acesso irrestrito ao host.
Mas afinal, o que é Docker Sandbox?
O Docker Sandbox é um ambiente isolado para execução de agentes de código, como o Codex ou Claude Code, criado para que eles possam trabalhar de forma mais livre e segura. A principal diferença é que cada sandbox roda dentro de uma microVM própria, com seu próprio kernel Linux, sua própria rede, seu próprio filesystem e até um Docker Engine isolado. Em outras palavras, o agente pode fazer build, instalar dependências, executar containers e modificar arquivos do projeto sem tocar diretamente na sua máquina hospedeira.
Na prática, ele foi desenhado para o cenário que os desenvolvedores querem atingir com agentes, você especifica a tarefa, deixa o agente trabalhar sozinho e volta depois para revisar o resultado, idealmente com build executado, testes rodados e mudanças prontas para commit ou PR. Esse é exatamente o tipo de fluxo que o Docker passou a associar ao uso de sandboxes em "modo autônomo".
Em 30 de janeiro de 2026, a Docker anunciou a “próxima evolução” do produto com isolamento por microVM. Em 31 de março de 2026, publicou o lançamento focado no uso autônomo de agents em “YOLO mode”, e em 16 de abril de 2026 detalhou a arquitetura por trás da solução.
Vale ler o artigo oficial publiado => Docker Sandboxes: Run Agents in YOLO Mode, Safely
Por que não usar somente o Docker?
Essa é a parte mais importante.
Um container Docker comum continua sendo isolado, mas ele compartilha o kernel do host. Já o Docker Sandbox coloca o agente dentro de uma microVM com kernel próprio, criando uma fronteira mais forte, via hypervisor. Segundo a documentação da Docker, essa é a principal barreira de confiança do sistema. O segredo é são as camadas de isolamento, hypervisor, rede, docker-engine, credenciais, não vou entrar em todos os detalhes, mas você pode conferir aqui => Isolation Layers.
Container comum foi feito para empacotar e executar aplicações. O Docker Sandbox foi feito para conter agentes autônomos com segurança.
Os 3 passos de instalação
Primeiro passo: instalar o Docker Sandbox. Conclua essa etapa no seu SO favorito. No macOS brew install docker/tap/sbx. No Windows, com winget install Docker.sbx. Ubuntu via pacote docker-sbx. Veja a doc ofifical de instalação => Acesse a documentação oficial
Acessei alguns outros artigos que estavam usando o CLI docker sandbox.Hoje a experiência principal está no CLI sbx, e a própria Docker informa que os comandos integrados ao Docker Desktop foram depreciados em favor desse CLI standalone.
Segundo passo, instale seu Agent de IA favorito:
npm install -g @google/gemini-cli
Obs.: Gemini não é o meu Agent favorito. Foi só a cobaia para escrever o artigo, porque neste momento tenho estudado sobre ele!
Terceiro passo: Rodar o agente dentro do sandbox dentro da pasta do seu projeto Python, Java, NextJS, Ruby… whatever.
cd my-beautiful-project
sbx run gemini
Repare que o campo sandbox agora é exibido como current process, indicando que a execução está acontecendo dentro de um ambiente isolado do processo principal, com restrições e controle sobre recursos e operações do sistema.
Agora posso continuar meu projeto SaaS, que irá se tornar uma startup unicórnio de um homem só, com toda a velocidade do mundo e com segurança 😎.
Duas considerações finais:
Até a publicação deste artigo, experimentei o Docker Sandbox com Gemini e Claude Code. Meu foco tem sido investir cada vez mais tempo na especificação dos projetos e menos na execução manual. Nesse cenário, o Sandbox resolveu um ponto essencial, eliminou a fricção das aprovações constantes e deixou o fluxo muito mais contínuo. Além disso, percebi um ganho de cerca de 50% na velocidade das implementações com Gemini, o que tornou a experiência significativamente mais fluida.
...
Não significa que vou abrir mão de revisão, critério ou responsabilidade técnica. Cada projeto exige um nível diferente de acompanhamento, em alguns, reviso tudo manualmente, em outros, reviso o trabalho já refinado pelo próprio Agent. O ponto central é que velocidade e segurança não precisam competir entre si. Com Agents operando em um ambiente isolado como o Docker Sandbox, fica muito mais viável acelerar a entrega sem perder controle do processo nem expor o host.
...
Ref..:
Top comments (0)