Sandbox de Código Gerado por IA: Requisitos para Aplicações de Produção

Aplicações de produção que executam código gerado por IA precisam de um sandbox que garanta isolamento em nível de processo, suporte a sessões concorrentes, exponha uma API de ciclo de vida programável, forneça logs e métricas de recursos observáveis, imponha políticas de pacotes e rede e se integre de forma limpa com o backend da aplicação. Escolher um sandbox sem avaliar cada uma dessas dimensões de forma sistemática é a maneira mais comum de as equipes encontrarem problemas após o lançamento: uma carga de trabalho que parecia segura em staging falha sob tráfego real, vaza estado entre tenants ou executa silenciosamente código que a aplicação nunca teve a intenção de permitir.

Este guia é um checklist de requisitos. Ele abrange o que verificar em cada nível de isolamento, o que uma API de ciclo de vida de produção deve expor, como devem ser a observabilidade e os controles de recursos, e onde os padrões de integração com backend podem fazer ou quebrar o design. Esteja você avaliando um sandbox gerenciado ou construindo o seu próprio, estas são as perguntas que valem a pena responder antes de lançar.

Isolamento do Sandbox: Processo, Contêiner e MicroVM

Isolamento é um espectro, e cada nível traz diferentes compromissos entre desempenho, portabilidade e o quanto de confiança você está estendendo ao código gerado.

Isolamento em nível de processo usa primitivas do SO — namespaces, cgroups, seccomp e perfis AppArmor ou SELinux — para restringir o que um processo pode acessar. É rápido e não requer um kernel de VM separado, mas todos os processos compartilham o kernel do host. Uma vulnerabilidade do kernel ou uma chamada de sistema privilegiada que passe pelo filtro seccomp pode afetar outras cargas de trabalho no mesmo host. O isolamento de processo é um ponto de partida razoável para caminhos de código de baixo risco, curta duração e confiáveis, mas é um limite fraco para código gerado por IA não confiável que pode tentar chamadas de sistema, criação de subprocessos ou instalação de pacotes.

O que verificar neste nível:

• Quais chamadas de sistema estão bloqueadas e qual é a política padrão quando uma chamada de sistema desconhecida é tentada?
• Os namespaces são escopados por tarefa, por tenant ou compartilhados entre jobs?
• Os limites de cgroup são aplicados no nível da tarefa ou apenas no nível do host?
• O sandbox limpa todos os processos, arquivos temporários, sockets e memória compartilhada ao sair?

Isolamento em nível de contêiner adiciona um limite de sistema de arquivos e namespace de rede, tornando o gerenciamento de imagens repetível. Contêineres são mais rápidos de iniciar do que VMs completas, mais fáceis de compor e amplamente suportados por camadas de orquestração. A contrapartida é que os contêineres ainda compartilham o kernel do host, e o limite do contêiner é tão forte quanto a configuração do runtime subjacente. Contêineres privilegiados, conjuntos amplos de capacidades, sockets do host montados e modo de rede do host reduzem o limite efetivo a praticamente nada.

O que verificar neste nível:

• A imagem do contêiner é mínima, contendo apenas os runtimes e ferramentas que a carga de trabalho realmente precisa?
• As capacidades são reduzidas ao conjunto mínimo necessário?
• O contêiner é rootless ou requer root e quais controles existem em torno disso?
• O namespace PID do host, a rede do host e o socket Docker estão explicitamente excluídos?
• Os volumes montados são limitados a caminhos explicitamente definidos e o sistema de arquivos raiz é somente leitura sempre que possível?

Isolamento microVM coloca cada carga de trabalho dentro de uma máquina virtual leve — com seu próprio kernel convidado, dispositivos virtuais e um limite baseado em KVM entre o convidado e o host. Tecnologias como Firecracker usam um modelo de dispositivo mínimo para reduzir a superfície de ataque, mantendo a inicialização rápida o suficiente para uso interativo. O limite do microVM significa que uma exploração do kernel no convidado não afeta automaticamente o host ou outros convidados.

O que verificar neste nível:

• Cada execução de agente, cada tenant ou cada sessão concorrente recebe um microVM separado?
• Qual é a latência de inicialização desde a chamada da API até estar pronto para executar, e isso é medido a partir de um pool aquecido, snapshot ou boot frio?
• As imagens convidadas são versionadas, auditadas quanto aos runtimes e ferramentas que incluem e atualizadas em uma programação regular?
• O que acontece no nível do host se o kernel convidado entrar em pânico ou se tornar não responsivo?

