Como Isolar Agentes de IA com Segurança sem Docker Cloud

A Docker anunciou recentemente o Cloud Sandboxes, um recurso pensado para resolver uma dor de cabeça imediata: rodar agentes de IA autônomos para programar sem deixar que eles destruam o sistema operacional da sua máquina. A proposta parece ótima no papel. Você roda agentes locais dentro de ambientes virtuais leves gerenciados pelo Docker Desktop e, quando seu notebook começa a ferver ou ficar sem memória RAM, você desvia esses sandboxes direto para o Docker Cloud.

O agente roda isolado dentro de uma microVM, executa comandos arbitrários no terminal, edita arquivos de código e sincroniza o resultado. Só que, ao olhar de perto os detalhes técnicos, as limitações aparecem na hora. O Docker Desktop atua como o único intermediário, a opção para escalar o uso empurra você para assinaturas pagas do Docker Cloud e servidores Linux sem interface gráfica (headless) — justamente as máquinas bare-metal e os servidores de homelab onde rodamos tarefas contínuas — foram deixados de fora.

Se você mantém um homelab ou infraestrutura de servidores própria, não precisa do Docker Cloud para isolar agentes de IA com segurança. Dá para construir exatamente o mesmo nível de isolamento direto no seu Linux usando virtualização de código aberto e regras básicas de firewall.

---

Por que containers padrão não são seguros para agentes de IA

A maioria dos desenvolvedores começa colocando o agente dentro de um container Docker comum, usando o runtime padrão runc. Essa configuração traz uma falsa sensação de segurança.

Containers compartilham o mesmo kernel do sistema operacional host. O isolamento depende inteiramente dos grupos de controle (cgroups) e namespaces do Linux. Pense nos cgroups e namespaces como divisórias de gesso em um escritório: elas evitam que alguém olhe a tela do vizinho sem querer, mas não impedem ninguém de derrubar a parede com um chute. Esse modelo funciona bem para serviços web confiáveis que já conhecemos, como Nginx ou PostgreSQL. Mas a história muda completamente quando damos a um modelo de linguagem (LLM) acesso livre ao terminal para baixar pacotes de terceiros, compilar extensões em C desconhecidas e rodar código arbitrário.

text Container OCI padrão (runc): [ Processo do Agente ] -> [ Namespaces / cgroups do Linux ] -> [ Kernel compartilhado do Host ] -> [ Hardware ] ▲ Exploit de kernel = Comprometimento do Host

Isolamento via MicroVM (Firecracker / Kata): [ Processo do Agente ] -> [ SO Guest / Kernel Guest ] -> [ Hipervisor (KVM) ] -> [ Hardware ] ▲ Fronteira física: o Guest não enxerga o Kernel do Host

Existem três problemas graves que tornam containers comuns perigosos para fluxos de trabalho com agentes autônomos:

1. Exploits de Kernel: se o agente executar um script que explore uma vulnerabilidade no kernel (como uma falha de escalonamento local de privilégios), ele escapa direto para o sistema host. Como o container divide o kernel com a máquina física, comprometer esse kernel dá ao agente permissões de root sobre todo o servidor.
2. Vazamento de Syscalls e Dispositivos: containers padrão expõem centenas de chamadas de sistema (syscalls) do Linux diretamente ao processo. A menos que você gaste horas configurando e mantendo perfis restritos de seccomp, o agente tem terreno de sobra para vasculhar falhas de montagem e arquivos desprotegidos em /sys ou /proc.
3. Varredura da Rede Local: por padrão, a rede em modo bridge do Docker permite que o container acerte em cheio a sua rede local (LAN). Um agente capaz de rodar curl, nmap ou abrir conexões via raw sockets consegue conversar com qualquer dispositivo que o seu host alcance.

