Sandboxes para Agentes de Aprendizado por Reforço: Testes Seguros, Estado e Resetabilidade

Sandboxes de agentes RL devem tornar experimentos repetíveis ao isolar estado, controlar recursos, registrar ações e saídas, e redefinir ambientes entre testes. Isso é importante para aprendizado por reforço, loops de avaliação, agentes de codificação, agentes de navegador e qualquer sistema de tentativa e erro onde um agente pode executar comandos, modificar arquivos, chamar ferramentas ou alterar o ambiente do qual está aprendendo.

Por que agentes RL precisam de um sandbox

O aprendizado por reforço é construído em torno da interação. Um agente observa um ambiente, escolhe uma ação, recebe feedback e atualiza sua política ou processo de decisão. Em um simulador simples, esse loop pode apenas mover um token em uma grade. Em um sistema de agente moderno, a ação pode executar Python, instalar um pacote, editar um repositório, navegar por um aplicativo web, chamar uma ferramenta ou produzir um arquivo que um avaliador avalia.

Isso torna o ambiente de execução parte do experimento. Se dois testes compartilham um sistema de arquivos, cache, sessão de navegador, processo em segundo plano ou repositório parcialmente modificado, o segundo teste não está começando do mesmo estado que o primeiro. A recompensa pode melhorar porque o agente aprendeu, ou porque o ambiente reteve acidentalmente uma dependência, credencial, binário compilado, cookie de navegador ou arquivo auxiliar gerado. Sem contenção e comportamento de reset, é difícil distinguir.

Um sandbox fornece a cada teste um limite de execução definido. Não é uma estratégia de segurança completa por si só, e não remove a necessidade de design de recompensa, revisão de política, controle de acesso ou aprovação humana. Ele dá aos construtores um local controlado para executar ações do agente, observar efeitos colaterais, capturar artefatos e redefinir o ambiente antes da próxima tentativa.

Para trabalho de agente no estilo RL, a pergunta útil não é simplesmente “este sandbox é seguro?”. Uma pergunta melhor é: este ambiente de execução pode suportar experimentos repetíveis sem permitir que um teste contamine silenciosamente o próximo?

O que resetabilidade significa para testes de agentes RL

Resetabilidade é a capacidade de retornar o ambiente a uma linha de base conhecida antes de um novo episódio, avaliação ou lote de treinamento. Na prática, essa linha de base inclui mais do que um diretório limpo.

Um sandbox de agente RL pode precisar resetar:

• Arquivos criados, editados, excluídos ou baixados durante o teste.
• Pacotes instalados, caches de build, artefatos compilados e arquivos temporários.
• Processos em execução, portas, sockets, sessões de navegador e trabalhos em segundo plano.
• Variáveis de ambiente e credenciais com escopo.
• Fixtures de banco de dados, serviços locais, filas ou APIs simuladas.
• Política de rede, configuração de registro de pacotes e permissões de ferramentas.
• Estado da avaliação, logs de recompensa e entradas do avaliador.

O mecanismo de reset depende da carga de trabalho. Um benchmark de codificação pode restaurar um checkout de repositório e uma fixture de teste. Uma tarefa de navegador pode limpar cookies, armazenamento local, downloads e o perfil do navegador. Um agente de análise de dados pode resetar conjuntos de dados de entrada enquanto preserva apenas artefatos de saída aprovados. Uma avaliação de agente de múltiplas etapas pode precisar pausar, inspecionar e depois retomar ou descartar o sandbox.

O erro é tratar o reset como um script de limpeza que é executado no final. Scripts de limpeza falham. Agentes podem matá-los, travar antes de executar, encher o disco, deixar processos em segundo plano ou criar caminhos que o script não conhece. Um design mais forte inicia cada teste a partir de um template ou snapshot conhecido, registra o que mudou e depois derruba ou reseta todo o limite do ambiente de execução.

Ambientes repetíveis e snapshots de estado

Testes RL repetíveis precisam de uma linha de base clara. Essa linha de base deve definir a imagem do sistema operacional, runtimes de linguagem, pacotes, versões de conjuntos de dados, variáveis de ambiente, arquivos, política de rede, limites de recursos e comandos de entrada.

Existem três padrões comuns de linha de base:

Padrão	Melhor para	Cuidado com
Sandbox novo a partir de um template	Episódios independentes, avaliações em lote, tarefas de codificação, tarefas de navegador	Tempo de inicialização e instalação de pacotes pode dominar testes curtos
Snapshot e restauração	Tarefas de múltiplas etapas que precisam de um ambiente preparado antes de cada tentativa	Deriva de snapshot pode esconder alterações se o snapshot não for versionado
Sandbox de longa duração com checkpoints controlados	Depuração interativa, tarefas de currículo, correção com humano no loop	Estado pode vazar entre testes a menos que checkpoints sejam explícitos

