Sandbox para Agentes de IA: onde o código que o agente escreve pode rodar sem colocar a empresa em risco

Boa parte do valor dos agentes de IA vem de uma capacidade simples: eles escrevem código e o executam. É assim que um agente analisa uma planilha de 200 mil linhas, converte arquivos, consulta uma API ou monta um relatório. Mas há um detalhe que muda a conversa de arquitetura: esse código foi gerado por um modelo, a partir de instruções que podem ter vindo de um e-mail, de uma página da web ou de um documento de terceiros. Em termos de segurança, é código não confiável rodando dentro da sua infraestrutura.

Por que o risco é diferente de software tradicional

Em software convencional, alguém escreveu, revisou e testou o código antes de ele ir para produção. Com agentes, o código é criado em tempo de execução, sem revisão humana, e pode ser influenciado por prompt injection: um texto malicioso escondido em um documento pode levar o agente a executar um comando que ele nunca deveria executar, como enviar dados para fora ou apagar arquivos. Não se trata de supor que o modelo é mal-intencionado, e sim de assumir que ele pode ser enganado.

Por isso, a pergunta de arquitetura deixa de ser "o modelo é seguro?" e passa a ser "o que acontece se ele errar, ou for manipulado, dentro do ambiente onde roda?". A resposta tem nome: sandbox, um ambiente isolado, descartável e com permissões mínimas.

Os três níveis de isolamento

Existem, em essência, três abordagens, com um trade-off claro entre força do isolamento e custo operacional:

• Containers: compartilham o kernel do servidor hospedeiro. São rápidos (iniciam em milissegundos), mas uma falha de kernel ou uma fuga de container pode atingir o host. Servem como camada de empacotamento, n��o como fronteira de segurança para código não confiável.
• gVisor: intercepta as chamadas de sistema em espaço de usuário, reduzindo a superfície de ataque sem precisar iniciar uma máquina virtual. É um meio-termo, com a ressalva de que nem todas as chamadas do Linux são suportadas.
• microVMs (Firecracker, Kata Containers): cada tarefa ganha seu próprio kernel, protegido por virtualização de hardware. É a fronteira mais forte, e o tempo de inicialização do Firecracker pode ficar na casa de 125 ms, o que torna o custo de latência pequeno para a maioria dos casos de uso corporativos.

Os quatro controles que um executivo deve exigir

Independentemente da tecnologia escolhida, vale usar uma lista de verificação simples ao avaliar um projeto de agentes que executam código:

• Efêmero: cada sessão roda em um ambiente criado para ela e destruído ao fim, sem estado compartilhado entre clientes ou tarefas. Um incidente fica contido naquela execução.
• Saída de rede restrita: bloquear o tráfego de saída por padrão e liberar apenas o que é necessário (um repositório de pacotes, uma API específica). É o controle de maior alavancagem contra vazamento de dados.
• Credenciais com menor privilégio: cada tarefa recebe apenas o acesso de que precisa, com tokens limitados ao que será usado, em vez de uma chave ampla herdada por todos os ambientes.
• Saída auditável: o que o agente faz sai por um canal revisável, como um pull request, um ticket ou uma aprovação, e tudo o que foi executado fica registrado em log.

Somam-se a isso limites de CPU, memória, disco e tempo por execução, que evitam tanto o abuso quanto o custo inesperado de um agente preso em loop.

Como começar sem travar o projeto

Um caminho prático é começar pelo menor risco: agentes que só leem dados e geram análises, rodando em microVMs gerenciadas por um provedor, com rede fechada e sem credenciais de escrita. À medida que o time ganha confiança, amplia-se o escopo com aprovação humana nas ações irreversíveis. Para o conselho e o comitê de risco, a mensagem é objetiva: autonomia do agente e isolamento do ambiente crescem juntos. Quanto mais o agente pode fazer, mais forte precisa ser a fronteira ao redor dele.

No Gartner AI Roadmap, esse tema se encaixa na camada de governança e risco: o isolamento de execução é um requisito de arquitetura que deve ser definido antes de o piloto escalar, e não um ajuste feito depois do primeiro incidente.