✓ BertahanKe-1 dari 2VentureKeamanan

Pengujian escape berkelanjutan untuk sandbox agen

Harness pengujian dan layanan pemantauan CVE yang terus-menerus menguji library sandbox (mxc, bubblewrap, gVisor) untuk mencari escape dan salah konfigurasi sebelum vendor tool agen merilisnya.

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.

Buka diskusinya ↗

Ringkasan siap tempel untuk Claude Code, Cursor, atau agen coding lainnya (dalam bahasa Inggris).

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

Argumen mendukung

Siapa yang membayarPimpinan security/engineering di perusahaan coding-agent dan agent-runtime (20–500 engineer), $2–10k/bulan dari anggaran security testing, berjalan bersama pengeluaran pentest yang sudah ada.$2–10k

Apa kata orang

Diparafrasekan dari diskusi. Ikuti tautan untuk komentar aslinya.

Mengapa sekarang

Hampir semua vendor agen tahun ini merilis atau mengadopsi sandbox (Codex sudah memakai mxc menurut c:50020557), dan komentator mendemonstrasikan bahwa basis kodenya sudah memuat escape yang bisa dieksploitasi, sehingga permintaan validasi independen menjadi mendesak.

Argumen menentang

✕ Yang bisa membuatnya gagalVendor sandbox memperbaiki kelas escape yang mudah dengan cepat, dan pembeli memutuskan pentest sesekali sudah cukup sehingga tidak ada anggaran berulang.

Keberatan terkuat dari red team

Vendor agen merilis sandbox yang tidak bisa diaudit dengan escape yang sudah diketahui, sehingga muncul permintaan nyata dan mendesak untuk pengujian escape independen yang berkelanjutan, yang tidak tercakup oleh pentest sesekali; TAM-nya kecil tetapi celahnya nyata dan waktunya tepat.

Parit pertahanan 5/10

Korpus kasus uji escape dan fingerprint konfigurasi per backend yang terus bertambah setiap ada CVE atau audit yang diungkap, ditambah integrasi ke CI yang membuat pindah layanan mahal.

Yang sudah ada

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

Celahnya

Opsi yang ada hanya audit manusia yang bersifat sesekali atau fuzzer generik; belum ada yang secara berkelanjutan melakukan regression test pada library sandbox dan konfigurasinya terhadap kelas escape yang sudah diketahui (urutan capability, kesalahan setuid, asumsi batas kernel) lintas versi dan backend setiap kali dirilis.

Bangun dalam 3 langkah

1Bangun harness yang menjalankan kumpulan teknik escape sandbox yang sudah dikenal (capability, setuid, syscall, namespace filesystem) terhadap konfigurasi bubblewrap, mxc, dan gVisor
2Rilis CI action yang memberi tanda ketika upgrade dependensi atau perubahan kebijakan membuka kelas escape
3Publikasikan tracker CVE sandbox publik dengan analisis applicability per library untuk membangun distribusi awal

Diskusi asli“MXC - a sandboxed code execution system” ↗196 poin, 85 komentarDari komentarArtikel tertaut

Diterjemahkan dari bahasa Inggris. Baca versi asli

Pengujian escape berkelanjutan untuk sandbox agen

Argumen mendukung

Argumen menentang

Bangun dalam 3 langkah

Lainnya dari edisi ini