Quão Seguro é o Sandbox de IA para Execução de Código?

Um sandbox de IA para executar código é tão seguro quanto sua fronteira de isolamento — e a fronteira de isolamento é apenas parte da resposta. A melhor pergunta é: o que o sandbox realmente isola, e o que ainda pode escapar? A maioria dos sandboxes interrompe bem algumas coisas (execução de código em nível de processo, gravações arbitrárias no sistema de arquivos do host) e deixa outras coisas abertas por padrão (rede de saída, instalações de pacotes, segredos em variáveis de ambiente). Entender essas lacunas é como você avalia se um sandbox se adequa ao seu modelo de risco.

O que “seguro” significa para um sandbox de execução de código

Segurança em um sandbox de execução de código não é uma propriedade binária. É um conjunto de controles, cada um abordando uma categoria específica de risco. Quando alguém pergunta “este sandbox é seguro?” geralmente está fazendo várias perguntas distintas ao mesmo tempo:

• Isolamento do host: O código executado dentro do sandbox pode escapar para o sistema host?
• Isolamento de inquilinos: O código de um usuário pode afetar a sessão de outro usuário?
• Controle de egresso: O código dentro do sandbox pode alcançar a internet, serviços internos ou endpoints de metadados?
• Escopo de segredos: As credenciais estão acessíveis a mais partes do sandbox do que o necessário?
• Risco de cadeia de suprimentos: Instalações de pacotes podem introduzir código inesperado ou malicioso?
• Auditabilidade: Você pode reconstruir o que o agente realmente fez posteriormente?

Um sandbox pode ser forte em isolamento de host e fraco em egresso. Forte em egresso e fraco em segredos. Avaliar “quão seguro” requer verificar cada dimensão separadamente, não aceitar um único rótulo como “containerizado” ou “baseado em microVM” como a resposta completa.

Comparação entre camadas de isolamento

Existem três modelos principais de isolamento usados em sandboxes de execução de código de IA. Cada um fornece uma fronteira diferente.

Isolamento de processo

O isolamento de processo usa primitivas do nível do sistema operacional — namespaces Linux, cgroups, filtros seccomp e perfis AppArmor ou SELinux — para restringir o que um processo pode acessar. O sandbox executa como um processo no sistema operacional host, compartilhando o kernel do host.

O que impede: Acesso ao sistema de arquivos mais amplo, outros processos fora do sandbox e chamadas de sistema explicitamente bloqueadas pela política seccomp.

O que não impede: Explorações do kernel que escalam privilégios através de uma vulnerabilidade compartilhada. Um bypass do seccomp ou uma vulnerabilidade do kernel pode romper a fronteira do host.

Quando é apropriado: Código de curta duração, baixo risco e razoavelmente confiável, onde a velocidade de inicialização e a portabilidade importam mais do que uma fronteira rígida de VM. Não recomendado para executar código arbitrário gerado por agente de usuários externos.

Isolamento de contêiner (Docker/namespaces)

O isolamento de contêiner estende o isolamento de processo com um modelo de imagem mais estruturado, namespacing de rede e montagens de volume. A maioria das implementações de sandbox baseadas em Docker executa código dentro de um contêiner com uma imagem mínima e um perfil seccomp restrito.

O que impede: Acesso direto ao sistema de arquivos do host, a maior parte do acesso de rede a contêineres adjacentes (quando configurado corretamente), acesso fácil a processos do host.

O que não impede: Explorações em nível de kernel ainda se aplicam — contêineres compartilham o kernel do host. Montagens de volume mal configuradas, perfis seccomp muito amplos, modo --privileged e sockets Docker expostos podem anular a fronteira pretendida.

Quando é apropriado: Muitas implantações de produção usam contêineres de forma eficaz para execução de código de IA quando o perfil seccomp é rigoroso, a imagem é mínima, o egresso é restrito e nenhum acesso privilegiado é concedido. O modelo de risco é diferente das microVMs, mas gerenciável com configuração cuidadosa.

Isolamento de microVM (Firecracker/gVisor)

O isolamento de microVM executa cada sandbox em uma máquina virtual leve com seu próprio kernel convidado, isolado do host por uma fronteira de hypervisor KVM. Firecracker é a implementação mais comum; gVisor (com seu kernel em espaço de usuário) oferece uma troca diferente.

O que impede: Explorações do kernel convidado não se propagam para o kernel do host ou outros convidados. A superfície de ataque do host é reduzida ao VMM (monitor de máquina virtual), que é projetado para ser mínimo.

