Um agente de IA que escreve e executa o seu próprio código só é seguro na medida em que o ambiente onde esse código é executado o é. Num tutorial publicado pelo Machine Learning Mastery, o autor mostra como isolar esse código em três níveis: um subprocesso limitado, um container Docker reforçado e uma microVM Firecracker, comparando depois a sua segurança e latência.
- Um agente de IA só é seguro se o ambiente onde executa o seu código também o for.
- O tutorial compara três níveis de isolamento : subprocesso, container Docker reforçado e microVM Firecracker.
- O subprocesso deixa passar dois dos seis ataques, enquanto o container deve bloqueá-los todos.
- A microVM é recomendada para código de vários utilizadores e para tudo o que envolva segredos.
O subprocesso é o nível mais leve: trata-se de um processo filho cujo tempo de computação, memória e tamanho dos ficheiros são limitados, mas que partilha o kernel e os ficheiros da máquina hospedeira. Um container adiciona espaços de nomes e grupos de controlo (cgroups), mas continua a ser um conjunto de processos no kernel do hospedeiro. O artigo recorda que, em novembro de 2025, três vulnerabilidades no motor de execução runc permitiram que atacantes saíssem de containers. Uma microVM, por sua vez, atribui a cada ambiente o seu próprio kernel, por detrás de um hipervisor, o software que executa máquinas virtuais.
O dispositivo baseia-se numa única ferramenta, run_python, disponibilizada ao agente. Cada código produzido pelo modelo passa por um objeto «sandbox» dotado de um método run(código), de modo que alterar o nível de isolamento não modifica o agente. O tutorial requer Python 3.10 ou mais recente, um sistema Linux ou WSL para o nível de subprocesso, Docker para o container, e uma conta e uma chave de API E2B para a microVM. Uma chave de API da Anthropic é útil para o agente, mas pode ser dispensada para testes.
Seis ataques idênticos contra cada nível
Para comparar os três níveis, são executados os mesmos seis programas hostis: um ciclo infinito, uma alocação de 512 MB de memória, um «fork flood» de 200 processos, a escrita de um ficheiro de 50 MB, a leitura de um ficheiro falso de credenciais e a ligação a um serviço interno falso. Um ataque é considerado bloqueado quando a palavra-teste não aparece na saída ou, para o ciclo infinito, quando a execução expira.
No nível de subprocesso, executado com um utilizador Linux comum, quatro ataques são bloqueados e dois passam. O limite de processos só se aplica a um utilizador dedicado, pelo que o fork flood é permitido, e o ficheiro de credenciais falsas permanece legível porque o código é executado sob a identidade do utilizador. O autor conclui que este nível é adequado sobretudo para código em que se confia.
Para o container Docker, o autor indica que, com as opções escolhidas, o Docker deverá bloquear os seis ataques, uma vez que o container não tem rede, o seu sistema de ficheiros não contém os ficheiros do utilizador e os limites de memória, processos e disco se aplicam. Numa microVM, os ataques à memória, processos e disco podem atingir os limites da máquina virtual, mas permanecem confinados a ela, e o ficheiro secreto e o serviço local não existem nela.
Latência e escolha do nível
O subprocesso deve ser o mais rápido, uma vez que apenas lança Python. Para os outros dois níveis, o autor esclarece que os números publicados são afirmações e não garantias: um artigo citado indica que a E2B arranca em cerca de 150 ms, enquanto a AWS e a Docker descrevem arranques quase instantâneos para os seus produtos de microVM. O script bench.py permite medir, na própria máquina, a mediana e o tempo mais longo em dez execuções de um programa print(1).
O autor recomenda reservar o subprocesso para código de confiança, como scripts de desenvolvimento pessoais, e o container reforçado para casos em que se controla o hospedeiro e os riscos são baixos, mantendo o runc atualizado. A microVM impõe-se para código proveniente de vários utilizadores, para tudo o que envolva segredos, e quando o agente tem de construir e executar ele próprio containers, algo que os containers clássicos gerem mal, segundo a Docker. A Docker lançou as suas Docker Sandboxes em microVM em abril de 2026, e a AWS oferece Lambda MicroVMs que mantêm o seu estado até 8 horas e suspendem-se quando inativas. Segundo a Docker, os ficheiros, as regras de rede e os segredos devem ser definidos pela infraestrutura, e não pelo agente, antes da sua execução.
