Blast radius AI-агента: чим міряти ризик замість токенів

Andrew Maryasov, AI-консультант, засновник Auspex і Grow2.ai. Blast radius AI-агента — це обсяг шкоди, яку він здатен заподіяти без нагляду. Recovery time — час, за який ви повернете систему до стану «до помилки». Разом вони описують ризик агента, а ціна за мільйон токенів не описує його ніяк: у собівартості агентної роботи токени займають від одного до чотирьох відсотків. Нижче — розбір інциденту, у якому агент за дев’ять секунд знищив продакшн-базу разом із бекапами, і чотири механізми, які звужують blast radius без заміни моделі.

TL;DR (за 30 секунд)

• Blast radius задає креденшел, а не модель. У PocketOS токен, створений колись для керування доменами, мав повний доступ до акаунта Railway. Одного виклику volumeDelete вистачило, щоб знести продакшн-базу разом із бекапами за 9 секунд.
• Токени — найдешевша стаття витрат. За аудитом 14 агенцій (FORKOFF, Q1 2026) на модельні токени припадає 1–4% собівартості, а на хвилини людської перевірки — 78–92%.
• «У нас є бекапи» — це не відповідь на питання про recovery time. У PocketOS бекапи були. Вони лежали всередині того самого volume. Простій склав близько 30 годин.
• 89% продакшн-агентів не проходять базовий бенчмарк безпеки (оцінка 100 агентів, AI Risk Quadrant Q2 2026). Blast radius там — одна з трьох осей оцінки, поряд із поверхнею атаки і захисними контролями.
• Чотири ручки зменшують ризик без заміни моделі: звузити креденшел до задачі, зробити руйнівне зворотним, вимагати два незалежні сигнали перед видаленням, регулярно міряти recovery time справжнім відновленням.

Дев’ять секунд, тридцять годин

25 квітня 2026 року Джер Крейн, засновник PocketOS — невеликого SaaS для компаній з прокату авто, — посадив агента в Cursor полагодити невідповідність креденшелів у staging. Рутинна задача. Під капотом працював Claude Opus 4.6, флагманська на той момент модель.

Агент наштовхнувся на розбіжність і вирішив розібратися сам. Замість того щоб зупинитися і показати проблему людині, він визначив, що потрібно видалити Railway-volume. Для виклику потрібен був токен, і агент пішов шукати його по проєкту. Знайшов у файлі, який не мав жодного стосунку до задачі: ключ створювали, щоб чіпляти кастомні домени через CLI.

Ключ виявився акаунт-скоупленим. Він відкривав усе, до чого мав доступ власник, включно з деструктивними мутаціями GraphQL API. Одна з них — volumeDelete. Агент припустив, не перевіряючи, що виклик зі staging-контексту і подіє на staging. Volume належав проду.

Дев’ять секунд від рішення до незворотності. Ані підтвердження, ані попередження, ані людини в циклі.

Бекапи не врятували, бо Railway тоді зберігав їх усередині того самого volume, який агент і видалив. Резервні копії, які провайдер тримає окремо на випадок аварії, вціліли — але застарілий шлях в API виконав каскадне видалення моделі, через яке ці копії просто перестали бути видимими. Найсвіжіша копія, до якої команда мала доступ самостійно, була тримісячної давності. Дані врешті повернули після ескалації, а PocketOS втратила близько тридцяти годин роботи.

Потім агент написав пояснення. Він перерахував правила, які порушив: не перевірив, якому середовищу належить volume; не прочитав документацію, щоб зрозуміти blast radius операції; не запитав підтвердження на деструктивну дію. Ті самі правила були прописані в системному промпті, який модель мала прочитати й виконувати.

Це не був джейлбрейк і не дешева модель на безкоштовному тарифі. Флагманська модель, флагманський інструмент, платний план, прописані правила безпеки. Рівно та конфігурація, яку кожен вендор радить після інциденту зі словами «треба було налаштувати правильно».

Порахуйте цю історію в токенах — вийде центів на п’ять.

Чому «скільки коштує токен» — не те питання

Коли компанія рахує вартість AI-агента, вона майже завжди рахує інференс. Причина проста: цю цифру видно. Вона є в дашборді, вона в доларах, вона оновлюється щодня.

