Como trancar o código de um agente de IA: subprocess, Docker e microVM — três níveis de proteção

Você deu ao agente uma ferramenta de «executar código Python» — e nesse momento passou a ter não apenas um assistente, mas execução remota de código, ainda que a pedido do modelo. O modelo pode errar, ou pode receber uma instrução nociva de uma página ou arquivo plantado. Por isso a pergunta não é «o agente é inteligente?», mas «o que um programa malicioso conseguirá alcançar quando for executado». Os autores da análise no Machine Learning Mastery respondem de forma prática: constroem três sandboxes e aplicam os mesmos ataques a cada uma.

Uma ferramenta, backends intercambiáveis

A arquitetura é simples. O agente conhece uma única ferramenta, run_python: ela recebe uma string com código e devolve stdout, stderr e o código de saída. O código do modelo nunca é executado dentro do processo do próprio agente. Ele vai para um objeto sandbox com o método run(code), e qualquer classe com esse método serve. Por isso, trocar o nível de isolamento não exige mexer na lógica do agente: troca-se o backend e pronto. Um código de retorno diferente de zero é marcado como erro, e o modelo vê isso e pode se corrigir.

Um princípio importante do blog da Docker, que os autores aplicam a todos os níveis: o acesso a arquivos, a política de rede e os segredos são definidos pela infraestrutura antes de o agente iniciar, e não pelo próprio agente.

Três fronteiras

Subprocess é a opção mais leve. É um processo filho com limites de tempo de CPU, memória (espaço de endereçamento) e tamanho dos arquivos que pode gravar. Em torno dele:

• execução em modo isolado python -I em uma pasta temporária;
• ambiente limpo, sem chaves de API nem diretório home;
• unshare --net, ou seja, uma rede privada vazia;
• saída em arquivos, de modo que o limite de tamanho de arquivo também protege contra uma enxurrada de print;
• ao estourar o timeout, todo o grupo de processos é encerrado.

Se o construtor não consegue ativar o isolamento de rede, ele falha com um erro em vez de deixar a rede aberta em silêncio. Quando executado como root, o código é primeiro rebaixado para o usuário nobody.

Mas este nível traz uma ressalva honesta: o kernel e o sistema de arquivos continuam sendo os do host. O código roda em seu nome, no seu sistema de arquivos, e não esconde os seus arquivos. O limite de número de processos conta todos os processos do usuário, por isso só faz sentido para um usuário dedicado; em um notebook comum ele é ignorado.

O contêiner Docker adiciona namespaces e cgroups, mas continuam sendo os mesmos processos no kernel do host. A documentação do Docker diz claramente que, sem configurações explícitas, o contêiner não tem limites de recursos, por isso na sandbox são definidos memória, número de CPUs e número de processos (no exemplo, 256 MB, uma CPU, 64 pids). E as fugas acontecem: em novembro de 2025, três vulnerabilidades no runc permitiam sair do contêiner.

A microVM sobre Firecracker (no exemplo, via E2B) dá a cada sandbox o seu próprio kernel atrás de um hipervisor. A Docker chama isso de fronteira de hardware, e a AWS afirma que no Lambda sobre Firecracker o kernel não é compartilhado entre sessões. É a opção mais cara em latência e exige uma conta E2B com chave.

O que fazer com isso

Os autores testam cada nível com programas hostis idênticos: esgotamento de CPU, memória, processos e disco, além de tentativas de ler arquivos e acessar a rede. Depois, em bench.py, medem o custo em latência do reforço do isolamento. Na parte disponível do material não há números das medições, então rode o benchmark no seu próprio hardware: a latência depende muito do ambiente.

A lógica prática de escolha é esta:

• Subprocess serve para experimentos locais e código em que você quase confia. Requer Linux ou WSL.
• Docker com flags rígidas é adequado para ferramentas internas em que você está disposto a aceitar o risco de uma fuga.
• MicroVM é a escolha para entradas de terceiros e não confiáveis e para produtos multi-inquilino, onde uma fuga significa um incidente.

E o principal: não entregue ao agente a decisão sobre a própria sandbox. Segredos, rede e arquivos são definidos por quem implanta a infraestrutura. Se você quer uma solução pronta, e não montada por conta própria, os autores têm um artigo separado sobre cinco sandboxes hospedadas; aqui tudo é montado à mão para que se veja exatamente o que essas plataformas fazem por baixo dos panos.