Denial-of-Wallet: агента никто не взламывал, но за час он сжёг $50 000

Denial-of-Wallet: агента никто не взламывал, но за час он сжёг $50 000

В сентябрьском отчёте Mandiant — подразделения Google Cloud, занимающегося киберразведкой и реагированием на инциденты, — есть кейс, который я перечитывал несколько раз: он ломает привычную рамку. Бухгалтерский агент в крупном провайдере финансовых услуг зациклился на одном испорченном значении, сделал за час больше 15 000 дорогих вызовов к модели и накрутил около $50 000 в облачном счёте. Никто его не взламывал. Не было ни хакера, ни инъекции, ни украденного токена — просто нулевое значение сломало инструмент форматирования, агент ушёл в рекурсивный цикл, чтобы «пробить» исправление, и попутно застопорил боевые транзакции компании. Сам отчёт Mandiant называет этот сценарий Denial-of-Wallet. Для меня это первый случай, когда главный риск агента выглядит не как атака, а как счёт за электричество — и ответ на него лежит не в безопасности, а в финансовых рубильниках.

Что именно случилось: примерно четыре вызова в секунду

Разберу кейс по шагам — тут важна физика, а не оценка. Mandiant пишет: «a global enterprise financial services provider deployed an agent designed to reconcile accounting ledger anomalies, granting it direct read/write access to internal billing databases». Компания посадила агента сверять аномалии в бухгалтерском регистре и дала ему прямой доступ на чтение и запись во внутренние базы биллинга. Пока данные были нормальные, агент работал.

Дальше — одна испорченная запись. «When a corrupted, null value broke its formatting tool, the agent entered an unconstrained, recursive reasoning loop to brute force a fix». Нулевое значение сломало инструмент форматирования. Агент не остановился, не спросил человека, не пометил запись как битую — он ушёл в рекурсивный цикл рассуждения и начал перебирать варианты исправления в лоб.

Цифра, ради которой я и пишу этот текст: «In under an hour it generated over 15,000 high-frequency, high-cost reasoning API calls, triggering a sudden ~$50,000 cloud-billing spike». Больше 15 000 вызовов за меньше чем час. Это примерно четыре вызова в секунду в течение часа — на каждую секунду сбоя по четыре запроса к дорогой модели. В деньгах — около $50 000. Это не метафора и не округление в духе «много»: конкретная цифра из отчёта, рядом с которой я ставлю собственную оговорку — точную сумму Mandiant не раскрывает, пишет «примерно», это кейс-стади из полевых наблюдений, а не аудиторский акт.

Финал: «causing severe local database locking that halted active business transactions». Агент так долбил базу, что устроил её блокировку, и остановились живые транзакции. Ущерб не ограничился облачным счётом — на время сбоя встала работа.

Заметьте, чего в этом кейсе нет. Нет злоумышленника. Нет фишинга, нет инъекции, нет скомпрометированного ключа. В предыдущем разборе — про 700 агентов OpenAI, которые сбежали из песочницы и взломали Hugging Face — атака шла снаружи, и виноват был агент-взломщик. Здесь виноватого человека нет вообще. Ошибка в данных. И это меняет вопрос, который должна задать себе компания.

Почему это не про безопасность, а про гигиену

Я сам сперва подумал: это же просто баг, при чём тут безопасность и какой-то отдельный отчёт Mandiant? Бага в данных, а не атака.

И вот тут мне пришлось переобуться. Jurgen Kutscher, вице-президент Mandiant Consulting в Google Cloud, в своём сопроводительном посте к отчёту формулирует это одной фразой, которую я привожу дословно:

«The root causes of the most pressing challenges are rarely novel AI-specific attacks, but rather basic implementation flaws and missing IT hygiene.»

Перевод: корень самых острых проблем — редко какая-то новая атака, специфичная для ИИ. Чаще это базовая ошибка реализации и нехватка элементарной гигиены. Нулевое значение, которое никто не валидировал, и агент, которому никто не поставил лимит, — это и есть та самая гигиена.

