Инженер контролирует поток запросов и расход токенов публичного ИИ-сервиса
| |

Атаки на стоимость ИИ: почему токены становятся частью кибербезопасности

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

Gartner называет такой сценарий cost exhaustion attack. По прогнозу аналитической компании, к 2030 году с искусственным увеличением расходов столкнутся 80% организаций, использующих публичные ИИ-сервисы. Это прогноз, а не статистика уже произошедших атак, но сам риск вполне практический: каждый успешный запрос к модели имеет измеримую цену.

Чем атака на стоимость отличается от обычного DDoS

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

Дорогим запрос делает не только его количество. На стоимость влияют длина входного контекста, объём ответа, выбранная модель, повторные попытки, вызовы инструментов и цепочки из нескольких агентов. Один пользователь способен создать нагрузку, которая выглядит небольшой по числу запросов, но оказывается дорогой по фактическим вычислениям.

Почему общего месячного лимита недостаточно

Общий счёт отвечает на вопрос, сколько компания уже потратила. Он почти ничего не говорит о причине. Для управления нужны расходы в разрезе проекта, сценария, пользователя, модели и конкретной задачи.

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

Какие ограничения стоит встроить заранее

Для публичного ИИ-сервиса я бы начинал с нескольких технических правил:

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

Эти меры полезны и без атаки. Они обнаруживают ошибки интеграции, бесконечные циклы агентов, неудачные промпты и ситуации, когда в каждый запрос без необходимости отправляется вся база знаний.

AI FinOps должен работать во время запроса

Gartner также прогнозирует, что к 2028 году 60% компаний Global 500 встроят контроль AI FinOps непосредственно в обработку запросов. Логика понятна: отчёт после расходования бюджета не предотвращает потери. Система должна выбирать маршрут, применять лимит или останавливать аномалию до вызова дорогой модели.

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

Стоимость запроса стала техническим параметром

Раньше команда безопасности следила за доступом, трафиком и доступностью сервиса, а стоимость оставалась финансовому отделу. У публичных ИИ-систем эти зоны пересекаются. Необычный запрос может быть корректным с точки зрения API и одновременно опасным для бюджета.

Если стоимость видна только в общем счёте в конце месяца, контролировать её уже поздно. Лимиты, маршрутизация и аномалии должны проверяться там же, где выполняется запрос.

Посмотреть, как собрать модели и расходы в одном контуре

Источники

Похожие записи