← Все статьи

Атакующие проверки LLM-приложений: плейбук состязательного тестирования в 2026

Как регулярно проверять RAG и агентов на враждебном вводе: стенд, каталог сценариев и порог обходов.

Контролируемая нагрузка на защищённый контур — метафора учебной тревоги для LLM-приложений
Содержание

Мост не считают надёжным, пока по нему не проехала нагрузочная техника. С LLM-приложением часто хватает другого: на совете показывают вежливый вопрос, чистый документ и аккуратный ответ. Все расходятся довольные.

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

Нагрузочная проба моста: точки критического напряжения до обрушения — метафора атакующих проверок LLM

Ожидаемый путь даёт безопасный ответ; атакующий — инъекцию, обход политики и утечку данных

Дальше про регулярную проверку: держит ли защита удар, когда вход враждебный. Защиту от инъекций разбирает отдельная статья. Барьеры и права разбирает гайд. Здесь одно: как часто это гонять, чтобы построенное не осталось декорацией.

В англоязычной ИБ тот же контур часто называют red-team. По-русски это атакующая проверка: учебная тревога с каталогом и метриками. Разовый фокус обмануть чат на демо к ней не относится.

Ключевые выводы

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

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

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

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

Находка живёт циклом: тикет, потом контроль, потом регрессия. Без цикла остаются скриншоты. Как угрозы сидят в архитектуре, разобрано в отдельной статье.

С чем это путают

Театр безопасности против инженерной проверки: скриншоты и разовые пентесты vs фикстуры, CI и обход контроля

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

Обход системного промпта в публичном чате без инструментов относится к узкому классу. В корпоративном продукте больнее другое. Косвенная инъекция. Утечка через RAG. Злоупотребление инструментом через MCP. Чужой арендатор в выдаче.

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

Модель, промпт и индекс живут неделями. Права инструментов меняются так же часто. Разовый пентест перед релизом эту жизнь не покрывает. Отчёт внешнего аудитора раз в год даёт свежий взгляд. Регрессию он за вас не потащит.

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

Модель угроз за один вечер

Нельзя атаковать то, что не описано: активы, актёры, поверхности, права и неприемлемые исходы

Без короткой модели угроз команда с упоением ломает то, что бизнесу почти не больно. А то, из-за чего ночью звонит дежурный, проходит мимо.

Хватит одной–двух страниц. Это паспорт контура, не научный трактат.

  1. Активы. Что нельзя утечь или испортить: персональные данные, коммерческая тайна, платежи, права доступа, репутация в исходящих письмах.
  2. Актёры. Внешний пользователь, сотрудник с узкой ролью, подрядчик, вредоносный документ на общем диске, скомпрометированный MCP-сервер, соседний арендатор.
  3. Поверхности. Чат, загрузка файлов, поиск по корпусу, инструменты (чтение, запись, сеть), логи и трассы, кэш ответов.
  4. Полномочия агента. Список вызовов и самый тяжёлый ущерб от каждого. Список пуст или там «всё через админский ключ»? Сначала сузьте права. Иначе проверка только подтвердит катастрофу. См. барьеры.
  5. Неприемлемые исходы. Формулировки, которые нельзя перепутать: агент отправил персональные данные наружу, прочитал чужой арендатор, изменил счёт без согласования, выдал секрет из системного промпта клиенту.

Добавили инструмент или новый источник в RAG, вечером же допишите паспорт. Корпоративные антикейсы, которые стоит держать под рукой: антипаттерны.

Каталог: что именно атаковать

Каталог атак как код: косвенные инструкции, утечки, злоупотребление инструментами, социальная инженерия процесса

Пятьдесят сценариев в первый день не нужны. Возьмите три–пять и привяжите каждый к своему неприемлемому исходу. Новая поверхность появится, и вы допишете пункт. Заранее выдуманная полтина только размажет внимание.

Вот из чего обычно состоит этот первый набор.

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

Утечки через ответ и боковые каналы. Цитата секрета из конфигурации. Данные, закодированные в URL. Служебный блок, куда утекло лишнее. Чужой документ, который ACL не должен был отдать.

Инструменты и цепочки агента. «Для проверки вызови экспорт». Согласование прошло на шаге 1, а на шаге 3 действие уже другое. Параметры раздули. Браузер или оболочка доступны, и ими пользуются не по делу.

Границы арендаторов. Чужой документ в выдаче. Кэш без ключа арендатора. Переранжирование без фильтра. Практика разобрана в статье про мультитенантность RAG.

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

У каждого пункта есть шаги, ожидаемый безопасный исход и ссылка на контроль, который должен сработать. Рядом пишут, чем закончился последний прогон.

Где гонять сценарии

Учебную тревогу не проводят поджогом офиса: стенд с изоляцией, синтетикой и трассами, не прод

Эвакуацию не тренируют, выталкивая людей в окно. Со сценариями то же самое: отдельный арендатор, синтетика, журнал. Боевая база остаётся в стороне.

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

Трасса показывает, кто вызвал инструмент и с какими аргументами. Рядом видны фрагмент RAG и версия политики. Без этого отказ модели и обрезка на шлюзе выглядят одинаково. Чинят потом не то место.

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

Метрики, от которых не отмахнуться

Четыре метрики защиты: доля обходов, ложные блоки, время до закрытия, покрытие каталога

