에이전트 샌드박스 지속 탈출 테스트
mxc, bubblewrap, gVisor 같은 샌드박스 라이브러리를 공급사가 배포하기 전에 지속적으로 탈출 취약점과 설정 오류를 검사하는 테스트 하네스 및 CVE 감시 서비스입니다.
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 등 코딩 에이전트에 바로 붙여 넣을 수 있는 브리프(영어)입니다.
6.410점 만점
찬성 근거
누가 돈을 내나AI 코딩 에이전트 및 에이전트 런타임 회사(엔지니어 20~500명)의 보안/엔지니어링 리더. 월 $2,000~10,000이며 기존 침투 테스트 예산에서 집행됩니다.$2,000
사람들이 한 말
- EX.1mxc와 bubblewrap에서 샌드박스 탈출과 잘못된 capability 순서를 발견하고 두 경우 모두 완전한 탈출 방법을 작성했습니다.댓글 읽기 ↗
- EX.2백엔드 문서를 훑어본 뒤 이 프로젝트가 LLM으로 생성된 것 같고 일관된 보안 설계가 없어 보인다고 결론지어 전혀 신뢰하지 않습니다.댓글 읽기 ↗
- EX.3복사-붙여넣기식 저품질 샌드박스가 확산되면 하나의 CVE가 많은 샌드박스를 동시에 공격할 수 있는데 아무도 제대로 고치지 못할까 우려합니다.댓글 읽기 ↗
- EX.435만 줄 규모의 코드베이스를 신뢰하지 않으며, 이해할 수 있을 만큼 작은 것 위에 만들고 싶어 합니다.댓글 읽기 ↗
왜 지금인가
올해 모든 에이전트 벤더가 샌드박스를 출시하거나 도입하고 있습니다(Codex는 이미 c:50020557에 따라 mxc를 사용). 커뮤니티에서는 이 코드베이스들에 실제 악용 가능한 탈출 취약점이 있다는 사례가 나오고 있어 독립적인 검증 수요가 시급합니다.
반대 근거
✕ 실패한다면 그 이유샌드박스 벤더가 쉬운 탈출 유형을 빠르게 수정하고, 구매자가 가끔의 침투 테스트로 충분하다고 판단하면 반복 예산이 남지 않습니다.
레드팀의 가장 강한 반론
감사할 수 없는 샌드박스를 알려진 탈출 취약점과 함께 배포하는 에이전트 벤더들 때문에, 일회성 침투 테스트로는 다루지 못하는 독립적인 지속 탈출 테스트에 대한 실질적이고 시급한 수요가 있습니다. 시장 규모는 작지만 실제 공백이 있고 타이밍도 맞습니다.
해자 5/10
공개된 CVE와 감사마다 늘어나는 탈출 테스트 케이스 모음과 백엔드별 설정 지문 데이터, 그리고 CI 통합으로 인해 전환 비용이 커집니다.
이미 있는 것
Manual pentest firms (Trail of Bits, NCC Group)OSS-Fuzz / generic fuzzingOne-off audits and CVE feedsIn-house red teaming
공백현재 선택지는 일회성 사람 감사나 범용 퍼저뿐입니다. 샌드박스 라이브러리와 설정을 알려진 탈출 유형(capability 순서, setuid 실수, 커널 경계 가정 등) 기준으로 버전과 백엔드마다 지속 회귀 테스트하는 서비스는 없습니다.
3단계로 만들기
- 1bubblewrap, mxc, gVisor 설정에 대해 알려진 샌드박스 탈출 기법(capability, setuid, syscall, 파일시스템 네임스페이스)을 일괄 실행하는 하네스를 구축합니다.
- 2의존성 업그레이드나 정책 변경으로 탈출 유형이 열릴 때 표시하는 CI 액션을 배포합니다.
- 3라이브러리별 적용 가능성 분석을 포함한 공개 샌드박스 CVE 트래커를 발행해 초기 유입을 확보합니다.
영어에서 번역했습니다. 원문 읽기