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

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

Este guia é uma lista de verificação de requisitos. 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 os controlos de observabilidade e recursos, e onde os padrões de integração de backend podem fazer ou quebrar o design. Quer esteja a avaliar uma sandbox gerida ou a construir a sua própria, estas são as perguntas que vale a pena responder antes de lançar.

Isolamento da Sandbox: Processo, Contentor e MicroVM

O isolamento é um espetro, e cada nível acarreta diferentes compromissos em termos de desempenho, portabilidade e quanta confiança está a estender ao código gerado.

Isolamento ao nível do processo usa primitivas do SO — namespaces, cgroups, seccomp e perfis AppArmor ou SELinux — para restringir o que um processo pode aceder. É rápido e não requer um kernel de VM separado, mas todos os processos partilham o kernel do anfitrião. Uma vulnerabilidade do kernel ou uma chamada de sistema privilegiada que escape ao filtro seccomp pode afetar outras cargas de trabalho no mesmo anfitrião. O isolamento de processos é um ponto de partida razoável para caminhos de código de baixo risco, de curta duração e confiáveis, mas é uma fronteira frágil para código gerado por IA não confiável que possa 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 estão limitados por tarefa, por inquilino ou partilhados entre tarefas?
• Os limites de cgroup são aplicados ao nível da tarefa ou apenas ao nível do anfitrião?
• A sandbox limpa todos os processos, ficheiros temporários, sockets e memória partilhada ao sair?

Isolamento ao nível do contentor adiciona uma fronteira de sistema de ficheiros e namespace de rede e torna a gestão de imagens repetível. Os contentores são mais rápidos de iniciar do que VMs completas, mais fáceis de compor e amplamente suportados por camadas de orquestração. O compromisso é que os contentores ainda partilham o kernel do anfitrião, e a fronteira do contentor é tão forte quanto a configuração do runtime subjacente. Contentores privilegiados, conjuntos amplos de capacidades, sockets do anfitrião montados e modo de rede do anfitrião reduzem a fronteira efetiva a praticamente nada.

O que verificar neste nível:

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

Isolamento MicroVM coloca cada carga de trabalho dentro de uma máquina virtual leve — com o seu próprio kernel convidado, dispositivos virtuais e uma fronteira baseada em KVM entre o convidado e o anfitrião. Tecnologias como o Firecracker usam um modelo de dispositivos mínimo para reduzir a superfície de ataque, mantendo ao mesmo tempo um arranque suficientemente rápido para uso interativo. A fronteira MicroVM significa que uma exploração do kernel no convidado não afeta automaticamente o anfitrião ou outros convidados.

O que verificar neste nível:

• Cada execução de agente, cada inquilino ou cada sessão simultânea recebe uma MicroVM separada?
• Qual é a latência de arranque desde a chamada da API até estar pronto a executar, e isso é medido a partir de um pool quente, snapshot ou arranque a frio?
• As imagens convidadas têm controlo de versões, são auditadas quanto aos runtimes e ferramentas que incluem e são atualizadas regularmente?
• O que acontece ao nível do anfitrião se o kernel convidado entrar em pânico ou ficar sem resposta?

A decisão prática depende do seu modelo de ameaça. O isolamento MicroVM é a fronteira 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 ficheiros, controlos de egresso, governança de pacotes ou tratamento de segredos. Esses controlos devem estar sobre a camada de isolamento que escolher.

Gerir Sessões Simultâneas na Sandbox

Uma aplicação de produção que gera código para vários utilizadores ao mesmo tempo precisa de uma sandbox que lide com a concorrência como uma preocupação de primeira classe, não como uma reflexão tardia.

As questões chave são:

Isolamento por sessão: Quando 50 sessões estão a decorrer ao mesmo tempo, cada sessão tem o seu próprio sistema de ficheiros isolado, árvore de processos, namespace de rede e âmbito de credenciais? A fuga de estado entre sessões é um dos modos de falha mais prejudiciais em aplicações sandbox multi-inquilino, e é muitas vezes invisível em testes onde as sessões decorrem sequencialmente.