O que não impede: Vulnerabilidades no próprio VMM (raro, mas não impossível). Controles de rede, pacotes e segredos ainda existem fora da fronteira da VM — o isolamento de microVM não lida com eles.

Quando é apropriado: Executar código não confiável ou gerado por agente de usuários externos, ambientes multi-inquilinos onde o raio de explosão importa e cargas de trabalho que podem executar comandos shell arbitrários ou scripts de instalação de pacotes.

Modelo de isolamento	Kernel do host compartilhado	Separação de inquilinos	Sobrecarga de inicialização	Risco de escape do host
Processo	Sim	Fraca	Mínima	Máximo
Contêiner	Sim	Moderada	Baixa	Médio (dependente da configuração)
MicroVM	Não	Forte	Moderada	Baixo

O que ainda pode escapar de cada fronteira

O modelo de isolamento aborda a execução de código em tempo de execução. Ele não aborda automaticamente o que entra ou sai do sandbox através de outros caminhos.

Rede de saída: Todos os três modelos de isolamento deixam o acesso à rede de saída para a configuração da política. Egresso aberto por padrão significa que o código dentro do sandbox pode alcançar a internet pública, endpoints de metadados de nuvem (169.254.169.254 na AWS e GCP), serviços internos na mesma rede e APIs externas arbitrárias. Isso é um caminho de exfiltração de dados, um caminho de recuperação de segredos e um caminho de comando e controle, independentemente do modelo de isolamento.

Instalações de pacotes: Um apt install, pip install ou npm install busca e executa código de um registro externo. Se o sandbox permite instalações de pacotes e tem egresso aberto, uma colisão de nome de pacote, ataque de typosquatting ou ataque de confusão de dependência pode introduzir código malicioso que é executado com todas as permissões do sandbox. A fronteira de isolamento contém o raio de explosão, mas não impede a instalação.

Estado compartilhado: Em implantações multi-inquilinos, caches compartilhados, registros de pacotes compartilhados, imagens de template compartilhadas ou montagens de sistema de arquivos compartilhadas criam canais entre inquilinos que contornam a fronteira de isolamento.

Segredos em variáveis de ambiente: Variáveis de ambiente visíveis para o processo do agente são legíveis por qualquer código que o agente execute. Se uma credencial de banco de dados ou chave de API está no ambiente, ela está acessível ao sandbox e a tudo que ele executa ou instala.

Egresso e controles de rede

Egresso é onde a maioria dos sandboxes tem sua maior lacuna. Acesso de saída aberto à internet é comum porque é conveniente — agentes precisam instalar pacotes, chamar APIs e buscar recursos. Mas também cria riscos:

Endpoints de metadados de nuvem: Em infraestrutura de nuvem hospedada, 169.254.169.254 (e seu equivalente IPv6) fornece metadados de instância, incluindo credenciais IAM. Código dentro de um sandbox com egresso aberto pode alcançar esse endpoint e recuperar credenciais para o host subjacente.

Exfiltração baseada em DNS: Mesmo que HTTP esteja bloqueado, consultas DNS de saída podem ser usadas para exfiltrar dados codificando-os em buscas de domínio. O bloqueio de DNS requer filtragem no nível do resolvedor, não apenas bloquear TCP/UDP 53 para servidores externos.

Serviços internos: Se o sandbox executa em um segmento de rede privada, o egresso aberto pode permitir acesso a bancos de dados internos, painéis de administração e APIs que não deveriam ser acessíveis a partir do código do agente.

Controles a avaliar:

Controle	O que previne	O que verificar
Egresso padrão-negar	Conexões de saída para destinos não listados	Também bloqueia DNS além de TCP/UDP?
Egresso baseado em lista de permissões	Conexões para domínios não aprovados	A lista de permissões é configurável pelo cliente?
Bloqueio de endpoint de metadados	Recuperação de credenciais de nuvem via 169.254.169.254	O IPv6 de metadados também está bloqueado?
Proxy de egresso	Registro e inspeção de todo tráfego de saída	O log do proxy está acessível?
Filtragem DNS	Exfiltração baseada em DNS e resolução de nomes interna	Qual resolvedor é usado dentro do sandbox?

Não existe uma política de egresso universalmente correta. Algumas cargas de trabalho de agente realmente precisam de amplo acesso à internet para serem úteis. O ponto chave é que a política seja deliberada e auditável, não aberta por padrão porque nunca foi configurada.

