✓ SobreviveuNº 1 de 2VentureSegurança

Teste contínuo de escape para sandboxes de agentes

Um harness de testes e um serviço de monitoramento de CVEs que sondam continuamente bibliotecas de sandbox (mxc, bubblewrap, gVisor) em busca de escapes e configurações incorretas, antes que os fornecedores de ferramentas de agentes as publiquem.

I want to build a venture-scale product. Help me plan and start the MVP.

Product: Continuous escape testing for agent sandboxes
What it is: A test harness and CVE-watch service that continuously probes sandbox libraries (mxc, bubblewrap, gVisor) for escapes and misconfigurations before agent-tool vendors ship them.
Who pays: Security/engineering leads at AI coding-agent and agent-runtime companies (20–500 engineers), $2–10k/mo from the security-testing budget, alongside existing pentest spend.
Closest alternatives: Manual pentest firms (Trail of Bits, NCC Group), OSS-Fuzz / generic fuzzing, One-off audits and CVE feeds, In-house red teaming
The gap: Existing options are episodic human audits or generic fuzzers; nothing continuously regression-tests sandbox libraries and configurations for known escape classes (capability ordering, setuid mistakes, kernel-boundary assumptions) across versions and backends as they ship.
Why now: Every agent vendor is shipping or adopting a sandbox this year (Codex already uses mxc per c:50020557), and commenters demonstrate these codebases already contain exploitable escapes, creating urgent demand for independent validation.
Moat to build toward: A growing corpus of escape test cases and per-backend configuration fingerprints that improves with each disclosed CVE and audit, plus integration into CI making switching costly.

Abrir a discussão ↗

Um briefing pronto para colar no Claude Code, Cursor ou qualquer agente de programação (em inglês).

I want to build a venture-scale product. Help me plan and start the MVP.

Product: Continuous escape testing for agent sandboxes
What it is: A test harness and CVE-watch service that continuously probes sandbox libraries (mxc, bubblewrap, gVisor) for escapes and misconfigurations before agent-tool vendors ship them.
Who pays: Security/engineering leads at AI coding-agent and agent-runtime companies (20–500 engineers), $2–10k/mo from the security-testing budget, alongside existing pentest spend.
Closest alternatives: Manual pentest firms (Trail of Bits, NCC Group), OSS-Fuzz / generic fuzzing, One-off audits and CVE feeds, In-house red teaming
The gap: Existing options are episodic human audits or generic fuzzers; nothing continuously regression-tests sandbox libraries and configurations for known escape classes (capability ordering, setuid mistakes, kernel-boundary assumptions) across versions and backends as they ship.
Why now: Every agent vendor is shipping or adopting a sandbox this year (Codex already uses mxc per c:50020557), and commenters demonstrate these codebases already contain exploitable escapes, creating urgent demand for independent validation.
Moat to build toward: A growing corpus of escape test cases and per-backend configuration fingerprints that improves with each disclosed CVE and audit, plus integration into CI making switching costly.
Biggest risk: Sandbox vendors fix the easy escape classes quickly and buyers decide occasional pentests are enough, leaving no recurring budget.

First three steps:
1. Build a harness that runs a battery of known sandbox escape techniques (capability, setuid, syscall, filesystem namespace) against bubblewrap, mxc, and gVisor configs
2. Ship a CI action that flags when a dependency upgrade or policy change opens an escape class
3. Publish a public sandbox-CVE tracker with per-library applicability analysis to seed distribution

Start by asking me up to five questions about constraints (stack, budget, timeline), then propose the smallest version a paying customer would use, and scaffold it.

6.4de 10

A favor

Quem pagaLíderes de segurança e engenharia em empresas de agentes de codificação com IA e runtimes de agentes (20 a 500 engenheiros), com orçamento de US$ 2 a 10 mil/mês vindo da verba de testes de segurança, junto com os gastos atuais em pentest.$ 2

O que as pessoas disseram

Parafraseado da discussão. Siga os links para ler os comentários originais.

Por que agora

Todo fornecedor de agentes está lançando ou adotando uma sandbox este ano (o Codex já usa o mxc, segundo c:50020557), e comentaristas demonstram que essas bases de código já contêm escapes explotáveis, criando demanda urgente por validação independente.

Contra

✕ O que a faria fracassarOs fornecedores de sandbox corrigem rapidamente as classes de escape mais fáceis, e os compradores concluem que pentests ocasionais bastam, deixando sem orçamento recorrente.

A objeção mais forte do red team

Fornecedores de agentes lançando sandboxes não auditáveis com escapes conhecidos cria demanda real e urgente por teste contínuo independente de escape, que pentests pontuais não cobrem. O TAM é pequeno, mas há uma lacuna genuína e o momento é oportuno.

Fosso 5/10

Um corpus crescente de casos de teste de escape e impressões digitais de configuração por backend, que melhora a cada CVE divulgado e a cada auditoria, somado à integração em CI, o que torna a troca de fornecedor custosa.

O que já existe

Manual pentest firms (Trail of Bits, NCC Group)OSS-Fuzz / generic fuzzingOne-off audits and CVE feedsIn-house red teaming

A lacuna

As opções atuais são auditorias humanas pontuais ou fuzzers genéricos. Nada testa continuamente, por regressão, bibliotecas de sandbox e suas configurações contra classes conhecidas de escape (ordenação de capabilities, erros de setuid, premissas sobre a fronteira do kernel) entre versões e backends conforme são lançados.

Construa em 3 passos

1Construir um harness que executa uma bateria de técnicas conhecidas de escape de sandbox (capability, setuid, syscall, namespace do sistema de arquivos) contra configurações de bubblewrap, mxc e gVisor
2Lançar uma CI action que sinaliza quando uma atualização de dependência ou mudança de política abre uma classe de escape
3Publicar um rastreador público de CVEs de sandbox, com análise de aplicabilidade por biblioteca, para gerar distribuição inicial

Discussão original“MXC - a sandboxed code execution system” ↗196 pontos, 85 comentáriosDos comentáriosArtigo vinculado

Traduzido do inglês. Ler o original

Teste contínuo de escape para sandboxes de agentes

A favor

Contra

Construa em 3 passos

Mais desta edição