एजेंट सैंडबॉक्स के लिए लगातार एस्केप टेस्टिंग
एक टेस्ट हार्नेस और CVE-वॉच सेवा जो सैंडबॉक्स लाइब्रेरी (mxc, bubblewrap, gVisor) को विक्रेताओं द्वारा रिलीज़ करने से पहले लगातार एस्केप और misconfiguration के लिए परखती है।
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.
Claude Code, Cursor या किसी भी कोडिंग एजेंट में चिपकाने के लिए तैयार ब्रीफ़ (अंग्रेज़ी में)।
पक्ष में तर्क
- EX.1mxc और bubblewrap में सैंडबॉक्स एस्केप और गलत capability ordering मिला, और दोनों के लिए पूरे एस्केप लिखे।टिप्पणी पढ़ें ↗
- EX.2बैकएंड डॉक्स सरसरी तौर पर देखे और निष्कर्ष निकाला कि प्रोजेक्ट LLM से बना लगता है, जिसमें कोई सुसंगत सुरक्षा डिज़ाइन नहीं है, इसलिए भरोसा शून्य रहा।टिप्पणी पढ़ें ↗
- EX.3चिंता है कि copy-paste वाले स्लॉप सैंडबॉक्स के फैलाव से एक CVE कई में एक साथ लगेगा और उन्हें ठीक से ठीक करने वाला कोई नहीं होगा।टिप्पणी पढ़ें ↗
- EX.4350k-लाइन कोडबेस पर भरोसा नहीं, और ऐसी चीज़ पर बनाना पसंद करेंगे जो इतनी छोटी हो कि समझी जा सके।टिप्पणी पढ़ें ↗
इस साल हर एजेंट विक्रेता सैंडबॉक्स शिप या अपना रहा है (Codex पहले ही c:50020557 के अनुसार mxc इस्तेमाल करता है), और कमेंट करने वाले दिखा रहे हैं कि इन कोडबेस में पहले से exploitable एस्केप मौजूद हैं, जिससे स्वतंत्र सत्यापन की तुरंत माँग बन रही है।
विपक्ष में तर्क
ऐसे विक्रेता जो बिना ऑडिट वाले सैंडबॉक्स शिप कर रहे हैं जिनमें ज्ञात एस्केप हैं, स्वतंत्र और लगातार एस्केप टेस्टिंग की वास्तविक और तुरंत माँग पैदा करते हैं, जो समय-समय पर होने वाले pentest कवर नहीं करते। TAM छोटा है, पर अंतर और समय दोनों वास्तविक हैं।
एस्केप टेस्ट केस और प्रति-बैकएंड कॉन्फ़िगरेशन फिंगरप्रिंट का बढ़ता संग्रह, जो हर खुलासे किए गए CVE और ऑडिट के साथ बेहतर होता है, साथ ही CI में एकीकरण, जिससे स्विच करना महँगा पड़ता है।
मौजूदा विकल्प या तो समय-समय पर होने वाले मानव ऑडिट हैं या सामान्य fuzzer। कोई भी सैंडबॉक्स लाइब्रेरी और कॉन्फ़िगरेशन को ज्ञात एस्केप श्रेणियों (capability ordering, setuid गलतियाँ, kernel-boundary मान्यताएँ) के लिए, वर्शन और बैकएंड में बदलाव के साथ, लगातार रिग्रेशन-टेस्ट नहीं करता।
3 कदमों में बनाएँ
- 1ज्ञात सैंडबॉक्स एस्केप तकनीकों (capability, setuid, syscall, filesystem namespace) का एक बैटरी चलाने वाला हार्नेस bubblewrap, mxc और gVisor कॉन्फ़िग के खिलाफ बनाना
- 2CI action जारी करना जो dependency अपग्रेड या policy बदलाव से कोई एस्केप श्रेणी खुलने पर चेतावनी दे
- 3प्रति-लाइब्रेरी applicability विश्लेषण के साथ सार्वजनिक sandbox-CVE ट्रैकर प्रकाशित करना ताकि प्रचार हो सके
अंग्रेज़ी से अनूदित। मूल पढ़ें