Limites de sessão e contrapressão: A sandbox expõe os limites de concorrência como um contrato de API claro? Se 500 pedidos chegarem e a plataforma suportar 100 sessões simultâneas, a API retorna um erro estruturado, coloca o pedido em fila ou degrada-se silenciosamente? As aplicações de produção precisam desse sinal para implementar contrapressão, gestão de filas e feedback ao utilizador.

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

Pools quentes e latência de arranque de sessão: Funcionalidades de codificação interativas precisam de tempos de arranque de sessão abaixo do segundo. Isso geralmente requer um pool de ambientes pré-inicializados que podem ser reclamados imediatamente, em vez de iniciados a pedido. Verifique se a plataforma documenta a disponibilidade de pools quentes e qual a latência de arranque esperada em diferentes níveis de concorrência.

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

API de Ciclo de Vida: Criar, Executar, Terminar

A API de ciclo de vida é a interface entre a sua aplicação e o runtime da 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: Submeter código ou um comando para execução. Esta 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 output: Recuperar stdout e stderr como um fluxo, não apenas como um resultado final após a execução terminar. A transmissão é importante para tarefas de longa duração, passos de agente que demoram muitos segundos e qualquer UX que mostre ao utilizador progresso incremental.

Terminar: Terminar uma execução em curso antes de esta ser concluída. A sandbox deve garantir que a árvore de processos é limpa, não apenas o processo pai.

Limpeza: Destruir a sessão e libertar todos os recursos associados — sistema de ficheiros, memória, slots de processo, estado de rede e quaisquer credenciais detidas. Esta chamada deve ser idempotente para que repetições após um erro de rede não causem erros.

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

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

• Pausar e retomar: Uma sessão de longa duração pode ser suspensa e retomada mais tarde sem perder estado? Isto é útil para limitação de taxa, controlo de custos e transferência de sessão entre interações 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 quentes e ambientes reutilizáveis.
• Imposição de timeout: Se o código em execução exceder o timeout de relógio de parede, a plataforma termina-o limpidamente e reporta o estado de saída correto?

Observabilidade: Logs, Métricas e Traces

Não pode depurar ou auditar o que não consegue ver. As sandboxes de produção precisam de observabilidade incorporada, não adicionada posteriormente.

Captura de stdout e stderr: Cada execução deve produzir um registo de output capturado associado ao ID de sessão e ID de execução. Isto deve ser acessível através da API após a execução terminar, não apenas disponível como um fluxo em tempo real.

Logs de execução: A plataforma deve registar que código foi executado, quando começou, quando terminou, qual foi o código de saída, qual utilizador ou inquilino possuía a sessão e qual template ou snapshot foi usado. Estes registos são o mínimo necessário para reconstruir o que aconteceu quando algo corre mal.

Métricas de recursos: As 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 escritas no sistema de ficheiros. Isto permite planeamento de capacidade, deteção de anomalias e atribuição de custos por sessão.

Rastreio de erros: Quando uma sandbox falha ao iniciar, executar ou limpar, a superfície de erro deve ser estruturada: código de erro, mensagem, ID de sessão e contexto suficiente para distinguir um erro de utilizador (código mau, pacote em falta) de um erro de plataforma (quota excedida, falha interna).

Registo de auditoria: Para aplicações multi-inquilino, o registo de auditoria deve tornar o comportamento do agente reconstruível: ID de sessão, inquilino, sequência de execução, instalações de pacotes, domínios externos contactados, ficheiros escritos e resultado da limpeza. O código bruto do cliente e o output completo do comando podem não pertencer aos logs de auditoria por defeito — desenhe para o que as suas políticas de retenção e acesso podem realmente suportar.

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

Limites de CPU, Memória e Timeout

O consumo ilimitado de recursos é uma das formas 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.

Uma sandbox de produção deve impor limites ao nível da sessão, não apenas ao nível do anfitrião:

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 anfitrião. Verifique se o limite é um teto duro (o processo é limitado ou morto) ou um limite suave (está a competir com outros processos pela CPU disponível).

