Sandboxing Determinístico para Agentes de IA: WASI 0.2, seccomp-bpf, Landlock e MicroVMs na Execução Segura de Código

A execução autônoma de código por agentes de inteligência artificial transformou a fronteira de segurança da engenharia de software em 2026. Quando um agente de desenvolvimento — como o MaxVision Code, OpenCode, Claude Code ou Codex — sintetiza scripts, interage com o terminal bash, aciona servidores MCP (Model Context Protocol) ou roda suítes de testes, ele lida inerentemente com código não confiável e potencialmente perigoso. Submeter essas instruções diretamente ao sistema operacional do host ou a contêineres Docker compartilhados com acesso root cria vetores severos de injeção indireta, exfiltração de variáveis de ambiente e escape de processos.

O problema de segurança: por que rodar código de IA sem contenção é crítico

O risco fundamental na operação de agentes de engenharia decorre da confluência entre autonomia operacional e ingestão de dados externos não verificados. O ecossistema de segurança de IA categoriza essas vulnerabilidades através do documento oficial OWASP Top 10 for Large Language Model Applications (Edição 2025):

1. LLM02 — Insecure Output Handling (Manipulação Insegura de Saída): Ocorre quando a saída gerada pelo modelo é repassada diretamente para interpretadores do sistema (bash, python, sh) sem sanitização estrutural ou limites de privilégio. Um script sintetizado para "limpar temporários" pode executar inadvertidamente comandos destrutivos no diretório de trabalho do desenvolvedor.
2. LLM06 — Sensitive Information Disclosure & Indirect Prompt Injection: Agentes de desenvolvimento inspecionam logs, mensagens de compilação, páginas web e repositórios de terceiros. Se um arquivo clonado ou payload de dependência contiver instruções adversariais ocultas (injeção indireta de prompt), o modelo pode ser instruído a ler arquivos confidenciais (~/.ssh/id_rsa, .env, tokens de nuvem) e tentar transmiti-los para servidores externos via utilitários de rede ou resolução de DNS.
3. LLM08 — Excessive Agency (Agência Excessiva): Conceder permissões operacionais amplas, ferramentas com escopos genéricos e acesso irrestrito ao sistema operacional sem contenção determinística permite que ações imprevistas do agente causem danos irreversíveis à infraestrutura.
4. Ganchos de Ciclo de Vida em Instalação de Dependências: Comandos como npm install ou cargo build executam ganchos de ciclo de vida (preinstall, build.rs). Sem sandboxing a nível de processo e sistema de arquivos, dependências maliciosas exploram ganchos de automação durante a compilação.

Limitações do Docker tradicional na operação de agentes

Historicamente, equipes de engenharia recorrem a contêineres Docker para isolar processos. No entanto, para a execução contínua e interativa de agentes de desenvolvimento, contêineres OCI padrão impõem desafios arquiteturais:

• Latência de Inicialização do Daemon: Criar e inicializar um contêiner Docker via daemon impõe uma sobrecarga perceptível a cada ciclo de ferramenta (geralmente entre centenas de milissegundos a mais de um segundo), penalizando workflows de agentes que demandam dezenas de checagens sintáticas rápidas.
• Superfície de Kernel Compartilhado: Contêineres OCI compartilham o mesmo kernel do sistema hospedeiro. Vulnerabilidades documentadas no ecossistema de runtime de contêineres — como o escape de contêiner CVE-2024-21626 no runc por vazamento de descritores de arquivo internos (/sys/fs/cgroup) — evidenciam que isolamento baseado apenas em namespaces Linux tradicionais não oferece barreira de contenção absoluta contra processos maliciosos com acesso root interno.
• Exposição do Socket do Daemon: Disponibilizar o socket /var/run/docker.sock para conceder ao agente a capacidade de gerenciar contêineres concede, na prática, privilégios equivalentes a acesso root no host.

Primitivas nativas do Linux Kernel: seccomp-bpf e Landlock LSM

Para isolar processos locais sem a sobrecarga de gerenciar daemons de contêineres, o kernel Linux oferece primitivas de segurança programáveis e unprivileged.

+-------------------------------------------------------------------------+
|                        Processo do Agente / Ferramenta                   |
+-------------------------------------------------------------------------+
       |                                                 |
       | Syscall request                                 | I/O em Filesystem / Rede
       v                                                 v
