Пентест LLM-приложений: что проверяют и как на самом деле ломают AI-ботов

Чем LLM-пентест отличается от обычного

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

Ключевое отличие: в LLM-приложении данные и инструкции идут одним каналом. Любой текст, который попадает в контекст модели — сообщение пользователя, документ из базы знаний, страница из интернета — потенциально является командой. Это фундаментальное свойство архитектуры, а не баг, поэтому «пропатчить» его нельзя — можно только грамотно ограничить последствия.

Основные классы атак

На практике мы проверяем шесть классов, которые пересекаются с OWASP Top 10 for LLM Applications:

• ◇Прямая prompt injection — пользователь текстом заставляет бота нарушить собственные правила: раскрыть скрытые инструкции, обойти ограничения тематики, выполнить чужую задачу за счёт ваших токенов.
• ◇Косвенная prompt injection — команда прячется в данных, которые модель читает сама: в документе из RAG-базы, в письме, в описании товара, в веб-странице. Пользователь может вообще не знать, что атака произошла.
• ◇Jailbreak агента — вывод агента за рамки сценария: лишние действия, вызов инструментов с чужими параметрами, действия от имени другого пользователя.
• ◇Утечка системного промпта — извлечение инструкций, внутренней логики, ключей и ссылок на внутренние системы из контекста модели.
• ◇RAG leakage — доступ к чужим документам через поиск: модель находит и цитирует данные, к которым у этого пользователя не должно быть доступа. Классическая ошибка — фильтрация прав после поиска, а не до.
• ◇Excessive agency — у агента больше прав, чем нужно: инструмент «отправить письмо» может писать кому угодно, инструмент «посмотреть заказ» принимает любой ID. Это IDOR нового поколения, и ловится он так же — перебором и сравнением ответов.

Как выглядит методика

Пентест LLM-продукта идёт в четыре шага. Разведка: определяем модель, архитектуру (прямой вызов, RAG, агент с инструментами), точки входа недоверенных данных. Составление сценариев: под каждую точку входа — свой набор атак, от простых инъекций до многоходовых цепочек через память и инструменты. Эксплуатация: атаки прогоняются на живом продукте или стенде, каждая находка фиксируется с воспроизводимым диалогом. Отчёт: доказанные находки с уровнем риска, транскриптом атаки и конкретными рекомендациями — что чинить первым.

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

Что сделать разработчику прямо сейчас

• ◇Разделяйте инструкции и данные: всё, что пришло извне, оборачивайте в явные маркеры и говорите модели относиться к этому как к данным.
• ◇Режьте права инструментов: агент должен уметь ровно то, что нужно сценарию, и проверка прав должна жить в коде инструмента, а не в промпте.
• ◇Фильтруйте RAG до поиска, а не после: права пользователя применяются на этапе запроса к индексу.
• ◇Валидируйте вывод: ответ модели, который уходит в HTML, SQL или shell — это недоверенный ввод.
• ◇Логируйте диалоги и вызовы инструментов — без этого инцидент нельзя ни заметить, ни расследовать.

FAQ