Sandboxing de Agentes

1. Visão Geral do Conceito e Problema Sistêmico

Agentes autônomos atingem seu potencial máximo apenas quando têm a capacidade de executar comandos de sistema no terminal, escrever código, instalar pacotes e testar programas em tempo real. No entanto, conceder ao agente acesso direto ao sistema host do desenvolvedor ou servidor representa um risco crítico de segurança da informação:

1. Imprevisibilidade do LLM: O modelo pode gerar um comando destrutivo devido a alucinações (por exemplo, um rm -rf recursivo acidental em um caminho mal formado).
2. Ataques de Prompt Injection Indireto (Indirect Injection): Se o agente analisar um site externo ou ler um repositório GitHub de terceiros, um prompt malicioso oculto no texto pode forçar o modelo a ler arquivos como ~/.ssh/id_rsa, .env e enviá-los para o servidor remoto do atacante via curl.
3. Esgotamento de Recursos do Host: Loops infinitos ou Fork Bombs podem paralisar todo o servidor.

O Agent Sandboxing resolve esse conflito, fornecendo ao agente um ambiente absolutamente seguro, isolado e efêmero (ephemeral).

2. Taxonomia Arquitetural e Modelo Mental

Dependendo dos requisitos de segurança e velocidade de inicialização, distinguem-se quatro níveis arquiteturais de isolamento:

• 1. Isolamento de Processo do SO (Namespaces & Cgroups, Bubblewrap): Separação básica do sistema de arquivos, PID e limites de memória dentro do Linux. Possui a inicialização mais rápida (<50 ms), mas não protege contra exploits no nível do kernel.
• 2. Virtualização no Nível do Kernel (gVisor / User-space Kernel): Camada especial desenvolvida pela Google que emula o kernel Linux no espaço do usuário. Cada chamada de sistema (syscall) é filtrada e não interage com o kernel real do host.
• 3. MicroVMs de Hardware (AWS Firecracker, Kata Containers): Padrão ouro da segurança em nuvem. Uma máquina virtual minimalista real com seu próprio kernel Linux, que inicia em 100–150 ms e está totalmente isolada no nível do hypervisor de hardware KVM.
• 4. WebAssembly (Wasm / WASI Runtimes): Execução de código em bytecode isolado interno (por exemplo, Wasmtime). Ideal para execução segura de JavaScript/Python sem um sistema operacional, mas possui limitações para chamadas de utilitários do sistema.

3. Pipeline Técnico e Mecânica Interna

O ciclo de vida da execução isolada de tarefas consiste em 4 etapas:

1. Provisionamento Efêmero (Ephemeral Provisioning): O orquestrador cria uma nova instância de microcontainer a partir de uma imagem snapshot pré-preparada com o ambiente instalado (Node.js, Python, Git).
2. Montagem do Workspace Virtual e Redação de Segredos (Virtual Workspace Mount & Secret Redaction): Apenas a pasta de trabalho do projeto atual é montada na sandbox. Todos os tokens de acesso reais (chaves AWS, credenciais de banco de dados de produção) são substituídos por tokens mockados ou tokens temporários com escopo limitado.
3. Execução e Interceptação de Syscalls (Execution & Syscall Interception): O agente envia o comando via gRPC ou WebSocket API. O driver da sandbox executa o comando, transmite stdout/stderr para o agente e interrompe automaticamente a execução se o processo exceder o limite de tempo (Execution Timeout) ou de memória (OOM Watchdog).
4. Desmontagem Instantânea e Coleta de Lixo (Instant Teardown & Garbage Collection): Após a conclusão da tarefa, todo o container é destruído irreversivelmente junto com todos os artefatos temporários. Nenhum estado persiste para a próxima sessão.

4. Cenários Práticos de Engenharia em Produção

01. Code Interpreter Seguro para Usuários

O serviço permite que usuários façam upload de tabelas CSV/Excel e solicitem ao agente que escreva scripts Python para visualizações complexas. O código é executado em microcontainers E2B sem o risco de leitura de arquivos adjacentes de outros usuários.

02. Teste Autônomo de Repositórios de Terceiros e PRs

O agente baixa automaticamente Pull Requests, executa npm install e roda testes. Se houver um script preinstall malicioso nas dependências (ataque à cadeia de suprimentos), o ataque será bloqueado pelas paredes da sandbox.

03. Scraping Web e Browsing Isolados

O agente usa Headless Chromium para navegar em sites perigosos na web. O navegador é executado em um container isolado sem acesso ao armazenamento de senhas do sistema ou VPN corporativa.

5. Armadilhas Comuns, Erros Típicos e Segurança

• Vazamentos SSRF de Egress de Rede (Network Egress SSRF Leaks): Por padrão, o container pode fazer ping na rede local do host. É necessário configurar uma política estrita de tráfego egress (Isolamento de Rede), bloqueando o acesso a localhost e sub-redes de metadados de nuvem.
• Desequilíbrio entre Latência vs. Segurança (Latency vs Security): Máquinas virtuais completas levam segundos para iniciar, o que irrita o usuário. Use pools de containers "aquecidos" (Warm Pools) ou tecnologia de Forking MicroVM para resposta instantânea.
• Fome de Recursos (Resource Starvation / Fork Bombs): O agente ou script pode criar processos infinitamente (:(){ :|:& };:). Limite rigorosamente sempre o número máximo de processos (pids_limit) e a memória (mem_limit).