- Por que Usar Sandbox para Agentes de IA
- Modelos de Isolamento do Sandbox
- Egresso do Sandbox e Política de Rede
- Acesso a Arquivos e o Sistema de Arquivos do Host
- Estado da Sessão e Persistência
- Instalações de Pacotes e Dependências de Tempo de Execução
- Segredos e Manipulação de Credenciais
- Logs de Auditoria e Observabilidade
- Conformidade e Revisão de Segurança
- Preços do Sandbox e Direcionadores de Custo
- Auto-Hospedagem vs. Sandbox de Agente de IA Gerenciado
- Executando Código Não Confiável com Segurança
- Artigos Recomendados
Este FAQ do sandbox de agentes de IA responde às perguntas práticas de segurança que os desenvolvedores fazem antes de executar código gerado por agentes: como o isolamento funciona, que acesso de rede os agentes têm, para onde vão os arquivos e o estado da sessão, e como lidar com segredos, logs de auditoria, conformidade e custo. Se você é novo em sandboxes, comece com O que é um Sandbox de Agente de IA? para uma base sobre modelos de isolamento, egresso e snapshot. Se você está escolhendo um provedor, veja Melhores Sandboxes de Agentes de IA em 2026 ou o guia de avaliação E2B vs. Daytona.
Por que Usar Sandbox para Agentes de IA
Por que as equipes usam um sandbox dedicado para agentes de IA?
Os agentes de IA diferem do software tradicional em um aspecto crítico: o código que eles executam não é escrito por um humano e revisado antes da execução. Um LLM gera instruções, seleciona ferramentas, instala pacotes e faz chamadas de API dinamicamente — muitas vezes de maneiras que o desenvolvedor da aplicação não enumerou antecipadamente. Um sandbox fornece uma camada de aplicação de tempo de execução que contém as consequências dessas ações sem exigir que cada ação possível seja pré-aprovada. Sem um sandbox, um agente malcomportado ou manipulado pode afetar o sistema host, workloads adjacentes ou infraestrutura externa. Com um sandbox, o pior raio de explosão é limitado ao ambiente isolado, que pode ser descartado após a sessão.
O que é execução de código de agente de IA?
A execução de código de agente de IA é a fase de tempo de execução onde as decisões de um LLM se tornam instruções reais que um computador executa. O agente recebe uma tarefa, raciocina sobre ela, gera código ou chamadas de ferramenta, e a camada de execução executa essas ações e retorna os resultados para o agente. Um sandbox é a camada de infraestrutura padrão para esta fase de execução: ele fornece o ambiente de computação, sistema de arquivos e rede que o agente precisa, mantendo esse ambiente isolado de tudo o mais. O ciclo de “modelo raciocina → camada de execução executa → resultados alimentam o modelo” se repete até que o agente complete a tarefa.
Como o sandbox é diferente de apenas executar um agente em um contêiner?
Um contêiner adiciona separação de namespace de sistema de arquivos e rede, mas todos os contêineres no mesmo host compartilham o kernel do SO. Para agentes de IA executando código gerado por LLM a partir de entradas não confiáveis, uma fuga ao nível do kernel através de uma vulnerabilidade compartilhada pode afetar workloads adjacentes. Um sandbox de agente de IA dedicado geralmente adiciona um limite de microVM: o código do agente é executado dentro de uma máquina virtual leve com seu próprio kernel convidado, de modo que mesmo uma exploração ao nível do kernel no convidado não afeta o host. O trade-off prático é uma pequena sobrecarga adicional de inicialização a frio (geralmente abaixo de 500 ms para plataformas baseadas em Firecracker). Veja a seção de modelos de isolamento para uma comparação completa.
Modelos de Isolamento do Sandbox
O que significa “isolamento” em um sandbox de agente de IA?
Isolamento significa que o código, arquivos, processos e acesso de rede do agente estão confinados a um ambiente limitado que não pode afetar o sistema host ou outros inquilinos. Na prática, o isolamento é um espectro: isolamento ao nível de processo usa primitivas do SO (namespaces, cgroups, seccomp) para restringir chamadas de sistema e acesso a recursos; o isolamento de contêiner adiciona um limite de sistema de arquivos e namespace de rede; e o isolamento de microVM envolve a workload em uma máquina virtual leve com seu próprio kernel convidado. Cada passo acima na pilha aumenta a força do limite ao custo de alguma sobrecarga de inicialização e complexidade operacional. Para uma visão geral abrangente de todas as dimensões de isolamento, veja O que é um Sandbox de Agente de IA?. Veja Firecracker para Sandboxes de Agentes de IA para um quadro de avaliação detalhado.
O Docker é suficiente para executar código gerado por agentes?
Contêineres fornecem imagens reproduzíveis e bons controles de recursos, mas todos os contêineres no mesmo host compartilham o kernel do host. Uma vulnerabilidade do kernel, ou uma chamada de sistema que escapa pelo filtro seccomp, pode afetar outras workloads. Para tarefas de baixo risco e curta duração executando código confiável ou quase confiável, os contêineres são frequentemente adequados quando endurecidos corretamente — sem modo privilegiado, capacidades mínimas, sem montagem do socket Docker, sistema de arquivos raiz somente leitura quando possível. Para código não confiável gerado por IA que pode instalar pacotes, gerar subprocessos ou chamar comandos shell arbitrários, um limite mais forte vale a pena ser avaliado. A resposta depende do seu modelo de ameaça real. Veja Sandbox de Código Gerado por IA: Requisitos para Aplicações de Produção para a lista de verificação em cada nível de isolamento.
Qual é a diferença entre isolamento de contêiner e microVM?
A principal diferença é o limite do kernel. Contêineres compartilham o kernel do host; microVMs executam cada um um kernel convidado dentro de uma máquina virtual leve, apoiada por virtualização de hardware (KVM). Um sandbox baseado em microVM usando tecnologia como Firecracker fornece um limite do tipo VM sem a sobrecarga total de uma VM tradicional: a latência de inicialização é projetada para ser rápida, o modelo de dispositivo é mínimo para reduzir a superfície de ataque, e o convidado é isolado do kernel do host por design. A implicação prática é que uma exploração do kernel no convidado não afeta automaticamente o host ou outros convidados, enquanto em um modelo de contêiner com kernel compartilhado poderia. Veja Firecracker para Sandboxes de Agentes de IA para onde o limite de microVM ajuda e onde não resolve o problema inteiro.
Existe um sandbox por agente, por usuário ou por tarefa?
Isso depende da plataforma e de como a aplicação é projetada. O padrão mais seguro para aplicações multi-inquilino é um ambiente de sandbox isolado por execução de agente ou por tarefa — significando que a sessão de cada usuário tem sua própria árvore de processos, sistema de arquivos, namespace de rede e escopo de credenciais. Compartilhar um sandbox entre usuários ou entre tarefas não relacionadas é a fonte mais comum de vazamento de estado em aplicações de agente em produção. Ao avaliar uma plataforma, verifique se as sessões concorrentes são isoladas ao nível do sistema de arquivos, processos e rede, não apenas ao nível do roteamento de API. Veja Sandbox de Código Gerado por IA: Requisitos para Aplicações de Produção para a lista de verificação de isolamento por sessão.
Egresso do Sandbox e Política de Rede
Um agente de IA pode fazer chamadas de rede de saída a partir de um sandbox?
Depende da política de egresso do sandbox. Por padrão, muitos sandboxes permitem conexões de saída, o que é conveniente para pesquisa na web, chamadas de API e instalações de pacotes. Para workloads de produção executando código não confiável, egresso aberto por padrão é um risco: um agente comprometido ou malcomportado pode exfiltrar dados, alcançar serviços de metadados internos ou puxar código inesperado de URLs arbitrárias. Uma postura de produção mais forte é egresso negado por padrão com uma lista de permissões explícita de destinos permitidos. Qualquer política que você escolher, deve ser explícita e registrada. Veja Firecracker para Sandboxes de Agentes de IA para como avaliar controles de rede.
Como o DNS é controlado em um sandbox?
DNS é uma lacuna comum na política de egresso: uma lista de permissões para destinos HTTP não restringe automaticamente a resolução de DNS. Um agente que pode resolver nomes de domínio arbitrários pode inferir topologia de rede, sondar nomes internos ou usar DNS como um canal lateral mesmo quando o HTTP está bloqueado. Para uma política de egresso coerente, a resolução de DNS deve ser tratada de forma consistente — seja apontando para um resolvedor interno que respeite a lista de permissões, ou restringindo a resolução a domínios aprovados. Verifique com seu provedor de sandbox como o DNS é escopado em relação à política de egresso mais ampla.
Como as buscas de pacotes são controladas durante sessões com rede restrita?
Instalações de pacotes são operações de rede. Se o egresso for restrito a uma lista de permissões, a lista deve incluir os registros de pacotes que o agente precisa legitimamente, ou o sandbox deve fornecer um cache pull-through dentro da rede confiável. O cache pull-through tem o benefício adicional de servir como um ponto de inspeção: você pode ver quais pacotes são buscados, capturar dependências inesperadas e reduzir egresso redundante. Algumas equipes usam modelos de sandbox pré-construídos para workloads onde a reprodutibilidade importa mais do que a flexibilidade, o que elimina completamente as buscas de pacotes em tempo de execução. Veja a seção Instalações de Pacotes para mais sobre como governar instalações em tempo de execução.
Acesso a Arquivos e o Sistema de Arquivos do Host
Que acesso a arquivos um agente em sandbox tem?
Um agente em sandbox deve ter acesso apenas aos arquivos explicitamente montados em seu espaço de trabalho. Para um agente de codificação, isso pode ser um repositório verificado e um diretório de trabalho para artefatos gerados. Para um agente de análise de dados, isso pode ser um CSV carregado e uma pasta de saída. O agente não deve ser capaz de alcançar o sistema de arquivos do host, espaços de trabalho de outros inquilinos, segredos do servidor de aplicação ou diretórios do sistema fora de seus caminhos montados. Uma boa prática é montar material de origem como somente leitura e fornecer um diretório de saída separado de leitura e escrita para artefatos gerados. Veja Sandbox de Servidor MCP: Servidores MCP Isolados com Controles de Sistema de Arquivos, Segredos e Rede para como escopear montagens de sistema de arquivos por ferramenta.
O sistema de arquivos do host é acessível de dentro de um sandbox?
Não deveria ser. Um sandbox configurado corretamente — contêiner ou microVM — restringe a visão do agente ao seu próprio sistema de arquivos convidado. Acessar o sistema de arquivos do host de dentro de um sandbox é uma falha de configuração, não um comportamento esperado. Erros comuns que quebram esse limite incluem montar diretórios amplos (como o diretório home de um desenvolvedor ou /), usar modo privilegiado em contêineres ou montar o socket Docker dentro do sandbox. Ao avaliar uma plataforma ou construir a sua própria, verifique o que está montado, quais são as permissões do sistema de arquivos raiz e se escapes de symlink ou truques de extração de arquivo podem alcançar caminhos fora do espaço de trabalho pretendido.
O que acontece com os arquivos após o término de uma sessão?
Para sessões efêmeras, o diretório de trabalho e todos os arquivos gerados são destruídos quando a sessão termina. Este é o padrão correto para conclusão de código, execuções de avaliação e qualquer tarefa onde a reprodutibilidade importa mais do que a continuidade. Para espaços de trabalho persistentes (agentes de codificação de longa duração, sessões de desenvolvimento iterativo), os arquivos podem sobreviver entre chamadas de execução dentro de uma sessão e podem ser retidos após o término da sessão se a plataforma suportar persistência de espaço de trabalho ou snapshots. As principais perguntas a responder são: quem possui um espaço de trabalho retido, quando é limpo e se o espaço de trabalho de um usuário pode vazar para o de outro? Veja Sandbox de Código Gerado por IA: Requisitos para Aplicações de Produção para a lista de verificação do modelo de persistência.
Estado da Sessão e Persistência
Uma sessão de sandbox é stateful ou efêmera?
Ambos os padrões existem e servem a diferentes workloads. Sessões efêmeras começam a partir de uma linha de base limpa para cada tarefa — sem pacotes acumulados, arquivos ou histórico. Elas são mais fáceis de raciocinar e ideais para execuções de avaliação ou execução de código único. Sessões stateful preservam arquivos, pacotes instalados, histórico de shell e estado do ambiente em múltiplas chamadas de execução, o que é necessário para agentes de codificação de múltiplas etapas, análise de dados interativa e workflows de longa duração. A maioria das plataformas de produção suporta ambos. O trade-off é que sessões stateful exigem políticas de limpeza explícitas e isolamento de inquilino mais cuidadoso.
Quanto tempo o estado persiste em um sandbox gerenciado?
A duração da sessão varia por plataforma e plano. Alguns provedores definem um tempo limite de sessão padrão (comumente 60 minutos a 24 horas), após o qual a sessão é terminada e o estado é perdido a menos que persistido em um snapshot ou armazenamento externo. Workflows de agente de longa duração — sessões que podem pausar entre chamadas de LLM por minutos ou horas — precisam de uma plataforma que suporte pausa e retomada de sessão ou pausa automática para evitar cobrança por tempo ocioso enquanto preserva o estado. Verifique o comprimento máximo da sessão e o que acontece com o estado em andamento quando ocorre um tempo limite. O Novita Agent Sandbox suporta sessões de até 24 horas e documenta uma capacidade de Pausa/Retomada Automática para gerenciar tempo ocioso. Veja Novita Sandbox: Uma Alternativa Custo-Efetiva ao E2B Pro com Compatibilidade Perfeita para uma comparação de recursos.
As sessões podem ser pausadas e retomadas?
Algumas plataformas suportam pausa e retomada, onde a sessão é suspensa no disco e pode ser reiniciada posteriormente a partir do mesmo estado. Isso é útil para agentes que esperam por respostas do LLM entre etapas, para limitar a taxa de workloads caros e para sessões que abrangem múltiplas interações do usuário ao longo do tempo. As principais coisas a verificar são: por quanto tempo uma sessão pausada pode permanecer suspensa, o que acontece com as conexões de rede mantidas durante uma pausa e se as credenciais injetadas no início da sessão permanecem válidas após a retomada ou precisam ser renovadas.
O estado do sandbox pode ser snapshotado e reutilizado?
Modelos e snapshots são relacionados, mas distintos. Um modelo é um ambiente de linha de base pré-construído — runtimes, ferramentas, pacotes aprovados — a partir do qual novas sessões começam. Um snapshot captura o estado atual de uma sessão em execução e o usa como ponto de partida para sessões futuras. Modelos reduzem a sobrecarga de inicialização por sessão e garantem que todos os agentes comecem a partir de uma linha de base consistente e governada. Snapshots são úteis para preservar trabalho parcial ou iniciar tarefas iterativas a quente. Ambos precisam de governança: quem pode criá-los, quem pode lê-los, a qual inquilino pertencem e como são versionados.
Instalações de Pacotes e Dependências de Tempo de Execução
Os agentes podem instalar pacotes em tempo de execução?
A maioria dos ambientes de sandbox permite instalações de pacotes em tempo de execução (pip install, npm install, apt-get, etc.) por padrão porque muitas workloads de agente precisam deles. A questão não é se as instalações são permitidas, mas sim se cada instalação é governada. Instalações de pacotes não governadas são uma das operações de maior risco em um sandbox: elas puxam código externo para o ambiente de execução em tempo de execução, podem incluir scripts pós-instalação que executam comandos arbitrários e podem introduzir risco à cadeia de suprimentos.
Quais políticas governam as instalações de pacotes em tempo de execução?
Uma política de pacotes de produção normalmente inclui alguma combinação de lista de permissões de registro (buscar apenas de registros ou mirrors de pacotes aprovados), caches pull-through (inspecionar o que entra antes de executar), registro de instalação (gravar o nome do pacote, versão, origem e resultado para cada instalação) e modo offline opcional (pré-construir dependências no modelo e proibir instalações em tempo de execução para pipelines de avaliação onde a reprodutibilidade importa). A política correta depende da workload: um agente de codificação ajudando um desenvolvedor a depurar código pode precisar de acesso flexível a pacotes; um pipeline de avaliação automatizado provavelmente deve executar a partir de um ambiente congelado. Veja Construa um Analista de Dados de IA com Python em Sandbox e Acesso Controlado a Pacotes para um exemplo de implementação prática.
Segredos e Manipulação de Credenciais
Como os segredos e credenciais são tratados em um sandbox?
Os segredos devem ser injetados de forma estreita — apenas a credencial que uma tarefa específica precisa, pela duração dessa sessão. O antipadrão comum é montar um arquivo de ambiente amplo contendo todas as chaves de API em cada sessão; isso significa que qualquer sessão, se comprometida, pode acessar todas as credenciais nesse arquivo. Prefira tokens de curta duração com escopo para a tarefa e prefira mecanismos de injeção (variáveis de ambiente ou arquivos montados) em vez de codificação rígida. Para as credenciais mais sensíveis, uma API de segredos em tempo de execução que fornece valores apenas a um processo explicitamente autorizado oferece isolamento mais forte do que uma variável de ambiente plana disponível para todos os processos.
O modelo pode ver as variáveis de ambiente injetadas no sandbox?
Sim, se a variável de ambiente for injetada no processo onde o código do modelo é executado. As variáveis de ambiente são visíveis para todos os processos na mesma sessão por padrão. O modelo não pode lê-las diretamente de sua janela de contexto, mas o código gerado que executa dentro do sandbox pode lê-las com os.environ, process.env ou equivalente. É por isso que o escopo estreito é importante: injete apenas as credenciais que a tarefa requer e prefira tokens de curta duração para que uma credencial vazada tenha uma janela de utilidade limitada. A redação é uma responsabilidade da aplicação: não registre stdout completo por padrão se segredos podem aparecer em mensagens de erro ou declarações de impressão.
O que acontece com os segredos quando uma sessão termina?
Variáveis de ambiente e arquivos de segredos montados devem ser limpos como parte do encerramento da sessão. Se a plataforma preserva o estado entre sessões (snapshots, volumes persistentes), verifique se as credenciais escritas no sistema de arquivos ou armazenadas em cache por um provedor de credenciais também são limpas ou rotacionadas. Credenciais obsoletas em um snapshot retomável são um risco — após o encerramento da sessão, o snapshot não deve reter tokens que eram válidos apenas para a duração da sessão original.
Logs de Auditoria e Observabilidade
Quais eventos são registrados em um sandbox?
Registros de auditoria úteis do sandbox incluem criação e encerramento de sessão (ID da sessão, inquilino, versão do modelo, alocação de recursos, duração), eventos de execução (qual código ou categoria de comando foi executado, hora de início/término, status de saída), instalações de pacotes (nome, versão, origem, resultado), contatos de rede de saída (domínios, IPs, portas), arquivos lidos ou escritos em caminhos específicos e resultado da limpeza. O objetivo é tornar o comportamento do agente reconstruível a posteriori sem transformar o log de auditoria em um segundo armazenamento de segredos. Arquivos brutos do cliente, saída completa de comandos e prompts completos geralmente não pertencem a logs de auditoria, a menos que sua retenção e controles de acesso sejam projetados especificamente para esses dados.
Quem pode acessar os logs de auditoria?
Os controles de acesso aos logs de auditoria devem ser escopados para o operador e, quando relevante, para o inquilino. Em plataformas multi-inquilino, os registros de auditoria de um inquilino não devem ser visíveis para outros inquilinos. Para implantações sensíveis à conformidade, a trilha de auditoria precisa ser à prova de adulteração, retida pelo período exigido e acessível a revisores autorizados (equipe de segurança, oficial de conformidade) sob demanda. Pergunte ao seu provedor de sandbox qual período de retenção de logs é fornecido por padrão, se os logs podem ser exportados para seu próprio SIEM ou armazenamento e quais controles de acesso protegem os dados do log.
Conformidade e Revisão de Segurança
Que revisão de conformidade é necessária antes de usar um sandbox em produção?
Os requisitos específicos dependem do seu setor e jurisdição, mas as perguntas padrão para qualquer sistema de agente de produção incluem: quais dados entram no sandbox (e esses dados estão sujeitos ao GDPR, HIPAA, SOC 2 ou outros frameworks), onde o sandbox está hospedado e isso satisfaz os requisitos de residência de dados, qual é o modelo de isolamento e você pode documentá-lo para um auditor, como as credenciais são gerenciadas e rotacionadas, e como é a trilha de auditoria? A maioria das revisões de segurança também perguntará se o código gerado pode alcançar bancos de dados de produção, superfícies administrativas internas ou dados do cliente fora do escopo pretendido. Estes são controles arquitetônicos, não apenas certificações de fornecedores.
Que perguntas as equipes de segurança devem fazer ao avaliar um sandbox de agente de IA?
Uma lista de verificação de avaliação prática para revisão de segurança:
- Isolamento: Qual é o limite — processo, contêiner ou microVM? Cada sessão de agente é isolada ao nível do sistema de arquivos, processo e rede?
- Egresso: Qual é a política de egresso padrão? Os destinos de saída podem ser incluídos em uma lista de permissões? Como o DNS é controlado?
- Segredos: Como as credenciais são injetadas? Elas têm escopo para a tarefa? São limpas no encerramento da sessão?
- Auditoria: Quais eventos são registrados? Quem pode acessar os logs? Qual é o período de retenção?
- Residência de dados: Onde os sandboxes estão hospedados? A implantação pode ser escopada para uma região de nuvem ou conta específica?
- Postura de conformidade: O provedor possui certificações relevantes (SOC 2, ISO 27001)? Qual é o modelo de responsabilidade compartilhada?
- Alcance de rede: Um sandbox pode alcançar serviços de metadados internos, APIs privadas ou recursos de outros inquilinos? Como o movimento lateral é prevenido?
Enquadre estas como perguntas para avaliar, não como requisitos que qualquer fornecedor único atende automaticamente. As alegações de segurança e conformidade na documentação do fornecedor devem ser verificadas contra os documentos atuais do produto, não aceitas pelo valor nominal. Para equipes com requisitos regulatórios ou contratuais, faça a revisão pela sua equipe de segurança antes da implantação em produção, não depois.
Quando o BYOC (traga sua própria nuvem) ou implantação VPC é relevante?
Requisitos de residência de dados, políticas de segurança de rede ou restrições regulatórias que proíbem a saída de dados de uma conta de nuvem específica são as principais razões pelas quais as equipes escolhem BYOC ou implantação VPC em vez de um serviço gerenciado compartilhado. Executar sandboxes dentro de sua própria VPC AWS ou GCP significa que o ambiente de execução está dentro do seu perímetro de rede, os controles de acesso da sua conta de nuvem se aplicam e o egresso do sandbox pode ser governado por suas políticas de rede existentes. O trade-off é a responsabilidade operacional: você gerencia a infraestrutura, patches e escalonamento. O Novita Agent Sandbox documenta a implantação BYOC em contas AWS ou GCP como um recurso para equipes com esses requisitos. Verifique a disponibilidade atual e as opções de configuração na documentação do Novita Agent Sandbox.
Preços do Sandbox e Direcionadores de Custo
O que impulsiona os custos do sandbox?
Os custos do sandbox são tipicamente uma combinação de tempo de computação (vCPU e memória cobrados por segundo ou por minuto), sobrecarga de sessão (uma taxa de inicialização por sessão em algumas plataformas), armazenamento persistente acima do nível gratuito incluído e transferência de dados de saída (egresso). O peso relativo de cada um depende da sua workload: um interpretador de código de sessão curta é principalmente computação; um agente de automação de navegador que baixa arquivos grandes pode gerar egresso significativo; um espaço de trabalho de codificação persistente acumulará armazenamento. O tratamento do tempo ocioso é um grande diferencial — plataformas com pausa automática param de cobrar quando um sandbox está esperando uma resposta do LLM, o que pode reduzir custos significativamente para workflows interativos. Veja Modelos de Preços de Sandbox de Agente de IA: Por Sessão, Computação, Armazenamento e Egresso para uma análise detalhada de cada eixo de preço.
Como o tempo de sessão, computação e egresso interagem no custo?
Para a maioria das workloads, o tempo de computação domina. Uma sessão de codificação de 10 minutos em 1 vCPU custa mais do que 1 GB de egresso a taxas típicas. Mas a interação é importante para workloads específicas: um agente de dados que baixa um grande conjunto de dados de treinamento gerará cobranças de egresso que superam o custo de computação. Um agente de navegador que mantém sessões abertas entre turnos do LLM acumulará computação ociosa se a pausa automática não estiver ativada. A abordagem prática é estimar cada dimensão em relação ao seu perfil de workload real antes de se comprometer com uma plataforma. O Novita Agent Sandbox fatura por segundo com base no uso real de vCPU e memória, sem taxa de inicialização por sessão; em meados de 2026, 1 vCPU tem preço de $0,0000098/s. (Fonte: página de preços da Novita AI, verificado na documentação publicada. Sempre verifique as taxas atuais antes do planejamento orçamentário.)
Auto-Hospedagem vs. Sandbox de Agente de IA Gerenciado
Quando as equipes devem auto-hospedar em vez de usar um sandbox gerenciado?
Auto-hospedar (executar sua própria infraestrutura de sandbox, geralmente em Firecracker ou uma camada de microVM comparável) faz sentido quando: requisitos de residência de dados ou política de rede proíbem o uso de um serviço gerenciado de terceiros, o volume de workload é alto o suficiente para que o custo do serviço gerenciado exceda o custo operacional de executar sua própria infraestrutura, ou a equipe tem capacidade de engenharia de plataforma existente e deseja controle total sobre o modelo de isolamento, governança de imagem e política de rede. Auto-hospedar é mais difícil do que parece: gerenciar kernels, sistemas de arquivos raiz, imagens, snapshots, limitadores de taxa, métricas, limpeza e isolamento multi-inquilino é trabalho real. Veja Firecracker para Sandboxes de Agentes de IA para saber como é o escopo operacional.
Quando um sandbox gerenciado faz mais sentido?
Para a maioria das equipes construindo agentes de codificação, ferramentas de análise de dados, workflows de automação de navegador ou pipelines de avaliação, um sandbox gerenciado é o caminho mais rápido para produção. A plataforma lida com provisionamento de infraestrutura, endurecimento de segurança, atualizações de imagem, escalonamento e gerenciamento de ciclo de vida. A equipe se concentra na arquitetura do agente, não nos internals do sandbox. A comparação de custos não é apenas as taxas de computação em nuvem: leve em consideração o tempo de engenharia para construir e manter a camada de isolamento, o trabalho de conformidade para documentá-la e a resposta a incidentes quando algo inesperado acontece. Para equipes sem capacidade dedicada de engenharia de plataforma, os serviços gerenciados geralmente chegam mais rápido à produção e mantêm um custo total de propriedade mais baixo. Veja Modelos de Preços de Sandbox de Agente de IA para um framework para comparar o custo total gerenciado vs. auto-hospedado.
Que perguntas as equipes devem fazer ao avaliar provedores de sandbox gerenciados?
Perguntas de avaliação práticas além do preço principal:
- Qual é o modelo de isolamento por sessão (microVM, contêiner, processo)?
- Qual é a política de egresso padrão e configurável?
- Quais opções de governança de instalação de pacotes existem?
- Como os segredos são injetados e limpos?
- Quais dados de log de auditoria estão disponíveis e como são acessados?
- Quais são os limites de duração da sessão e concorrência no seu nível exigido?
- O provedor suporta implantação BYOC ou VPC?
- Qual é o comportamento de pausa/retomada e como ele afeta o faturamento?
- Como a latência de inicialização se comporta em escala (pool quente, snapshot, inicialização a frio)?
Executando Código Não Confiável com Segurança
Como executar código gerado por IA com segurança em produção?
A linha de base é: não execute código gerado por LLM no seu host. Roteie toda a execução através de um sandbox que forneça isolamento de sistema de arquivos, processo e rede. Além disso, cinco práticas fazem uma diferença significativa: (1) defina a política de egresso explicitamente — negar por padrão com uma lista de permissões é mais seguro do que abrir por padrão; (2) escopee segredos estreitamente — injete apenas as credenciais que a tarefa atual precisa; (3) governe instalações de pacotes — permita instalações de registros aprovados ou use imagens pré-construídas para workloads reproduzíveis; (4) registre no nível do kernel ou hipervisor em vez de confiar em logs de camada de aplicação; (5) defina limites de recursos — CPU, memória, disco e tempo limite de parede — para que um agente descontrolado não possa afetar sessões adjacentes. Veja Quão Seguro é o Sandbox de IA para Executar Código? para uma lista de verificação de avaliação completa.
Existe um sandbox de agente de IA de código aberto?
Sim. Daytona é de código aberto sob licença AGPL e suporta implantação auto-hospedada. O SDK principal do E2B é de código aberto, embora a infraestrutura de tempo de execução gerenciada não seja. Se você quiser construir seu próprio sandbox do zero, a abordagem mais comum é Firecracker (desenvolvido pela AWS, licenciado Apache 2.0) como o tempo de execução de microVM, combinado com seu próprio gerenciamento de imagem, orquestração e controle de ciclo de vida. Auto-hospedar significa assumir o escopo operacional que um serviço gerenciado abstrai: gerenciamento de kernel, governança de sistema de arquivos raiz, limitação de taxa, armazenamento de snapshot, políticas de limpeza e isolamento multi-inquilino. Veja Firecracker para Sandboxes de Agentes de IA para como esse escopo parece na prática.
O que é uma plataforma de sandbox de IA gerenciada?
Uma plataforma de sandbox de IA gerenciada é um serviço de nuvem que fornece infraestrutura de sandbox como uma API: você chama o SDK, um sandbox é provisionado e retornado em um estado pronto, e a plataforma lida com a computação, rede, gerenciamento de imagem e ciclo de vida subjacentes. Novita Agent Sandbox, E2B e o modo gerenciado do Daytona são exemplos. A alternativa é auto-hospedar, onde você provisiona e opera a infraestrutura de sandbox você mesmo. As principais perguntas para qualquer plataforma gerenciada são: qual modelo de isolamento ela usa, qual política de egresso é configurável, se a implantação BYOC ou VPC está disponível e qual é o preço por segundo para sua workload esperada. Veja Melhores Sandboxes de Agentes de IA em 2026 para uma comparação estruturada.
O que é um sandbox de agente de IA para uso empresarial?
Os requisitos de sandbox de agente de IA empresarial normalmente se estendem além do que um serviço gerenciado focado em desenvolvedores fornece por padrão. Os requisitos comuns incluem: implantação BYOC ou VPC (o sandbox executa dentro da sua conta de nuvem, não em um inquilino de terceiros compartilhado); certificação SOC 2 ou ISO 27001; política de egresso configurável e exportação de log de auditoria para um SIEM; escopo de credenciais ao nível da sessão com tokens de curta duração; e controles de residência de dados que restringem onde as workloads do agente executam. O Novita Agent Sandbox suporta implantação BYOC em sua própria VPC AWS ou GCP, o que atende aos requisitos mais comuns de residência de dados e isolamento de rede empresarial. Verifique as certificações de conformidade atuais e as opções de configuração disponíveis na documentação do produto antes de tomar decisões de arquitetura.
