Sandbox para código gerado por IA: como executar sem risco

Sandbox para código gerado por IA: como executar sem risco

Para executar código gerado por IA sem risco, rode-o em um ambiente descartável, sem rede por padrão, sem segredos e com limites de tempo, memória e arquivos. A escolha entre contêiner, microVM e serviço gerenciado depende de quanto você confia na origem do código e do que existe de valioso por perto. O isolamento reduz o estrago, mas são os limites que evitam que o problema comece.

Principais pontos

• Código escrito por um modelo deve ser tratado como código não confiável, porque o modelo pode ser induzido por texto malicioso ou simplesmente errar.
• Contêiner comum é um isolamento fraco para código não confiável, pois compartilha o kernel do servidor. Runtimes reforçados, microVMs e serviços gerenciados oferecem uma fronteira mais forte.
• Rede, tempo de execução e sistema de arquivos precisam de limites explícitos, e o padrão deve ser negar.
• Segredos nunca entram no sandbox. Se o código precisa de uma credencial, ela deve ser restrita, de curta duração e entregue por um intermediário controlado.
• Registrar o que foi executado, com qual entrada e qual saída, é tão importante quanto isolar.

Por que código gerado por IA precisa de sandbox?

Um agente que escreve e executa código ganha uma capacidade enorme: analisar planilhas, converter arquivos, calcular, gerar relatórios. Ao mesmo tempo, ele passa a rodar instruções que ninguém revisou linha a linha. O código pode ter um erro simples, como apagar a pasta errada, ou pode ser resultado de uma injeção de prompt, em que um texto dentro de um e-mail, PDF ou página web convence o modelo a fazer algo que o dono do sistema nunca pediu.

A lista de riscos para aplicações com modelos de linguagem mantida pela OWASP trata esse ponto como uma categoria própria, e o guia de prevenção de injeção de prompt da mesma organização mostra que filtrar texto não basta. A defesa realista é assumir que o modelo pode ser enganado e limitar o que o código consegue fazer quando isso acontecer.

Por isso, a pergunta útil não é se o código é seguro, e sim: se este código fosse hostil, o que ele alcançaria? Se a resposta inclui banco de dados de produção, chaves de API ou a rede interna da empresa, falta fronteira.

Quais são as opções de isolamento?

Existem quatro famílias comuns, com trocas diferentes entre força do isolamento, custo operacional e facilidade.

• Contêiner comum: processos isolados por recursos do kernel do servidor, como namespaces e cgroups. É rápido e conhecido pela equipe, mas todos os contêineres compartilham o mesmo kernel. Uma falha no kernel ou uma configuração frouxa pode permitir fuga para o servidor.
• Contêiner com runtime reforçado: soluções como o gVisor interceptam as chamadas de sistema do código e as tratam em uma camada intermediária, reduzindo a superfície exposta ao kernel real. Continua parecendo um contêiner para quem opera, com fronteira mais forte.
• MicroVM: cada execução ganha uma máquina virtual mínima, com seu próprio kernel, apoiada em virtualização por hardware. O Firecracker é um exemplo conhecido dessa abordagem. A fronteira é mais forte, em troca de mais trabalho de infraestrutura.
• Serviço gerenciado: um provedor oferece ambientes de execução prontos para agentes, normalmente por API, e cuida do isolamento, da limpeza e da escala. Você ganha velocidade e transfere parte da operação, mas passa a depender das garantias e da localização dos dados do provedor.

Um ponto que costuma passar despercebido: rodar o código direto no mesmo servidor do aplicativo, mesmo em outro processo ou usuário, não é sandbox. É apenas um processo a mais com acesso ao que o servidor enxerga.

Como escolher: um guia de decisão

Use estas perguntas, nesta ordem, para decidir o nível de isolamento.

• O código vem só de pessoas da equipe, revisado, e roda sobre dados internos de baixo risco? Um contêiner bem configurado, sem privilégios e sem rede, pode bastar.
• O código é escrito por um modelo, mas as entradas são controladas por você (por exemplo, planilhas que você mesmo gera)? Prefira contêiner com runtime reforçado ou microVM.
• O modelo lê conteúdo de terceiros, como e-mails de clientes, anexos de WhatsApp, páginas web ou documentos enviados? Trate como hostil: microVM ou serviço gerenciado, rede negada e nenhum segredo dentro.
• Há dados pessoais sensíveis envolvidos? Verifique onde o serviço executa e armazena. Se o provedor processa fora do país, avalie o que a LGPD exige em transferência internacional de dados com IA.
• A equipe tem capacidade de operar infraestrutura de virtualização com atualizações e monitoramento? Se não, um serviço gerenciado costuma ser mais seguro do que uma microVM mal mantida.

A regra de bolso: quanto mais o código depende de entradas que você não controla, mais forte deve ser a fronteira.

Como limitar rede, tempo e arquivos?

O isolamento define onde o código roda. Os limites definem o que ele pode fazer lá dentro. Os três mais importantes são rede, tempo e arquivos.

Rede. O padrão deve ser nenhuma saída. A maior parte das tarefas de análise e conversão não precisa de internet. Quando precisa instalar pacotes ou chamar uma API, use uma lista de destinos permitidos, aplicada fora do sandbox (no firewall ou em um proxy de saída), e nunca uma instrução no prompt. Bloqueie também endereços internos e de metadados da nuvem, que são alvos clássicos de quem tenta sair de um ambiente isolado. Se o código precisa de dados externos, deixe que uma ferramenta controlada os busque e entregue o resultado como arquivo.

Tempo e recursos. Defina um tempo máximo por execução, um teto de memória, de processador e de número de processos. Isso protege contra laços infinitos, bombas de memória e mineração indevida. O mesmo raciocínio vale para o agente como um todo, que precisa de limites de passos e de gasto, como explicamos em agente de IA em loop infinito. Ao estourar o limite, a execução deve ser encerrada e registrada, não repetida em silêncio.

