Непрерывное тестирование песочниц агентов на побеги
Harness и сервис отслеживания CVE, который непрерывно проверяет библиотеки песочниц (mxc, bubblewrap, gVisor) на побеги и misconfigurations до того, как их выпустят вендоры инструментов для агентов.
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.1Нашли побеги из песочниц и неверный порядок capabilities в mxc и bubblewrap и написали полные эксплойты для обоих.Читать комментарий ↗
- EX.2Бегло просмотрели документацию бэкендов и пришли к выводу, что проект похож на сгенерированный LLM, без связного дизайна безопасности, поэтому доверия у них нет.Читать комментарий ↗
- EX.3Опасаются, что распространение копипастных песочниц-«слопа» означает: одна CVE ударит по многим из них, и никто не сможет нормально их починить.Читать комментарий ↗
- EX.4Не доверяют кодовой базе в 350 тысяч строк и предпочли бы строить на чём-то достаточно маленьком, чтобы его понимать.Читать комментарий ↗
В этом году каждый вендор агентов выпускает или внедряет песочницу (Codex уже использует mxc, см. c:50020557), а комментаторы показывают, что в этих кодовых базах уже есть эксплуатируемые побеги. Это создаёт срочный спрос на независимую валидацию.
Аргументы против
Вендоры агентов выпускают непроверяемые песочницы с известными побегами, и это создаёт реальный срочный спрос на независимое непрерывное тестирование побегов, которое разовые пентесты не покрывают. TAM небольшой, но разрыв и тайминг настоящие.
Растущий корпус тест-кейсов на побеги и отпечатков конфигураций для каждого бэкенда, которые улучшаются с каждой раскрытой CVE и аудитом, плюс интеграция в CI, из-за которой переход к другому инструменту становится дорогим.
Сейчас есть либо разовые аудиты людьми, либо общие фаззеры. Никто не проводит непрерывную регрессионную проверку библиотек песочниц и их конфигураций на известные классы побегов (порядок capabilities, ошибки setuid, допущения о границе ядра) между версиями и бэкендами по мере выпуска.
Построить за 3 шага
- 1Создать harness, который прогоняет набор известных техник побегов из песочниц (capability, setuid, syscall, пространство имён файловой системы) против конфигураций bubblewrap, mxc и gVisor
- 2Выпустить CI-action, который сигнализирует, когда обновление зависимости или изменение политики открывает класс побегов
- 3Опубликовать публичный трекер CVE для песочниц с анализом применимости для каждой библиотеки, чтобы запустить распространение
Переведено с английского. Читать оригинал