+-------------------------------+               +-------------------------+
|          seccomp-bpf          |               |      Landlock LSM       |
|  - Filtra tabela de syscalls  |               |  - Whitelist de paths   |
|  - Bloqueia execve/ptrace     |               |  - Bloqueia TCP bind    |
+-------------------------------+               +-------------------------+
       |                                                 |
       +-----------------------+-------------------------+
                               |
                               v
               [ Kernel Linux (Host / Subsystem) ]

seccomp-bpf: filtragem determinística de syscalls

O seccomp-bpf (Secure Computing Mode with Berkeley Packet Filter), conforme especificado na documentação oficial do Linux Kernel (seccomp_filter), permite acoplar um programa de filtro BPF a um processo e a todos os seus filhos.

Ao receber uma chamada de sistema, o filtro BPF inspeciona o número da syscall e seus argumentos em tempo de execução, retornando uma das seguintes ações:

• SECCOMP_RET_ALLOW: Executa a chamada normalmente.
• SECCOMP_RET_KILL_PROCESS: Encerra o processo imediatamente ao detectar uma violação de segurança.
• SECCOMP_RET_ERRNO: Bloqueia a execução e retorna um erro simulado (ex: EPERM ou EACCES) para a aplicação sem derrubar o processo.

Em ambientes de agentes, o seccomp-bpf é configurado para restringir chamadas perigosas como ptrace (inspeção de outros processos em memória), process_vm_writev e manipulação indevida de namespaces.

Landlock LSM: controle de acesso unprivileged em profundidade

Introduzido no Linux 5.13 e expandido em versões recentes do kernel, o Landlock LSM (Linux Security Module) soluciona uma limitação histórica: ele permite que processos sem privilégios de root (unprivileged) restrinjam seu próprio acesso ao sistema de arquivos e à rede.

Uma ferramenta de agente invoca a syscall landlock_restrict_self(), estabelecendo uma cerca hierárquica imutável:

// Exemplo conceitual de restrição unprivileged via Landlock
struct landlock_ruleset_attr attr = {
    .handled_access_fs = LANDLOCK_ACCESS_FS_READ_FILE |
                         LANDLOCK_ACCESS_FS_WRITE_FILE |
                         LANDLOCK_ACCESS_FS_READ_DIR,
};
int ruleset_fd = landlock_create_ruleset(&attr, sizeof(attr), 0);

// Concede leitura/escrita estritamente no diretório de scratch do agente
struct landlock_path_beneath_attr path_attr = {
    .allowed_access = LANDLOCK_ACCESS_FS_READ_FILE | LANDLOCK_ACCESS_FS_WRITE_FILE,
    .parent_fd = open("/tmp/agent-scratch", O_PATH | O_DIRECTORY),
};
landlock_add_rule(ruleset_fd, LANDLOCK_RULE_PATH_BENEATH, &path_attr, 0);

// Aplica a restrição de forma irreversível para a thread e seus filhos
prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0);
landlock_restrict_self(ruleset_fd, 0);

Após essa chamada, qualquer tentativa do processo ou de seus filhos de ler arquivos fora de /tmp/agent-scratch (como ~/.ssh/ ou /etc/shadow) falha imediatamente a nível de kernel com EACCES, mesmo que as permissões POSIX tradicionais permitissem a leitura.

WASI 0.2 e WebAssembly Component Model: isolamento por Software Fault Isolation (SFI)

Embora seccomp e Landlock limitem processos nativos do sistema operacional, a compilação de plugins e ferramentas para WASI 0.2 (WebAssembly System Interface) oferece um modelo de isolamento baseado em capacidades e contenção de memória no nível de bytecode.

Conforme documentado pela Bytecode Alliance na especificação do WASI 0.2, a evolução para o Component Model introduz garantias formais de segurança:

Segurança baseada em capacidades e eliminação de autoridade ambiente

No modelo tradicional de sistemas operacionais, qualquer processo herda a autoridade ambiente (ambient authority): se o usuário logado tem permissão para ler o arquivo .env, qualquer script invocado por ele herda esse privilégio automaticamente.

O WASI 0.2 elimina essa premissa através de segurança orientada a capacidades (capability-based security):

