エージェント用サンドボックスの継続的エスケープテスト
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〜10万円($2〜10k)程度を、既存のペネトレーションテスト予算から支出する想定。$2
議論での声
- EX.1mxcとbubblewrapでサンドボックスのエスケープとケーパビリティ順序の誤りを発見し、両方について完全なエスケープ手順を書き起こした。コメントを読む ↗
- 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
空白既存の選択肢は、単発の人手による監査か汎用ファザーに限られる。ケーパビリティの順序、setuidの誤り、カーネル境界の前提といった既知のエスケープ分類について、バージョンやバックエンドをまたいでサンドボックスライブラリと設定を継続的にリグレッションテストするものはない。
3ステップで作る
- 1bubblewrap、mxc、gVisorの設定に対し、既知のサンドボックスエスケープ手法(ケーパビリティ、setuid、システムコール、ファイルシステムの名前空間)の一式を実行するハーネスを構築する。
- 2依存関係のアップグレードやポリシー変更によってエスケープ分類が発生したときに警告を出すCIアクションを提供する。
- 3ライブラリごとの該当性分析を付けた公開のサンドボックスCVEトラッカーを公開し、配布の起点とする。
英語からの翻訳です。 原文を読む