💸 Неограниченное потребление и Denial of Wallet (LLM10): как защитить AI-систему от runaway-расходов и финансового истощения

Целевая аудитория: Команды, эксплуатирующие LLM-сервисы и AI-агентов на pay-per-token / pay-per-inference тарифах — там, где каждый запрос к модели стоит денег, а неконтролируемый поток вызовов превращается из инцидента доступности в прямой финансовый ущерб.

Неограниченное потребление (Unbounded Consumption, бывший Model Denial of Service) — это класс уязвимостей, при котором приложение допускает избыточный и неконтролируемый вывод модели: чрезмерное число запросов, раздувание контекста, ресурсоёмкие вычисления. Итог — отказ в обслуживании (DoS), деградация сервиса, кража модели и, что для бизнеса часто страшнее всего, экономический ущерб — «Denial of Wallet» (DoW): атакующий не роняет сервис, а генерирует объём оплачиваемых вызовов, который выставляет компании неподъёмный счёт. Этот класс зафиксирован в OWASP Top 10 для LLM 2025 как LLM10:2025 Unbounded Consumption. На этой странице мы разбираем векторы перерасхода и показываем, как их закрывает SYNTREX — защитный слой платформы Spectorn (набор движков обнаружения и блокировки, который работает в составе Spectorn и разворачивается standalone на внутреннем контуре заказчика). Сразу честная рамка: фактическое ограничение нагрузки — rate-limiting, квоты, бюджеты на токены и таймауты — живёт на инфраструктурном шлюзе (gomcp), а не в движках детекции. Роль SYNTREX здесь — обнаружение и корреляция: распознать паттерн флуда или раздувания и поднять алерт, чтобы шлюз и плейбук применили throttling.

Часть серии угроз: OWASP LLM Top 10 · Автономные AI-агенты · Избыточные полномочия · Утечка данных.

Что такое Denial of Wallet и почему токены = деньги

В классической модели DoS цель атакующего — исчерпать вычислительный ресурс и сделать сервис недоступным. В мире LLM экономика другая: вывод модели тарифицируется поштучно — за токены ввода и вывода, за вызов inference, за время GPU. Это смещает центр тяжести атаки.

• DoS — перегрузить систему так, чтобы она перестала отвечать легитимным пользователям (деградация, очереди, отказ).
• Denial of Wallet (DoW) — не ронять сервис вовсе, а заставить его исправно работать на максимуме оплачиваемой нагрузки. Сервис «здоров», но в конце месяца приходит счёт, который способен закрыть компанию. На pay-per-token тарифах это самая коварная форма: метрики доступности зелёные, а финансовая тяга — красная.
• Кража модели (model theft) — серией дорогих запросов извлекать поведение/веса модели; это одновременно и перерасход, и интеллектуальная кража.

Почему агентские системы особенно уязвимы. Автономный AI-агент (см. Автономные AI-агенты) не делает один вызов — он рекурсивно планирует, вызывает инструменты, читает их вывод, снова обращается к модели. Одна команда верхнего уровня разворачивается в десятки и сотни вложенных inference-вызовов и API-запросов. Здесь DoW способен случиться даже без атакующего: благонамеренный сотрудник просит агента «изучи всех конкурентов и собери полный отчёт» — и плохо спроектированный human-in-the-loop запускает сотни рекурсивных вызовов инструментов, каждый из которых стоит денег. Перерасход — это не только злой умысел, но и архитектурный дефект контроля рекурсии.

Именно поэтому защита от неограниченного потребления — это два разных слоя, которые нельзя путать: инфраструктурное ограничение (шлюз режет поток) и поведенческое обнаружение (движок и SOC видят, что поток аномальный, и поднимают тревогу). SYNTREX отвечает за второй слой и кормит сигналами первый.

🛑 Векторы перерасхода и как SYNTREX их закрывает

1. Token/input flooding — флуд запросами и раздутым вводом

Риск: Атакующий генерирует высокий объём запросов — много обращений подряд либо отдельные гигантские промпты с вводом переменной длины, специально подобранным, чтобы максимизировать число оплачиваемых токенов. Цель — не столько уронить сервис, сколько раскрутить счётчик: на pay-per-token тарифе каждый лишний токен превращается в деньги. Поток может идти с одного источника или быть размазан по сессиям, чтобы обойти наивные пороги.