1. Memória Linear Isolada (Software Fault Isolation - SFI): O código WebAssembly compilado é confinado a um espaço contíguo de memória virtual (WebAssembly.Memory). O código não possui ponteiros brutos para a memória do host e não pode acessar bytes fora de sua tabela de alocação.
2. Ausência de Chamadas Implícitas: Um componente WASI não possui uma função open(path) genérica com acesso a caminhos arbitrários. Para acessar um diretório, o runtime hospedeiro (como o Wasmtime) deve passar explicitamente um descritor de arquivo com permissões pré-configuradas.
3. Interfaces Tipadas com WIT (Wasm Interface Types): As fronteiras entre ferramentas são definidas formalmente em arquivos .wit. Ferramentas escritas em Rust, Go, C++ ou TypeScript comunicam-se diretamente em memória com validação estrita de esquemas, sem custos de serialização JSON e sem expor chamadas de sistema.
4. Instanciação em Sub-Milissegundos: Por não inicializar um kernel ou carregar estruturas de sistema operacional, a instanciação de um componente WebAssembly em runtimes como Wasmtime ocorre tipicamente em frações de milissegundo, permitindo invocações isoladas sob demanda para checagens de código.

MicroVMs: isolamento por hardware com Firecracker e gVisor

Quando a tarefa do agente exige a compilação de linguagens nativas (C, C++, Rust, Go), a execução de comandos complexos de shell ou o provisionamento de serviços locais, o isolamento por software precisa ser complementado por virtualização leve baseada em hardware.

Firecracker: virtualização minimalista com KVM

Desenvolvido pela AWS e apresentado no artigo de pesquisa da USENIX NSDI 2020 (Firecracker: Lightweight Virtualization for Serverless Applications), o Firecracker é um monitor de máquinas virtuais (Virtual Machine Monitor - VMM) escrito em Rust que opera diretamente sobre a interface KVM (Kernel-based Virtual Machine) do Linux:

• Dispositivos Minimalistas: O Firecracker remove periféricos legados de PCs tradicionais (barramento PCI complexo, controladores ACPI desnecessários e drivers de vídeo), mantendo apenas dispositivos essenciais baseados no padrão virtio (virtio-net, virtio-block, virtio-vsock e console serial).
• Tempo de Boot e Overhead Reduzido: Em testes documentados pelo artigo da NSDI 2020, o Firecracker inicializa um kernel Linux em aproximadamente 5 ms em hosts dedicados, com consumo de memória base na faixa de 5 MB por MicroVM.
• Restauração por Snapshot: Utilizando mecanismos de Copy-on-Write (CoW) sobre snapshots de memória previamente inicializados, o tempo de inicialização de um ambiente de execução cai para milissegundos baixos, permitindo que cada execução de comando de um agente rode em uma máquina virtual limpa e descartável.

gVisor: interceptação de chamadas em userspace

O Google gVisor adota uma abordagem de contenção em nível de processo: seu núcleo, denominado Sentry, atua como uma camada de emulação de kernel escrita em Go que roda em espaço de usuário (userspace). O Sentry intercepta e implementa as chamadas de sistema da aplicação, evitando que o código em execução dentro do sandbox realize syscalls diretas ao kernel do host.

Comparativo de abordagens de contenção

A tabela abaixo resume as propriedades arquiteturais observadas na literatura técnica e documentação oficial dos projetos:

Arquitetura de referência: modelo de defesa em três camadas

Com base nas primitivas auditadas, a arquitetura de referência proposta para sistemas autônomos como o MaxVision Code organiza o isolamento em três camadas de defesa (Multi-Tier Defense-in-Depth):

[ Tarefa / Solicitação do Usuário ]
        |
        v
+-------------------------------------------------------------------------+
|                  Orquestrador de Agentes de Código                      |
+-------------------------------------------------------------------------+
        |
        +---> Camada L1 (Ferramentas Rápidas): WASI 0.2 / Landlock
        |     - Análise sintática de AST, linters, formatters
        |     - Instanciação imediata em memória, zero autoridade de rede
        |
        +---> Camada L2 (Compilação & Testes): MicroVM Firecracker Efêmera
        |     - Execução de comandos bash, suítes de testes, builds nativos
        |     - Isolamento KVM, descarte automático de estado pós-execução
        |
        +---> Camada L3 (Network Egress Gateway): Proxy Determinístico
              - Allowlist estrita de registries de pacotes e repositórios
              - Bloqueio imediato de metadados de nuvem (169.254.169.254) e RFC 1918

1. Camada L1: Ferramentas Leves e Plugins MCP (WASI 0.2 & Landlock)

