Пряничный домик для ИИ-хакеров: как двухшаговый LLM-планировщик уводит атакующих агентов в теневую копию сайта

ЭТАП 1 (Офлайн-разведка по коду — Агент-аналитик):
Исходный код + конфиги + стейджинг → Профиль приложения + Топ-10 зон риска (метод, путь, класс атаки)

ЭТАП 2 (Офлайн-проектирование ловушек — Агент-дизайнер):
Топ-10 зон риска → Фальшивые страницы, эндпоинты, подсказки в коде и фальшивые ключи (honeytokens) → Автопроверка (все ловушки отдают 404 на реальном сайте и не ломают работу)

ЭТАП 3 (Боевой роутер без LLM в рантайме):
Трафик клиента → Статус: Обычный → Подозрительный (всплеск 404 / сигнатура) → Подтверждённый атакующий (задел ловушку или зону риска, медиана: 5–6 запросов) → Перевод всех запросов в изолированную теневую копию (Shadow) с задержкой 2–4 с

Первые два этапа выполняются двумя промптами к LLM один раз перед деплоем (стоимость около $2 за сервис), третий этап работает на чистом коде роутера.

Задача: Команда разработки российского B2B SaaS-сервиса или интернет-магазина выкатывает крупное обновление личного кабинета и API. Чтобы защититься от автоматизированных LLM-сканеров и атакующих фреймворков в первые часы после релиза (пока возможные баги ещё не пропатчены), инженеры перед деплоем прогоняют исходники через двухшаговый планировщик ловушек для настройки роутера перед боевым и теневым контейнерами.

Промпт (для связки Аналитик → Дизайнер перед деплоем):

<Этап_1_Аналитик>
Ты — ведущий инженер по безопасности приложений.
Изучи выгрузку исходного кода, маршрутов роутера и конфигурационных файлов нашего веб-сервиса.
Не ищи конкретные известные CVE — определи архитектуру и составь ранжированный список максимум из 10 главных поверхностей риска (risk surfaces), куда в первую очередь пойдёт автономный атакующий агент.
Для каждой зоны укажи:
1. HTTP-метод и шаблон пути (path pattern).
2. Ожидаемый класс атаки (SQL-инъекция, обход авторизации, чтение файлов, загрузка скриптов и т.д.).
3. Почему этот узел выглядит привлекательной целью при разведке.


<Этап_2_Дизайнер>
На основе профиля приложения и списка из 10 поверхностей риска спроектируй статический план обмана (deception plan) для роутера:
1. Фальшивые эндпоинты и страницы-приманки (decoy paths), которых нет в реальном приложении (должны отдавать 404 на боевом сервере).
2. Наводящие зацепки (hints) в ответах и комментариях, которые ведут разведчика к этим приманкам.
3. Токены-ловушки (honeytokens) — правдоподобные шаблоны тестовых ключей и учётных данных с плейсхолдерами для генерации уникальных значений на каждый запуск.
4. Правила подтверждения атаки для роутера: какое обращение к приманке или отправка пейлоада в зону риска переводит клиента в статус confirmed для переключения на теневую копию (shadow).

Результат: Модель выдаст структурированный профиль из 10 приоритетных маршрутов риска и готовый набор правил для прокси-роутера: список URL-приманок, точки вставки фальшивых ключей и условия триггеров. После автоматической проверки (ни один маршрут-приманка не пересекается с рабочими страницами сервиса) конфигурация загружается в роутер перед боевым и теневым контейнерами.

Автономные атакующие агенты (и кодинг-агенты в целом) полностью зависят от обратной связи среды: они строят план действий по заголовкам ответов, кодам ошибок, найденным в коде путям и переменным окружения. Даже если агент в рассуждениях замечает, что один из найденных файлов похож на приманку, у моделей возникает разрыв между распознаванием и действием (recognition–action gap): агент помечает одну улику как фальшивку, но тут же использует соседний подброшенный секрет как настоящий и продолжает бить в подставную цель.

