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

Андрей Марьясов, 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 агентов, Cloud Security Alliance, AI Risk Quadrant Q2 2026). Blast radius там — одна из трёх осей оценки, наряду с поверхностью атаки и защитными мерами.
• Четыре ручки снижают риск без замены модели: сузить креденшел до задачи, сделать разрушительное обратимым, требовать два независимых сигнала перед удалением, регулярно измерять recovery time настоящим восстановлением.

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

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

Агент наткнулся на расхождение и решил разобраться сам. Вместо того чтобы остановиться и показать проблему человеку, он определил, что нужно удалить 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-архитектуры, чтобы ограничить масштаб воздействия» — то есть разрежьте систему на изолированные ячейки, чтобы поломка одной не доставала до остальных.

Для агента это формулируется проще: от каких дверей у него ключи в три часа ночи, когда на него никто не смотрит.

Термин уже стал измеримым. В отчёте Cloud Security Alliance 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 символов — на удаление. Выглядит безобидно, пока не посмотришь на живые данные. У реального клиента в этом поле лежал список доменов через запятую, длинный, но никак не мусор.

Поймал я это случайно, когда читал план вслух. Спасла, впрочем, не моя внимательность. Спасло то, что Bitrix24 удаляет в корзину: дверь, за которой не пропасть, а комната, откуда можно выйти.

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-агента не лечится выбором вендора и не измеряется в токенах. Он измеряется двумя цифрами, которые вы можете получить на этой неделе: что эта штука способна удалить, если ошибётся в три часа ночи, и сколько часов стоит откат.

Нет ответов на эти два вопроса — забронируйте тридцать минут в моём календаре. Пройдёмся по системе и посмотрим, где у неё самый широкий blast radius и есть ли из него выход.

Смотрите также:

• Reward hacking: как AI-агент сломает вашу метрику — о том, что агент оптимизирует сигнал, а не результат.
• Самообучение AI-агента: почему оно не работает без проверки — почему цикл обратной связи важнее модели.
• Как оценить AI-инструмент за 20 минут: мой фреймворк — сначала критерий, потом демо.
• Какие автоматизации внедрять первыми: 5 шагов по порядку — с чего начинать, чтобы было что измерять.

Источники:

• Your AI wants to nuke your database. Guardrails fix that. — разбор инцидента от Railway, 29 апреля 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.