Ferramentas dedicadas à inspeção de árvores sintáticas (AST via Tree-sitter), checagem de tipos ou formatação são estruturadas como componentes WASI 0.2 ou executadas sob Landlock LSM. Elas operam restritas aos arquivos explicitamente repassados na requisição, sem capacidade de comunicação com a rede externa.

2. Camada L2: Execução de Shell e Compilação Arbitrária (Firecracker MicroVM)

Quando o fluxo de trabalho exige rodar testes unitários (vitest, pytest, cargo test) ou construir artefatos via compiladores nativos, o despachante inicializa uma MicroVM Firecracker efêmera a partir de uma imagem base com o toolchain pré-configurado. Ao término do comando, o estado da VM é descartado, prevenindo a persistência de modificações residuais.

3. Camada L3: Egress Gateway com Allowlist Estrita

O tráfego de rede gerado durante a resolução de pacotes passa por um proxy de saída determinístico:

• Allowlist de Registries Confiáveis: Conexões externas permitidas exclusivamente para endpoints de pacotes oficiais (registry.npmjs.org, pypi.org, crates.io, github.com).
• Bloqueio de Metadados de Nuvem e Redes Privadas: Bloqueio mandatório de faixas IP privadas RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) e de endpoints de metadados de provedores cloud (169.254.169.254), mitigando vetores de SSRF voltados ao roubo de credenciais IAM.

Perguntas frequentes sobre sandboxing de agentes de código

Por que não usar apenas Docker com usuário sem privilégios (non-root)?

Executar contêineres sem privilégios de root reduz a autoridade interna do processo, mas mantém o kernel compartilhado com o sistema operacional hospedeiro. Vulnerabilidades na camada de runtime (como falhas de descritores de arquivos no runc) e acessos indevidos a interfaces de rede continuam exigindo mecanismos adicionais de contenção.

Qual é a diferença prática entre WASI 0.2 e uma MicroVM Firecracker?

O WASI 0.2 implementa isolamento no nível de bytecode e memória de processo (Software Fault Isolation), sendo indicado para funções específicas, plugins e ferramentas compiladas sem necessidade de kernel completo. O Firecracker provê uma máquina virtual sobre KVM com um kernel Linux dedicado, necessária para executar scripts bash arbitrários, dependências compiladas e ambientes completos de desenvolvimento.

O Landlock LSM requer privilégios de root para ser configurado?

Não. O Landlock LSM foi projetado como uma interface unprivileged. Qualquer processo de usuário pode aplicar regras restritivas de sistema de arquivos e rede para si mesmo e para todos os seus processos filhos invocando a syscall landlock_restrict_self().

Fontes citadas e referências técnicas

1. Linux Kernel Documentation — seccomp BPF System Call Filtering: https://docs.kernel.org/userspace-api/seccomp_filter.html — Especificação técnica oficial sobre o modo de computação segura com filtros BPF no kernel Linux.
2. Linux Kernel Documentation — Landlock: Unprivileged Access-Control: https://docs.kernel.org/security/landlock.html — Documentação da arquitetura e APIs do Linux Security Module para restrição hierárquica sem privilégios de root.
3. Bytecode Alliance — WebAssembly System Interface (WASI) 0.2 Specification: https://bytecodealliance.org/articles/WASI-0.2 — Especificações formais do Component Model, WIT interfaces e segurança orientada a capacidades no WebAssembly.
4. USENIX NSDI 2020 — Firecracker: Lightweight Virtualization for Serverless Applications: https://www.usenix.org/conference/nsdi20/presentation/agache — Artigo acadêmico detalhando a arquitetura de MicroVMs em Rust sobre KVM.
5. Google gVisor Architecture & Threat Model: https://gvisor.dev/docs/architecture_guide/ — Arquitetura de contenção de contêineres com emulação de chamadas de sistema em userspace via Sentry.
6. OWASP Top 10 for Large Language Model Applications (Edição 2025): https://owasp.org/www-project-top-10-for-large-language-model-applications/ — Diretrizes de segurança cobrindo LLM02 (Insecure Output Handling), LLM06 (Sensitive Information Disclosure) e LLM08 (Excessive Agency).
7. Open Containers Initiative (OCI) / runc Security Advisory CVE-2024-21626: https://github.com/opencontainers/runc/security/advisories/GHSA-xr7r-f8xq-vfvv — Detalhamento técnico da vulnerabilidade de escape de contêiner via vazamento de descritores de arquivo internos no runc.