Docker lança Sandboxes para isolar agentes de IA com microVMs

Tecnologia

Docker apresenta uma nova solução para melhorar a segurança e o isolamento de agentes de IA usando microVMs dedicadas.

Leia também: Aviator lança sistema que redefine revisão de código

Docker Sandboxes surge como a nova aposta da Docker para isolar agentes autônomos de IA em ambientes de desenvolvimento, ao criar microVMs dedicadas com kernel Linux próprio e estado persistente, em contraste com os containers tradicionais que seguem compartilhando o kernel do host.

O que muda entre containers e Docker Sandboxes

Na base, containers continuam sendo processos isolados que rodam sobre o mesmo kernel da máquina — ou da VM criada pelo Docker Desktop em sistemas como Windows e macOS. Eles usam namespaces para dar a cada processo uma visão própria de sistema de arquivos, processos e rede, e cgroups para limitar CPU, memória e I/O. Essa arquitetura, consolidada há mais de uma década, garante inicialização quase instantânea, alta densidade e pouco consumo de recursos.

Docker Sandboxes, por outro lado, não são apenas “mais um tipo de container”. Cada sandbox é uma microVM com seu próprio kernel Linux, sistema de arquivos e pilha de rede isolados, além de um Docker Engine privado. Dentro dela, o agente de IA atua com privilégios de sudo, como se estivesse em um laptop de desenvolvimento: pode instalar pacotes, iniciar serviços, subir bancos de dados, construir imagens, rodar aplicações completas com Docker Compose e preservar tudo isso entre sessões.

Mark Cavage, presidente da Docker, resumiu o momento ao afirmar na keynote do WeAreDevelopers que “containers estão fazendo exatamente o trabalho para o qual foram projetados, mas estamos pedindo que eles façam um trabalho diferente”. Na visão dele, esse “trabalho diferente” é justamente servir de ambiente completo e mutável para agentes autônomos de IA — algo para o qual o modelo clássico de container não foi pensado.

Por que agentes de IA expõem limites dos containers

Em workloads tradicionais, um container nasce a partir de uma imagem com dependências já conhecidas, executa um serviço ou tarefa pontual e, ao terminar, pode ser descartado e recriado sem prejuízo. O estado que precisa sobreviver é explicitamente colocado em volumes ou em serviços externos.

Agentes autônomos de IA que programam sozinhos trabalham de outro jeito. A sessão desses agentes se parece com a tarde de um desenvolvedor: clonam repositórios, instalam bibliotecas, sobem PostgreSQL ou outros bancos, rodam migrações, constroem imagens, lançam aplicações, leem logs, ajustam o código e repetem o ciclo por horas. Cada etapa depende do que a anterior deixou para trás.

Num container tradicional, boa parte desse estado se perde quando o processo é reiniciado ou a imagem é recriada, a menos que tudo seja cuidadosamente mapeado em volumes — o que não combina com a natureza exploratória e imprevisível de um agente. Além disso, o compartilhamento do kernel do host define um limite de segurança mais frágil para workloads que executam código gerado em tempo real, potencialmente malicioso ou simplesmente errado.

Box by ASCII, responsável por um dos projetos que inspiraram o desenho das sandboxes, descreve assim o novo modelo: “A sandbox é usada do jeito que um desenvolvedor usa um laptop, então a sandbox tem que se comportar como um”.

Segurança: do kernel compartilhado à microVM descartável

Na prática, o ponto de ruptura entre containers e Docker Sandboxes está no tipo de fronteira de isolamento. Em Linux, um container depende do kernel compartilhado para fazer valer seu “muro” de segurança. Escapar desse limite exige, em geral, explorar falhas no kernel ou em canais laterais — não é trivial, mas, uma vez dentro, o invasor está no mesmo kernel que sustenta todos os processos e, em muitos casos, tem acesso a credenciais e volumes montados.

O risco cresce quando o container recebe acesso ao socket do Docker (/var/run/docker.sock) para construir imagens ou orquestrar outros containers. Esse padrão é comum em pipelines de CI, ferramentas de observabilidade e cenários de “Docker dentro do Docker”. Para um agente de IA que vasculha ativamente o ambiente — e executa comandos derivados de arquivos, páginas da web e descrições de ferramentas —, esse tipo de brecha vira um atalho para chegar ao host, sem precisar de vulnerabilidade inédita.

