A Docker apresentou o Docker Sandboxes, uma solução criada para aumentar a segurança e o isolamento de agentes autônomos de inteligência artificial em ambientes de desenvolvimento. A tecnologia utiliza microVMs dedicadas, com kernel Linux próprio, sistema de arquivos e rede isolados, além de um Docker Engine privado e estado persistente.
A proposta surge como alternativa aos containers tradicionais, que continuam sendo processos isolados executados sobre o mesmo kernel do host — ou da máquina virtual usada pelo Docker Desktop em sistemas como Windows e macOS. Essa arquitetura utiliza namespaces para oferecer a cada processo uma visão própria do sistema de arquivos, dos processos e da rede, além de cgroups para limitar o uso de CPU, memória e I/O. Consolidado há mais de uma década, o modelo permite inicialização rápida, alta densidade e baixo consumo de recursos.
As Docker Sandboxes, porém, não são apenas um novo tipo de container. Cada sandbox funciona como uma microVM com kernel Linux, sistema de arquivos, rede e Docker Engine próprios. Dentro desse ambiente, o agente de IA pode operar com privilégios de sudo, como faria em um laptop de desenvolvimento: instalar pacotes, iniciar serviços, criar bancos de dados, construir imagens, executar aplicações com Docker Compose e preservar essas alterações entre sessões.
Mark Cavage, presidente da Docker, afirmou durante a keynote do evento WeAreDevelopers que os containers “estão fazendo exatamente o trabalho para o qual foram projetados, mas estamos pedindo que eles façam um trabalho diferente”. Segundo ele, esse novo uso consiste em transformar o container em um ambiente completo e mutável para agentes autônomos de IA, algo para o qual o modelo tradicional não foi concebido.
Em workloads convencionais, um container é criado a partir de uma imagem com dependências conhecidas, executa um serviço ou uma tarefa específica e pode ser descartado ao final. Os dados que precisam permanecer são armazenados explicitamente em volumes ou serviços externos.
Agentes autônomos de IA que programam sozinhos operam de maneira diferente. Suas sessões podem se assemelhar à rotina de um desenvolvedor: eles clonam repositórios, instalam bibliotecas, iniciam bancos como PostgreSQL, executam migrações, constroem imagens, lançam aplicações, analisam logs, modificam o código e repetem o processo por horas. Cada etapa depende do estado deixado pelas anteriores.
Em um container tradicional, parte desse estado pode ser perdida quando o processo é reiniciado ou a imagem é recriada, a menos que os dados sejam cuidadosamente mapeados em volumes. Essa exigência nem sempre combina com o comportamento exploratório e imprevisível de um agente. Além disso, o compartilhamento do kernel do host cria uma fronteira de segurança mais limitada para workloads que executam código gerado em tempo real, potencialmente malicioso ou simplesmente incorreto.
A Box by ASCII, responsável por um dos projetos que inspiraram o desenho das sandboxes, resume o conceito afirmando que “a sandbox é usada do jeito que um desenvolvedor usa um laptop, então a sandbox tem que se comportar como um”.
A principal diferença entre containers e Docker Sandboxes está no tipo de isolamento. No Linux, um container depende do kernel compartilhado para sustentar sua separação. A violação desse limite geralmente exige a exploração de falhas no kernel ou de canais laterais. Embora não seja uma tarefa simples, um invasor que consiga ultrapassá-lo chega ao mesmo kernel que sustenta os demais processos e, em determinadas configurações, pode alcançar credenciais e volumes montados.
O risco aumenta quando o container recebe acesso ao socket do Docker, localizado normalmente em /var/run/docker.sock, para construir imagens ou orquestrar outros containers. Esse padrão aparece em pipelines de integração contínua, ferramentas de observabilidade e cenários conhecidos como “Docker dentro do Docker”. Para um agente de IA que examina ativamente o ambiente e executa comandos derivados de arquivos, páginas da web e descrições de ferramentas, essa exposição pode criar um caminho até o host sem a necessidade de uma vulnerabilidade inédita.
Com as Docker Sandboxes, cada agente é executado dentro de uma microVM protegida por um hypervisor e com kernel próprio. Caso o agente escape de um container interno, ele permanece dentro da microVM. A sandbox pode então ser apagada e recriada. O host e as demais sandboxes da máquina ficam separados, pois cada ambiente possui sua própria microVM e seu próprio Docker Engine.
Nesse modelo, o agente se comunica apenas com o Docker Engine interno, que recebe comandos para criar containers, construir imagens e iniciar stacks, sem expor o daemon do host. A comunicação externa fica limitada aos recursos que o usuário decidir montar ou liberar, como workspace, destinos de rede, servidores MCP e outras “skills”.
A persistência de estado é um dos principais recursos das sandboxes. Tudo o que o agente fizer dentro da microVM, desde a instalação de pacotes até o provisionamento de bancos de dados, permanece disponível na retomada seguinte, até que o ambiente seja removido. A experiência se aproxima da utilização de uma máquina própria, mas com a possibilidade de descartar e recriar o ambiente de forma controlada.
Para facilitar o uso, a Docker oferece o sbx, uma interface de linha de comando para as Docker Sandboxes. Com um único comando, o usuário pode criar e iniciar uma sandbox, incluindo o agente. Também é possível pausar, retomar e voltar ao ponto em que a sessão foi interrompida. A administração de múltiplas sandboxes passa a seguir uma lógica semelhante à gestão de containers.
A Docker afirma que o modelo concede aos agentes a “autoridade de uma máquina inteira”, mas dentro de uma fronteira que eles não conseguem alterar ou ampliar de dentro para fora. O objetivo é reduzir o impacto de erros graves, como o caso já relatado de um agente que apagou um banco de dados de produção após interpretar uma instrução de forma equivocada, além de comandos maliciosos ocultos em arquivos README, issues ou descrições de ferramentas.
Durante mais de uma década, os containers se consolidaram 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 tratá-los como unidades básicas de implantação, principalmente para serviços de backend, APIs e tarefas pontuais.
Quando agentes de IA começaram a assumir atividades de desenvolvimento e operação, uma alternativa inicial foi colocá-los em containers comuns. Na prática, porém, esses agentes se comportam mais como usuários do que como serviços: alteram o ambiente em tempo real, instalam e removem dependências, modificam arquivos de configuração e executam códigos que não foram revisados. Esse tipo de workload evidenciou que o isolamento tradicional não foi projetado para um ator que, por definição, tenta ampliar os limites do próprio ambiente.
A introdução das Docker Sandboxes pode alterar estratégias de infraestrutura de equipes que já testam ou operam agentes autônomos de IA em escala. Segundo a Docker, os containers continuam adequados para aplicações, microserviços, APIs, workers, testes e execuções rápidas, por serem leves e amplamente compatíveis.
Já os workloads em que o agente atua como desenvolvedor — com sessões longas, vários serviços auxiliares, manipulação de estado local e código pouco previsível — são candidatos ao uso de sandboxes. Setores que empregam IA para automação de pipelines, refatoração em larga escala, manutenção contínua de sistemas legados e operações complexas podem obter uma camada adicional de segurança operacional sem perder a flexibilidade de um ambiente de desenvolvimento.
A mudança também é relevante em ambientes multiplataforma, incluindo Linux, Windows e macOS com Docker Desktop. Atualmente, mesmo nesses sistemas, os containers Linux são executados dentro de uma única máquina virtual e compartilham o mesmo kernel. As sandboxes acrescentam um nível de separação ao oferecer microVMs independentes para cada agente, o que pode reduzir o impacto de falhas e ataques.
A tendência apontada por desenvolvedores que já experimentam a tecnologia é uma divisão mais clara: containers tradicionais para serviços e tarefas previsíveis; Docker Sandboxes para agentes autônomos de IA que precisam de isolamento ampliado, privilégios elevados e preservação de estado por longos períodos. Com isso, ferramentas como o sbx podem ganhar espaço nos próximos meses, à medida que plataformas de desenvolvimento e orquestração de workloads de IA incorporem esse novo tipo de unidade de execução aos fluxos de trabalho.
Fonte: Miraí Broadcast