Templates são úteis quando a maioria dos testes começa da mesma imagem conhecida. Snapshots são úteis após configuração cara: instalar dependências, baixar fixtures públicas, compilar um projeto ou abrir um workspace pronto para navegador. Sessões de longa duração podem ajudar com fluxos de trabalho de agente que genuinamente precisam de memória e estado, mas não devem se tornar o padrão para avaliação a menos que o modelo de estado faça parte do experimento.

Uma regra prática: defina o que pode persistir antes do teste começar. Se a resposta for “nada exceto artefatos aprovados”, use sandboxes novos ou restauração de snapshot. Se a resposta for “o agente deve construir em tentativas anteriores”, trate essa persistência como parte do experimento e registre-a como tal.

Execuções determinísticas e não determinísticas

Nem todo teste de agente pode ser perfeitamente determinístico. Amostragem de modelo de linguagem, APIs externas, tempo de navegador, disponibilidade de registro de pacotes, processos paralelos e latência de rede podem variar. Ainda assim, um sandbox pode reduzir as fontes evitáveis de variação.

Para execuções mais repetíveis, controle as partes que você pode:

• Fixe versões de pacotes, imagens de contêiner, conjuntos de dados, prompts, código do avaliador e configuração do modelo.
• Registre sementes aleatórias onde o modelo, ambiente ou avaliador as suporta.
• Congele fixtures de benchmark e saídas esperadas.
• Direcione instalações de pacotes através de registros ou caches aprovados.
• Evite sistemas de produção ao vivo como fontes de recompensa, a menos que a tarefa seja explicitamente sobre integração ao vivo.
• Capture os comandos exatos, chamadas de ferramentas, arquivos e destinos de rede usados durante a execução.

Em seguida, separe falhas determinísticas de comportamento estocástico. Se o teste 7 falhou porque o agente escolheu um plano diferente, isso é informação útil. Se o teste 7 falhou porque o teste anterior deixou um processo na mesma porta, isso é contaminação do ambiente. Se o teste 7 falhou porque um registro de pacotes retornou uma versão diferente, isso é deriva de dependência.

O sandbox deve tornar essas diferenças visíveis. O objetivo não é fingir que toda execução de agente RL é determinística. O objetivo é remover estado oculto e preservar evidências suficientes para explicar por que uma execução mudou.

Limites de recursos e tempo para loops de teste

Loops de RL e avaliação podem executar muitos testes. Um único bug de agente pode se multiplicar rapidamente: loops infinitos, instalações de pacotes descontroladas, processos bifurcados, grandes downloads, logs ilimitados ou sessões repetidas de navegador. Controles de recursos impedem que um teste ruim consuma todo o orçamento de avaliação.

Defina limites no nível do sandbox, não apenas dentro dos prompts do agente:

Limite	Por que é importante para agentes RL
Timeout de tempo real	Evita que episódios travados bloqueiem o lote
Cota de CPU e memória	Mantém um teste de sufocar testes vizinhos
Cota de disco	Controla logs, caches, instalações de pacotes e artefatos gerados
Limite de processos	Reduz falhas de subprocessos e trabalhos em segundo plano descontrolados
Política de rede	Evita chamadas inesperadas, downloads ou acesso interno
Limite de tamanho de saída	Mantém o contexto do modelo e pipelines de telemetria utilizáveis
Limite de sandboxes simultâneos	Protege orçamento e infraestrutura compartilhada durante varreduras

Timeouts precisam de nuance. Um timeout rígido é adequado para episódios curtos de benchmark. Uma tarefa de longa duração pode precisar de pausa, retomada ou checkpoint para que um humano possa inspecionar o progresso antes de decidir se continua. A parte importante é que a política de tempo de execução seja explícita. O agente não deve obter computação ilimitada só porque o loop de recompensa não terminou.

Telemetria para recompensas, avaliações e depuração

Sinais de recompensa só são úteis se você puder explicá-los. Em sistemas de agente, uma pontuação frequentemente combina muitas coisas: sucesso da tarefa, resultados de teste, códigos de saída de comandos, diffs de arquivos, estado do navegador, latência, uso de tokens, rótulos humanos e saída do avaliador. Um sandbox deve capturar as evidências necessárias para entender a pontuação sem armazenar segredos desnecessários ou dados privados.

Telemetria útil inclui:

• ID do sandbox, ID do teste, ID da tarefa, versão do template ou snapshot e hora de início.
• Configuração do modelo e agente usada para a execução.
• Chamadas de ferramentas, comandos de shell, códigos de saída e duração da execução.
• Arquivos lidos, escritos, criados, excluídos ou exportados.
• Domínios de rede contatados e nomes de pacotes instalados.
• Ações do navegador, screenshots, downloads e estado final da página quando relevante.
• Entradas do avaliador, saídas de recompensa, resultados de teste e erros do avaliador.
• Artefatos copiados para fora do sandbox para revisão.

