Kontinuierliche Escape-Tests für Agent-Sandboxes
Ein Test-Harness und CVE-Watch-Dienst, der Sandbox-Bibliotheken (mxc, bubblewrap, gVisor) laufend auf Escapes und Fehlkonfigurationen prüft, bevor Anbieter von Agent-Tools sie ausliefern.
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.
Ein fertiges Briefing für Claude Code, Cursor oder jeden anderen Coding-Agenten (auf Englisch).
Was dafür spricht
- EX.1Hat Sandbox-Escapes und falsche Capability-Reihenfolge in mxc und bubblewrap gefunden und für beide vollständige Escapes ausgearbeitet.Kommentar lesen ↗
- EX.2Hat die Backend-Doku überflogen und daraus geschlossen, dass das Projekt wie LLM-generiert wirkt und kein kohärentes Sicherheitskonzept erkennen lässt. Das Vertrauen liegt bei null.Kommentar lesen ↗
- EX.3Befürchtet, dass die Verbreitung von Copy-Paste-Sandboxes dazu führt, dass eine einzige CVE viele davon trifft, ohne dass jemand sie sauber beheben kann.Kommentar lesen ↗
- EX.4Misstraut der 350.000-Zeilen-Codebasis und würde lieber auf etwas aufbauen, das klein genug ist, um es zu verstehen.Kommentar lesen ↗
Jeder Agent-Anbieter bringt dieses Jahr eine Sandbox auf den Markt oder übernimmt eine (Codex nutzt laut c:50020557 bereits mxc), und Kommentatoren zeigen, dass diese Codebasen bereits ausnutzbare Escapes enthalten. Daraus entsteht dringender Bedarf an unabhängiger Validierung.
Was dagegen spricht
Agent-Anbieter, die unprüfbare Sandboxes mit bekannten Escapes ausliefern, erzeugen echten, dringenden Bedarf an unabhängigen, kontinuierlichen Escape-Tests, den punktuelle Pentests nicht abdecken. Der TAM ist klein, aber Lücke und Zeitpunkt sind real.
Ein wachsender Korpus aus Escape-Testfällen und Konfigurations-Fingerprints pro Backend, der mit jeder offengelegten CVE und jedem Audit besser wird, dazu die Integration in CI, die einen Wechsel teuer macht.
Bestehende Optionen sind punktuelle Audits durch Menschen oder generische Fuzzer. Niemand testet Sandbox-Bibliotheken und ihre Konfigurationen kontinuierlich per Regressionstest auf bekannte Escape-Klassen (Capability-Reihenfolge, setuid-Fehler, Annahmen an der Kernel-Grenze) über Versionen und Backends hinweg, während sie ausgeliefert werden.
In 3 Schritten bauen
- 1Harness bauen, das eine Batterie bekannter Sandbox-Escape-Techniken (Capability, setuid, Syscall, Filesystem-Namespace) gegen bubblewrap-, mxc- und gVisor-Konfigurationen ausführt
- 2CI-Action ausliefern, die meldet, wenn ein Dependency-Upgrade oder eine Policy-Änderung eine Escape-Klasse öffnet
- 3Öffentlichen Sandbox-CVE-Tracker mit Anwendbarkeitsanalyse pro Bibliothek veröffentlichen, um Reichweite aufzubauen
Aus dem Englischen übersetzt. Original lesen