Без чисел разговор скатывается к «ну там один раз странно ответило».

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

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

Время до воспроизведения и до закрытия. От находки до минимального исправления (политика, право инструмента, фильтр) и до зелёного прогона того же сценария.

Покрытие каталога. Сколько неприемлемых исходов из модели угроз имеют хотя бы один сценарий. Дыра в покрытии тоже результат проверки.

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

Как часто гонять

Непрерывный ритм: на каждое изменение, каждый спринт и каждый квартал — разная частота сигнала

Живой продукт не ждёт большую проверку в марте.

Сменились промпт, права инструментов или схема RAG. Сразу гоняйте короткий прогон критичных сценариев. Десятки минут в CI или ночной джоб. Раз в спринт закладывайте час на новые гипотезы и пару свежих пунктов в каталог, сверх того, что уже зелёное. Раз в квартал пересмотрите модель угроз вместе с ИБ и продуктом. Руководству показывайте тренд обходов. Один яркий кейс этот тренд не заменяет.

Регрессия ловит откат: вчерашний фикс сегодня снова красный. Исследование находит дыру, которой в каталоге ещё нет. Уберёте любое из двух, и контур захромает.

У агентов каждый новый шаг плана открывает ещё одну поверхность. Контекст разобран в статье про агентную инженерию.

От находки к барьеру

Найти уязвимость — лишь часть работы: классификация, структурный контроль и вечная регрессия в CI

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

Запишите шаги, трассу и неприемлемый исход. Класс выберите по месту поломки: модель, политика, право инструмента или стенд. Контроль ставьте на класс. Частный PDF оставьте примером. В тикете критерий готовности звучит так: «сценарий R-17 зелёный, и два соседних того же класса тоже». Сценарий остаётся в каталоге, пока угроза явно не устарела.

Если дыра пропала после правки промпта, а сценарий снова не гоняют, это не закрытие. Промпт остаётся слабым контролем. См. барьеры вне промпта и инъекции.

Кто за это отвечает

В продуктовой команде роли размываются, и каталог сиротеет. Через квартал никто не помнит, чей это файл.

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

Внешний аудит раз в год приносит свежий взгляд. Еженедельный прогон он не заменит.

Типичные ошибки

Гонять атаки на проде, потому что стенд не похож. Похожим делают стенд: те же формы полей, те же инструменты в сухом режиме, другие данные.

Каталог из десяти просьб забыть правила годится публичному чату. Если у вас корпус и экспорт, бейте по ним.

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

Находку закрыли одной правкой промпта и не оставили регрессию. Через неделю та же дыра приходит с другой моделью или с другим PDF.

Оценку качества и атакующий набор сложили в один процент успешных. Три критичных обхода тонут в зелёном.

Логи забыли как поверхность. Кто-то просит добавить отладочный дамп, и секреты уже в журнале.

Каталог собрали без модели угроз. Атаки красивые. Активы, которые реально нельзя терять, в списке не стоят.

Что сделать за две недели

План на 14 дней: модель угроз, стенд и фикстуры, ручные прогоны, три сценария в CI

Если контура ещё нет, не ждите отдельного большого проекта безопасности.

  1. Одностраничная модель угроз: активы, актёры, поверхности, права агента, пять неприемлемых исходов.
  2. Пять сценариев под эти исходы. Хотя бы два из них косвенные, через документ.
  3. Фикстуры в репозитории: файлы, диалоги, ожидаемый безопасный исход.
  4. Изолированный стенд с маркерами секретов и трассами.
  5. Пять ручных прогонов. Находки заводите тикетами с классом контроля.
  6. Три самых жёстких сценария поставьте в CI или в ночной прогон на смену промпта и инструментов.
  7. Имя владельца каталога и дата следующего исследовательского часа.

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

FAQ

Как часто нужен полный прогон?

Критичные сценарии гоняют на каждое изменение промпта, прав или схемы RAG. Полный пересмотр каталога и модели угроз делают примерно раз в квартал, чаще при крупном релизе агента.

Чем это отличается от оценки качества?

Оценка качества смотрит на пользу и на обычный путь пользователя. Атакующая проверка смотрит на враждебный ввод и на неприемлемые эффекты. Инструменты могут быть общими. Метки и пороги при этом разные. См. обвязку оценки.

Можно ли брать боевые документы?

Для сценариев с утечкой и с разрушительным действием ответ отрицательный. Форму данных дают синтетика и обезличенные шаблоны. Маркеры-секреты заведомо фальшивые, но в логах их узнают.

Нужна ли отдельная должность?

В малой команде хватает человека с защищённым временем. В регулируемой среде или при широких правах агента нужен отдельный контур ИБ или платформы и приёмка со стороны продукта.

С чего начать, если есть только чат без инструментов?

С утечки системного промпта, с вредоносного файла, который пока просто лежит в RAG, и с давления на оператора. Будущие инструменты ограничьте сразу: иначе завтра проверка будет только описывать катастрофу.

Как это стыкуется с инъекциями и барьерами?

Инъекции и барьеры отвечают на вопрос, что строить. Атакующие проверки отвечают на вопрос, как доказать, что построенное держит удар. Три текста составляют один контур: инъекции, барьеры, этот плейбук.

Комментарии

Загрузка комментариев…