A decisão prática está relacionada ao seu modelo de ameaça. O isolamento microVM é o limite geralmente disponível mais forte para código gerado por IA não confiável, mas não substitui a política de sistema de arquivos, controles de saída, governança de pacotes ou tratamento de segredos. Esses controles devem estar acima de qualquer camada de isolamento que você escolher.

Gerenciando Sessões Concorrentes no Sandbox

Uma aplicação de produção que gera código para múltiplos usuários simultaneamente precisa de um sandbox que lide com concorrência como uma preocupação de primeira classe, não como uma reflexão tardia.

As principais perguntas são:

Isolamento por sessão: Quando 50 sessões estão sendo executadas ao mesmo tempo, cada sessão tem seu próprio sistema de arquivos isolado, árvore de processos, namespace de rede e escopo de credenciais? O vazamento de estado entre sessões é um dos modos de falha mais prejudiciais em aplicações multi-tenant em sandbox, e muitas vezes é invisível em testes onde as sessões são executadas sequencialmente.

Limites de sessão e backpressure: O sandbox expõe os limites de concorrência como um contrato de API claro? Se 500 requisições chegarem e a plataforma suportar 100 sessões concorrentes, a API retorna um erro estruturado, enfileira a requisição ou degrada silenciosamente? Aplicações de produção precisam desse sinal para implementar backpressure, gerenciamento de filas e feedback visível ao usuário.

Justiça de recursos sob carga: Quando uma sessão consome CPU ou memória excepcionalmente altos, outras sessões são protegidas por limites de recursos por sessão, ou uma carga de trabalho ruidosa pode degradar todo o pool?

Pools aquecidos e latência de inicialização de sessão: Recursos de codificação interativos precisam de tempos de início de sessão abaixo de um segundo. Isso geralmente requer um pool de ambientes pré-inicializados que podem ser reivindicados imediatamente, em vez de inicializados sob demanda. Verifique se a plataforma documenta a disponibilidade de pool aquecido e qual latência de inicialização esperar em diferentes níveis de concorrência.

Reutilização de sessão vs. ambientes novos: Algumas aplicações se beneficiam da reutilização de uma sessão de longa duração em várias etapas do agente, enquanto outras precisam de um ambiente limpo para cada requisição. Verifique se ambos os padrões são suportados e se a reutilização de sessão não carrega estado obsoleto de uma conversa anterior.

API de Ciclo de Vida: Criar, Executar, Encerrar

A API de ciclo de vida é a interface entre sua aplicação e o runtime do sandbox. Uma API de nível de produção deve expor no mínimo:

Criar: Inicializar uma nova sessão de sandbox, opcionalmente a partir de um template ou snapshot, com limites de recursos especificados, variáveis de ambiente e volumes montados. A resposta deve incluir um ID de sessão e um sinal de pronto, não apenas um reconhecimento.

Executar: Enviar código ou um comando para execução. Deve ser uma chamada assíncrona que retorna um ID de execução. A API deve suportar a especificação de um diretório de trabalho, substituições de ambiente para a chamada e um timeout.

Transmitir saída: Recuperar stdout e stderr como um stream, não apenas como um resultado final após a conclusão da execução. A transmissão é importante para jobs de longa duração, etapas de agente que levam muitos segundos e qualquer UX que mostre progresso incremental ao usuário.

Encerrar: Finalizar uma execução em andamento antes de sua conclusão. O sandbox deve garantir que a árvore de processos seja limpa, não apenas o processo pai.

Limpeza: Destruir a sessão e liberar todos os recursos associados — sistema de arquivos, memória, slots de processo, estado de rede e quaisquer credenciais mantidas. Esta chamada deve ser idempotente para que novas tentativas após um erro de rede não causem erros.

Carregar e baixar arquivos: Transferir arquivos de entrada para o sandbox antes da execução e recuperar artefatos de saída após. As transferências de arquivos devem ser limitadas por limites de tamanho e controladas por política para quais caminhos são graváveis.

Capacidades adicionais que valem a pena verificar para uso em produção:

• Pausar e retomar: Uma sessão de longa duração pode ser suspensa e retomada posteriormente sem perder estado? Isso é útil para limitação de taxa, controle de custos e transferência de sessão entre etapas do agente.
• Snapshot: O estado atual da sessão pode ser capturado e usado como ponto de partida para sessões futuras? Este é o mecanismo chave para pools aquecidos e ambientes reutilizáveis.
• Aplicação de timeout: Se o código em execução exceder o timeout de relógio de parede, a plataforma o encerra de forma limpa e relata o status de saída correto?

Observabilidade: Logs, Métricas e Rastreamentos

Você não pode depurar ou auditar o que não pode ver. Sandboxes de produção precisam de observabilidade integrada, não adicionada posteriormente.

Captura de stdout e stderr: Cada execução deve produzir um registro de saída capturada associado ao ID da sessão e ID da execução. Isso deve ser acessível via API após a conclusão da execução, não apenas disponível como um stream em tempo real.

Logs de execução: A plataforma deve registrar qual código foi executado, quando começou, quando terminou, qual foi o código de saída, qual usuário ou tenant possuía a sessão e qual template ou snapshot foi usado. Esses registros são o mínimo necessário para reconstruir o que aconteceu quando algo dá errado.

Métricas de recursos: Aplicações de produção precisam de métricas por sessão para uso de CPU, pico de memória, tempo de relógio de parede e gravações no sistema de arquivos. Isso permite planejamento de capacidade, detecção de anomalias e atribuição de custo por sessão.

Rastreamento de erros: Quando um sandbox falha ao iniciar, executar ou limpar, a superfície de erro deve ser estruturada: código de erro, mensagem, ID da sessão e contexto suficiente para distinguir um erro do usuário (código ruim, pacote ausente) de um erro da plataforma (cota excedida, falha interna).

Trilha de auditoria: Para aplicações multi-tenant, a trilha de auditoria deve tornar o comportamento do agente reconstruível: ID da sessão, tenant, sequência de execução, instalações de pacotes, domínios externos contatados, arquivos gravados e resultado da limpeza. O código bruto do cliente e a saída completa do comando podem não pertencer aos logs de auditoria por padrão — projete para o que suas políticas de retenção e acesso podem realmente suportar.

O que evitar: um sandbox que mostra apenas “execução falhou” sem erro estruturado, logs em nível de sessão e nenhuma maneira de distinguir um timeout de um OOM de uma tentativa de fuga de processo. Isso força você a instrumentar tudo na camada da aplicação, o que duplica o trabalho e perde eventos que o sandbox pode observar diretamente.

Limites de CPU, Memória e Timeout

O consumo ilimitado de recursos é uma das maneiras mais simples de uma carga de trabalho em sandbox causar problemas em produção — seja degradando outras sessões ou criando custos de infraestrutura inesperados.

Um sandbox de produção deve impor limites no nível da sessão, não apenas no nível do host:

CPU: Limitar quanto tempo de CPU uma única sessão pode consumir. Uma sessão que gera um loop infinito não deve degradar outras sessões no mesmo host. Verifique se o limite é um teto rígido (o processo é limitado ou morto) ou um limite flexível (está competindo com outros processos pela CPU disponível).

Memória: Definir um limite de memória que aciona a limpeza ou encerramento, em vez de permitir que a sessão esgote a memória do host. Verifique o que acontece quando o limite é atingido: morte OOM, resposta de erro estruturada ou travamento silencioso.

Timeout de relógio de parede: Cada chamada de execução deve ter uma duração máxima. O timeout deve ser aplicável no nível da plataforma, não apenas no nível do cliente — se o cliente perder a conexão, o sandbox ainda deve encerrar a execução no limite configurado.

Uso de disco: O código gerado pode gravar arquivos de saída grandes, instalar pacotes grandes ou preencher o diretório de trabalho. Uma cota de disco no diretório de trabalho da sessão evita gravações descontroladas.

Contagem de processos: O código gerado por IA pode criar subprocessos, workers em segundo plano ou comandos de shell que, por sua vez, criam mais processos. Um limite no número total de processos no namespace da sessão evita fork bombs e árvores de subprocessos descontroladas.

