Checklist de Isolamento de Sandbox para Agentes de IA em Revisões de Segurança

Uma revisão de isolamento de sandbox para agentes de IA deve verificar o limite de execução, a exposição do sistema de arquivos, os controles de processo e recursos, a política de rede e DNS, o comportamento de busca de pacotes, o tratamento de segredos, os logs, a captura de artefatos, a semântica de redefinição, os pontos de aprovação humana e as premissas de resposta a incidentes antes que o código gerado possa ser executado contra sistemas ou dados reais.

Por que as revisões de isolamento de agentes de IA são importantes

As revisões tradicionais de sandbox geralmente começam com uma pergunta: este sistema consegue executar código não confiável sem expor o host? As revisões de agentes de IA precisam dessa pergunta, mas também precisam de uma checklist mais ampla, porque os agentes fazem mais do que executar um único script. Eles podem clonar repositórios, instalar pacotes, navegar em sites, gravar arquivos, chamar APIs, abrir sessões de GUI, repetir comandos com falha e transformar a saída do modelo em ações de shell.

Isso muda o modelo de risco. Um agente de codificação pode se comportar como um engenheiro júnior com acesso ao terminal. Um agente de análise de dados pode se comportar como um usuário de notebook que envia arquivos, busca pacotes e exporta gráficos. Um agente de navegador pode se comportar como um usuário com cookies, downloads, capturas de tela e ações de preenchimento de formulários. Um agente de aprendizado por reforço ou avaliação pode executar a mesma tarefa milhares de vezes, o que faz com que pequenas lacunas de egresso, recursos ou logging importem em escala.

Use a checklist abaixo para revisar o limite antes de conectar uma sandbox a repositórios sensíveis, dados de clientes, APIs internas, credenciais privilegiadas ou sistemas de implantação em produção.

Segurança do Limite de Execução

Comece pelo limite que separa a carga de trabalho do agente do host e de outros inquilinos. A revisão deve ser explícita o suficiente para que um engenheiro de segurança consiga descrever o que falha se o agente executar código hostil.

Verifique:

• Qual camada de isolamento é usada: contêiner, microVM, VM completa, mediação de chamadas de sistema semelhante ao gVisor, sandboxing do Kubernetes ou outro modelo?
• Cada sandbox tem seu próprio limite de kernel ou compartilha o kernel do host?
• CPU, memória, sistema de arquivos, tabela de processos, pilha de rede e acesso a dispositivos estão separados de outras cargas de trabalho?
• A sandbox pode acessar sockets do runtime de contêiner, namespaces de processos do host, caminhos do host, serviços de metadados da nuvem ou dispositivos privilegiados?
• Como sessões de navegador, desktops GUI, fluxos VNC e interpretadores de código são colocados dentro do mesmo limite?
• Qual é a premissa documentada de escape do host: contenção, redução de risco ou uma garantia mais forte?

Evite aceitar uma declaração genérica de “sandbox segura” como resposta completa. Pergunte pelo mecanismo concreto de isolamento, o que está dentro do limite, o que está fora dele e quais premissas ainda precisam de controles compensatórios.

Segurança do Sistema de Arquivos e Montagens

Os sistemas de arquivos dos agentes merecem uma revisão separada, porque os agentes frequentemente criam, editam e exfiltram arquivos como parte do trabalho normal. A parte arriscada não é apenas o acesso de leitura/gravação; é o carregamento acidental entre tarefas e o acesso implícito a arquivos de projeto que o usuário não pretendia compartilhar.

Verifique:

• O sistema de arquivos padrão é vazio, baseado em template ou pré-carregado com arquivos de projeto?
• Quais caminhos são graváveis pelo agente e quais são somente leitura?
• Diretórios do host, montagens de repositório, chaves SSH, caches de pacotes, perfis de navegador ou arquivos de configuração da nuvem estão montados na sandbox?
• O agente pode atravessar symlinks ou bind mounts para caminhos não pretendidos?
• O acesso a arquivos é delimitado por sandbox, por usuário, por projeto ou por organização?
• Os arquivos enviados são excluídos, retidos, capturados em snapshots ou disponibilizados para sessões posteriores?
• Os arquivos gerados e os diffs podem ser revisados antes de saírem da sandbox?

Para agentes de codificação, o padrão mais seguro geralmente é um workspace de projeto restrito, exportação explícita de artefatos e nenhum acesso ambiente aos diretórios pessoais dos desenvolvedores ou repositórios compartilhados de credenciais.