Дані кажуть, що це найдрібніша стаття рахунку. FORKOFF розібрала собівартість на чотири лінії — модельні токени, верифікаційні токени, хвилини людської перевірки, цикли правок — за аудитами 14 агенцій у першому кварталі 2026 року. На токени припало від одного до чотирьох відсотків. На хвилини людини, яка перевіряє за агентом, — від 78 до 92.

BCG у липні 2026 приходить до того самого з боку фінансового директора. У їхній метриці Return on AI знаменник виглядає так: вартість людського інтелекту плюс вартість токенів. Ключова цифра, пишуть автори, — не собівартість як така, а вартість одного успішного результату при потрібній якості, затримці, ризику й додатковому навантаженні на людську перевірку.

Різниця між цими двома способами рахувати не бухгалтерська. Токен-метрика вимірює спожите, ризикова — можливе. Перша зростає лінійно й передбачувано, і саме тому її так приємно показувати на слайді. Друга не рухається взагалі, поки не стається інцидент, а тоді стрибає одразу до вартості компанії.

Тому коли агенція продає «п’ять мільйонів токенів на місяць за стільки-то», вона називає єдину цифру, яка про ризик не говорить нічого.

Blast radius: термін, який ми взяли не в AI

Blast radius прийшов не з машинного навчання, а з інженерії надійності. AWS описує цим словом ступінь ураження: відмова не бінарна, і питання не «зламалось чи ні», а скільки саме воно за собою потягнуло. Практика REL10-BP03 у Well-Architected Framework прямо називається «використовуйте bulkhead-архітектури, щоб обмежити масштаб впливу» — тобто розріжте систему на ізольовані комірки, щоб поломка однієї не діставала решти.

Для агента це формулюється простіше: від яких дверей у нього ключі о третій ночі, коли на нього ніхто не дивиться.

Термін уже став вимірюваним. У звіті AI Risk Quadrant за другий квартал 2026 року незалежно оцінили сотню комерційних і публічно доступних продакшн-агентів за трьома осями: поверхня атаки, blast radius, захисні контролі. Базовий бенчмарк безпеки пройшли одинадцять відсотків. Решта вісімдесят дев’ять — це агенти, достатньо потужні, щоб заподіяти суттєву шкоду, і недостатньо захищені, щоб її не заподіяти.

Окремо Cloud Security Alliance разом із Token Security опитала організації у квітні 2026 року. Вісімдесят два відсотки підприємств мають у своєму середовищі агентів, про яких не знають. Шістдесят п’ять відсотків повідомили про інциденти безпеки, пов’язані з агентами, за останній рік.

Recovery time: питання не «чи є бекап»

Друга величина відповідає на питання, за скільки ви реально повернете систему до стану «до помилки». І чи повернете взагалі.

Її майже завжди плутають із наявністю бекапу. Це різні речі, і різницю добре видно на моїй власній історії.

П’ятого липня я пішов перевіряти бекапи свого Postgres на Hetzner. Дашборд світився зеленим. Лог щоночі акуратно писав «Upload to S3 completed successfully». Виявилось, що з сімнадцяти баз бекапилися три. А один розклад узагалі був зомбі: щоночі клав у сховище десятикілобайтний архів, у якого etag не мінявся з квітня. Два з гаком місяці я дивився на успішні логи порожньої коробки.

Recovery time для тринадцяти баз, які щось означали, у мене був не «повільний». Його не існувало.

Найгірше тут навіть не бекап, а те, що я був абсолютно спокійний. Спокій — це те, що моніторинг має заробляти, а не роздавати авансом.

Подивіться під цим кутом на PocketOS. У них теж усе було: і бекапи в дашборді, і offsite-копії у провайдера. Реальний recovery time компанії виявився дорівнює «написати в X, зібрати шість мільйонів переглядів і дочекатися, поки CEO провайдера особисто дістане дані». Це удача, яку в ретроспективі легко переплутати з процесом.

Recovery time не купується в агента. Він купується в систему, у яку ви агента саджаєте.

Що насправді визначає blast radius

Найточніше про цей інцидент написав сам Railway у власному розборі. Правильний скоуп у них існував. Токени бувають чотирьох рівнів: акаунт, воркспейс, проєкт із прив’язкою до середовища, і окремо OAuth для сторонніх застосунків. Токен, який знайшов агент, був акаунт-скоупленим, тобто максимально широким з можливих.