Ao avaliar uma plataforma de sandbox, verifique se esses limites são configuráveis por sessão (para que diferentes níveis de usuário ou tipos de tarefa possam ter limites diferentes), se são aplicados no nível do sandbox e se atingir um limite produz um erro de API estruturado ou uma falha silenciosa.

Políticas de Instalação de Pacotes

O código gerado por IA frequentemente solicita instalações de pacotes — pip install, npm install, apt-get, clones Git, buscas de URL diretas. Cada uma dessas operações puxa código externo para o sandbox em tempo de execução, o que é uma das operações de maior risco que um sandbox precisa governar.

Uma política de pacotes de produção deve cobrir:

Listas de permissão de registros: Quais registros de pacotes são permitidos? PyPI e npm são padrões, mas muitas equipes desejam a opção de restringir a mirrors internos, registros curados ou fontes explicitamente aprovadas.

Cache de instalação: Quando muitas sessões instalam os mesmos pacotes populares, um cache de camadas ou proxy pull-through evita downloads redundantes, reduz a latência de inicialização e fornece um ponto para inspecionar o que está sendo buscado.

Modo offline: Algumas cargas de trabalho devem ser executadas sem instalações de pacotes — o ambiente é pré-construído na imagem ou template, e as tentativas de instalação devem falhar com um erro claro. Este é o modo apropriado para execuções de avaliação onde a reprodutibilidade importa mais do que a flexibilidade.

Verificação de hash e lockfiles: Quando pacotes são permitidos, versões fixadas e verificação de hash reduzem o risco de um comprometimento do registro alterar qual código é executado dentro do sandbox.

Limites de tamanho: Pacotes e suas dependências transitivas podem ser grandes. Um limite de tamanho no total de downloads por sessão evita a exaustão acidental ou intencional de armazenamento.

Registro de pacotes: Cada tentativa de instalação deve ser registrada no log de auditoria de execução: nome do pacote, versão solicitada, origem do registro e sucesso ou falha. Esses são os dados necessários para reconstruir o que entrou no sandbox durante um incidente.

A pergunta a fazer a um fornecedor de sandbox não é “os usuários podem instalar pacotes?” mas sim “como cada instalação é auditada, quais registros são permitidos por padrão e posso configurar uma política mais rigorosa para cargas de trabalho sensíveis?”

Controles de Rede e Egresso

O acesso à rede é o segundo vetor principal para um sandbox alcançar destinos inesperados. Egresso aberto por padrão é conveniente no desenvolvimento, mas é um padrão ruim para aplicações de produção que executam código gerado por IA.

Egresso negado por padrão: A postura de produção mais forte é bloquear todas as conexões de saída por padrão e permitir explicitamente os destinos que uma sessão legitima precisa. Isso requer mais configuração, mas torna o modelo de acesso auditável.

Destinos permitidos: Para agentes de codificação, destinos permitidos típicos podem incluir registros de pacotes, um conjunto específico de APIs públicas que o agente foi construído para chamar e nada mais. Para agentes de análise de dados, a lista pode incluir fontes de dados específicas. Verifique se a plataforma suporta listas de permissão de destino por sessão ou por tenant.

Política de DNS: O DNS deve ser tratado de forma consistente com a política de egresso. Uma sessão que não pode alcançar destinos HTTP arbitrários também não deve ser capaz de resolver nomes DNS arbitrários e usar isso para inferir topologia de rede ou contornar controles por meio de canais baseados em DNS.

Acesso a serviços internos: O código gerado por IA não deve ser capaz de alcançar endpoints de metadados da nuvem (por exemplo, o serviço de metadados de instância da AWS), APIs internas, bancos de dados privados ou painéis de administração, a menos que explicitamente configurados. Verifique se a política de rede padrão do sandbox bloqueia intervalos de endereços internos conhecidos.

Egresso de download de pacotes: Instalações de pacotes são operações de rede. Se o egresso for restrito, certifique-se de que a lista de permissão do registro de pacotes seja consistente com a política de egresso, ou use um proxy pull-through dentro da rede confiável.

Registro de conexões de saída: Mesmo quando o egresso é permitido, registrar quais domínios e IPs uma sessão contatou é útil para investigação de incidentes. Nem todas as plataformas de sandbox fornecem isso nativamente; verifique o que você obterá.

Segredos e Injeção de Credenciais