Memória: Definir um teto de memória que aciona a limpeza ou terminação em vez de permitir que a sessão esgote a memória do anfitrião. Verifique o que acontece quando o limite é atingido: kill OOM, resposta de erro estruturada ou bloqueio 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 ao nível da plataforma, não apenas ao nível do cliente — se o cliente perder a ligação, a sandbox deve ainda terminar a execução no limite configurado.

Uso de disco: O código gerado pode escrever ficheiros de output grandes, instalar pacotes grandes ou encher o diretório de trabalho. Uma quota de disco no diretório de trabalho da sessão evita escritas descontroladas.

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

Ao avaliar uma plataforma de sandbox, verifique se estes limites são configuráveis por sessão (para que diferentes níveis de utilizador ou tipos de tarefa possam ter limites diferentes), se são aplicados ao nível da 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 solicita frequentemente a instalação de pacotes — pip install, npm install, apt-get, clones Git, descarregamentos diretos de URL. Cada uma dessas operações puxa código externo para a sandbox em tempo de execução, o que é uma das operações de maior risco que uma sandbox precisa de governar.

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

Listas de permissões de registos: Quais registos de pacotes são permitidos? PyPI e npm são os padrões, mas muitas equipas querem a opção de restringir a espelhos internos, registos selecionados ou fontes explicitamente aprovadas.

Cache de instalação: Quando muitas sessões instalam os mesmos pacotes populares, uma cache de camada ou proxy pull-through evita descarregamentos redundantes, reduz a latência de arranque e dá-lhe um ponto para inspecionar o que está a ser descarregado.

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 é mais importante que a flexibilidade.

Verificação de hash e ficheiros de bloqueio: Quando os pacotes são permitidos, versões fixadas e verificação de hash reduzem o risco de um comprometimento do registo alterar o código que é executado dentro da sandbox.

Limites de tamanho: Os pacotes e as suas dependências transitivas podem ser grandes. Um limite de tamanho na pegada total descarregada por sessão evita a exaustão acidental ou intencional de armazenamento.

Registo de pacotes: Cada tentativa de instalação deve ser registada no log de auditoria de execução: nome do pacote, versão solicitada, fonte do registo e sucesso ou falha. Estes são os dados de que precisa para reconstruir o que entrou na sandbox durante um incidente.

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

Rede e Controlos de Egresso

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

Egresso negado por defeito: A postura de produção mais forte é bloquear todas as ligações de saída por defeito e permitir explicitamente na lista de permissões os destinos que uma sessão precisa legitimamente. Isto requer mais configuração, mas torna o modelo de acesso auditável.

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

Política de DNS: O DNS deve ser tratado de forma consistente com a política de egresso. Uma sessão que não consegue 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 controlos através 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 cloud (por exemplo, o serviço de metadados de instância AWS), APIs internas, bases de dados privadas ou painéis de administração, a menos que estejam explicitamente configurados. Verifique se a política de rede padrão da sandbox bloqueia intervalos de endereços internos bem conhecidos.

Egresso de descarregamento de pacotes: As instalações de pacotes são operações de rede. Se o egresso estiver restrito, certifique-se de que a lista de permissões do registo de pacotes é consistente com a política de egresso, ou use um proxy pull-through dentro da rede de confiança.

Registo de ligações de saída: Mesmo quando o egresso é permitido, registar que domínios e IPs uma sessão contactou é útil para investigação de incidentes. Nem todas as plataformas de sandbox fornecem isto nativamente; verifique o que irá obter.

Segredos e Injeção de Credenciais

Os agentes de IA frequentemente precisam de credenciais — chaves de API, ligações a bases de dados, tokens OAuth, credenciais cloud de curta duração. Como uma sandbox lida com segredos é importante tanto para a segurança como para a fiabilidade operacional.

Âmbito restrito: Cada sessão deve receber apenas os segredos de que necessita para a tarefa específica que está a executar. Montar um ficheiro de ambiente amplo com todas as credenciais em todas as sessões é operacionalmente conveniente, mas significa que código comprometido ou mal comportado em qualquer sessão pode aceder a todas essas credenciais.