Controles de Processo e Recursos

Um agente pode criar um fork bomb acidentalmente, travar um build, encher um disco, executar um servidor em segundo plano ou continuar repetindo um comando caro. Os controles de recursos transformam essas falhas em falhas limitadas.

Verifique:

• Limites de CPU, memória, disco, descritores de arquivo, número de processos e tempo de execução são aplicados?
• Existe uma duração máxima de relógio para comandos e sessões?
• Processos em segundo plano podem sobreviver depois que um comando termina?
• Os processos filhos são encerrados quando a sandbox é interrompida ou redefinida?
• O agente pode abrir portas de escuta e, se puder, essas portas são expostas apenas por meio de um mecanismo explícito de preview?
• Logs grandes de stdout/stderr são truncados, transmitidos ou armazenados?
• As falhas de cota são visíveis para o chamador em vez de serem repetidas silenciosamente?

Para fluxos de trabalho de agentes em produção, os limites devem fazer parte do contrato da API, não apenas um conceito de cobrança. A equipe de segurança deve saber o que acontece quando um agente atinge um limite e se a falha deixa estado parcial para trás.

Controles de Rede e Egresso

A política de rede é onde muitas revisões de sandbox se tornam vagas demais. Algumas cargas de trabalho de agentes precisam de acesso à internet; outras não devem ter esse acesso por padrão. A resposta correta depende de a sandbox estar executando testes, navegando em páginas públicas, buscando pacotes, chamando APIs internas ou processando dados sensíveis.

Verifique:

• O acesso à internet de saída está habilitado por padrão?
• O acesso à rede pode ser desabilitado por sandbox, por template ou por projeto?
• Listas de permissão de egresso estão disponíveis para domínios, faixas de IP, portas ou protocolos?
• O acesso a endpoints de metadados da nuvem está bloqueado?
• A sandbox pode alcançar VPCs privados, serviços internos, bancos de dados ou sistemas de implantação?
• O tráfego de navegador, tráfego de CLI, tráfego de gerenciador de pacotes e conexões diretas de socket são regidos pela mesma política?
• As solicitações de saída são registradas com timestamp, destino, contexto de processo ou comando e status da resposta?

Trate o egresso de agentes como o egresso de sistemas de build. Se o agente puder instalar pacotes, enviar artefatos, chamar webhooks ou navegar em sites arbitrários, a revisão deve cobrir tanto código malicioso quanto comportamento conduzido por injeção de prompt.

Riscos de DNS e Acesso a Pacotes

DNS e gerenciadores de pacotes são fáceis de ignorar porque parecem infraestrutura básica. Para agentes, eles fazem parte da superfície de execução. Um script gerado pode codificar dados em consultas DNS, buscar um pacote typosquatted ou puxar um script de uma URL que nunca foi revisada.

Verifique:

• O tráfego de DNS segue a mesma política de egresso que HTTP e HTTPS?
• As consultas DNS são registradas, filtradas ou forçadas por resolvedores controlados?
• Os gerenciadores de pacotes podem acessar registries públicos por padrão?
• Os registries de pacotes são permitidos, proxy, armazenados em cache ou fixados?
• Nomes de pacotes instalados, versões, URLs, hashes e alterações em lockfiles são capturados?
• O agente pode executar scripts de instalação, hooks de pós-instalação ou etapas arbitrárias de build de pacotes?
• Existe um portão de revisão antes que novas dependências sejam persistidas em um template ou fluxo de produção?

Se o acesso a pacotes for necessário, prefira versões fixadas, lockfiles, listas de permissão de registry e logs que permitam aos revisores reconstruir o que foi baixado e executado.

Tratamento de Segredos

Segredos geralmente são o caminho mais rápido para um limite de sandbox se tornar irrelevante. Se um agente vê um token amplo, ele pode vazar dados sem escapar do host.

Verifique:

• Segredos são injetados somente quando uma tarefa precisa explicitamente deles?
• Os segredos são limitados à sandbox, à tarefa, ao repositório, ao ambiente e ao tempo de vida?
• Os segredos podem ser lidos a partir de variáveis de ambiente, arquivos, histórico do shell, listas de processos, logs, capturas de tela ou armazenamento do navegador?
• Logs e artefatos são redigidos antes do armazenamento ou exportação?
• Tokens de curta duração são usados em vez de credenciais de longa duração?
• O agente pode acessar chaves SSH de nível de usuário, credenciais Git, credenciais de nuvem, cookies de navegador ou chaves de API do host?
• O acesso a segredos é visível nos logs de auditoria?

