Промпт длиной 919 тысяч символов сам по себе не доказывает атаку. Но для владельца AI-сервиса это не особенно утешительно: такой запрос способен потреблять ресурсы независимо от намерений отправителя. Свежие наблюдения с двух ханипотов показывают, что размер контекста пора считать частью периметра, а не безобидным пользовательским вводом.
Что пришло в приманки
Автор разбора на Habr три месяца наблюдал за двумя среднеинтерактивными ханипотами. Первый изображал традиционный стенд с SCADA и Bitrix, второй был поддельным AI gateway с Ollama-compatible API. За время эксперимента было собрано 2,5 млн событий Cowrie, стотысячный MySQL password spray и 183 сохранённых payload. Отдельно автор зафиксировал массовую эксплуатацию AI API и MCP-разведку.
На традиционном стенде поведение выглядело знакомо. Один хакер полтора часа исследовал поддельный Bitrix-сервер: нашёл конфигурацию, извлёк ложные учётные данные базы, пытался выгрузить таблицы и записать PHP-файл. Это последовательная работа по инфраструктуре: обнаружить поверхность, получить секреты, добраться до данных, закрепиться.
С AI-приманкой картина была другой. Один клиент отправил в открытый API 27 тысяч реальных задач. Самый большой промпт содержал 919 тысяч символов. При этом модели за API не было, поэтому эксперимент зафиксировал поток запросов, но не расходы на их обработку моделью.
Это важная граница. Наблюдение подтверждает, что открытый AI endpoint быстро начинают использовать в промышленных объёмах. Но оно не позволяет посчитать ущерб, который возник бы в продакшене, или уверенно назвать каждый длинный запрос злонамеренным. За 27 тысячами задач может стоять эксплуатация чужого ресурса, неудачная автоматизация или клиент, который просто не считает ваши деньги. Для инфраструктуры разница быстро становится академической.
Что воспроизводимо, а что зависит от приманки
Воспроизводимая часть здесь не конкретный набор команд, а логика поиска доступного ресурса. Традиционный сервис проверяют на конфигурации, учётные данные и возможность записи файлов. AI API проверяют на доступность, затем начинают кормить задачами. MCP становится ещё одной поверхностью разведки.
Масштаб этой поверхности растёт. В предыдущем материале на Habr автор другого проекта писал, что за полтора года число MCP-серверов выросло с десятков до десятков тысяч, а его агрегатор собрал более 80 тысяч записей из девяти источников. Чем больше каталог, тем проще обнаружение. Это не означает, что каждая запись уязвима, но само наличие MCP-разведки в ханипоте уже не выглядит экзотикой.
Специфика приманок тоже существенна. AI gateway был открытым, поэтому эксперимент не показывает обход аутентификации. Конфигурация была найдена на поддельном Bitrix-сервере, а извлечённые учётные данные базы были ложными. Наконец, отсутствие модели не даёт проверить, насколько длинные запросы увеличили бы время обработки и счёт.
Но отсюда не следует, что достаточно закрыть API ключом. Аутентификация отвечает на вопрос, кто отправил запрос. Она не отвечает на вопросы, сколько этот запрос может стоить, как долго он будет исполняться и должен ли один клиент получить право отправить ещё 26 999 задач.
Какие лимиты поставить сейчас
Практический вывод скучен, а значит полезен. Ограничьте размер тела запроса и допустимого контекста до значений, которые нужны продукту, а не до максимума, который способен принять провайдер. Введите бюджетную отсечку на клиента и ключ, временной предел обработки и лимит частоты запросов. Отдельно логируйте аномально длинные промпты и резкие серии однотипных задач.
Полезно разделять три сигнала: необычный объём одного запроса, необычное число запросов и необычную продолжительность активности. По отдельности каждый может оказаться легитимным. Вместе они дают оператору повод остановить обработку раньше, чем расследование начнётся с облачного счёта.
Главный маркер на ближайшее время прост: появятся ли в ваших логах клиенты, которые укладываются в формальные права доступа, но систематически выбивают контекст, частоту или бюджет. Если да, AI-безопасность уже сместилась от защиты секретов к управлению стоимостью каждого разрешённого действия.