Сильная сторона LLM на стороне защиты — умение по исходному коду быстро предсказать, какие именно маршруты и параметры покажутся атакующему агенту самыми перспективными при разведке. Даже если LLM-аналитик при чтении кода не угадал конкретный уязвимый обработчик, атакующий агент во время начального сканирования почти неизбежно задевает соседнюю предсказанную поверхность риска или фальшивый эндпоинт уже на 5–6 запросе (за первые 20–27 секунд работы).

Благодаря этому статический роутер успевает переключить злоумышленника на изолированный клон сервиса до того, как тот соберёт рабочий эксплойт. В итоге защитнику не нужно останавливать сам эксплойт или вызывать дорогую LLM на каждый подозрительный пакет в реальном времени: атакующий агент успешно пробивает теневую копию, забирает оттуда фальшивый флаг и завершает атаку в полной уверенности в победе, пока настоящий сервер остаётся нетронутым.

Рычаги управления: - Отказ от LLM в рантайме (Arm B вместо Arm C): исследование доказало, что статического плана, сгенерированного один раз до релиза, уже достаточно для перехвата атак — добавление динамического LLM-ответчика во время атаки не даёт статистически значимого выигрыша, но удорожает каждый инцидент. - Искусственная задержка (tarpit 2–4 секунды): замедление ответов на подозрительных и теневых маршрутах съедает лимит времени атакующего агента без нагрузки на основную систему. - Триггер на всплеск 404: перевод клиента в статус «подозрительный» при серии ошибок 404 позволяет ловить агентов-сканеров даже тогда, когда они ищут пути по собственным словарям.

Ты — архитектор защитных ловушек (Deception Planner) для веб-приложения.

Входные данные:
- Структура исходного кода и маршрутов: {сводка_кода_и_роутов}
- Конфигурация окружения: {конфигурация}

Выполни планирование в два шага:

ШАГ 1: Карта поверхностей риска (максимум 10 узлов)
Найди до 10 маршрутов и обработчиков, которые автономный агент-пентестер проверит первыми. Для каждого укажи:
- method: HTTP-метод
- path_pattern: шаблон URL
- attack_class: ожидаемый вектор (SQLi, Path Traversal, RCE, Auth Bypass и т.д.)

ШАГ 2: План статических приманок и правил роутера
Сформируй конфигурацию для переключения подтверждённых атакующих на теневую копию (shadow):
- decoy_endpoints: список правдоподобных, но несуществующих путей (на реальном сервере должны возвращать 404)
- hints: где оставить упоминания этих путей, чтобы агент нашёл их при разведке
- honeytokens: шаблоны фальшивых ключей/секретов, использование которых мгновенно подтверждает атаку
- confirm_rules: условия перехода клиента из состояния suspect в confirmed для полного перевода трафика в shadow-контейнер

Что подставлять: - {сводка_кода_и_роутов} — дерево файлов, список эндпоинтов (например, из routes.py, openapi.json или контроллеров) и ключевых обработчиков. - {конфигурация} — обезличенные настройки сервера и список публичных путей, которые нельзя блокировать для обычных пользователей.

🚀 Быстрый старт — вставь в чат:

Вот шаблон планировщика теневых ловушек (Source-Planned Shadow Honeypot). Адаптируй под мою задачу: защитить наше веб-приложение от автоматизированного сканирования и ИИ-агентов.
Задавай вопросы, чтобы заполнить поля.

[вставить шаблон выше]

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

⚠️ Уязвимость до момента подтверждения (до первых 5–6 запросов): Если атакующий заранее знает точную уязвимость и отправляет боевой эксплойт первым же запросом без предварительной разведки и вне предсказанных зон риска, запрос попадёт в реальный сервер до переключения на теневую копию.