Agentes de IA frequentemente precisam de credenciais — chaves de API, conexões de banco de dados, tokens OAuth, credenciais de nuvem de curta duração. Como um sandbox lida com segredos é importante tanto para a segurança quanto para a confiabilidade operacional.

Escopo estreito: Cada sessão deve receber apenas os segredos necessários para a tarefa específica que está executando. Montar um arquivo de ambiente amplo com todas as credenciais em cada sessão é conveniente operacionalmente, mas significa que código comprometido ou mal-comportado em qualquer sessão pode alcançar todas essas credenciais.

Credenciais de curta duração: Onde o backend suportar, prefira tokens de curta duração com um TTL com escopo definido para a duração da sessão. Isso limita a janela durante a qual uma credencial vazada é útil.

Mecanismo de injeção: Verifique se os segredos são injetados como variáveis de ambiente, arquivos montados ou por meio de uma API de segredos. As variáveis de ambiente são acessíveis a todos os processos na sessão por padrão; os arquivos montados podem ser escopados para um caminho e conjunto de permissões. Para as credenciais mais sensíveis, considere uma API de segredos que forneça valores apenas a um processo explicitamente autorizado.

Redação: O sandbox não deve ecoar segredos de volta através de stdout, stderr, logs de execução, mensagens de erro ou respostas de ferramentas visíveis ao modelo. A redação é uma responsabilidade da camada de aplicação, mas um sandbox que suporta a limpeza configurável de logs reduz o raio de explosão de uma exposição acidental.

Limpeza: Após o término da sessão, verifique se as variáveis de ambiente, arquivos de segredos montados e quaisquer dados de credenciais em cache são limpos como parte da destruição da sessão, não deixados para a próxima sessão herdar.

Armazenamento de Arquivos Efêmero vs. Persistente

Diferentes cargas de trabalho têm diferentes necessidades de persistência, e um sandbox de produção deve suportar ambos os padrões claramente.

Sessões efêmeras: O padrão para execução de código de curta duração é uma sessão que cria um diretório de trabalho limpo, executa código, produz saída e é destruída. Sessões efêmeras são fáceis de entender: cada execução começa de uma linha de base conhecida, nenhum estado se acumula e a limpeza é direta. Elas são a escolha certa para jobs de avaliação, conclusões de código únicas e qualquer tarefa onde a reprodutibilidade importa mais do que a continuidade.

Espaços de trabalho persistentes: Agentes de codificação de longa duração, fluxos de trabalho de desenvolvimento iterativos e sessões de agente com várias etapas geralmente precisam de um espaço de trabalho que sobreviva a várias chamadas de execução. Arquivos instalados, dependências em cache, código escrito e histórico acumulado em uma etapa devem estar disponíveis na próxima. Espaços de trabalho persistentes são mais complexos de operar: eles acumulam estado, podem se desviar do template e precisam de um ciclo de vida explícito — quando o espaço de trabalho é limpo, quem o possui e quais controles de acesso o protegem entre as sessões?

Snapshots e templates: Templates permitem definir um ambiente de linha de base conhecido e bom — runtimes, ferramentas, dependências — e iniciar sessões a partir dele de forma consistente. Snapshots capturam o estado atual de uma sessão em execução e o usam como ponto de partida para sessões futuras. Ambos são úteis para equipes que precisam de ambientes repetíveis e baixa latência de inicialização. Verifique se os templates são versionados, se quem pode criá-los e atualizá-los é controlado e se os snapshots são isolados por tenant.

Exportação de artefatos de saída: Após a execução, o que pode sair do sandbox? Uma política de produção deve definir quais caminhos de arquivo são exportáveis, quais limites de tamanho se aplicam e se os artefatos são revisados ou filtrados antes de a aplicação recebê-los.

Estado entre sessões: Seja explícito sobre se o design da sua aplicação pretende que as sessões compartilhem estado ou não. O compartilhamento acidental — por meio de um cache de pacotes compartilhado, um volume compartilhado ou um espaço de trabalho mal roteado — é uma falha comum de isolamento multi-tenant.

Integração com Backend: REST, WebSocket, SDK

Um sandbox só é útil se ele se integrar de forma limpa ao backend da aplicação. Os três principais padrões de integração são REST, WebSocket e SDK.