Uma regra prática: se um humano não colaria uma credencial em um job de build não confiável, não a dê a um agente autônomo sem escopo mais restrito e logging mais forte.

Logs e Trilhas de Auditoria

As equipes de segurança precisam de mais do que sucesso ou falha. Elas precisam saber qual código foi executado, quais arquivos foram alterados, quais chamadas de rede ocorreram e quais saídas foram produzidas.

Verifique:

• As invocações de comando são registradas com argumentos, diretório de trabalho, código de saída, horário de início e duração?
• Leituras, gravações, exclusões, uploads, downloads e alterações de permissão de arquivos são registrados?
• Instalações de pacotes e buscas externas são registradas?
• Ações de navegador, capturas de tela, downloads e envios de formulários são capturados quando relevantes?
• Chamadas de API, invocações de ferramentas e transições de modelo para ferramenta são correlacionadas à mesma sessão?
• Os logs são resistentes a adulteração a partir de dentro da sandbox?
• Qual é o período de retenção e quem pode acessar os logs?

Para fluxos de trabalho regulamentados ou empresariais, a trilha de auditoria deve apoiar tanto a depuração quanto a reconstrução pós-incidente. Uma transcrição parcial do terminal geralmente não é suficiente.

Captura e Revisão de Artefatos

Os agentes criam saídas úteis: diffs, resultados de teste, relatórios, capturas de tela, arquivos gerados, URLs de preview e conjuntos de dados. O tratamento de artefatos deve tornar essas saídas revisáveis sem expor mais estado do que o necessário.

Verifique:

• Quais artefatos são exportados automaticamente e quais exigem seleção explícita?
• Os revisores podem inspecionar arquivos gerados antes de serem commitados, enviados ou encaminhados a outro serviço?
• Os artefatos são verificados quanto a segredos, malware, tipos de arquivo inseguros ou tamanhos inesperados?
• Os downloads do navegador são armazenados separadamente dos diffs de código-fonte e das saídas de teste?
• Os artefatos podem ser vinculados ao comando exato, à etapa do agente e à sessão de sandbox que os produziu?
• Os artefatos são retidos após a exclusão da sandbox e podem ser purgados?

O objetivo é preservar evidências úteis, evitando um segundo canal de vazamento de dados por meio de logs, capturas de tela, arquivos ou pacotes gerados.

Controles de Ciclo de Vida e Redefinição

Sessões de agentes podem ser de curta duração, longas, pausadas, retomadas, capturadas em snapshots ou clonadas a partir de templates. Cada modo de ciclo de vida altera o limite.

Verifique:

• Cada sandbox é criada do zero, retomada a partir de estado ou clonada de um template?
• Quais dados sobrevivem à pausa, retomada, snapshot, criação de template e exclusão?
• Arquivos temporários, caches de pacotes, histórico do shell, cookies de navegador e bancos de dados locais são limpos na redefinição?
• Uma sessão comprometida pode envenenar um template reutilizável?
• Existe um tempo de vida máximo para a sessão?
• Sandboxes interrompidas são verdadeiramente encerradas ou tarefas em segundo plano podem continuar?
• A mesma tarefa pode ser reproduzida a partir de um ambiente limpo?

A capacidade de redefinição também é importante para cargas de trabalho de avaliação e aprendizado por reforço. Se cada tentativa começa a partir de um estado ligeiramente diferente, os achados de segurança e o comportamento do modelo se tornam mais difíceis de confiar.

Controles de Aprovação Humana

A aprovação humana não é apenas um recurso de UX. É um plano de controle para ações que cruzam limites de confiança.

Verifique:

• Quais ações podem ser executadas autonomamente e quais exigem aprovação?
• Os avisos de aprovação são específicos o suficiente para mostrar comando, arquivos, destino, escopo de credenciais e efeito esperado?
• As políticas podem exigir aprovação para instalação de pacotes, acesso externo à rede, gravações em repositório, comandos de implantação ou acesso a segredos?
• As aprovações são registradas com usuário, timestamp, ação e comando resultante?
• As aprovações podem ser limitadas no tempo e na tarefa, em vez de conceder permissão ampla para o futuro?
• Existe um caminho de break-glass e ele é auditado?

Use a aprovação humana para ações irreversíveis ou de alto impacto: excluir arquivos, gravar em branches de produção, chamar APIs de implantação, acessar dados de clientes e alterar templates de sandbox.