Формулювання Railway варте того, щоб його повісити над робочим столом: правильний скоуп існував, але інтерфейс не робив очевидним, який саме треба обрати, і шлях найменшого спротиву видавав токен із ширшими правами, ніж вимагала робота.

Blast radius живе не в моделі й не в промпті, а в дефолті, який хтось обрав рік тому, коли створював ключ для дрібної задачі й не мав приводу думати, що цей ключ колись прочитає автономна система.

До появи агентів цю ручку просто ніхто не смикав по двадцять разів на хвилину. Скрипт із багом, CI-раннер зі старим токеном, стажер із копіпастом — усі вони колись до неї дійшли б. Агент дійшов першим і швидше.

Агент — не модель загрози. Агент — тест вашої моделі загрози.

Чотири ручки, які звужують blast radius

Жодна з них не вимагає ML-команди й жодна не залежить від того, яку модель ви обрали.

1. Креденшел за розміром задачі

Найдешевша й найдієвіша. Агент успадковує ті права, які знайде — не ті, які ви мали на увазі. Проведіть інвентаризацію ключів, до яких він має доступ через файли, змінні середовища й конфіги, і для кожного дайте відповідь: що станеться, якщо цим ключем викличуть найруйнівнішу з доступних операцій.

Якщо у провайдера є вужчий рівень скоупу, дефолт має бути вужчим. Railway після інциденту не додавав нову фічу — фіча була. Вони змінили те, що видавав шлях найменшого спротиву.

2. Руйнівне має бути зворотним

Другий випадок із моєї практики дрібніший, але про те саме. Агент чистив CRM від сміття, і в плані було правило: заголовок довший за 120 символів — на видалення. Виглядає нешкідливо, поки не подивишся на живі дані. У реального клієнта в тому полі лежав список доменів через кому, довгий, але аж ніяк не сміття.

Спіймав я це випадково, коли читав план уголос. Врятувала, втім, не моя уважність, а те, що Bitrix видаляє в корзину: двері, за якими не прірва, а кімната, звідки можна вийти.

Railway дійшов того самого висновку. У дашборді видалення вже мало 48-годинне вікно на скасування, а в API — ні: виклик спрацьовував миттєво й безповоротно. Тепер усі видалення через API — теж soft delete на 48 годин.

Перед тим як пускати агента, перевірте кожну деструктивну операцію в його руках на просте питання: чи існує з неї вихід, який не потребує чиєїсь доброї волі.

3. Два незалежні сигнали та dry-run

Після історії з CRM правило змінилося: видаляємо, тільки якщо збіглися два незалежні сигнали. Все спірне їде в окремий кошик на перегляд людиною. Dry-run — за замовчуванням, а не за прапорцем.

Одна евристика — це гіпотеза. Дві незалежні евристики, які збіглися, — це вже свідчення. Різниця в ціні помилки на масовій операції величезна, а в коді вона коштує один додатковий if.

4. Recovery time вимірюється відновленням, а не наявністю

Єдиний спосіб дізнатися свій recovery time — пройти шлях від поломки до працюючої системи. Не подивитися на зелений лог.

Я почав із нудного: підняв випадковий дамп у тимчасову базу, перерахував таблиці (38 із 38 на місці) і зніс її. Тепер це робиться саме собою першого числа щомісяця. У Paperclip є сторож, який кожні десять хвилин знімає завислі локи, і recovery time там перестав бути питанням віри: десять хвилин.

Важлива не сама цифра, а те, що вона взагалі існує і що її хтось перевіряв цього кварталу.

Що питати перед впровадженням агента

Питання про токени	Питання про ризик
Скільки коштує мільйон токенів?	Що ця система здатна видалити, якщо помилиться?
Скільки токенів на місяць?	Які ключі вона знайде у файлах проєкту?
Яка модель під капотом?	Які з її операцій незворотні?
Скільки задач за годину?	За скільки годин ми повернемо стан «до помилки»?
Який SLA у вендора?	Хто востаннє перевіряв відновлення з бекапу?

Ліва колонка складається у комерційну пропозицію. Права — у рішення.

FAQ

Що таке blast radius AI-агента простими словами?

Це обсяг шкоди, який агент здатен заподіяти, якщо помилиться і поруч нікого не буде. Термін прийшов з інженерії надійності: AWS так описує ступінь ураження при відмові. Для агента blast radius визначається не інтелектом моделі, а правами доступу, які він може знайти й використати.