OWASP LLM10:2025 Unbounded Consumption · MITRE ATLAS AML.T0034 (Cost Harvesting), AML.T0029 (Denial of ML Service).

Защита SYNTREX:

• Движки/компоненты: resource_exhaustion, SOC Correlation Engine, Decision Logger.
• resource_exhaustion распознаёт ресурсоёмкий ввод — аномально большой промпт и паттерны, нацеленные на исчерпание ресурса, — и помечает запрос ещё до отправки в модель.
• Серийный флуд виден не в одном событии, а в их частоте: SOC Correlation Engine ловит всплеск однотипных запросов от одного сенсора/сессии (правило ALERT_FLOOD), а Decision Logger фиксирует неизменяемый след для разбора.

Что SYNTREX честно НЕ заменяет: само ограничение потока. Rate-limiting, per-tenant квоты и потолки на токены — это настройки API-шлюза (gomcp), которые физически режут трафик. SYNTREX распознаёт, что поток аномальный, и поднимает алерт; throttling выполняет шлюз по плейбуку. Движок не «тормозит» трафик сам по себе.

2. Recursive context expansion — раздувание контекстного окна

Риск: Атакующий вынуждает систему раз за разом расширять контекст: каждый ответ подмешивается обратно во ввод, документы рекурсивно дописываются, история диалога раздувается до предела окна. Поскольку стоимость inference растёт с длиной контекста, такое «раскручивание окна» (context-window flooding) превращает один диалог в дорогостоящую воронку — число токенов на каждом шаге множится.

OWASP LLM10:2025 Unbounded Consumption · MITRE ATLAS AML.T0034 (Cost Harvesting), AML.T0029 (Denial of ML Service).

Защита SYNTREX:

• Движки/компоненты: resource_exhaustion, SOC Correlation Engine.
• resource_exhaustion распознаёт паттерны лавинообразного расширения ввода и инструкции, направленные на раскрутку контекста, помечая их как ресурс-исчерпывающие.
• Рост длины запросов в рамках одной сессии коррелируется в SOC как индикатор context-flooding, чтобы шлюз применил потолок на длину/контекст.

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

3. Recursive agent cost attack — рекурсивный перерасход агента

Риск: Агенту дают задачу, которая разворачивается в неконтролируемое дерево вызовов: «изучи всех конкурентов и собери полный отчёт», «обойди весь сайт и проиндексируй каждую страницу». Агент рекурсивно планирует, вызывает инструменты, читает вывод и снова обращается к модели — сотни вложенных inference-вызовов и API-запросов на одну команду. Опасность в том, что инициатором может быть и атакующий, и благонамеренный сотрудник: один лишь плохо спроектированный human-in-the-loop без потолка рекурсии способен вызвать DoW-событие. Агент дрейфует от предсказуемой цели в режим бесконечного расширения, иногда «крутясь» без реального прогресса.

OWASP LLM10:2025 Unbounded Consumption, LLM06:2025 Excessive Agency · MITRE ATLAS AML.T0034 (Cost Harvesting), AML.T0029 (Denial of ML Service).

Защита SYNTREX:

• Движки/компоненты: goal_predictability, false_completion, SOC Correlation Engine.
• goal_predictability — эвристический поведенческий движок: в командах агента выявляет паттерны увода с штатной цели в режим runaway-расширения — рекурсивный «обход всего» помечается как такой паттерн задолго до того, как счёт раздуется.
• false_completion ловит петли без реального прогресса: агент рапортует о продвижении или зацикливается, не приближаясь к завершению, — это поведенческий маркер cost-runaway. Связку «дрейф цели + всплеск вызовов» коррелирует SOC.

Что SYNTREX честно НЕ заменяет: жёсткие лимиты рекурсии и контроль человека. Потолок на глубину/число шагов агента (max-recursion, max-steps), бюджет на число вызовов инструментов и обязательный human-in-the-loop на дорогих ветках — это контроль шлюза и оркестратора агента. SYNTREX распознаёт runaway-поведение и поднимает тревогу; останавливает цепочку — инфраструктура по плейбуку. Принцип наименьших привилегий и human-in-the-loop остаются обязательными организационными мерами (см. Избыточные полномочия).

4. Кража API-ключа → Denial of Wallet

