✓ RetenueN° 1 sur 2VentureSécurité

Tests d'évasion continus pour les sandboxes d'agents

Un harnais de test et un service de veille CVE qui sondent en continu les bibliothèques de sandbox (mxc, bubblewrap, gVisor) à la recherche d'évasions et de mauvaises configurations, avant que les éditeurs d'outils d'agents ne les livrent.

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.

Ouvrir la discussion ↗

Un brief prêt à coller dans Claude Code, Cursor ou tout agent de code (en anglais).

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.4sur 10

Les arguments pour

Qui paieResponsables sécurité et ingénierie chez des entreprises d'agents de code IA et de runtimes d'agents (20 à 500 ingénieurs), 2 à 10 k$/mois sur le budget de tests de sécurité, en complément des pentests existants.

Ce que les gens ont dit

Reformulé à partir de la discussion. Suivez les liens pour lire les commentaires d'origine.

Pourquoi maintenant

Chaque éditeur d'agents déploie ou adopte une sandbox cette année (Codex utilise déjà mxc, cf. c:50020557), et des commentateurs démontrent que ces codebases contiennent déjà des évasions exploitables, ce qui crée une demande urgente de validation indépendante.

Les arguments contre

✕ Ce qui la ferait échouerLes éditeurs de sandbox corrigent rapidement les classes d'évasion faciles, et les acheteurs estiment que des pentests occasionnels suffisent, ce qui supprime le budget récurrent.

L'objection la plus forte de la red team

Des éditeurs d'agents livrent des sandboxes non auditables avec des évasions connues, ce qui crée une demande réelle et urgente de tests d'évasion continus et indépendants, que les pentests ponctuels ne couvrent pas ; TAM réduit mais vrai manque et bon timing.

Avantage défensif 5/10

Un corpus croissant de cas de test d'évasion et d'empreintes de configuration par backend, qui s'améliore à chaque CVE divulguée et chaque audit, ainsi qu'une intégration en CI qui rend le changement de fournisseur coûteux.

Ce qui existe déjà

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

Le manque

Les options actuelles sont des audits humains ponctuels ou des fuzzers généralistes ; personne ne soumet en continu les bibliothèques de sandbox et leurs configurations à des tests de non-régression sur les classes d'évasion connues (ordre des capabilities, erreurs setuid, hypothèses sur la frontière noyau), à travers les versions et les backends au fil des livraisons.

La construire en 3 étapes

1Construire un harnais qui exécute une batterie de techniques d'évasion de sandbox connues (capabilities, setuid, syscalls, namespaces de système de fichiers) contre des configurations bubblewrap, mxc et gVisor
2Livrer une action CI qui signale lorsqu'une mise à jour de dépendance ou un changement de politique ouvre une classe d'évasion
3Publier un suivi public des CVE de sandbox avec une analyse d'applicabilité par bibliothèque pour amorcer la diffusion

Discussion d'origine“MXC - a sandboxed code execution system” ↗196 points, 85 commentairesDes commentairesArticle lié

Traduit de l'anglais. Lire l'original

Tests d'évasion continus pour les sandboxes d'agents

Les arguments pour

Les arguments contre

La construire en 3 étapes

Plus dans cette édition