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

Що сталось

Vercel поставив $1M на кін і запросив дослідників ламати свій Sandbox – ізольоване середовище, в якому виконується зокрема й код, згенерований 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 – але рев'ю ловить не все. Останній рубіж – середовище виконання. І челендж 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);
  • жодних довгоживучих секретів усередині – тільки short-lived, тільки мінімальний scope;
  • короткоживуче середовище – sandbox, який живе хвилини, гірша мішень за той, що живе тижні;
  • ліміти ресурсів – CPU/памʼять/час, щоб компрометація не стала ще й майнінг-фермою;
  • audit log – без нього ти не дізнаєшся, що межу вже пробували;
  • approvals для небезпечних дій – деплой, видалення, гроші проходять через людину, як у робочих процесах із Claude Code.

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

До речі, та сама логіка щойно прийшла і в CI: lockfiles для GitHub Actions – це той самий «не довіряй рухомому» принцип, тільки для 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, щоб індустрія ще раз це почула. Нам із тобою цей урок дістається безкоштовно.