Tratamento de segredos

Segredos em sandboxes de agentes de IA seguem os mesmos princípios que segredos em qualquer sistema de software, com uma restrição adicional: o agente pode executar código que lê, registra ou transmite o ambiente sem intenção do desenvolvedor.

Escopo: Monte apenas as credenciais que o sandbox realmente precisa para a tarefa atual. Um sandbox executando uma tarefa de codificação não precisa de credenciais de banco de dados de produção. Um sandbox avaliando saídas de modelo não precisa da chave de API para um serviço de faturamento.

Tempo de vida: Credenciais de curta duração são significativamente mais seguras que as de longa duração. Se uma credencial vazar dentro de um sandbox, um TTL curto limita a janela de exposição. Muitos sistemas IAM de nuvem suportam tokens de curta duração que expiram em minutos ou horas.

Método de injeção: Variáveis de ambiente são o método de injeção mais comum e o mais acessível a qualquer código no processo. Segredos que podem ser injetados via montagens de sistema de arquivos, montados em um caminho que o agente não precisa percorrer, ou buscados dinamicamente apenas quando a ferramenta específica que precisa deles é executada, são mais restritos do que um conjunto de variáveis de ambiente genérico.

Redação: Segredos devem ser redigidos de stdout, stderr, payloads de resposta de ferramentas, contexto visível ao modelo e logs de auditoria. Um agente que ecoa seu ambiente, chama env ou passa um token para uma chamada de API com falha pode vazar credenciais para logs que são então armazenados ou visíveis para operadores.

Limites de recursos e risco de negação de serviço

Um sandbox sem limites de recursos é vulnerável a cargas de trabalho de agente que exaurem CPU, memória, disco ou largura de banda de rede — seja por código descontrolado, um loop infinito, um vazamento de memória em um pacote instalado ou uma tentativa deliberada de interromper cargas de trabalho adjacentes.

Controles de recursos a verificar:

• Limites de CPU: Aceleração ou limites rígidos por sessão impedem que uma sessão monopolize a capacidade do host.
• Limites de memória: Políticas de OOM kill devem encerrar a sessão do sandbox, não o processo do host.
• Cotas de disco: Limites de gravação por sessão impedem que uma sessão preencha o armazenamento compartilhado.
• Timeout de execução: Sessões que excedem um limite de tempo de parede devem ser encerradas de forma limpa, não deixadas em execução.
• Limites de taxa de rede: Limites de largura de banda de saída podem restringir a exfiltração mesmo quando a política de egresso permite o destino.
• Limites de processos concorrentes: Agentes que bifurcam agressivamente ou geram processos em segundo plano podem esgotar os slots da tabela de processos.

Violações de limites de recursos também valem a pena ser registradas. Uma sessão que atinge consistentemente o acelerador de CPU ou OOM kill durante tarefas que deveriam ser leves é um sinal que merece investigação.

Visibilidade de auditoria

Os controles de isolamento reduzem o raio de explosão quando algo dá errado. Logs de auditoria são como você descobre que algo deu errado e reconstrói o que aconteceu.

Para sandboxes de agentes de IA especificamente, a cobertura de auditoria útil inclui:

• Execução de processos: Cada comando que executa, com lista completa de argumentos, UID e processo pai. Sem listas de argumentos, curl e python em um log não são significativos.
• Acesso ao sistema de arquivos: Leituras e gravações em caminhos sensíveis. Gravações e exclusões têm prioridade mais alta que leituras para a maioria dos modelos de ameaça.
• Rede de saída: Destinos, protocolos, consultas DNS e bytes transferidos. O registro de consultas DNS é frequentemente ausente, mas importante.
• Instalações de pacotes: Gerenciador de pacotes, nome do pacote, versão, registro de origem e hash.
• Ciclo de vida da sessão: Eventos de criação, pausa, retomada, término e limpeza com códigos de motivo.
• Eventos de limite de recursos: OOM kills, aceleração de CPU, término por timeout.

O mecanismo de coleta importa tanto quanto a cobertura. Logs gerados dentro do processo do sandbox podem ser suprimidos ou modificados por um agente suficientemente privilegiado. A coleta em nível de kernel (via auditd, eBPF ou instrumentação de hypervisor) é gerada abaixo da camada de aplicação, onde o agente não tem acesso de gravação.