As microVMs aceleradas por hardware — como as viabilizadas por Linux KVM, AWS Firecracker ou Kata Containers — eliminam o problema no kernel entregando ao agente o seu próprio kernel Linux dedicado e enxuto. O agente pode causar um kernel panic no sistema convidado, apagar a pasta / inteira ou travar a máquina com um fork-bomb acidental. O kernel do host continua totalmente protegido do outro lado da barreira do hipervisor.

---

O perigo invisível: invasão da rede local no homelab

Mesmo que um agente não consiga quebrar a barreira do kernel, ele ainda pode invadir sua rede interna.

Quando um agente autônomo roda comandos como npm install, pip install ou clona um repositório público, códigos de terceiros entram em execução imediata na sua máquina por meio de scripts de configuração e hooks de build. A rede padrão do Docker cria uma interface bridge virtual que roteia o tráfego de saída diretamente pelo gateway principal do seu host.

Se o agente tentar escanear a faixa 192.168.1.0/24, seu servidor vai encaminhar esses pacotes de bom grado para a sua rede doméstica ou da empresa. Uma dependência maliciosa ou um agente confuso que comece a alucinar pode disparar requisições contra o seu storage NAS, tentar abrir a interface web do roteador ou cutucar a API de um cluster Proxmox local.

Para rodar agentes com tranquilidade, o hipervisor ou runtime de containers precisa aplicar regras rígidas de saída de rede que bloqueiem o tráfego destinado a faixas privadas (RFC 1918), mantendo aberto apenas o acesso aos repositórios públicos de pacotes na internet.

---

Comparativo de arquitetura

---

Requisitos mínimos de hardware

Antes de subir microVMs isoladas em um servidor Linux headless, confirme se o hardware atende a estes requisitos básicos por sandbox ativo:

• Processador: pelo menos 2 vCPUs dedicadas com extensões de virtualização ativadas na BIOS/UEFI (vmx para Intel, svm para AMD).
• Memória RAM: 4 GB no mínimo. Suba para 8 GB se o agente for compilar dependências em Node.js com módulos em C++, compilar projetos em Rust ou rodar instâncias do Chromium headless para scraping.
• Armazenamento: 20 GB de espaço em disco (formato sparse) em uma partição ext4 ou ZFS.
• Kernel: Linux 6.x ou superior com o módulo KVM carregado.

Rode estes dois comandos para validar o suporte à virtualização na sua CPU e checar se o usuário tem permissão para acessar o dispositivo KVM:

# Verifica se as flags de virtualização existem no processador
egrep -c '(vmx|svm)' /proc/cpuinfo

# Verifica as permissões do dispositivo KVM
ls -la /dev/kvm
# Saída esperada: crw-rw---- 1 root kvm ...

Se o primeiro comando retornar 0, reinicie a máquina, entre na BIOS/UEFI e ative o Intel VT-x ou AMD SVM. Se o arquivo /dev/kvm não existir, carregue o módulo do kernel manualmente:

sudo modprobe kvm
sudo modprobe kvm_intel  # Para processadores Intel
# ou: sudo modprobe kvm_amd    # Para processadores AMD

---

Criando um sandbox isolado no Linux sem interface gráfica

Você não precisa do Docker Desktop para rodar sandboxes em microVMs. Dá para montar um ambiente totalmente isolado usando o Kata Containers integrado ao daemon do Docker que você já usa.

O Kata Containers atua como um runtime OCI alternativo. Quando o Docker inicia um container apontado para o Kata, ele não cria simples namespaces no Linux host. Em vez disso, ele sobe uma máquina virtual ultraleve usando QEMU ou Cloud-Hypervisor, carrega um kernel convidado enxuto e executa a imagem do container dentro dessa VM. Para o Docker, tudo se comporta como um container comum. Para o sistema operacional do host, trata-se de uma microVM isolada por hardware.

Veja o passo a passo para configurar o runtime e blindar a rede em um servidor Debian ou Ubuntu.

Passo 1: Instalar o runtime do Kata Containers