Com Docker Sandboxes, cada agente roda dentro de uma microVM com hypervisor, atrás de um kernel próprio. Se o agente escapar de um container interno, ele cai apenas na microVM, considerada descartável; basta apagar a sandbox e criar outra. O host permanece fora de alcance, assim como outras sandboxes rodando na mesma máquina, já que cada uma tem sua própria microVM e seu próprio Docker Engine.

Nesse modelo, o agente fala apenas com o Docker Engine interno, que aceita comandos para criar containers, construir imagens e subir stacks, sem expor o daemon do host. A comunicação com o exterior fica limitada ao que o usuário decidir montar ou liberar: workspace, destinos de rede, servidores MCP e outras “skills”.

Estado persistente e ferramenta sbx facilitam adoção

Um dos pontos centrais das sandboxes é a persistência de estado. Tudo o que o agente fizer dentro da microVM — da instalação de pacotes ao provisionamento de bancos de dados — continua lá na próxima retomada, até que a sandbox seja removida. Isso aproxima a experiência daquilo que um desenvolvedor espera de uma máquina própria, só que com a vantagem de poder ser descartada e recriada de forma controlada.

Para simplificar o dia a dia, a Docker oferece o sbx, CLI das Docker Sandboxes. Com um único comando, o usuário cria e inicia a sandbox, incluindo o agente. Depois, pode pausar, retomar e voltar exatamente ao ponto em que a sessão parou. A gestão de múltiplas sandboxes passa a ser tão simples quanto lidar com containers no fluxo atual.

A empresa argumenta que esse desenho dá aos agentes a “autoridade de uma máquina inteira”, mas circunscrita por uma fronteira que eles não conseguem alterar ou ampliar de dentro para fora. O objetivo é conter o impacto de erros graves — como o já relatado caso de um agente que apagou um banco de dados de produção após interpretar mal uma instrução — e de comandos maliciosos escondidos em READMEs, issues ou descrições de ferramentas.

Entenda o contexto

Por mais de uma década, o ecossistema em torno de containers se consolidou como padrão na indústria de software. Ferramentas de orquestração, registries, scanners de imagens e pipelines de integração contínua passaram a tratar o container como unidade básica de deploy, principalmente para serviços de backend, APIs e jobs pontuais.

Quando agentes de IA começaram a assumir tarefas de desenvolvimento e operação de sistemas, a solução intuitiva foi colocá-los dentro de containers comuns. Mas, na prática, esses agentes se comportam mais como usuários do que como serviços: mudam o ambiente em tempo real, instalam e removem dependências, mexem em arquivos de configuração e rodam códigos que ninguém revisou. Esse novo tipo de workload expôs que o modelo tradicional de isolamento não foi desenhado para um ator que tenta, por definição, empurrar os limites do próprio ambiente.

Impactos para desenvolvimento de software e DevOps

A introdução das Docker Sandboxes tende a redesenhar parte das estratégias de infraestrutura para times que já estão testando ou operando agentes autônomos de IA em escala. A mensagem de Mark Cavage é que containers continuam ‘no lugar certo’ quando se trata de isolar aplicações: microserviços, APIs, workers, testes e execuções rápidas seguem melhor atendidos pelo modelo atual, leve e amplamente suportado.

Ao mesmo tempo, workloads em que o agente de IA atua como desenvolvedor — com sessões longas, múltiplos serviços auxiliares, manipulação de estado local e código pouco previsível — passam a ser candidatos naturais ao uso de sandboxes. Setores que usam IA para automação de pipelines, refatoração massiva de código, manutenção contínua de bases legadas e operações complexas devem se beneficiar de uma camada extra de segurança operacional, sem abrir mão da flexibilidade do ambiente de desenvolvimento.

Em ambientes multi-plataforma, incluindo Linux, Windows e macOS com Docker Desktop, a mudança também é relevante. Hoje, mesmo nesses sistemas, containers Linux rodam dentro de uma única VM, compartilhando o mesmo kernel. As sandboxes criam um nível adicional de separação ao oferecer microVMs independentes para cada agente, o que pode reduzir o raio de impacto de falhas e ataques.

A tendência, avaliam desenvolvedores que já experimentam a tecnologia, é que se estabeleça uma divisão mais clara: containers tradicionais para serviços e tarefas previsíveis; Docker Sandboxes para agentes autônomos de IA que exigem isolamento completo, privilégios elevados e preservação de estado de longo prazo. Com isso, ferramentas como o sbx devem ganhar protagonismo nos próximos meses, à medida que plataformas de desenvolvimento e orquestração de workloads de IA integrem esse novo tipo de unidade de execução aos seus fluxos padrão.