Perguntas a fazer a qualquer provedor ou projeto de sandbox

Use esta lista de verificação ao avaliar um serviço de sandbox gerenciado ou uma estrutura de sandbox de código aberto:

Isolamento

• Cada sessão de agente recebe seu próprio ambiente isolado, ou as sessões são agrupadas em ambientes de execução compartilhados?
• Qual modelo de isolamento é usado: processo, contêiner ou microVM?
• O kernel convidado é compartilhado com o host?

Rede e egresso

• O egresso é padrão-aberto ou padrão-negar?
• A política de egresso pode ser configurada por inquilino ou por sessão?
• O endpoint de metadados de nuvem (169.254.169.254) está bloqueado?
• Como o DNS é tratado dentro do sandbox?

Instalações de pacotes

• As instalações de pacotes são permitidas por padrão?
• As instalações podem ser limitadas a registros aprovados?
• Os eventos de instalação são registrados com origem e hash?

Segredos

• Como as credenciais são injetadas no sandbox?
• As credenciais podem ser limitadas à ferramenta ou tarefa específica que precisa delas?
• Os segredos são redigidos dos logs e saídas visíveis ao modelo?

Limites de recursos

• Limites de CPU, memória, disco e tempo limite são aplicados?
• O que acontece quando um limite é atingido — acelerar, matar ou alertar?

Logs de auditoria

• Os logs são gerados no nível do kernel/hypervisor ou dentro do processo do sandbox?
• Quais categorias de eventos são registradas por padrão?
• Os logs podem ser exportados para um SIEM externo ou sistema de agregação de logs?
• Qual é a política de retenção de logs?

Inquilinato

• As cargas de trabalho de diferentes inquilinos são isoladas umas das outras?
• Existem caches, imagens ou montagens compartilhadas que criam canais entre inquilinos?

Onde o Novita Agent Sandbox se encaixa

O Novita Agent Sandbox é projetado para cargas de trabalho de agente que precisam de ambientes de execução isolados para código, arquivos, processos e sessões de maior duração. Ele visa equipes que constroem agentes de codificação, pipelines de avaliação, agentes de análise de dados e fluxos de trabalho de agente baseados em navegador.

O sandbox suporta controles de ciclo de vida de sessão, incluindo pausa, retomada e pausa automática para sessões ociosas. Ele fornece métricas de recursos e logs de execução no nível da sessão acessíveis através da API. Para equipes que já usam APIs de modelo da Novita, ele pode servir como a camada de execução em uma arquitetura de agente onde o modelo planeja e chama ferramentas, e o sandbox lida com a execução em tempo de execução em um ambiente isolado.

Ao avaliar o Novita Agent Sandbox para casos de uso sensíveis à segurança, verifique o modelo de isolamento atual, padrões de política de egresso, cobertura de log e tratamento de segredos na documentação do produto antes de tomar decisões de arquitetura. Os requisitos de segurança variam significativamente por carga de trabalho — o que é apropriado para um pipeline de avaliação interno pode não ser suficiente para um produto multi-inquilino que lida com código fornecido pelo usuário.

Como em qualquer sandbox, a postura de segurança depende tanto dos padrões da plataforma quanto dos seus controles no nível da aplicação: como as credenciais são escopadas, o que o agente tem permissão para solicitar, quais chamadas de ferramenta exigem aprovação humana e como os logs de auditoria são monitorados.

Limitações e o que nenhum sandbox elimina

Nenhum sandbox elimina todo o risco. Entender o que permanece fora da fronteira é tão importante quanto entender o que a fronteira fornece.

Decisões de confiança em nível de aplicação: O sandbox controla a execução em tempo de execução. Ele não decide o que o agente tem permissão para pedir. Se sua aplicação permite que um agente solicite uma credencial, execute comandos shell arbitrários ou chame qualquer API, o sandbox reduz o raio de explosão, mas não impede essas ações.

Injeção de prompt: Um agente que processa conteúdo não confiável — páginas da web, arquivos enviados pelo usuário, respostas de API externas — pode ser manipulado através desse conteúdo para realizar ações que não deveria. Isso é um problema de design da aplicação, não um problema do sandbox. O sandbox pode limitar onde essas ações chegam, mas a lógica de decisão reside na sua aplicação.

