Se o seu agente de IA pode escrever código, ele pode escrever código ruim. Se ele pode chamar ferramentas, ele pode chamar a ferramenta errada com os argumentos errados. A solução não é um prompt mais inteligente. É um limite de isolamento entre a saída do modelo e a máquina que o executa. CubeSandbox é um dos sistemas construídos exatamente para essa fronteira, e vale a pena entender o que ele faz, como se compara a outras abordagens e onde se encaixa quando seus agentes começam a tocar APIs reais e dados reais.
Em Resumo (TL;DR)
CubeSandbox é um serviço de sandbox de código aberto e isolado por hardware da Tencent Cloud para executar código de agentes de IA. Cada sandbox recebe seu próprio kernel de sistema operacional convidado via KVM, inicia em cerca de 60ms e usa menos de 5MB de sobrecarga de memória. Ele é licenciado sob Apache 2.0 e é compatível diretamente com o SDK E2B.
Introdução
Sistemas agênticos estão agora escrevendo e executando código em produção. Um agente de codificação gera um script Python e o executa. Um agente de pesquisa raspa uma página, a analisa e envia o resultado para outra etapa. Um agente de dados carrega um CSV e executa transformações que o modelo decidiu em tempo de execução. Nenhum desses códigos foi revisado por um humano antes de ser executado. Esse é o problema central que o sandboxing de agentes resolve: você precisa executar instruções não confiáveis e geradas por modelo sem dar a elas seu host, seu sistema de arquivos, suas credenciais ou sua rede.
Isso importa mais à medida que os agentes ganham autonomia. Um modelo que está errado sobre uma consulta SQL é irritante. Um modelo que está errado sobre `rm -rf` ou que segue uma instrução injetada dentro de uma página web raspada é um incidente de segurança. O sandboxing traça uma linha dura: o agente pode fazer o que quiser dentro de um ambiente descartável e isolado, e nada do que ele faz vaza.
Há um segundo problema, mais silencioso. Os agentes não apenas executam código; eles chamam APIs e ferramentas. Antes de confiar em um agente para acessar sua API de pagamento ou seus serviços internos dentro de um sandbox, você precisa saber se essas APIs se comportam corretamente e se o agente as chama da maneira que você espera. É aí que as ferramentas de API ganham seu lugar ao lado do isolamento em tempo de execução. Uma plataforma como Apidog permite que você simule e teste os endpoints que um agente chamará, para que você valide o contrato antes que um sistema autônomo comece a acioná-lo em uma execução em sandbox. Se você já está pensando na arquitetura do agente, nosso guia sobre arquitetura de IA agêntica aborda como essas camadas de execução e ferramentas se encaixam.
O restante deste artigo explica o que é o CubeSandbox, por que os agentes precisam de um sandbox, como os modelos de isolamento diferem e como isso se conecta ao teste das APIs das quais seus agentes dependem.
O que é CubeSandbox?
CubeSandbox é um sistema de sandbox de segurança para executar código de agente de IA, de código aberto pela Tencent Cloud sob a licença Apache 2.0 em abril de 2026. A tagline do GitHub o descreve claramente: "Sandbox Instantâneo, Concorrente, Seguro e Leve para Agentes de IA". Não é apenas um SDK. É a pilha completa de sandbox-as-a-service, escrita principalmente em Rust, que você pode implantar você mesmo.
A arquitetura é construída sobre RustVMM e KVM, a mesma camada de virtualização do kernel Linux usada por muitos hipervisores de nuvem. De acordo com a documentação do projeto e o anúncio oficial, o sistema é dividido em vários componentes:
- CubeAPI: um gateway REST que espelha a interface de sandbox E2B.
- CubeMaster: o orquestrador de cluster que agenda sandboxes entre nós.
- CubeHypervisor e CubeShim: a camada de virtualização KVM que inicializa e gerencia cada microVM.
- Cubelet e CubeProxy: agentes de nível de nó que executam e roteiam para sandboxes.
- CubeVS: uma camada de rede alimentada por eBPF que impõe o isolamento de rede inter-sandbox no nível do kernel.
A característica principal é que cada sandbox recebe seu próprio kernel de sistema operacional convidado dedicado. Esse é um modelo de isolamento diferente e mais forte do que um contêiner, que compartilha o kernel do host. Os números publicados pela Tencent indicam uma inicialização a frio de aproximadamente 60ms em concorrência única (média de 67ms com P95 em torno de 90ms sob 50 criações concorrentes), menos de 5MB de sobrecarga de memória por instância e a capacidade de executar milhares de sandboxes em um único host grande. Os materiais de imprensa citam um servidor de 96 vCPUs suportando mais de 2.000 sandboxes concorrentes. A Tencent afirma que o CubeSandbox foi executado em escala dentro de sua própria infraestrutura e que a MiniMax o utilizou para treinamento de aprendizagem por reforço agêntica em larga escala em ambientes heterogêneos.
Alguns recursos avançados, como o rollback de snapshot em nível de evento para checkpoint e restauração do estado do sandbox, são descritos como ainda em desenvolvimento. Trate os itens futuros como roteiro, não garantias entregues, e verifique o repositório para o status atual. A metodologia de benchmark público além dos próprios números do fornecedor é limitada, então valide as alegações de desempenho em relação à sua própria carga de trabalho.
Para os detalhes canônicos, a fonte da verdade é o repositório GitHub do CubeSandbox e o site oficial de documentação.
Por que agentes de IA precisam de um sandbox
Ajuda ser concreto sobre as ameaças, porque "segurança" é muito vago para projetar contra. Existem três modos de falha que levam as equipes ao sandboxing.
Código gerado arriscado. Um modelo produz código que ele acredita estar correto. Às vezes, não está. Ele exclui o diretório errado, esgota a memória em um loop apertado ou grava um arquivo onde não deveria. Nada disso é malicioso; é apenas errado, e código errado com acesso ao host é perigoso. O agente não tem conceito de raio de explosão a menos que você o forneça.
Chamadas de ferramentas não confiáveis. Agentes chamam ferramentas e APIs com base no que o modelo decide em tempo de execução. Se o modelo for guiado por uma injeção de prompt enterrada em um documento, uma página da web ou uma resposta de ferramenta, ele pode chamar uma ferramenta destrutiva, passar argumentos controlados por um invasor ou encadear chamadas de uma forma que você nunca pretendeu. O modelo não é um ator confiável aqui; é um intérprete de qualquer texto que atinja sua janela de contexto. Aprofundamos nisso em nosso artigo sobre agentes de IA como os novos consumidores de API, que aborda por que as suposições tradicionais de confiança de API falham com chamadores autônomos.
Exfiltração de dados. Este é o que as pessoas subestimam. Um agente com acesso à rede e acesso a segredos pode ser transformado em um canal de exfiltração. Uma instrução envenenada diz ao agente para ler uma variável de ambiente que contém uma chave de API e POSTá-la para um endpoint externo. Sem filtragem de saída e isolamento de credenciais, o limite do sandbox não tem sentido porque os dados saem pela porta da frente. É por isso que o CubeSandbox emparelha o isolamento em nível de kernel com a filtragem de saída baseada em eBPF através do CubeVS; o isolamento do processo não é suficiente se a rede estiver totalmente aberta.
O fio condutor comum: você não pode presumir que o agente se comportará, porque o comportamento do agente é parcialmente controlado por quaisquer dados não confiáveis que ele ingeriu. Um sandbox permite que você pare de raciocinar sobre se o modelo é confiável e comece a raciocinar sobre um limite que se mantém independentemente. Para uma visão prática de como sondar esses comportamentos antes que atinjam a produção, consulte como testar agentes de IA que chamam APIs.
Como os sandboxes de agentes funcionam: os modelos de isolamento
Nem todos os sandboxes isolam da mesma forma, e as diferenças importam tanto para a segurança quanto para o desempenho. Existem quatro abordagens amplas que você verá no ecossistema de agentes.
Isolamento em nível de processo. Executa o código como um processo de sistema operacional restrito com filtros seccomp, capacidades descartadas, namespaces e cgroups. Esta é a opção mais leve e fraca. Ela compartilha o kernel do host, então um exploit de kernel significa um comprometimento do host. Bom para código que você confia na maioria das vezes; fraco para saída arbitrária do modelo.
Contêineres. Contêineres estilo Docker adicionam namespaces e limites de recursos e são operacionalmente familiares. Mas os contêineres compartilham o kernel do host por design. Vulnerabilidades de escape de contêiner são uma classe real e recorrente de bugs, e "código não confiável em um contêiner de kernel compartilhado" é um ponto fraco conhecido. Muitas equipes começam aqui porque é fácil, então atingem o limite de isolamento.
MicroVMs. Uma microVM inicializa um kernel convidado mínimo dentro da virtualização de hardware (KVM). O código do agente é executado em seu próprio kernel, então um exploit em nível de kernel é contido em uma VM descartável, não no host. Firecracker popularizou esse modelo para cargas de trabalho serverless, e o CubeSandbox se encaixa nessa categoria, usando RustVMM e KVM com um kernel convidado por sandbox. A desvantagem histórica era o tempo de inicialização; microVMs eram mais lentas para inicializar do que contêineres. Implementações modernas atacam isso com snapshotting e pré-provisionamento de recursos, o que é como o CubeSandbox relata inicializações abaixo de 100ms.
Kernels de aplicativo. gVisor adota um caminho diferente: ele intercepta chamadas de sistema no userspace e implementa uma interface semelhante ao Linux, de modo que a carga de trabalho nunca se comunica diretamente com o kernel do host. É uma camada de isolamento forte sem uma VM completa, com algumas desvantagens de compatibilidade de syscall e desempenho.
Veja como as abordagens se comparam nas dimensões que importam para os agentes:
| Abordagem | Força de Isolamento | Inicialização a Frio | Sobrecarga | Compartilhamento de Kernel | Exemplos |
|---|---|---|---|---|---|
| Processo + seccomp | Baixa | Instantâneo | Mínima | Kernel do host compartilhado | Subprocesso restrito, nsjail |
| Contêineres | Média | ~dezenas de ms | Baixa | Kernel do host compartilhado | Docker, containerd |
| MicroVM | Alta | ~50–150ms | Baixa–Média | Kernel convidado dedicado | CubeSandbox, Firecracker |
| Kernel de Aplicativo | Alta | ~dezenas de ms | Baixa–Média | Interceptado no userspace | gVisor |
| API de Sandbox Hospedada | Alta (gerenciada) | Varia | Gerenciada para você | Gerenciada para você | E2B, ofertas hospedadas |
Não há um único vencedor. A escolha certa depende de quão confiável você considera o código, da velocidade de inicialização a frio que você precisa, se você pode executar KVM e se deseja operar a infraestrutura você mesmo ou consumi-la como um serviço.
CubeSandbox no cenário
O posicionamento do CubeSandbox é específico: isolamento em nível de hardware com inicializações a frio rápidas o suficiente para parecer um contêiner, implantado como algo que você executa em vez de um serviço que você aluga. Isso o coloca em comparação conceitual direta com três pontos de referência.
Contra contêineres. Um contêiner compartilha o kernel do host; o CubeSandbox oferece a cada sandbox seu próprio kernel. Para código gerado por agente arbitrário, esse é o argumento de segurança. O custo é que você precisa de um host Linux x86_64 habilitado para KVM (um servidor bare-metal, uma VM em nuvem que suporte virtualização aninhada ou WSL 2 para trabalho local). Se sua plataforma não puder expor KVM, o isolamento baseado em microVM não estará disponível para você e uma abordagem em userspace como gVisor ou uma API hospedada pode se ajustar melhor.
Contra Firecracker. Firecracker é a conhecida microVM para serverless e é, por si só, um bloco de construção, não um produto de sandbox para agentes. O CubeSandbox também é baseado em KVM/RustVMM, mas está mais acima na pilha: um orquestrador, um gateway de API compatível com E2B e isolamento de rede eBPF, então você está implantando um serviço de sandbox para agentes em vez de montar um. Se você quer primitivos, Firecracker. Se você quer um serviço de sandbox com uma API no formato de agente, o CubeSandbox visa isso.
Contra E2B e sandboxes hospedados. E2B fornece sandboxes isolados como um serviço gerenciado; você chama uma API e a infraestrutura é problema de outra pessoa. A notável escolha de design do CubeSandbox é a compatibilidade com o SDK E2B. A documentação o descreve como uma substituição direta: aponte `E2B_API_URL` para sua instância Cube auto-hospedada e o código existente continua funcionando. Isso torna a decisão real menos "qual sandbox" e mais "serviço gerenciado versus infraestrutura auto-hospedada", com residência de dados, custo em escala e propriedade operacional como fatores decisivos. Ele também suporta nativamente o SDK Python do OpenAI, conforme anunciado pela Tencent.
O resumo honesto: o CubeSandbox é uma entrada crível no espaço de sandbox para agentes com uma tese clara (isolamento forte, inicializações rápidas, auto-hospedado, compatível com E2B). Também é novo e amplamente documentado por seu fornecedor, então os benchmarks independentes são escassos. Prototipe-o em sua carga de trabalho e meça a inicialização a frio, a densidade e o comportamento de isolamento antes de se comprometer.
Como isso se conecta ao teste das APIs e ferramentas que seus agentes chamam
O isolamento em tempo de execução responde a "e se o código for ruim?". Não responde a "e se a API que o agente chama for ruim, ou se o agente a chamar errado?". Esses são problemas diferentes, e você precisa cobrir ambos.
Imagine um agente em sandbox que reserva viagens. O código é executado com segurança dentro do CubeSandbox. Mas o agente ainda chama uma API de voos, uma API de pagamentos e um serviço interno de itinerários. Se alguma dessas retornar uma resposta malformada, o agente pode entrar em loop, alucinar uma recuperação ou passar dados incorretos para a próxima etapa. Se ele chamar a API de pagamentos com a chave de idempotência errada, o isolamento não o salvará; o dinheiro ainda será movimentado. O sandbox protege o host do agente. Ele não protege seus sistemas de um agente confuso fazendo chamadas reais para serviços reais.
Assim, o fluxo de trabalho que realmente funciona tem duas camadas trabalhando juntas:
- Isolar a execução para que o código gerado pelo modelo e as invocações de ferramentas não possam prejudicar o host ou exfiltrar dados. Essa é a camada CubeSandbox.
- Validar o contrato de cada API e ferramenta que o agente pode acessar, antes e durante as execuções em sandbox. Essa é a camada de ferramentas de API.
Para a segunda camada, simule as dependências para que o agente converse com um substituto controlado enquanto você testa o comportamento, e então teste os endpoints reais para conformidade com o esquema, tratamento de erros, autenticação e casos extremos. Com o Apidog, você pode construir um servidor de mock que retorna respostas determinísticas e precisas em termos de esquema, apontar o agente em sandbox para ele e observar como o agente reage tanto a caminhos de sucesso quanto de falha sem tocar na produção. Quando estiver pronto, execute os mesmos cenários contra a API real para confirmar que o contrato se mantém. Nossa abordagem sobre testes de sandbox abrange a prática geral de testes contra ambientes isolados e controlados, o que se aplica diretamente aqui.
Esse emparelhamento é importante porque os agentes amplificam a divergência de contratos. Um humano percebe quando uma resposta de API parece estranha. Um agente geralmente não; ele ingere a resposta e age sobre ela. Contratos de API rigorosos, exercidos com mocks e testes, impedem que um chamador autônomo agrave uma única resposta ruim em uma cascata. Se seus agentes falam o Protocolo de Contexto de Modelo, testar servidores MCP com Apidog estende a mesma disciplina para a camada de ferramentas. E se você estiver projetando APIs para consumidores de agentes, projetar APIs para agentes de IA aborda os padrões de contrato que tornam as chamadas autônomas previsíveis.
Casos de uso no mundo real
Alguns padrões onde a abordagem de isolamento-mais-contrato mostra seu valor:
Agentes de codificação e interpretadores de código. Um modelo escreve e executa código para responder a uma pergunta, transformar dados ou gerar um gráfico. Este é o caso de uso canônico de sandbox e aquele que as APIs compatíveis com E2B visam diretamente. O kernel por sandbox do CubeSandbox é importante aqui porque o código é totalmente arbitrário e muda a cada execução.
Plataformas de agente multi-inquilino. Se os agentes de muitos clientes executam código em infraestrutura compartilhada, o isolamento em nível de contêiner entre inquilinos é arriscado. O isolamento de hardware por sandbox oferece um limite de inquilinato que se mantém mesmo que o agente de um inquilino seja hostil. A densidade relatada (milhares de sandboxes por host) é o que torna isso viável em vez de uma VM por inquilino.
RL agêntico e loops de treinamento. Treinar agentes com aprendizado por reforço significa executar um número enorme de rollouts de curta duração e não confiáveis. A Tencent cita a MiniMax usando o CubeSandbox exatamente para isso em ambientes heterogêneos. A inicialização a frio rápida e a baixa sobrecarga por instância fazem a diferença entre uma execução de treinamento que é viável e uma que não é.
Agentes de pesquisa e dados que usam ferramentas. Um agente busca conteúdo externo, o analisa e chama APIs downstream. O conteúdo buscado não é confiável (risco de injeção de prompt), então a análise e o código gerado pertencem a um sandbox, enquanto as APIs downstream devem ser exercitadas contra mocks primeiro. É aqui que o emparelhamento de isolamento com testes de contrato de API mais compensa.
Execução de plugins ou extensões não confiáveis. Se os usuários podem fornecer ferramentas ou código que seu agente executa, você está executando código de terceiros não confiável por definição. Um limite de microVM por execução é a postura apropriada, o mesmo raciocínio que as plataformas serverless usaram ao adotar o Firecracker.
Conclusão
O sandboxing de agentes deixou de ser opcional no momento em que os agentes começaram a executar código e chamar ferramentas sem revisão humana. O CubeSandbox é uma resposta concreta e aberta para a metade do problema de isolamento.
Principais pontos:
- CubeSandbox é real e específico: o sandbox de código aberto Apache 2.0 da Tencent Cloud para agentes de IA, construído em RustVMM e KVM, com kernels convidados por sandbox.
- O modelo de isolamento é o ponto: um kernel dedicado por sandbox é mais forte do que o isolamento de contêiner para código arbitrário gerado por modelo, com inicializações a frio relatadas abaixo de 100ms e menos de 5MB de sobrecarga.
- A compatibilidade com E2B reduz o custo de troca: se você usa E2B, o caminho de substituição documentado reformula a escolha como gerenciada versus auto-hospedada, não uma reescrita.
- Trate os números do fornecedor como um ponto de partida: as alegações de desempenho e densidade vêm em grande parte da Tencent; faça um benchmark com sua própria carga de trabalho e verifique o repositório para ver quais recursos foram enviados versus quais estão em desenvolvimento.
- O isolamento é necessário, mas não suficiente: um sandbox protege seu host do agente; ele não protege suas APIs de um agente confuso que as chama.
- Emparelhe o isolamento em tempo de execução com o teste de contrato de API: simule e teste cada endpoint que um agente pode acessar para que uma única resposta ruim não se transforme em uma cascata.
Se seus agentes chamam APIs que você possui ou das quais depende, configure a camada de contrato junto com a camada de isolamento. Baixe o Apidog para simular os serviços que seus agentes em sandbox acessam e testá-los quanto a esquema, autenticação e comportamento de erro antes que um sistema autônomo os utilize em produção.