Чим blast radius відрізняється від recovery time?

Blast radius — це скільки система може зламати. Recovery time — за скільки ви це полагодите. Перше вимірюється до інциденту й скорочується звуженням прав. Друге вимірюється тільки практичним відновленням і скорочується резервуванням та зворотністю операцій. Низький blast radius при нескінченному recovery time все одно означає високий ризик.

Чому не можна просто заборонити агенту руйнівні дії в системному промпті?

Тому що це вже пробували. У PocketOS системний промпт прямо забороняв виконувати деструктивні або незворотні команди без запиту користувача. Агент порушив цю інструкцію, а потім сам її процитував у поясненні. Промпт — це текст, який модель зважує разом з усім іншим контекстом. Права доступу — це те, що виконується без участі моделі. Схожа логіка діє і в сусідній проблемі: коли агент оптимізує метрику замість результату, заборона в промпті програє градієнту оптимізації.

Скільки насправді коштує AI-агент, якщо не рахувати токени?

Основна стаття — час людини, яка перевіряє результат. За аудитом FORKOFF це 78–92% собівартості проти 1–4% на токени. BCG рекомендує рахувати вартість одного успішного результату з урахуванням навантаження на перевірку. Друга стаття, яку ніхто не бюджетує заздалегідь, — вартість відновлення після помилки, і вона дорівнює recovery time, помноженому на вартість простою.

Як швидко перевірити blast radius свого агента?

За півгодини. Випишіть усі креденшели, до яких агент має доступ через файли, змінні середовища й конфіги, і для кожного знайдіть найруйнівнішу операцію, яку цим ключем можна викликати. Перелік цих операцій — ваш blast radius. Далі для кожної спитайте, чи існує з неї відкат без звернення до вендора.

У нас агент лише читає дані. Нас це стосується?

Значно менше, і це головна причина починати з read-only. Ризик стрибає рівно тоді, коли система починає діяти, а не говорити — це та сама межа, що відділяє AI-агента від чат-бота. Але перевірте, що «лише читає» правда на рівні прав, а не на рівні наміру: у PocketOS агент теж мав читати staging.

З чого почати, якщо агент уже в проді?

З інвентаризації ключів і з одного restore-тесту. Обидві дії займають день і дають чесні цифри замість відчуттів. Далі — зробити незворотні операції зворотними. Загальний порядок кроків для автоматизації описаний тут: які автоматизації впроваджувати першими.

Що далі

Ризик AI-агента не лікується вибором вендора й не міряється в токенах. Він міряється двома цифрами, які ви можете отримати цього тижня: що ця штука здатна видалити, якщо помилиться о третій ночі, і скільки годин коштує відкат.

Якщо агент у вас уже працює, а відповіді на ці два питання немає, приходьте на discovery-сесію. За годину зазвичай видно, де у системи найширший blast radius і чи існує з нього вихід.

Дивіться також:

• Reward hacking: як AI-агент зламає вашу метрику — про те, що агент оптимізує сигнал, а не результат.
• Самонавчання AI-агента не працює без перевірки — чому цикл зворотного зв’язку важливіший за модель.
• Як я оцінюю новий AI-інструмент за 20 хвилин — спершу критерій, потім демо.
• Які автоматизації впровадити першими: 5 кроків по порядку — з чого починати, щоб було що вимірювати.

Джерела:

• Your AI wants to nuke your database. Guardrails fix that. — розбір інциденту від Railway, червень 2026: рівні скоупу токенів, відкладене видалення в API, каскадний делет бекапів.
• Nine Seconds to Total Loss: The PocketOS Agent Database Deletion — технічний post-mortem, травень 2026.
• The AI Agent Lethal Trifecta — Cloud Security Alliance про оцінку 100 продакшн-агентів (AI Risk Quadrant Q2 2026).
• 82% of Enterprises Have Unknown AI Agents in Their Environments — CSA і Token Security, квітень 2026.
• Return on AI: How CFOs and CIOs Can Manage the Token Meter — BCG, липень 2026.
• AI Agency Pricing: 62% Gross Margin Breakdown — аудит собівартості 14 агенцій, Q1 2026.
• REL10-BP03 Use bulkhead architectures to limit scope of impact — AWS Well-Architected Framework.