REST: Uma API REST é a integração de menor atrito para aplicações que enviam requisições de execução discretas e consultam resultados. Funciona bem para tarefas de curta duração, é fácil de depurar com ferramentas HTTP padrão e se encaixa naturalmente em arquiteturas de serviço existentes. A contrapartida é que consultar resultados adiciona latência em comparação com notificações push, e transmitir saída de longa duração requer SSE ou consultar um endpoint de log.

WebSocket: Uma conexão WebSocket suporta comunicação bidirecional de baixa latência entre a aplicação e o sandbox. Esta é a escolha certa para casos de uso interativos: um assistente de codificação que transmite saída à medida que o código é executado, um agente de navegador que precisa enviar comandos e receber respostas em tempo real, ou um harness de avaliação que monitora a execução continuamente. A contrapartida é a complexidade operacional: conexões WebSocket exigem estado persistente, tratamento de reconexão e infraestrutura mais complexa tanto no lado do cliente quanto do servidor.

SDK: Um SDK nativo da linguagem oculta detalhes de transporte, lida com autenticação, fornece interfaces tipadas para gerenciamento de sessão e execução, e geralmente inclui ajudantes para transmitir saída, carregar arquivos e gerenciar templates. Um SDK é o caminho mais rápido para integração para a maioria dos desenvolvedores de aplicações. Verifique se o SDK é mantido ativamente, cobre toda a superfície da API e lida com erros de forma estruturada que sua aplicação possa processar.

Pontos de integração que sua aplicação precisa possuir: Independentemente do transporte, sua aplicação é responsável pela autorização (quais usuários podem criar sessões e com quais limites de recursos), portas de aprovação (quais chamadas de ferramenta ou execuções de código exigem revisão humana antes de executar), manipulação de resultados (como a saída do sandbox é apresentada ou processada pelo agente) e limpeza (acionar a destruição da sessão quando o fluxo do usuário é concluído ou a etapa do agente termina).

Uma API de sandbox bem projetada não tenta possuir a lógica de negócios da sua aplicação. Ela expõe primitivas — criar, executar, transmitir, encerrar, limpar — e permite que sua camada de aplicação construa o comportamento correto do produto sobre elas.

Recuperação de Falhas e Limpeza

Sistemas de produção falham. Um sandbox que lida com falhas graciosamente evita vazamentos de recursos, estado obsoleto e incidentes difíceis de depurar.

Tratamento de timeout de execução: Quando uma execução em andamento excede seu timeout, a plataforma deve encerrar a árvore de processos de forma limpa e retornar uma resposta de erro estruturada — não deixar uma sessão zumbi consumindo recursos. Verifique o que acontece com a sessão após um timeout: ela é automaticamente limpa ou requer uma chamada de limpeza explícita?

Recuperação de falha de sessão: Se o host do sandbox falhar ou a VM da sessão sair inesperadamente, a plataforma deve detectar a falha, marcar a sessão como encerrada e mostrar esse estado através da API para que a aplicação possa reagir. As sessões não devem desaparecer silenciosamente sem nenhum sinal da API.

Garantias de limpeza: Uma chamada de API cleanup ou terminate deve liberar todos os recursos de forma confiável: alocações de CPU e memória, cota do sistema de arquivos, slots de processo, estado de rede e credenciais. A limpeza deve ser idempotente — chamá-la várias vezes no mesmo ID de sessão não deve retornar um erro. Isso importa na prática: o código da aplicação que tenta limpar novamente após um erro de rede não deve quebrar.

Falhas parciais de execução: Quando o código falha no meio da execução — uma exceção não tratada, um processo morto, um pacote ausente — o sandbox deve retornar um resultado estruturado que distingue sucesso parcial (alguma saída foi produzida antes da falha) de falha total. As aplicações construídas em resultados parciais precisam disso para evitar apresentar saída incompleta ou enganosa aos usuários.

Tratamento de processos descontrolados: Se o código gerado criar um processo em segundo plano que sobrevive à execução principal, o sandbox deve encerrá-lo como parte da limpeza da sessão, em vez de permitir que ele seja executado indefinidamente. Verifique se a limpeza da plataforma cobre toda a árvore de processos, não apenas o filho imediato da chamada de execução.

Erros de capacidade e cota: Quando a plataforma está na capacidade máxima de sessões ou um tenant atingiu sua cota, a API deve retornar um código de erro específico que a aplicação possa tratar explicitamente — não um 500 genérico ou um travamento silencioso. Isso permite que a aplicação enfileire, recue ou mostre uma mensagem útil ao usuário.