Instale os pacotes necessários diretamente dos repositórios da sua distribuição:

# Atualiza os índices de pacotes e instala o Kata
sudo apt-get update
sudo apt-get install -y kata-containers

# Valida se a CPU e o kernel suportam as microVMs do Kata
sudo kata-runtime kata-check

O utilitário kata-check analisa as extensões de virtualização, valida as opções do kernel e testa o acesso ao /dev/kvm. Se tudo passar nos testes, registre o Kata como runtime no Docker.

Crie ou edite o arquivo /etc/docker/daemon.json adicionando a seguinte definição:

{
  "runtimes": {
    "kata-qemu": {
      "path": "/usr/bin/kata-runtime"
    }
  }
}

Recarregue as configurações do systemd e reinicie o serviço do Docker para aplicar a alteração:

sudo systemctl daemon-reload
sudo systemctl restart docker

A partir de agora, passar a flag --runtime=kata-qemu nos seus comandos comuns de docker run força o Docker a inicializar o container dentro de sua própria microVM isolada.

Passo 2: Blindar a rede bloqueando faixas RFC 1918

O isolamento por microVM protege o kernel do host, mas o tráfego de rede continua passando pela interface bridge. Como vimos, a rede bridge padrão do Docker aceita pacotes em direção à sua rede local.

Crie uma rede bridge exclusiva com uma sub-rede fixa e nome de interface previsível:

docker network create \
  --driver bridge \
  --opt "com.docker.network.bridge.name"="br-agent" \
  --subnet 172.28.0.0/16 \
  agent-sandbox-net

Agora, vamos aplicar regras no iptables para isolar essa interface bridge. Nosso objetivo com essas regras é:

1. Permitir respostas a conexões já estabelecidas que voltam para o sandbox.
2. Liberar requisições DNS (porta 53) exclusivamente para servidores públicos.
3. Liberar conexões de saída web padrão (80 e 443) para o agente baixar pacotes e ler documentações.
4. Bloquear qualquer pacote com destino a redes locais privadas definidas pela RFC 1918 (10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16).

Execute as regras de firewall:

# 1. Permite conexões ativas e relacionadas voltarem para o container
sudo iptables -I FORWARD 1 -m state --state RELATED,ESTABLISHED -j ACCEPT

# 2. Permite resolução de DNS (UDP 53) para fora
sudo iptables -I FORWARD 2 -i br-agent -p udp --dport 53 -j ACCEPT

# 3. Permite tráfego HTTP (TCP 80) e HTTPS (TCP 443) para a internet
sudo iptables -I FORWARD 3 -i br-agent -p tcp -m multiport --dports 80,443 -j ACCEPT

# 4. Bloqueia explicitamente pacotes para faixas privadas (RFC 1918)
sudo iptables -I FORWARD 4 -i br-agent -d 10.0.0.0/8 -j DROP
sudo iptables -I FORWARD 5 -i br-agent -d 172.16.0.0/12 -j DROP
sudo iptables -I FORWARD 6 -i br-agent -d 192.168.0.0/16 -j DROP

# 5. Bloqueia qualquer outro tráfego de saída originado na interface do agente
sudo iptables -I FORWARD 7 -i br-agent -j DROP

Como o parâmetro iptables -I insere as regras no topo da tabela, a numeração sequencial (1 a 7) garante que essas condições sejam avaliadas antes de qualquer regra padrão de roteamento do Docker encaminhar tráfego para a sua rede local.

Passo 3: Executar o agente sem medo

Com o Kata registrado e o firewall configurado, podemos iniciar o workspace do agente.

Crie uma pasta no host para persistir os arquivos do projeto e inicie o container. O comando abaixo sobe o ambiente dentro da microVM, conecta na rede filtrada, define o DNS da Cloudflare, limita o uso de hardware e abre um terminal interativo:

# Cria o diretório do projeto no host
mkdir -p /var/sandboxes/workspace-1