Premissas de Resposta a Incidentes

Nenhuma revisão de sandbox está completa sem perguntar o que acontece quando um limite falha ou um fluxo de trabalho se comporta inesperadamente. Isso é especialmente importante para sistemas de agentes, porque uma ação arriscada pode ser causada por saída do modelo, injeção de prompt, comprometimento de dependência ou bugs comuns de software.

Verifique:

• Quem é responsável pela triagem quando uma sandbox é suspeita de vazar dados ou executar código hostil?
• Sandboxes podem ser encerradas, colocadas em quarentena ou bloqueadas por projeto ou organização?
• O egresso de rede pode ser desabilitado rapidamente?
• Logs e artefatos são preservados para investigação?
• Templates afetados, caches de pacotes e snapshots são invalidados?
• As credenciais são rotacionadas automaticamente ou por meio de um runbook documentado?
• Existe uma distinção clara entre um problema de contenção da sandbox e um problema de política do agente?

A revisão deve terminar com um modelo de ameaças por escrito e um runbook curto. Mesmo que a decisão final seja “aprovado apenas para cargas de trabalho não sensíveis”, esse limite é útil.

Como a Novita Agent Sandbox se Enquadra

Novita Agent Sandbox é projetada para código gerado por IA, fluxos de navegador, uso por computador, avaliações, ambientes de aprendizado por reforço e tarefas de longa duração. A página do produto descreve sandboxes isoladas, inicialização em menos de um segundo, sessões persistentes, visualização de sessão ao vivo baseada em VNC, preços baseados em uso, templates e suporte a sistema de arquivos isolado. O quickstart da Novita Agent Sandbox mostra criação de sandbox via SDK, execução de comandos, listagem de arquivos e encerramento da sandbox.

Essas capacidades podem apoiar muitos dos fluxos de trabalho desta checklist, mas os critérios de avaliação e as afirmações do produto devem permanecer separados. Quando sua equipe revisar a Novita Agent Sandbox, ou qualquer outro runtime de agente, mapeie a configuração real que você planeja usar contra os controles acima: limite, arquivos, limites de processo, rede, DNS, buscas de pacotes, segredos, logs, artefatos, ciclo de vida, aprovação e resposta a incidentes.

Para equipes de engenharia que já usam as APIs de modelos da Novita AI, combinar a inferência de modelos com a execução em sandbox pode reduzir a dispersão de plataformas para cargas de trabalho de agentes. Para uso em produção sensível à segurança, ainda realize uma revisão específica da carga de trabalho antes de conectar a sandbox a repositórios privados, conjuntos de dados sensíveis, serviços internos ou credenciais de implantação.

Conclusão

Aprove uma sandbox de agente de IA somente depois que a revisão puder responder claramente a três perguntas: o que está isolado, o que ainda pode sair do limite e quais evidências permanecem se algo der errado. Se essas respostas forem vagas, limite a sandbox a cargas de trabalho não sensíveis até que os controles ausentes sejam documentados e testados.

Perguntas Frequentes

O que uma equipe de segurança deve verificar primeiro em uma revisão de sandbox de agente de IA?

Comece pelo limite de execução, pela exposição do sistema de arquivos e pelos padrões de rede. Esses três controles determinam se o código hostil pode alcançar o host, arquivos sensíveis ou destinos externos antes mesmo de você chegar a detalhes específicos do fluxo de trabalho, como aprovações e exportação de artefatos.

Uma sandbox somente com contêiner é suficiente para agentes de codificação autônomos?

Depende da carga de trabalho e dos dados que ela pode alcançar. Um contêiner pode ser aceitável para tarefas de baixa sensibilidade com montagens restritas, política de egresso rigorosa, credenciais de curta duração e logging forte, mas as equipes de segurança devem tomar essa decisão com base em controles documentados, e não apenas na palavra “contêiner”.

Por que DNS e acesso a pacotes devem ser revisados separadamente do egresso geral?

Porque os agentes frequentemente instalam dependências e resolvem hosts externos como parte da operação normal. Consultas DNS e buscas de pacotes podem se tornar tanto um caminho de exfiltração de dados quanto um risco de cadeia de suprimentos se não forem registradas, filtradas ou restritas.

Artigos recomendados:

• Como Sandboxes de Agente Impulsionam a Inovação em IA Segura e Escalável
• Construindo um Agente de Codificação com a Novita Agent Sandbox
• Novita vs E2B: A Comparação Definitiva de Sandboxes de Agente para Desenvolvedores e Empresas