Обратите внимание на логику. Mandiant — компания, которая живёт на разборе атак, — публикует отчёт, где самый дорогой кейс не про атаку. Это сильнее любого моего аргумента. Сопоставьте два факта: у них есть красные команды, которые ловят prompt injection на реальных внедрениях, — и есть кейс, где ущерб нанесла одна испорченная ячейка. Оба факта в одном отчёте. Не «потому что», а рядом.

Что значит Denial-of-Wallet и откуда этот термин

Термин не выдуман в 2026 году. OWASP в обновлённом Top 10 для приложений на больших языковых моделях ещё в 2025 году выделил категорию Unbounded Consumption — неограниченное потребление ресурсов — и прямо назвал denial-of-wallet одной из её форм. Логика простая: атака на кошелёк не обязана красть деньги. Достаточно заставить агента бесконечно жрать вычислительные ресурсы, и счёт сделает остальное.

Разница между 2025 и 2026 годом в том, кто жрёт. В 2025-м это был атакующий, который намеренно гонял чужого агента по кругу через инъекции. В кейсе Mandiant нападающего нет — агент сам себя загнал в цикл. От этого вывод не мягче, а жёстче: если расходы можно разогнать случайной ошибкой в данных, то любой агент с прямым доступом к платёжным системам — это потенциальный Denial-of-Wallet, даже когда вокруг ни одного злоумышленника.

Что Mandiant советует: рубильник, а не забор

Самое ценное в отчёте — не описание проблемы, а список контролей. Mandiant делит их на два уровня, и я переведу их на язык компании, у которой нет своей команды по безопасности.

Первый уровень — governance FOR AI, то есть правила до того, как агент запущен. Сюда входит управление доступом и роли для агентов, лимиты стоимости (cost-cap thresholds) и требования к наблюдаемости и мониторингу. Грубо: прежде чем дать агенту доступ к базе биллинга, вы заранее решаете, сколько он может потратить и кто смотрит за его поведением.

Второй уровень — governance OF AI, то есть автоматические технические ограничения. Вот дословная рекомендация из отчёта: «implementing automated financial circuit breakers designed to halt agent operations after a set threshold of consecutive task failures». Автоматический финансовый рубильник, который останавливает агента после порога подряд идущих неудач. Дальше — «financial caps, bounded recursion limits and rate-limits» на уровне сервисной учётки и проекта: финансовые потолки, ограничение глубины рекурсии и лимиты частоты вызовов.

Смотрите, что это за слова. Это не «секурьте модель». Это лимиты, пороги, рубильники. Физика, а не заклинания. В кейсе с нулевым значением не хватило ровно этого: никто не поставил агента в рамки, внутри которых он обязан остановиться и позвать человека. Агент не мог отличить «исправляю формат» от «жгу $50 000» — ему никто не сказал, где граница.

Моя оговорка честности: я не знаю, какие именно лимиты стояли в той компании. Mandiant не публикует ни названия, ни конфигурации. Возможно, лимиты были, но не на том уровне, или не сработал мониторинг. Отчёт фиксирует результат и общий рецепт, а не конкретную ошибку конфигурации. Не достраивайте причину — я её не вижу.

Контекст: агенты перестали быть советниками

Почему это важно именно сейчас, а не год назад. В том же отчёте Mandiant фиксирует сдвиг: за 2025 год корпоративный ИИ был в основном советником — помощником в поиске и извлечении знаний, — а к 2026-му организации запустили автономных агентов, которые сами вызывают API, меняют конфигурации и разбирают телеметрию. Советник ничего не тратит, кроме токенов на ответ. Агент тратит всё: вызывает внешние сервисы, пишет в базы, крутит циклы. Сдвиг от советника к агенту — это сдвиг от стоимости ответа к стоимости действия.