Arquivos. Monte somente os arquivos necessários para a tarefa, em modo leitura quando possível, e uma pasta de saída separada e pequena. Use sistema de arquivos descartável: ao fim da execução, tudo some, e só o que está na pasta de saída é recolhido e verificado. Defina tamanho máximo de entrada e de saída. Não monte pastas pessoais, repositórios inteiros nem diretórios com arquivos de configuração.

Segredos. Nenhuma variável de ambiente com chaves, nenhum arquivo de credenciais. Se uma etapa exige acesso a um sistema, faça-a fora do sandbox, por uma ferramenta com permissões mínimas, e peça aprovação humana para ações irreversíveis. Os guardrails de entrada, saída e ação descritos em guardrails para agentes de IA complementam esse desenho.

Passo a passo para montar o primeiro sandbox

Este roteiro serve para um primeiro piloto, independentemente da tecnologia escolhida.

• Descreva a tarefa em uma frase e liste as entradas e saídas esperadas. Se não cabe em uma frase, divida.
• Classifique a origem das entradas: internas e controladas, ou externas e não confiáveis.
• Escolha o nível de isolamento com o guia de decisão acima.
• Defina rede negada, tempo máximo, teto de memória e processador, e tamanho máximo de arquivos.
• Monte apenas as entradas necessárias, em leitura, e uma única pasta de saída.
• Garanta que nenhum segredo esteja no ambiente e que o ambiente seja descartado a cada execução.
• Registre o código executado, a entrada, a saída, o tempo gasto e o motivo de qualquer falha.
• Valide a saída antes de usá-la: formato esperado, tamanho, tipos de arquivo e revisão humana quando houver impacto externo.
• Teste de propósito com código ruim: tentativa de acessar a rede, ler arquivos fora da pasta, consumir memória sem parar. Confirme que cada tentativa falha e fica registrada.

O último item é o que mais se esquece e o que mais dá confiança. Um sandbox que nunca foi testado contra comportamento hostil é apenas uma suposição.

Cenário ilustrativo: agente que analisa planilhas enviadas por clientes

Imagine uma empresa de serviços que recebe planilhas de clientes por e-mail e usa um agente para gerar um resumo. Isto é um cenário ilustrativo, sem relação com nenhum caso real.

O agente escreve um script para ler a planilha e calcular totais. Sem sandbox, o script rodaria no servidor que também guarda as credenciais do sistema de gestão. Uma célula com texto malicioso poderia induzir o modelo a incluir no script uma chamada que envia arquivos para fora.

Com sandbox, o desenho muda: a planilha é copiada para um ambiente descartável em microVM ou serviço gerenciado, com rede negada e sem variáveis de ambiente sensíveis. O script tem tempo máximo curto e só escreve em uma pasta de saída. O resultado volta como um arquivo pequeno em formato conhecido, que passa por validação. Se o script tentar abrir uma conexão, a tentativa falha e aparece no registro. A pior hipótese deixa de ser vazamento e passa a ser uma execução que falhou.

Como aplicar o método: mapear, limitar, pilotar, transferir

Na prática de consultoria, o trabalho segue quatro etapas. Mapear: entender quais tarefas realmente exigem execução de código e quais podem ser resolvidas por um fluxo determinístico, que é mais barato e previsível. Limitar: definir dados, ferramentas, rede, tempo e permissões antes de ligar qualquer execução. Pilotar: rodar um fluxo real com registros e uma métrica de sucesso combinada, incluindo testes de abuso. Transferir: entregar à equipe a documentação, os registros e o critério para expandir, ajustar ou parar.

Quem trabalha com ferramentas de programação assistida pode ver o mesmo princípio em segurança no Claude Code para empresas. Para ambientes de agente mais amplos, o raciocínio de evidência antes de exposição aparece no checklist de segurança do OpenClaw Gateway. Para uma visão geral de como agentes devem ser construídos, vale ler o material da Anthropic sobre agentes eficazes, que recomenda começar simples e testar em ambiente controlado.

Perguntas frequentes

Contêiner Docker é suficiente como sandbox para código de IA? Depende da origem do código e das entradas. Para código revisado e dados internos, um contêiner sem privilégios, sem rede e com limites pode ser aceitável. Para código escrito por modelo que lê conteúdo de terceiros, prefira um runtime reforçado, uma microVM ou um serviço gerenciado, porque o contêiner comum compartilha o kernel do servidor.

O sandbox elimina o risco de injeção de prompt? Não. A injeção de prompt afeta o que o modelo decide fazer, e o sandbox limita o dano do que ele executa. Por isso o conjunto precisa incluir validação de entradas e saídas, permissões mínimas nas ferramentas e aprovação humana para ações com efeito externo.

Posso usar um serviço gerenciado com dados de clientes? Pode, desde que você saiba onde o serviço executa e armazena os dados, por quanto tempo os mantém e quem tem acesso. Se houver dados pessoais, defina a base legal, minimize o que entra no ambiente e avalie o tratamento fora do Brasil. A página da ANPD é o ponto de partida oficial para acompanhar orientações.

O que registrar de cada execução? Guarde o código executado, as entradas usadas, a saída produzida, o tempo e os recursos consumidos, e qualquer erro ou bloqueio. Evite gravar dados pessoais desnecessários nos registros e defina por quanto tempo eles são mantidos. Esses dados permitem investigar incidentes e decidir, com evidência, se o piloto deve crescer.

Fontes

• OWASP Top 10 for LLM Applications
• OWASP: prompt injection prevention
• Anthropic: Building effective agents
• ANPD: Autoridade Nacional de Proteção de Dados