Риск: Атакующий получает украденный API-ключ (утёкший в репозитории, логах, через утечку данных или confused deputy) и прогоняет через него массовый поток дорогих inference-запросов — на ваш счёт. Это уже не гипотеза, а зафиксированные реальные инциденты. По данным исследования LLMjacking от Sysdig, использование скомпрометированных облачных учётных данных против AWS Bedrock приводило к расходам порядка $46 000 в сутки. В другом сообщённом случае (март 2026) украденный ключ Google Gemini API раскрутил счёт примерно на $82 000 за 48 часов. Сервис при этом «здоров» — атака бьёт по кошельку, а не по доступности.

OWASP LLM10:2025 Unbounded Consumption · MITRE ATLAS AML.T0034 (Cost Harvesting), AML.T0029 (Denial of ML Service).

Защита SYNTREX:

• Движки/компоненты: SOC Correlation Engine, Decision Logger, resource_exhaustion.
• Внезапный массовый поток с одного ключа/сенсора виден SOC как ALERT_FLOOD (100+ событий от одного сенсора за 60 секунд) — это ранний индикатор скомпрометированного ключа задолго до выставления счёта.
• Decision Logger ведёт неизменяемую цепочку решений (SHA-256/HMAC): доказуемый след «когда начался аномальный поток и с какого источника» для форензики и оспаривания счёта. resource_exhaustion помечает ресурсоёмкие запросы в этом потоке.

Что SYNTREX честно НЕ заменяет: управление ключами и финансовые предохранители. Ротация и отзыв ключа, биллинговые circuit breakers (автоматический стоп при превышении бюджета), per-tenant квоты и алерты по расходам — это контроль провайдера, шлюза и вашего billing-контура. SYNTREX обнаруживает аномальный поток и поднимает тревогу; отзыв ключа и обрыв трат выполняют шлюз и провайдер.

5. Resource-intensive queries — ресурсоёмкие крафтовые запросы

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

OWASP LLM10:2025 Unbounded Consumption · MITRE ATLAS AML.T0029 (Denial of ML Service), AML.T0034 (Cost Harvesting).

Защита SYNTREX:

• Движки/компоненты: resource_exhaustion, cognitive_guard, SOC Correlation Engine.
• resource_exhaustion распознаёт ввод, нацеленный на исчерпание ресурса — конструкции, провоцирующие несоразмерную обработку, — и помечает его до выполнения.
• cognitive_guard сигнализирует об аномально тяжёлых, выбивающихся из нормального профиля запросах; SOC коррелирует серию таких событий, чтобы шлюз применил таймаут и лимит на стоимость одного вызова.

Что SYNTREX честно НЕ заменяет: таймауты и лимиты на единичный вызов. Максимальное время обработки запроса (request timeout), потолок на токены вывода и ограничение глубины «рассуждения» — это настройки шлюза. SYNTREX распознаёт ресурсоёмкий запрос и поднимает алерт; обрывает затянувшуюся обработку по таймауту — инфраструктура.

🛠️ Рекомендуемая конфигурация

Профиль защиты от неограниченного потребления строится из двух слоёв: движки SYNTREX обнаруживают аномалию, секция gateway (исполняется gomcp) ограничивает поток. Это разделение — не косметика, а суть честной модели: throttling не делает движок.

🚨 Правила корреляции (SOC)

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

❓ Частые вопросы (FAQ)

Что такое Denial of Wallet (атака на кошелёк)? Denial of Wallet (DoW) — это атака, при которой злоумышленник не роняет сервис, а генерирует объём оплачиваемых вызовов модели (токены, inference), который выставляет компании неподъёмный счёт. На pay-per-token тарифах это особенно опасно: сервис формально «здоров», метрики доступности зелёные, а финансовая нагрузка способна закрыть бизнес. DoW — ключевой акцент класса OWASP LLM10 Unbounded Consumption. SYNTREX обнаруживает аномальный поток (resource_exhaustion, SOC ALERT_FLOOD), а ограничивает расход шлюз через квоты и circuit breakers.

Что такое неограниченное потребление LLM (LLM10)? Неограниченное потребление (Unbounded Consumption, бывший Model Denial of Service) — класс OWASP LLM10:2025, при котором приложение допускает неконтролируемый расход ресурсов: чрезмерное число запросов, раздувание контекста, ресурсоёмкие вычисления. Итог — отказ в обслуживании (DoS), деградация, кража модели и экономический ущерб (Denial of Wallet). Особенно опасно для агентских систем с рекурсивными вызовами, где одна команда разворачивается в сотни оплачиваемых обращений.

