Защита ИИ-агентов: как не слить 100 000 ₽ на спам-атаках

Открытый веб-чат с умным ИИ-ассистентом на корпоративном сайте - это главная точка входа для потенциальных клиентов, но одновременно и прямая финансовая уязвимость. Каждый входящий запрос пользователя запускает цепочку генерации токенов в платной LLM. Простой цикл в 15 строк на Python или атака школьников-энтузиастов способны сжечь месячный депозит API за 30-40 минут.

Большинство разработчиков запускают чат-виджеты без базовых защитных барьеров. Вебхук принимает POST-запрос, сразу отправляет промпт во внешнюю модель и ждет ответ. Ниже - разбор трехуровневой системы Rate Limiting на чистом PostgreSQL, которая отсекает флуд-атаки без развертывания отдельного Redis и экономит бюджет компании.

1. Анатомия угрозы: как сжигается баланс токенов

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

• ✦ Скриптовый флуд (Loop Attack): ботнет или скрипт с циклом while True отправляет бессмысленные сообщения («Привет», «тест», случайный набор символов). 1 000 сообщений в минуту с контекстом RAG сжигают до 20-30 млн токенов в час.
• ✦ Атака раздувания контекста (Context Expansion): злоумышленник копирует длинные тексты (война и мир, многостраничные ТЗ) и заставляет LLM обрабатывать максимальное окно контекста на каждом шаге диалога.
• ✦ Бесконечные петли инструментов (Agent Loop Trap): при интеграции с CRM или базами данных провокационный промпт заставляет агента вызывать тяжелые функции поиска десятки раз подряд.

2. Почему Redis часто избыточен на первом этапе

Классическая рекомендация из учебников - поставить Redis рядом с n8n или Node.js бэкендом. Но для большинства корпоративных внедрений на выделенном VPS с 2-4 ГБ RAM это создает лишние проблемы:

1. 1. Потребление оперативной памяти: n8n с Node.js уже требует 1-1.5 ГБ RAM. Дополнительный контейнер Redis и менеджер очередей съедают еще 500-800 МБ, приближая сервер к Out-Of-Memory падению.
2. 2. Сложность сопровождения: нужно настраивать резервное копирование двух баз данных вместо одной, следить за политикой eviction (maxmemory) и сохранять консистентность.
3. 3. Возможности PostgreSQL: в базе данных n8n уже есть штатный PostgreSQL. Благодаря CTE (Common Table Expressions) и индексам по timestamp атомарная проверка скользящего окна занимает 1.5-2 миллисекунды. Этого с запасом хватает для нагрузки в 500-1000 обращений в минуту.

3. Архитектура: 3 уровня скользящих лимитов

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

4. Что видит пользователь и как реагирует Telegram

При срабатывании лимита вебхук возвращает стандартный код ответа HTTP 429 Too Many Requests. В теле ответа передается дружелюбное объяснение и оставшееся время ожидания:

{
  "status": 429,
  "error": "Too Many Requests",
  "message": "Вы отправили слишком много сообщений подряд. Пожалуйста, подождите 45 секунд или оставьте телефон для связи с инженером.",
  "retry_after_seconds": 45
}

Параллельно n8n отправляет беззвучный алерт дежурному инженеру в закрытый Telegram-чат с указанием подозрительного IP, геолокации и частоты запросов. При необходимости администратор нажимает кнопку «Заблокировать IP на 24 часа» прямо из мессенджера.