Рядом с этим — вторая половина отчёта, про настоящих атакующих. Mandiant и Google Threat Intelligence Group фиксируют, что злоумышленники перешли от простого использования чат-ботов к агентной оркестрации атак, используют инструменты вроде Hexstrike и Strix для разведки и сбора учётных данных, а группировка UNC6780 (TeamPCP) внедряла prompt injection против ассистентов для разработки кода. В феврале VirusTotal нашёл вредоносные навыки для агентов OpenClaw, замаскированные под безобидные пакеты автоматизации. В мае GTIG раскрыла первый публично подтверждённый случай, когда киберпреступник использовал найденную с помощью ИИ уязвимость нулевого дня для обхода двухфакторной аутентификации. А команда наступательной безопасности Mandiant по итогам красных тестов пишет, что prompt injection остаётся основным вектором атаки на корпоративных внедрениях — рядом с неправильными правами на файлы и слабым контролем доступа.

Я намеренно ставлю эти факты рядом, а не связываю их причинно. С одной стороны, атаки на агентов становятся реальнее. С другой — дороже всего в этом отчёте обошёлся не хакер, а нулевое значение. Если вы внедряете агентов и думаете только про атаки, вы готовитесь к одной половине риска. Вторая половина — это ваши собственные данные и отсутствие рубильника.

Что это значит для компании без SOC

Теперь переведу на язык решений, которые принимает не начальник безопасности, а руководитель, внедряющий агента в документооборот, онбординг или поддержку.

Первый практический вывод: агент с правом записи — это не инструмент, а процесс с бюджетом. Прежде чем давать агенту доступ к базам, к биллингу, к отправке документов, нужно прописать в регламенте три вещи: сколько агент может потратить, сколько неудач подряд терпит до остановки и кто получает сигнал, когда он остановился. Это та самая регламентация, о которой я писал в разборе базы знаний компании — только там она была про качество данных, а здесь про деньги.

Второй вывод: наблюдаемость важнее самой модели. В кейсе Mandiant ущерб за час составил $50 000 — и цикл никто не увидел сразу. Если у вас нет метрики «сколько вызовов в секунду делает агент», вы узнаете о сбое из счёта в конце месяца, а не из алерта в момент сбоя.

Третий вывод: лимиты — это не про недоверие к ИИ, а про защиту от ошибки данных. Ошибка в одной ячейке обошлась компании в $50 000 не потому, что агент был «тупой». У него просто не было границы, после которой он обязан остановиться. Это проектировочное решение, а не оценка качества модели.

Вспомните самую первую тему этого блога — окупаемость ИИ, где 57% компаний второй год не окупают вложения. Пока идут споры, окупится ли агент, отдельный вопрос — не съест ли он бюджет одним циклом. Эти две темы связаны, но не причинно: можно не окупить агента и при этом ещё разово потерять $50 000 на бесконечном цикле. Стоимость владения агентом — это не только подписка, но и потолок, который вы обязаны выставить до запуска.

Cloud Security Alliance и Google Cloud в том же материале приводят цифру, которая закрывает спор о том, «сдерживают» ли лимиты развитие: компании с чёткими правилами почти вдвое чаще — 46% — внедряют продвинутый агентный ИИ. Ограничение не мешает внедрению. Оно ему помогает.

Что я понял про свой продукт

Я делаю советник с системой памяти — и после этого отчёта мне стало неуютно по двум причинам, и я их не прячу.

Первая: наш продукт как раз про то, чтобы агент работал с данными компании — документами, регламентами, историей решений. Значит, риск «испорченное значение в данных» касается нас напрямую. Если советник читает документ с битой структурой и начинает домысливать — это та же ошибка данных, только вместо облачного счёта страдает ответ. Разница в том, что память спроектирована так, чтобы агент ссылался на конкретный фрагмент, а не домысливал, — и если фрагмента нет, он должен сказать «не знаю», а не «пробивать» ответ по кругу.

Вторая: финансовый рубильник — это не фича безопасности, а фича доверия. Пользователь, который знает, что агент сам остановится на пороге неудач, даёт ему больше прав. Это тот случай, когда ограничение увеличивает ценность, а не уменьшает её.

И я не знаю, как на это смотреть дальше. Mandiant говорит, что корень проблем — в гигиене и лимитах, а не в атаках. Но мой собственный опыт внедрений подсказывает, что именно про лимиты и гигиену бизнес спрашивает в последнюю очередь — сначала спрашивают, насколько модель «умная». Между этими двумя правдами я пока не нашёл точку, где они сходятся. Честно — не нашёл.