✓ Survived#1 of 2VentureSecurity

Continuous escape testing for agent sandboxes

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.

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.

Open the discussion ↗

A ready-to-paste brief for Claude Code, Cursor or any coding agent.

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.4out of 10

The case for

Who paysSecurity/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.$2–10k/mo

What people said

Paraphrased from the discussion. Follow the links for the original comments.

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.

The case against

✕ What would kill itSandbox vendors fix the easy escape classes quickly and buyers decide occasional pentests are enough, leaving no recurring budget.

The red team's strongest objection

Agent vendors shipping unauditable sandboxes with known escapes creates real, urgent demand for independent continuous escape testing that episodic pentests don't cover; small TAM but genuine gap and timing.

Moat 5/10

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.

Already out there

Manual pentest firms (Trail of Bits, NCC Group)OSS-Fuzz / generic fuzzingOne-off audits and CVE feedsIn-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.

Build it in 3 steps

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

Source discussion“MXC - a sandboxed code execution system” ↗196 points, 85 commentsFrom the commentsLinked article

Continuous escape testing for agent sandboxes

The case for

The case against

Build it in 3 steps

More from this issue