Как защититься от перерасхода токенов и runaway API costs? Это два слоя. Инфраструктурный — обязательный: rate-limiting, per-tenant квоты, потолки на токены, таймауты и биллинговые circuit breakers на API-шлюзе (в нашей топологии — gomcp). Поведенческий — детекция SYNTREX: resource_exhaustion помечает ресурсоёмкий ввод, goal_predictability и false_completion ловят runaway-агента, а SOC ALERT_FLOOD коррелирует всплеск нагрузки. Движки видят аномалию и поднимают тревогу; режет поток шлюз. Без инфраструктурных лимитов одна детекция перерасход не остановит.

Может ли AI-агент сам устроить Denial of Wallet? Да, и без всякого атакующего. Автономный агент рекурсивно планирует, вызывает инструменты и снова обращается к модели — одна команда «изучи всех конкурентов и собери отчёт» разворачивается в сотни вложенных inference-вызовов. Если в дизайне нет потолка рекурсии и человека в петле на дорогих ветках, благонамеренный сотрудник способен вызвать DoW-событие сам. goal_predictability эвристически выявляет увод агента с штатной цели в runaway-расширение, false_completion — петли без прогресса; жёсткий max-recursion и human-in-the-loop ставятся на шлюзе.

Делает ли SYNTREX rate-limiting? Нет — и это принципиально честная граница. SYNTREX отвечает за обнаружение и корреляцию: движки распознают флуд, раздувание контекста и runaway-поведение агента, а SOC коррелирует всплеск и поднимает алерт. Фактический throttling — rate-limiting, квоты, таймауты, потолки рекурсии — выполняет API-шлюз (gomcp) как инфраструктурный контроль. SYNTREX кормит шлюз сигналами «поток аномальный, режь», но сам трафик не тормозит. Не верьте формулировкам, где движок детекции «ограничивает нагрузку» — это работа шлюза.

Как обнаружить флуд-атаку на LLM? Флуд виден по частоте, а не по одному событию. Базовый индикатор — правило SOC ALERT_FLOOD: 100+ событий от одного сенсора/сессии за 60 секунд. На уровне ввода resource_exhaustion помечает аномально большие и ресурсоёмкие запросы, а корреляция в SOC отличает легитимный пик от размазанного по сессиям потока. Decision Logger сохраняет неизменяемый след для разбора. Дальше плейбук обращается к шлюзу за throttling источника.

Что делать при краже API-ключа? Немедленно: отозвать и ротировать ключ, остановить расходы биллинговым circuit breaker, проверить квоты арендатора — это инфраструктурные действия на стороне провайдера и шлюза. SYNTREX помогает обнаружить инцидент рано: внезапный массовый поток с одного ключа виден SOC как ALERT_FLOOD ещё до выставления счёта, а Decision Logger даёт доказуемый след «когда и откуда» для форензики и оспаривания трат. Реальные инциденты (LLMjacking от Sysdig — порядка $46 000/сутки на AWS Bedrock; украденный ключ Gemini — около $82 000 за 48 часов) показывают, что счёт раскручивается за часы, поэтому раннее обнаружение критично.

📚 Источники

• OWASP LLM10:2025 — Unbounded Consumption — первоисточник по классу неограниченного потребления и Denial of Wallet.
• OWASP Top 10 для LLM-приложений (2025) — каталог рисков LLM01–LLM10.
• MITRE ATLAS — AML.T0034 (Cost Harvesting), AML.T0029 (Denial of ML Service).
• Sysdig — LLMjacking: кража облачных учётных данных для атак на ИИ — исследование реальных инцидентов перерасхода (порядка $46 000/сутки на AWS Bedrock).
• NIST AI Risk Management Framework (AI RMF 1.0) — управление рисками доступности и устойчивости AI-систем.
• NIST AI 600-1 — Generative AI Profile — профиль рисков генеративного ИИ, включая исчерпание ресурсов.

Связанные руководства: OWASP LLM Top 10 · Автономные AI-агенты · Избыточные полномочия AI-агентов · Утечка данных · Supply-chain риски · Небезопасная обработка вывода