Vulnerabilidades de dia zero: Todos os modelos de isolamento têm vulnerabilidades conhecidas e desconhecidas. O isolamento de microVM fornece a fronteira mais forte no uso atual de produção, mas vulnerabilidades de VMM existem. Defesa em profundidade — combinar múltiplos controles em vez de confiar em uma única fronteira — é uma postura mais robusta do que qualquer modelo de isolamento único.

Engenharia social através da saída do modelo: Um agente pode produzir saída que persuade um operador humano a realizar uma ação insegura. Sandboxes não auditam decisões humanas.

Risco de conformidade e regulatório: Os controles de isolamento abordam o risco técnico. Requisitos regulatórios (GDPR, HIPAA, SOC 2, ISO 27001) abordam manuseio de dados, retenção, documentação e requisitos de auditoria que vão além do que um sandbox fornece no nível da infraestrutura.

A segurança em um sandbox de execução de código é melhor enquadrada como um conjunto de controles para avaliar e configurar, não uma propriedade que você adquire ao escolher um produto. As perguntas de avaliação acima se aplicam a toda decisão de sandbox — incluindo sua própria infraestrutura se você está construindo em vez de comprando.

FAQ

Quão seguro é um ambiente de execução de código de IA em sandbox comparado a executar código em um servidor?

Um sandbox bem configurado reduz significativamente o raio de explosão de executar código não confiável em comparação com executá-lo diretamente em um servidor. Ele restringe o acesso ao sistema de arquivos, o escopo do processo e o acesso à rede. No entanto, a diferença depende da configuração. Um contêiner com egresso aberto e injeção ampla de variáveis de ambiente pode ser menos seguro do que um servidor endurecido com controles de rede. O modelo de isolamento é um ponto de partida, não uma garantia.

O isolamento de microVM significa que um sandbox é totalmente seguro?

Não. O isolamento de microVM (Firecracker, baseado em KVM) fornece uma fronteira de host forte que contêineres de kernel compartilhado não têm. Mas não controla egresso, segredos, instalações de pacotes ou cobertura de auditoria. Uma microVM com egresso aberto e nenhuma coleta de log não é “totalmente segura”, mesmo que a camada de isolamento seja forte.

Código gerado por IA pode escapar de um sandbox?

Depende do modelo de isolamento e configuração. Escapes de contêiner exigem explorar o kernel ou uma configuração incorreta; escapes de microVM exigem explorar o VMM. Ambos são possíveis, mas incomuns. Os riscos mais práticos são exfiltração de dados através de caminhos de rede permitidos, leitura de segredos do ambiente ou instalação de pacotes maliciosos através de gerenciadores de pacotes sem restrições.

Qual é o maior risco de segurança na maioria dos sandboxes de código de IA?

Egresso de saída aberto é o risco mais comumente subabordado. Muitos sandboxes permitem acesso irrestrito à internet de saída por padrão porque é conveniente para agentes que precisam instalar pacotes e chamar APIs. Isso cria caminhos para exfiltração de dados, roubo de credenciais via endpoints de metadados de nuvem e comunicação de comando e controle que existem independentemente de quão forte é a fronteira de isolamento.

Devo usar um sandbox gerenciado ou construir o meu próprio?

Sandboxes gerenciados lidam com a complexidade operacional do ciclo de vida de microVM ou contêiner, capacidade do host e gerenciamento de imagens. Construir o seu próprio lhe dá mais controle sobre a pilha completa de políticas. De qualquer forma, as mesmas perguntas de avaliação se aplicam: política de egresso, tratamento de segredos, cobertura de log, limites de recursos e exportação de auditoria. A decisão de construir vs. comprar é separada da avaliação de segurança.

O que torna a segurança de sandbox de agente diferente da segurança tradicional de execução de código?

A segurança tradicional de execução de código assume que você sabe aproximadamente qual código será executado. Agentes de IA mudam isso: um único prompt pode fazer com que uma sessão instale pacotes, escreva arquivos, execute comandos shell, chame APIs externas e gere subprocessos sem aprovação explícita do desenvolvedor para cada etapa. Isso torna a cobertura de auditoria mais importante (você não pode antecipar cada ação), os controles de egresso mais importantes (o agente pode alcançar destinos que você não esperava) e o escopo de segredos mais importante (o agente tem acesso a tudo em seu ambiente).

Artigos recomendados

• Firecracker for AI Agent Sandboxes: Benefits, Limits, and Evaluation Questions
• Audit Logs for AI Agent Sandboxes: What Security Teams Need
• AI-Generated Code Sandbox: Requirements for Production Apps