Credenciais de curta duração: Onde o backend o suportar, prefira tokens de curta duração com um TTL limitado à duração da sessão. Isto limita a janela durante a qual uma credencial divulgada é útil.

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

Redação: A 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 da aplicação, mas uma sandbox que suporte a limpeza configurável de logs reduz o raio de explosão de uma exposição acidental.

Limpeza: Após o fim da sessão, verifique se as variáveis de ambiente, ficheiros de segredos montados e quaisquer dados de credenciais em cache são limpos como parte do desmantelamento da sessão, não deixados para a sessão seguinte herdar.

Armazenamento de Ficheiros Efémero vs. Persistente

Diferentes cargas de trabalho têm diferentes necessidades de persistência, e uma 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 output e é destruída. As sessões efémeras são fáceis de raciocinar: cada execução começa a partir de uma base conhecida, nenhum estado se acumula e a limpeza é direta. São a escolha certa para tarefas de avaliação, conclusões de código únicas e qualquer tarefa onde a reprodutibilidade seja mais importante 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 múltiplas interações frequentemente precisam de um espaço de trabalho que sobreviva a várias chamadas de execução. Ficheiros instalados, dependências em cache, código escrito e histórico acumulado numa interação devem estar disponíveis na seguinte. Os espaços de trabalho persistentes são mais complexos de operar: acumulam estado, podem desviar-se do template e precisam de um ciclo de vida explícito — quando é que o espaço de trabalho é limpo, quem o possui e que controlos de acesso o protegem entre sessões?

Snapshots e templates: Os templates permitem definir um ambiente de base conhecido e bom — runtimes, ferramentas, dependências — e lançar sessões a partir dele de forma consistente. Os snapshots capturam o estado atual de uma sessão em execução e usam-no como ponto de partida para sessões futuras. Ambos são úteis para equipas que precisam de ambientes repetíveis e baixa latência de arranque. Verifique se os templates têm controlo de versões, se quem pode criá-los e atualizá-los é controlado e se os snapshots são isolados por inquilino.

Exportação de artefactos de output: Após a execução, o que pode sair da sandbox? Uma política de produção deve definir quais caminhos de ficheiros são exportáveis, que limites de tamanho se aplicam e se os artefactos são revistos ou filtrados antes de a aplicação os receber.

Estado entre sessões: Seja explícito sobre se o design da sua aplicação pretende que as sessões partilhem estado ou não. A partilha acidental — através de uma cache de pacotes partilhada, um volume partilhado ou um espaço de trabalho mal direcionado — é uma falha comum de isolamento multi-inquilino.

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

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

REST: Uma API REST é a integração de menor atrito para aplicações que submetem pedidos de execução discretos e consultam resultados. Funciona bem para tarefas de curta duração, é fácil de depurar com ferramentas HTTP padrão e encaixa-se naturalmente em arquiteturas de serviço existentes. O compromisso é que a consulta de resultados adiciona latência em comparação com notificações push, e a transmissão de output de longa duração requer SSE ou consulta a um endpoint de log.

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

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

Pontos de integração que a sua aplicação precisa de possuir: Independentemente do transporte, a sua aplicação é responsável pela autorização (que utilizadores podem criar sessões e com que limites de recursos), portões de aprovação (que chamadas de ferramenta ou execuções de código requerem revisão humana antes de executar), tratamento de resultados (como o output da sandbox é apresentado ou processado pelo agente) e limpeza (acionar o desmantelamento da sessão quando o fluxo do utilizador termina ou a interação do agente acaba).

Uma API de sandbox bem desenhada não tenta possuir a lógica de negócio da sua aplicação. Expõe primitivas — criar, executar, transmitir, terminar, limpar — e permite que a sua camada de aplicação construa o comportamento de produto correto em cima delas.

Recuperação de Falhas e Limpeza

Os sistemas de produção falham. Uma sandbox que lida com falhas graciosamente evita fugas de recursos, estado obsoleto e incidentes difíceis de depurar.

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

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