# Inicia o container isolado do agente
docker run -it --rm \
  --runtime=kata-qemu \
  --net agent-sandbox-net \
  --dns 1.1.1.1 \
  --cpus 2.0 \
  --memory 4g \
  --pids-limit 200 \
  --name ai-agent-worker \
  -v /var/sandboxes/workspace-1:/workspace \
  -w /workspace \
  node:20-bookworm /bin/bash

Entenda o papel de cada parâmetro de contenção:

• --runtime=kata-qemu: inicializa o container em uma microVM QEMU dedicada, acelerada por KVM.
• --net agent-sandbox-net: conecta o container à nossa bridge blindada pelo firewall.
• --dns 1.1.1.1: sobrescreve a configuração de DNS do host para evitar que requisições tentem acessar um resolvedor local interno (como um Pi-hole da sua rede).
• --pids-limit 200: bloqueia fork-bombs ou processos descontrolados de esgotarem a tabela de processos do sistema.
• --cpus 2.0 e --memory 4g: impede que rotinas pesadas de build consumam todos os recursos do host.

Faça um teste de dentro do terminal do container para checar o funcionamento dos limites:

# Teste 1: Acesso a repositórios públicos deve funcionar normalmente
curl -I https://registry.npmjs.org
# HTTP/2 200 ...

# Teste 2: Consultas ao IP do seu roteador local devem expirar ou falhar
curl -m 2 http://192.168.1.1
# curl: (28) Connection timed out after 2001 milliseconds

O agente ganha privilégios totais de root dentro do próprio ambiente virtualizado, mas não tem como tocar no kernel do host nem bisbilhotar outros aparelhos da sua rede local.

---

Erros comuns e como evitá-los

Ao criar camadas manuais de isolamento, pequenos deslizes na configuração podem quebrar ferramentas de build ou deixar o host exposto. Fique atento a estes três pontos:

1. Resolução de DNS quebrada em resolvers locais

Em muitas redes domésticas ou de pequenos escritórios, o DHCP distribui o IP do próprio roteador, de um Pi-hole ou de um container com AdGuard Home (como 192.168.1.5) como servidor DNS primário.

Se o seu sandbox herdar o /etc/resolv.conf padrão do host, ele tentará usar esse IP privado. No momento em que nosso firewall descarta pacotes destinados à faixa 192.168.0.0/16, a resolução de nomes morre por completo. O agente vai reclamar dizendo que não consegue encontrar domínios como github.com ou registry.npmjs.org. Para evitar esse problema, passe sempre um DNS público com --dns 1.1.1.1 ou --dns 8.8.8.8 ao criar o container.

2. Discos cheios sem aviso no sistema host

Ferramentas de desenvolvimento modernas consomem espaço em disco de forma voraz. Um único fluxo de trabalho que instale pacotes npm, compile dependências pesadas em Rust e gere logs de debug pode facilmente criar dezenas de gigabytes nas pastas node_modules ou target.

Se você montar uma pasta do seu sistema raiz (/) direto no container sem limites de cota, um agente em loop pode lotar completamente o disco do servidor. Quando o Linux fica com 0% de espaço livre na partição raiz, serviços travam e o sistema para de registrar logs.

Para mitigar o risco, monte o workspace em um dataset ZFS com limite rígido:

# Cria um dataset no ZFS limitado a 20GB
sudo zfs create -o quota=20G zpool-data/sandboxes/workspace-1

Se você utiliza partições ext4 tradicionais, crie um arquivo de imagem sparse, formate-o e monte-o na pasta do projeto:

# Cria um arquivo esparso de 20GB
dd if=/dev/zero of=/var/sandboxes/workspace-1.img bs=1M count=0 seek=20480

# Formata o arquivo em ext4
mkfs.ext4 /var/sandboxes/workspace-1.img