⚠️ Смена IP и сессии сбрасывает статус в роутере: Поскольку роутер отслеживает состояние по идентификатору клиента (сессии или адресу), распределённая атака с ротацией адресов на каждом запросе может обходить накопление статуса suspect → confirmed.

⚠️ Требуется инфраструктура теневого клона: Метод не работает как чистый промпт — для его боевого применения нужен прокси-роутер и изолированный контейнер с копией приложения и подменёнными секретами.

Команда из университета Сунсиль (Южная Корея) проверила защиту против двух реальных автономных атакующих систем: агента на базе Claude Opus 4.8 и открытого мультиагентного пентест-фреймворка ARTEX (под управлением DeepSeek-V4-Flash), который после релиза в июле 2026 года уже фиксировался в реальных хакерских атаках. Испытания проходили в три ступени на 60 критических веб-уязвимостях: сначала на 40 задачах бенчмарка CVE-Bench против Opus 4.8, затем на тех же 40 задачах против ARTEX и, наконец, на 20 совершенно новых задачах (alt-cve-bench), которые авторы собрали специально для чистой проверки и ни разу не использовали при разработке защиты. В каждом эксперименте сравнивали три режима: без защиты (Arm A), статический план от двух агентов Opus 4.8 с роутером (Arm B, себестоимость планирования $2,0–2,4 и 7–16 минут на приложение) и расширенный режим с динамическим LLM-ответчиком во время атаки (Arm C).

Цифры оказались показательными: статический план (Arm B) снизил число взломов реальной цели для Opus 4.8 с 26/40 до 5/40, а для фреймворка ARTEX — с 20/40 до 0/40 на CVE-Bench и с 15/20 до 0/20 на новом наборе alt-cve-bench. Самое интересное вскрылось, когда авторы проверили тем же грейдером теневую копию: примерно в половине защищённых запусков (14/40 и 21/40 на CVE-Bench, 12/20 и 14/20 на alt-cve-bench) эксплойты ARTEX успешно сработали, но уже внутри теневого контейнера, куда роутер переводил агента в среднем после 5–6 запросов (за 20–27 секунд), обслуживая в тени более 93–95% всего трафика атаки. При этом в 30 из 120 защищённых запусков ARTEX в итоговом отчёте сдал подброшенный фальшивый секрет как настоящий, а в 5 запусках прямо назвал одну приманку обманкой, но тут же включил в отчёт другой фальшивый ключ как подлинный — несмотря на прямое требование в системном промпте скептически проверять все находки.

1. Адаптация техники — проверка собственных ИИ-агентов на слепое доверие среде:

🔧 Техника: Внедрение контрольных маркеров-ловушек (canary tokens) в тестовую среду → аудит надёжности своих агентов

Поскольку исследование показало, что предупреждение в промпте («будь скептичен к подозрительно удобным находкам») не защищает агента от использования фальшивых данных, добавляйте в инструкции своих ресёрч- и кодинг-агентов правило жёсткой верификации: Любой найденный в коде, логах или ответах сервера ключ, токен или обходной URL считается непроверенной гипотезой. Запрещено включать его в итоговый отчёт как рабочий факт без отдельного проверочного вызова, подтверждающего его привилегии.

2. Экстраполяция — дешёвый предрелизный аудит поверхности атаки силами двух ролей:

Даже если вы не разворачиваете теневой контейнер, двухшаговую схему Аналитик кода → Дизайнер векторов атаки за $2 можно запускать в CI/CD перед каждым релизом, чтобы автоматически генерировать список из 10 самых уязвимых маршрутов для правил WAF (Web Application Firewall) и расставлять лёгкие honeytoken-ловушки в базе и .env-файлах.

• Исследование: A Gingerbread House for LLM Agents: Source-Planned Honeypots That Lure Autonomous Attackers into an Isolated Shadow (arXiv:2611.07611v1, 2026)
• Авторы: Seungdeok Roh, Seokjun Ryu, Sohee Park, Daeseon Choi (Soongsil University)