Novita Agent Sandbox

O Novita Agent Sandbox é uma plataforma de sandbox gerenciada construída para cargas de trabalho de agentes. Ele tem como alvo agentes de codificação, agentes de análise de dados, fluxos de trabalho orientados a navegador e sessões de agente de longa duração onde o código gerado precisa ser executado em um ambiente isolado e observável, sem pousar em servidores de aplicação ou infraestrutura compartilhada.

Para equipes que já usam as APIs de modelo da Novita AI, o Agent Sandbox pode fazer parte de uma arquitetura de agente mais ampla: o modelo planeja e gera código, o sandbox fornece execução isolada com um ciclo de vida programável, e a camada de aplicação possui autorização, portas de aprovação e manipulação de resultados.

A Novita descreveu capacidades incluindo isolamento microVM, suporte a sessões concorrentes, uma API de ciclo de vida cobrindo criar, executar, transmitir, encerrar e limpar, Pausa e Retomada Automática para gerenciamento de estado de sessão, templates e snapshots para inicialização rápida e repetível de ambientes, e integração com as APIs de modelo da Novita. Verifique a disponibilidade atual de recursos, opções de configuração de recursos e preços na documentação do Novita Agent Sandbox e na página do produto antes de tomar decisões de arquitetura. Alegações sobre limites de isolamento específicos, limites de concorrência, latência de inicialização e política de rede devem ser confirmadas com a documentação atual do produto.

Ao avaliar o Novita Agent Sandbox em relação aos requisitos deste guia, aplique o mesmo checklist de qualquer outro fornecedor: limite de isolamento por sessão, completude da API de ciclo de vida, superfície de observabilidade, limites de recursos configuráveis, opções de política de pacotes, controles de egresso, tratamento de segredos, modelo de persistência e suporte de integração com backend.

FAQ

Qual modelo de isolamento devo escolher para código gerado por IA?

O isolamento microVM oferece o limite mais forte para código gerado por IA não confiável, mas adiciona complexidade operacional. O isolamento de contêiner é adequado para cargas de trabalho de menor risco quando o contêiner é corretamente endurecido — sem modo privilegiado, capacidades mínimas, sistema de arquivos raiz somente leitura sempre que possível e sem montagens de socket do host. O isolamento de processo sozinho é um limite muito fraco para código não confiável que pode tentar chamadas de sistema, criação de subprocessos ou instalações de pacotes. Corresponda o nível de isolamento ao seu modelo de ameaça real.

Como lidar com instalações de pacotes em um sandbox de produção?

Use listas de permissão de registros em vez de acesso aberto por padrão. Adicione um cache pull-through para reduzir downloads redundantes e fornecer um ponto de inspeção. Registre cada tentativa de instalação com nome do pacote, versão, origem e resultado. Para cargas de trabalho onde a reprodutibilidade importa mais do que a flexibilidade — execuções de avaliação, pipelines automatizados — considere um modo offline onde o ambiente é pré-construído e as instalações são totalmente proibidas.

O que uma API de ciclo de vida deve expor no mínimo?

Criar, executar com saída em stream, encerrar e limpar. A saída em stream é a capacidade que mais frequentemente está ausente em implementações mínimas e é a que mais importa para UIs de agentes interativos. A limpeza deve ser idempotente e deve cobrir toda a árvore de processos, não apenas o processo de ponto de entrada.

Como evitar que segredos vazem através de um sandbox?

Escopo as credenciais de forma restrita à tarefa — não um arquivo de ambiente amplo. Prefira tokens de curta duração. Não registre stdout completo por padrão se segredos podem aparecer lá. Verifique se o sandbox limpa as variáveis de ambiente e arquivos de segredos montados na destruição da sessão. Trate a redação como uma responsabilidade da aplicação, não uma garantia do sandbox.

---

Artigos recomendados

• Firecracker para Sandboxes de Agente de IA: Benefícios, Limites e Perguntas de Avaliação
• Servidores MCP em Sandboxes Isolados: Compensações de Sistema de Arquivos, Segredos e Rede
• Construa um Analista de Dados de IA com Python em Sandbox e Acesso Controlado a Pacotes