Docker Sandboxes – Sandboxes descartáveis e isoladas para agentes de IA
O novo recurso Sandboxes do Docker tem como objetivo executar agentes de codificação de IA dentro de microVMs descartáveis, com firewalls de saída e injeção de credenciais, para que ferramentas não confiáveis não possam acessar livremente a máquina ou os segredos de um desenvolvedor. Os comentaristas acolhem o isolamento mais forte do que contêineres tradicionais, mas criticam fortemente o login obrigatório no Docker, a ferramenta de código fechado e o suporte limitado a Linux, argumentando que isso mina a confiança e a viabilidade de longo prazo. Muitos apontam para um ecossistema crescente de sandboxes open source baseadas em VMs e contêineres, com alguns preferindo “vibecodear” suas próprias soluções adaptadas a fluxos de trabalho e modelos de ameaça específicos.
O que os Docker Sandboxes realmente são
- Vários comentaristas esclarecem que isto não é uma configuração comum de contêiner Docker.
- Cada agente/sessão é executado em uma microVM (estilo libkrun, com seu próprio kernel) sobre o hipervisor do host (Hypervisor.framework, WHP, KVM).
- Oferece isolamento mais forte do que contêineres simples e permite que o agente execute Docker dentro da sandbox sem comprometer o host.
Modelo de segurança: VMs vs contêineres vs sandboxes do SO
- Muitos argumentam que agentes de IA não confiáveis não devem compartilhar um kernel com o host; VMs/microVMs são preferíveis a contêineres baseados em cgroups.
- Outros contrapõem que contêineres sem privilégios são “bons o suficiente” para a maioria dos desenvolvedores, e fugas geralmente envolvem 0-days e configurações ruins.
- Alguns usam defesas em camadas: VM + contêineres dentro + firewalls de saída + mounts limitados.
- Há uma discussão ativa sobre bubblewrap, nono, gVisor, libkrun, Kata Containers, Incus/LXC, Flatpak, etc., como primitivas alternativas de sandboxing.
Exigência de login, código fechado e governança
- O login obrigatório no Docker para uma ferramenta de desenvolvimento local é amplamente desaprovado.
- Alguns veem isso como uma UX “lixo” e temem futuros paywalls/limites ou mudanças bruscas.
- Há um produto empresarial de “AI Governance” para impor centralmente políticas de sandbox.
Injeção de credenciais e controles de rede
- A injeção de credenciais na fronteira do proxy (segredos armazenados no keychain do host, injetados apenas para hostnames/headers correspondentes) é vista como um recurso de destaque.
- Há debate sobre quão robusto isso é contra tentativas engenhosas de exfiltração; alguns se preocupam com formas de refletir segredos de volta para o agente.
- Firewalls de saída / políticas de rede deny-by-default são valorizados; algumas alternativas implementam controles semelhantes.
Suporte a Linux e lacunas de plataforma
- Há confusão e frustração em torno do suporte a Linux: a página de marketing inicialmente o omitiu, mas docs e artefatos de release indicam que Ubuntu e algumas distribuições baseadas em RPM são suportados.
- Alguns reclamam que ele não está amplamente disponível em todas as distribuições ou arquiteturas Linux.
Alternativas DIY e open source
- Um grande número de usuários construiu suas próprias sandboxes (QEMU/KVM, microVMs estilo Firecracker, Incus, devcontainers, bubblewrap, Apple Container, Tart, podman+libkrun, etc.).
- Muitos linkam para projetos OSS que oferecem agentes baseados em microVM, proxies de credenciais, firewalls de saída ou melhor DX.
- Vários dizem preferir investir em configurações abertas e sob seu próprio controle em vez de uma ferramenta proprietária com login obrigatório.