Garantias de limpeza: Uma chamada de API cleanup ou terminate deve libertar de forma fiável todos os recursos: alocações de CPU e memória, quota de sistema de ficheiros, slots de processo, estado de rede e credenciais. A limpeza deve ser idempotente — chamá-la várias vezes para o mesmo ID de sessão não deve retornar um erro. Isto é importante na prática: o código da aplicação que repete a limpeza após um erro de rede não deve quebrar.

Falhas de execução parciais: Quando o código falha a meio da execução — uma exceção não tratada, um processo morto, um pacote em falta — a sandbox deve retornar um resultado estruturado que distinga sucesso parcial (algum output foi produzido antes da falha) de falha total. As aplicações construídas sobre resultados parciais precisam disto para evitar apresentar output incompleto ou enganoso aos utilizadores.

Tratamento de processos descontrolados: Se o código gerado criar um processo em segundo plano que sobrevive à execução principal, a sandbox deve terminá-lo como parte da limpeza da sessão, em vez de permitir que execute 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 quota: Quando a plataforma está na capacidade máxima de sessões ou um inquilino atingiu a sua quota, 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 bloqueio silencioso. Isto permite que a aplicação coloque em fila, recue ou mostre uma mensagem útil ao utilizador.

Novita Agent Sandbox

O Novita Agent Sandbox é uma plataforma de sandbox gerida construída para cargas de trabalho de agentes. Tem como alvo agentes de codificação, agentes de análise de dados, fluxos de trabalho orientados a navegadores e sessões de agente de maior duração onde o código gerado precisa de ser executado num ambiente isolado e observável, sem aterrar em servidores de aplicação ou infraestrutura partilhada.

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

A Novita descreveu capacidades incluindo isolamento MicroVM, suporte a sessões simultâneas, uma API de ciclo de vida que cobre criar, executar, transmitir, terminar e limpar, Pausar e Auto-retomar para gerir o estado da sessão, templates e snapshots para arranque rápido e repetível do ambiente, e integração com as APIs de modelo Novita. Verifique a disponibilidade atual de funcionalidades, 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 arranque 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 a mesma lista de verificação que para 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, controlos de egresso, tratamento de segredos, modelo de persistência e suporte de integração de backend.

FAQ

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

O isolamento MicroVM dá a fronteira mais forte para código gerado por IA não confiável, mas adiciona complexidade operacional. O isolamento de contentor é adequado para cargas de trabalho de menor risco quando o contentor é corretamente endurecido — sem modo privilegiado, capacidades mínimas, sistema de ficheiros raiz somente leitura sempre que possível e sem montagens de sockets do anfitrião. Apenas o isolamento de processo é uma fronteira demasiado fina para código não confiável que possa tentar chamadas de sistema, criação de subprocessos ou instalação de pacotes. Faça corresponder o nível de isolamento ao seu modelo de ameaça real.

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

Use listas de permissões de registos em vez de acesso aberto por defeito. Adicione uma cache pull-through para reduzir descarregamentos redundantes e dar-lhe um ponto de inspeção. Registe cada tentativa de instalação com nome do pacote, versão, fonte e resultado. Para cargas de trabalho onde a reprodutibilidade é mais importante 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 desativadas.

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

Criar, executar com transmissão de output, terminar e limpar. A transmissão de output é a capacidade que mais frequentemente falta em implementações mínimas, e é a que mais importa para UIs de agente interativas. 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 uma sandbox?

Limite o âmbito das credenciais estritamente à tarefa — não um ficheiro de ambiente amplo. Prefira tokens de curta duração. Não registe o stdout completo por defeito se os segredos puderem aparecer lá. Verifique se a sandbox limpa as variáveis de ambiente e os ficheiros de segredos montados ao desmantelar a sessão. Trate a redação como uma responsabilidade da aplicação, não uma garantia da sandbox.

---

Artigos recomendados

• Firecracker para AI Agent Sandboxes: Benefícios, Limites e Questões de Avaliação
• Servidores MCP em Sandboxes Isoladas: Compromissos de Sistema de Ficheiros, Segredos e Rede
• Construir um Analista de Dados de IA com Python em Sandbox e Acesso Controlado a Pacotes