# Monta o arquivo como dispositivo de loop no diretório do sandbox
mount -o loop /var/sandboxes/workspace-1.img /var/sandboxes/workspace-1

Se o agente perder o controle, ele vai esbarrar no limite de 20 GB do disco virtual e receber o erro "No space left on device", mantendo o sistema operacional principal intacto.

3. O Out-Of-Memory (OOM) Killer do Linux

Ao configurar o parâmetro --memory no container, lembre-se de que microVMs precisam de uma pequena fatia de memória para rodar seu próprio kernel convidado e processos essenciais (normalmente entre 120 MB e 250 MB).

Se você limitar o container a 1 GB ou 2 GB de RAM e pedir para o agente compilar um projeto em TypeScript complexo, o kernel da microVM vai acionar o OOM Killer. O processo simplesmente fecha com código de erro 137, sem maiores explicações. Mantenha pelo menos 4 GB de memória reservados para sandboxes que executem compiladores e runtimes de linguagens de programação.

---

Perguntas frequentes

Qual é a diferença entre o Docker Cloud Sandbox e containers normais?

Containers Docker comuns compartilham o mesmo kernel do host e usam isolamento puramente lógico via software (namespaces e cgroups). O Docker Cloud Sandbox roda processos dentro de microVMs reais isoladas por hardware, com kernel próprio, impedindo que falhas de escape de container cheguem ao sistema operacional principal.

É possível rodar o Docker Sandboxes no Linux sem interface gráfica e sem o Docker Desktop?

Não. A solução oficial de Sandboxes da Docker depende dos binários inclusos no Docker Desktop (disponível para macOS e Windows) ou da infraestrutura em nuvem mantida pela empresa. A Docker não disponibiliza esse orquestrador de microVMs como um daemon nativo independente para servidores Linux headless.

Quais alternativas self-hosted substituem o Docker Cloud Sandboxes para agentes de IA?

Você consegue o mesmo resultado integrando o Kata Containers com Docker ou Podman. Isso empacota imagens OCI normais dentro de máquinas virtuais KVM instantâneas. Para projetos que demandam controle direto de VMs sem o Docker, ferramentas como AWS Firecracker ou instâncias descartáveis no Proxmox oferecem ambientes seguros e rápidos em hardware próprio.

Como bloquear o acesso de agentes de IA autônomos à minha rede local (homelab)?

Crie uma rede bridge dedicada para o container e use regras de iptables ou nftables no host para rejeitar qualquer tráfego que tente alcançar as faixas privadas da RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Mantenha abertas apenas as portas de saída TCP 80 e 443 para a internet e configure um DNS público como 1.1.1.1 para que o container instale dependências sem fazer consultas na sua rede interna.

---

Veredito

O Docker Cloud Sandboxes traz um fluxo visual prático para desenvolvedores que já usam o Docker Desktop em notebooks pessoais. Por outro lado, enviar seus fluxos de trabalho com agentes para a nuvem da Docker cria dependência de um ecossistema fechado, gera custos variáveis e deixa o poder de fogo do seu próprio servidor ocioso.

Se você tem uma máquina rodando Linux ou um homelab ativo, adote o Kata Containers sobre o KVM e defina algumas regras no firewall. Você terá o mesmo isolamento seguro a nível de hardware, manterá seus arquivos e código dentro de casa e não precisará pagar nada a mais por isso na sua fatura de nuvem.

Artigos relacionados neste cluster

• /en/posts/cursor-xai-vs-local-llms-privacy-guide-for-homelabs/
• /en/posts/docker-sandbox-kit-securing-ai-agent-container-isolation/
• /en/posts/docker-sandbox-kit-spec-v3-hardening-ai-agent-containers/

Relacionados neste cluster

• /pt/posts/como-isolar-agentes-ia-docker-sandbox/
• /pt/posts/como-isolar-agentes-ia-docker/
• /pt/posts/como-isolar-containers-docker-seguranca/