# $1M Vercel Sandbox Challenge: sandbox – це не checkbox, а security boundary

> За два тижні челенджу – 1 285 репортів, $242 тис. виплат і zero-day у мережевому стеку ядра Linux. Що реальний sandbox escape вчить команди, які запускають код AI-агентів.

- Автор: Юра Скиба (https://cookiesoftware.io)
- Опубліковано: 2026-10-15
- Категорія: AI в роботі розробника
- Canonical: https://cookiesoftware.io/blog/vercel-sandbox-million-dollar-challenge

---

Vercel підбив підсумки $1M Sandbox Challenge: за два тижні (челендж проходив у серпні) – 1 285 репортів, $242 000 виплачених bounty і головна знахідка – zero-day у мережевому стеку ядра Linux, який дозволяв витягати пам'ять host-а через пакети, валити host і виконувати на ньому команди з правами адміністратора. При цьому, за даними Vercel, жоден репорт не показав доступу до даних клієнтів. Для всіх, хто запускає код AI-агентів, це найкращий безкоштовний урок року: sandbox – це не властивість із каталогу, а межа, яку хтось постійно пробує на міцність.

## Що сталось

Vercel поставив $1M на кін і [запросив дослідників ламати свій Sandbox](https://vercel.com/blog/findings-from-the-1-million-dollar-vercel-sandbox-challenge) – ізольоване середовище, в якому виконується зокрема й код, згенерований AI. Результат двох тижнів: 1 285 репортів, $242k виплат.

Найсерйозніша знахідка – дефект у networking-стеку ядра Linux (upstream, тобто не специфічний для Vercel). Дослідник показав три вектори:

- **витік пам'яті host-а**: чужа пам'ять «припливала» в пакети, які guest надсилав в інтернет;
- **компрометація host-а**: спеціально сформовані пакети валили його або піднімали привілеї;
- **виконання команд на host-і** з повними правами адміністратора – тобто повноцінний вихід за межу ізоляції.

І ключове формулювання звіту: «No reports showed anyone accessing customer data in Vercel Sandbox» – жодного доступу до файлів, секретів чи даних застосунків клієнтів. Межа зігнулась у лабораторних умовах, але клієнтський периметр устояв. Саме так виглядає система, спроєктована з припущенням, що окремий шар колись впаде.

## Чому це дуже релевантно AI-агентам

Coding-агент генерує і запускає код, який ніхто з людей не читав до виконання. Навіть якщо prompt бездоганний. Навіть якщо модель топ-1 у всіх бенчмарках. З погляду execution environment цей код **потенційно ворожий** – не тому, що модель зла, а тому, що вона помиляється, буває отруєна через prompt injection, а її вихід ніким не гарантований.

Я вже писав, що [перевіряти AI-код треба як чужий PR](/blog/ai-kod-chek-list-perevirky) – але рев'ю ловить не все. Останній рубіж – середовище виконання. І челендж Vercel показує: навіть у профінансованого вендора з окремою security-командою межа ізоляції тримається не на одному механізмі, а на їх складанні.

## Sandbox – не magic wall

Слово «sandboxed» у документації багатьох інструментів виконує роль заспокійливого. Реальність: ізоляція – це implementation. Конкретне ядро, конкретний мережевий стек, конкретні права процесу. Zero-day у будь-якому з цих шарів перетворює «безпечне середовище» на «середовище, яке було безпечним до вчора».

Висновки Vercel за підсумками (сформульовані разом із Trail of Bits) звучать як конспект курсу системної безпеки:

- **не довіряти guest-у взагалі нічого** – кожен вхід із sandbox вважається ворожим;
- **одна політика, один decider** – коли enforcement розмазаний по кількох місцях, десь обов'язково є шпарина;
- **свіжі ядра на host-ах і вимкнена вкладена віртуалізація** – бо наступний kernel zero-day це питання «коли», а не «чи».

## Defense in depth для твоїх агентів

Якщо ти запускаєш код агентів – у себе, у клієнта, у CI – ось шари, які мають існувати незалежно один від одного:

- **межа microVM/контейнера** – базова ізоляція процесу;
- **мінімальна мережа** – egress за allowlist, а не «інтернет, бо зручно»;
- **мінімальна файлова система** – лише робоча директорія, ніяких `~/.ssh` і системних шляхів (локальна версія цього – [Permission Model у Node.js](/blog/nodejs-permission-model));
- **жодних довгоживучих секретів усередині** – тільки short-lived, тільки мінімальний scope;
- **короткоживуче середовище** – sandbox, який живе хвилини, гірша мішень за той, що живе тижні;
- **ліміти ресурсів** – CPU/памʼять/час, щоб компрометація не стала ще й майнінг-фермою;
- **audit log** – без нього ти не дізнаєшся, що межу вже пробували;
- **approvals для небезпечних дій** – деплой, видалення, гроші проходять через людину, як у [робочих процесах із Claude Code](/blog/claude-code-dlia-react).

Падіння одного шару має обмежуватись наступним. У челенджі саме так і сталося: ядро пробили – а до даних клієнтів не дійшли.

До речі, та сама логіка щойно прийшла і в CI: [lockfiles для GitHub Actions](/blog/github-actions-lockfiles) – це той самий «не довіряй рухомому» принцип, тільки для supply chain.

## Проведи ревізію свого sandbox

Намалюй (буквально, на папері) шари ізоляції для свого agent-workflow і для кожного дай відповідь:

1. Що станеться, якщо саме цей шар впаде сьогодні?
2. Який наступний шар це зупинить?
3. Як я про це дізнаюсь (де лог/алерт)?

Якщо на друге питання хоч раз відповідь «ніякий» – у тебе не defense in depth, а один замок на скляних дверях.

## Ілюзії ізоляції, які зустрічаються найчастіше

- **«У нас Docker, отже sandbox».** Контейнер – це не межа безпеки проти ворожого коду без додаткових обмежень (user namespaces, seccomp, мережеві політики).
- **Секрети в середовищі агента «щоб працювало».** Все, що лежить у sandbox, вважай опублікованим у момент його компрометації.
- **Ізоляція без спостереження.** Межа без audit trail – це межа, про пробиття якої ти дізнаєшся від журналістів.
- **Трактувати «no customer data accessed» як «нас це не стосується».** Вистояло у Vercel – бо шарів було багато. Скопіюй підхід, а не заспокоєння.

«Sandboxed» – це початок threat model, а не кінець дискусії. Vercel заплатив $242k, щоб індустрія ще раз це почула. Нам із тобою цей урок дістається безкоштовно.