Mantenha logs brutos com escopo. Saída completa de comandos, prompts brutos, screenshots de navegador e arquivos gerados podem conter informações sensíveis. Para muitos sistemas, o padrão melhor é telemetria estruturada mais artefatos retidos seletivamente. Armazene o suficiente para reproduzir e depurar a execução; evite transformar logs em um segundo data lake cheio de credenciais, dados de clientes e saída de modelo não revisada.

O design de recompensa também deve levar em conta os limites do sandbox. Se o agente não pode acessar a internet pública, não o pontue como falha porque um site ao vivo estava indisponível. Se o sandbox tem uma cota de disco pequena, meça se o agente lidou com essa restrição, não se ele poderia forçar o armazenamento. A política do ambiente e a função de recompensa devem concordar.

Limites de arquivos, rede e ações inseguras

O sandbox é mais útil quando restringe o que um agente pode tocar. Para testes no estilo RL, comece com a suposição de que o agente pode descobrir ações surpreendentes. Ele pode executar comandos que o prompt não mencionou, inspecionar arquivos ocultos, tentar novamente um caminho de rede bloqueado, instalar pacotes ou gerar scripts que mudam o comportamento em etapas posteriores.

Use limites de sistema de arquivos que correspondam à tarefa:

• Monte entradas como somente leitura quando o agente só precisa inspecioná-las.
• Coloque saídas geradas em um diretório gravável separado.
• Mantenha credenciais, configuração do host, perfis de navegador e chaves de implantação fora do workspace.
• Resete diretórios graváveis entre testes.
• Copie para fora apenas artefatos aprovados, não todo o workspace por padrão.

A política de rede precisa da mesma precisão. Um benchmark de codificação pode não precisar de acesso à internet. Uma tarefa de instalação de pacotes pode precisar de uma lista de permissões de registro. Uma avaliação de agente de navegador pode precisar de sites públicos específicos e endpoints internos de metadados bloqueados. Um fluxo de trabalho de agente de dados pode precisar de uma API restrita em vez de ampla acessibilidade à rede privada.

Ações inseguras devem permanecer fora do loop automático, a menos que o experimento as inclua explicitamente e o caminho de revisão esteja claro. Exemplos incluem deploys de produção, mensagens voltadas ao cliente, alterações de faturamento, edições de controle de acesso, grandes exportações, gravações destrutivas de banco de dados e modificações de infraestrutura. Um sandbox pode conter efeitos colaterais de tempo de execução; ele não pode decidir quais ações de negócio merecem aprovação.

Captura de artefatos e revisão humana

O final de um teste de agente RL deve produzir um registro passível de revisão. Isso não significa preservar tudo. Significa preservar os artefatos necessários para pontuar, auditar e aprender com o teste.

Para agentes de codificação, isso pode ser um patch, log de teste, relatório gerado e diff final do workspace. Para agentes de navegador, pode ser uma sequência de screenshots, arquivo baixado, URL final e resumo do DOM. Para agentes de análise de dados, pode ser um notebook, gráfico, conjunto de dados transformado e pontuação do avaliador. Para fluxos de trabalho sensíveis à segurança, pode incluir ações negadas e solicitações de aprovação.

A revisão humana pertence no limite onde a experimentação em sandbox afetaria sistemas externos. Bons pontos de revisão incluem:

• Antes de exportar arquivos de um sandbox para um workspace de produção.
• Antes de enviar mensagens, abrir tickets, publicar páginas ou implantar código.
• Antes de conceder novas permissões de rede, sistema de arquivos ou segredos.
• Antes de usar uma política aprendida em usuários ao vivo ou dados de clientes.
• Após falhas repetidas que sugerem hacking de recompensa, injeção de prompt ou uso indevido do ambiente.

A revisão deve ser projetada no loop, não anexada depois que o agente tem acesso amplo. O sandbox deve tornar a ação proposta, os artefatos de suporte e o histórico do teste fáceis de inspecionar.

Onde o Novita Agent Sandbox se encaixa

Novita Agent Sandbox é um sandbox em nuvem para agentes de IA que precisam de ambientes isolados para execução de código, trabalho com sistema de arquivos, fluxos de trabalho no estilo navegador e tarefas de longa duração. A documentação atual do Novita descreve capacidades do sandbox como execução de comandos, operações de arquivos, templates, snapshots, pausa e retomada, execução em segundo plano e gerenciamento de ciclo de vida via SDK/CLI.

Para trabalho de agente no estilo RL, esses primitivos mapeiam para os requisitos centrais do ambiente:

Requisito de agente RL	Primitivo do sandbox a procurar
Iniciar cada teste a partir de uma linha de base conhecida	Criação de sandbox baseada em template ou snapshot
Executar ações do agente sem acesso ao host	Execução isolada de comandos e sistema de arquivos com escopo
Preservar apenas saídas selecionadas	Operações de arquivos e política de exportação de artefatos
Suportar avaliações de longa duração	Execução em segundo plano, pausa/retomada, política de timeout
Depurar testes falhos ou surpreendentes	Logs, resultados de comandos, diffs de arquivos e artefatos capturados
Separar avaliação da lógica do aplicativo	Controles de ciclo de vida via SDK/CLI em torno de cada execução

Mantenha o limite do produto claro. Novita Agent Sandbox fornece primitivos de ambiente de execução que podem suportar infraestrutura de avaliação e agente RL, mas os construtores ainda definem a função de recompensa, template do ambiente, política de ferramentas, regras de rede, esquema de telemetria, tratamento de segredos e fluxo de trabalho de aprovação humana. Não trate nenhum provedor de sandbox como uma camada de segurança completa para agentes autônomos.

Lista de verificação do sandbox de agente RL

Use esta lista de verificação antes de executar testes repetidos no estilo RL ou grandes lotes de avaliação:

Área	Perguntas a responder
Linha de base	De qual template, snapshot, conjunto de dados, conjunto de dependências e versão do avaliador cada teste começa?
Reset	Qual estado é limpo entre testes, e qual estado é intencionalmente preservado?
Determinismo	Quais sementes, versões de pacotes, configurações de modelo e fixtures estão fixadas?
Sistema de arquivos	Quais caminhos são somente leitura, graváveis, ocultos ou exportados?
Rede	O tráfego de saída está bloqueado, em lista de permissões, com proxy, registrado ou específico da tarefa?
Recursos	Quais são os limites de CPU, memória, disco, processos, timeout e concorrência?
Ferramentas	Quais comandos, gerenciadores de pacotes, navegadores e APIs o agente pode invocar?
Recompensas	Quais evidências alimentam a recompensa, e a pontuação pode ser explicada a partir de artefatos capturados?
Telemetria	Comandos, alterações de arquivos, chamadas de rede, saídas e resultados do avaliador são registrados sem armazenar segredos?
Artefatos	Quais saídas são copiadas para fora, retidas, redigidas ou descartadas?
Revisão humana	Quais ações requerem aprovação antes de sair do sandbox ou tocar em sistemas externos?

Se uma linha não estiver clara, corrija isso antes de escalar o loop. Pequenas ambiguidades se tornam caras quando multiplicadas por centenas ou milhares de testes.

Perguntas Frequentes

O que é um sandbox de agente RL?

Um sandbox de agente RL é um ambiente de execução isolado onde um agente pode tomar ações, receber feedback e resetar para um estado de ambiente conhecido entre testes. É usado para manter experimentos repetíveis, conter efeitos colaterais e capturar evidências para pontuação e depuração.

Por que a resetabilidade é importante para agentes de aprendizado por reforço?

A resetabilidade impede que arquivos, processos, caches, sessões de navegador ou pacotes instalados de um teste influenciem o próximo teste. Sem um reset confiável, mudanças na recompensa podem refletir deriva oculta do ambiente em vez de melhor comportamento do agente.

Sandboxes de agentes RL tornam agentes autônomos seguros?

Não. Um sandbox pode reduzir o raio de explosão do ambiente de execução e tornar os efeitos colaterais mais fáceis de observar, mas não é uma garantia completa de segurança. Construtores ainda precisam de permissões com escopo, política de rede, tratamento de segredos, design de recompensa, monitoramento e revisão humana para ações externas sensíveis.

Todo teste RL deve começar de um sandbox novo?

Nem sempre. Sandboxes novos são melhores para avaliações independentes. A restauração de snapshot pode ser mais eficiente após uma configuração cara. Sandboxes de longa duração podem se adequar a trabalho interativo ou no estilo de currículo, mas o estado persistente deve ser explícito e registrado.

O que um sandbox de agente RL deve registrar?

Registre o ID do teste, linha de base do sandbox, comandos, chamadas de ferramentas, códigos de saída, alterações de arquivos, destinos de rede, uso de recursos, entradas do avaliador, saídas de recompensa e artefatos aprovados. Evite registrar segredos brutos, dados desnecessários de clientes ou conteúdo completo de arquivos não revisados por padrão.

Artigos recomendados

• MCP Servers in Isolated Sandboxes: Filesystem, Secrets, and Network Tradeoffs
• Building a Coding Agent with Novita’s Agent Sandbox
• How Agent Sandboxes Power Secure, Scalable AI Innovation