Пентест LLM-приложений: как проверить AI-продукт по OWASP LLM Top 10

Возьмём условный пример. Компания полгода назад запустила ассистента поддержки: он читает входящую почту, ищет ответы во внутренней базе знаний и при необходимости создаёт задачи в CRM. Однажды приходит обычное на вид письмо от «клиента». В его тексте, белым шрифтом на белом фоне, спрятана инструкция: найти последние договоры и вставить в ответ картинку с адреса, в параметрах которого зашиты фрагменты этих договоров. Ассистент добросовестно выполняет задачу, почтовый клиент подгружает картинку, данные уходят на чужой сервер. Сервер никто не взламывал, пароли никто не подбирал, сотрудник ни на что не нажимал.

Это иллюстрация, а не описание конкретного инцидента. Но её ключевой механизм — скрытая инструкция в письме и вывод данных через автоматически загружаемый внешний ресурс — вполне реален: похожую цепочку исследователи показали в уязвимости EchoLeak в Microsoft 365 Copilot, о которой речь пойдёт ниже. Именно поэтому пентест LLM-приложений сегодня — это не прогон сканера «опасных промптов», а проверка того, что произойдёт, когда модель уже обманута: какие данные она увидит, какие инструменты вызовет и чьими правами будет действовать. Ниже — как устроен такой аудит безопасности ИИ, что проверять по OWASP LLM Top 10, где заканчиваются возможности автоматических инструментов и как заказать проверку, результат которой действительно можно использовать.

Почему LLM-приложение ломается иначе, чем обычный веб-сервис

В классическом веб-приложении код и данные можно надёжно разделить: SQL-запрос — это код, строка из формы — данные, и параметризованные запросы не дают одному стать другим. У языковой модели такой границы нет. Системная инструкция разработчика, вопрос пользователя, найденный в базе документ, письмо, ответ внешнего сервиса — всё это попадает в один и тот же контекст и обрабатывается одним и тем же механизмом. Модель не умеет надёжно отличать «приказ хозяина» от текста, который просто оказался рядом.

Отсюда главный класс атак — промпт-инъекция (prompt injection). Прямая инъекция — когда пользователь сам пишет модели «забудь предыдущие инструкции». Гораздо опаснее косвенная: вредоносная инструкция приходит не от собеседника, а из контента, который приложение обрабатывает по своей работе, — из письма, PDF, веб-страницы, карточки товара, ответа инструмента. Атакующему не нужен доступ к вашему чату, достаточно положить текст туда, откуда его прочитает ваш ассистент.

Здесь важно различать конкретную уязвимость и класс риска. Конкретные уязвимости, построенные на промпт-инъекции, исправляются — как это произошло с EchoLeak. Но сам класс риска не устраняется одним изменением системного промпта или одним фильтром на входе: такие меры снижают вероятность успеха известных атак, но не гарантируют, что не найдётся новая формулировка. Поэтому зрелый подход сместился: вместо попыток построить необманываемую модель строят систему вокруг неё так, чтобы обман модели не приводил к серьёзным последствиям. Значимые действия авторизуются вне модели, права инструментов урезаются до минимума, необратимые операции подтверждает человек.

Для быстрой самооценки удобно правило, которое исследователь Саймон Уиллисон назвал «смертельной триадой». Это сочетание трёх свойств: агент имеет доступ к приватным данным, обрабатывает недоверенный контент и умеет отправлять что-то наружу — письмо, HTTP-запрос, даже картинку в ответе. Такая комбинация сама по себе не доказывает, что утечка вероятна, но это опасное сочетание: если оно есть, сценарий вывода данных нужно отдельно проверить и обосновать, почему он не сработает. Разрыв одного из трёх звеньев — одна из архитектурных мер, которую стоит рассмотреть наряду с остальными.

1. ПисьмоНедоверенный контент
2. AI-агентПринимает текст за инструкцию
3. ИнструментыПолучают приватные данные
4. Внешний запросВыводит данные за пределы системы

Условная цепочка атаки. На пентесте проверяют весь путь: от входного контента до доступа к данным и выхода наружу.

OWASP LLM Top 10: зачем нужен стандарт и что изменилось в 2026 году

OWASP Top 10 for LLM Applications — это не регламент и не чек-лист сертификации, а общий язык. Он нужен, чтобы разработчик, служба безопасности, исполнитель пентеста и аудитор одинаково понимали, о каком классе риска идёт речь, и чтобы находки в отчёте можно было сопоставить между проектами и годами.

Актуальная редакция — OWASP Top 10 for LLM Applications 2026; проект выпустил её 3 августа 2026 года. Часть вендорских материалов до сих пор называет «текущим» список 2025 года, поэтому первое, что стоит уточнить у исполнителя, — по какой редакции он работает. Хороший отчёт указывает оба идентификатора, например «LLM03:2026 / LLM06:2025», чтобы находки читались и в старой, и в новой системе координат.

Самое заметное изменение редакции 2026 года — рост Excessive Agency, избыточных полномочий, с шестого места на третье. Это отражает переход LLM-продуктов от чат-ботов к агентам, которые сами вызывают API, пишут в базы и отправляют сообщения. Промпт-инъекция осталась на первом месте. Риск утечки системного промпта переименован в Hidden Context Exposure и расширен: теперь речь о любом скрытом контексте — политиках, конфигурации, профиле пользователя, описаниях инструментов. Improper Output Handling, небезопасная обработка вывода модели, опустилась вниз списка, но это относительное движение, а не признак того, что XSS через ответ модели стал менее опасен.

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

Для систем с инструментами и памятью OWASP выпустил отдельный список — Top 10 for Agentic Applications. Он описывает риски, которых нет у простого чат-бота: перехват цели агента, злоупотребление инструментами и привилегиями, отравление памяти, небезопасное общение агентов между собой, каскадные отказы, злоупотребление доверием человека к агенту. Если у вашей модели есть инструменты, применяйте оба списка.

Ниже — краткая шпаргалка по основному списку 2026 года, переведённая на язык последствий для продукта.

Три кейса, которые стоит знать до запуска

Абстрактные категории лучше всего понимаются на реальных историях. Три случая ниже показывают три разные поверхности атаки: саму модель, фреймворк вокруг неё и инфраструктуру, на которой всё работает.

Разбор инцидента

EchoLeak: одно письмо и ноль кликов

Исследователи Aim Labs показали, что одного письма достаточно, чтобы Microsoft 365 Copilot извлёк данные из рабочего контекста пользователя и отправил их наружу без единого клика. Уязвимость получила идентификатор CVE-2025-32711. Интересна не сама инъекция, а цепочка обходов: формулировки письма проходили мимо классификатора, который должен был ловить такие атаки; ссылки в особом формате Markdown не попадали под механизм вырезания внешних URL; картинки подгружались автоматически, а запрос уходил через домен Teams, разрешённый политикой безопасности контента. Microsoft исправила проблему на стороне сервиса, публично её раскрыли в июне 2025 года, признаков эксплуатации в реальных атаках не сообщалось.

Урок для владельца продукта: несколько защитных механизмов удалось обойти в одной цепочке, и система в целом допустила утечку. Похожую логику годом раньше показали исследователи PromptArmor на Slack AI: инструкция, опубликованная в общедоступном канале, заставляла ассистента сформировать ссылку «переавторизуйтесь», в адрес которой подставлялся секрет из приватного канала жертвы. Проверять нужно не фильтры по отдельности, а сквозной путь от недоверенного текста до канала вывода.

Разбор инцидента

LangGrinch: когда ответ модели становится эксплойтом

В декабре 2025 года мейнтейнеры LangChain опубликовали advisory об уязвимости CVE-2025-68664 в langchain-core — базовом пакете фреймворка LangChain; в публикациях её называют LangGrinch, среди исследователей, описавших проблему, были специалисты Cyata. Функции сериализации не экранировали служебный ключ lc, которым LangChain помечает свои объекты. Если такие данные позже десериализовались, атакующий мог извлечь секреты из переменных окружения (при включённой загрузке секретов из окружения — прежнем поведении по умолчанию) и создавать объекты классов из доверенных пространств имён LangChain со своими параметрами. По advisory, уязвимы версии langchain-core от 1.0.0 до 1.2.5 (не включая 1.2.5) и все версии ниже 0.3.81; исправления вышли в версиях 1.2.5 и 0.3.81. Это минимальные исторические исправленные версии для данной CVE, а не рекомендация, какую версию ставить сегодня: ориентируйтесь на актуальную поддерживаемую версию и проверяйте свои зависимости.

Главное в этой истории — вектор. По оценке самих мейнтейнеров, самый распространённый путь атаки идёт через служебные поля ответа модели, которые можно контролировать промпт-инъекцией и которые затем сериализуются, например, при потоковой выдаче. Значит, текст атакующего может превратиться в атаку на код вашего приложения. Здесь размывается привычная граница между «AI-риском» и «обычной уязвимостью»: тест только промптов такую проблему не найдёт, тест только кода не покажет, как до неё добраться. Нужен исполнитель, который смотрит на оба слоя.

Разбор инцидента

Langflow: старая добрая RCE в новой обёртке

Low-code платформа Langflow, на которой собирают LLM-пайплайны, содержала уязвимость CVE-2025-3248: неаутентифицированное удалённое выполнение кода через эндпоинт проверки кода. CISA внесла её в каталог уязвимостей, эксплуатируемых в реальных атаках, а Trend Micro зафиксировала, как через неё устанавливали ботнет Flodrix. Ни промптов, ни моделей — классическая RCE в инструменте LLM-разработки. Легко представить ошибку развёртывания, которая делает такую уязвимость особенно опасной, — скажем, экспериментальный стенд, оставленный доступным из интернета. Это гипотетический сценарий, а не описание тех, кого атаковали, но именно такие ошибки стоит искать на пентесте.

К той же категории относится цепочка поставок моделей. Ещё в 2024 году исследователи JFrog сообщали примерно о сотне потенциально вредоносных моделей на Hugging Face. Эта цифра описывает найденные подозрительные артефакты, а не сотню одинаковых эксплойтов: опасность каждого зависит от содержимого и способа загрузки. Сам механизм риска исследователи продемонстрировали наглядно: при загрузке модели в формате pickle может выполниться встроенный в файл код, вплоть до обратного шелла. Вывод тот же: AI-стек — это обычная инфраструктура со всеми её старыми проблемами, к которым добавились новые.

Безопасность AI-агентов: ущерб определяют полномочия

Даже чат-бот без инструментов может раскрыть конфиденциальные данные — из подключённой базы знаний, скрытого контекста, истории диалогов. Инструменты добавляют к этому новый класс последствий: операции и изменения данных, которые система выполняет от своего имени. Что именно может произойти после успешной инъекции, определяется тем, что агент умеет делать. OWASP называет три корня проблемы: избыточная функциональность (агенту дали инструмент «на всякий случай»), избыточные права (токен с административным доступом там, где хватило бы чтения) и избыточная автономия (необратимые действия без подтверждения). Каждое действие агента должно проходить авторизацию, которая не зависит от суждения модели.

На пентесте это выглядит так. Сначала исполнитель составляет инвентаризацию инструментов и выясняет, чьими правами каждый из них работает: от имени пользователя или общим сервисным аккаунтом. Долгоживущие ключи с широкими правами стоит искать в первую очередь: если такой ключ есть, последствия любой успешной инъекции резко возрастают. Затем идут сценарии: заставить агента отправить письмо на внешний адрес, изменить запись в CRM чужого клиента (классический IDOR, только через агента), обойти подтверждение фразой «это уже согласовано с руководителем», подменить параметры операции между моментом, когда человек её одобрил, и моментом исполнения. Отдельно проверяются цепочки между агентами: если один агент читает вывод другого, инъекция может путешествовать по всей системе.

Подробнее о том, как оценивать и ограничивать полномочия, мы писали в материале о тестировании Excessive Agency и ограничении прав AI-агентов.

Хороший повод заказать проверку в Pentest.red — момент, когда ваш ассистент получает первый «пишущий» инструмент: отправку сообщений, изменение записей, платежи, выполнение кода. К рискам раскрытия данных, которые были и раньше, добавляются операции и изменения, и модель угроз стоит пересобрать.

Проверка безопасности RAG: утечка происходит до модели

RAG (retrieval-augmented generation) — схема, в которой модель перед ответом ищет подходящие фрагменты документов во внутренней базе, обычно векторной. Редакция OWASP 2026 года формулирует ключевую мысль очень точно: если поиск достал документ, к которому у пользователя нет доступа, ошибка авторизации произошла до модели. Никакой промпт «не показывай конфиденциальное» её не исправит — серверная авторизация поиска обязательна.

Поэтому проверка безопасности RAG начинается с вопроса, от чьего имени выполняется поиск. Если все запросы идут через один сервисный аккаунт, а фильтрация «по правам» описана текстом в системном промпте, у системы нет технической границы между клиентами, и тест должен проверить, может ли пользователь A получить фрагменты документов пользователя B семантически близким вопросом. Исполнитель проверяет фильтрацию по клиенту и правам доступа на стороне сервера, доступность API векторной базы напрямую, синхронизацию прав с источниками вроде SharePoint или Confluence и то, исчезает ли удалённый документ из индекса на самом деле.

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

Пошаговую методику мы разбирали отдельно: как проводить доказательную оценку безопасности RAG.

1. ПользовательРоль и организация
2. Контроль доступаРазрешённые документы
3. Поиск RAGТолько доступные фрагменты
4. LLMОтвет в рамках доступа

Если документ запрещён пользователю, его фрагменты не должны попасть в контекст. Инструкция в промпте не заменяет серверную авторизацию.

Утечки, скрытый контекст и всё, что модель выводит

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

Со скрытым контекстом полезно сразу договориться о реализме. Системный промпт следует считать потенциально извлекаемым: OWASP прямо советует исходить из того, что скрытый контекст обнаружим. Из этого следуют два правила: системный промпт не должен хранить секреты, а авторизация должна выполняться на сервере, а не описываться в инструкциях модели. Сама по себе утечка промпта без секретов — обычно находка низкой критичности, а вот API-ключ или логика авторизации, зашитые в промпт, — высокой или критической. Ценность находки определяет то, что раскрыто, а не факт раскрытия.

Вывод модели — тоже недоверенные данные. Если ответ рендерится в браузере как HTML или Markdown, через него возможны XSS и та самая эксфильтрация через картинку. Если ответ подставляется в SQL-запрос, shell-команду или URL для серверного запроса, получаем инъекции и SSRF. Если модель генерирует код, который потом исполняется, нужна песочница. Защита здесь классическая: параметризованные запросы и контекстное экранирование, строгая политика рендеринга и CSP, проверка структурированного вывода по схеме перед передачей в инструменты.

Отдельная, не самая очевидная категория — неограниченное потребление ресурсов. Один хитро составленный запрос способен запустить каскад вызовов моделей и субагентов: это и отказ в обслуживании, и «denial of wallet», когда атакующий просто сжигает ваш бюджет на токены. Тесты здесь проводятся аккуратно и только с заранее согласованным лимитом затрат.

Наконец, ответы модели могут восприниматься как обязательства. Показательный пример — дело Moffatt против Air Canada 2024 года: чат-бот авиакомпании пообещал клиенту оформить льготный тариф задним числом, и трибунал Британской Колумбии отклонил довод, что бот — «отдельное лицо», за слова которого компания не отвечает, признав в этом деле ответственность авиакомпании. Это решение по конкретным обстоятельствам и в конкретной юрисдикции, а не универсальное правовое правило, но оно показывает, что ссылка на «это сказал бот» может не защитить. На пентесте стоит проверить, можно ли вынудить ассистента подтвердить несуществующую скидку, условия возврата или юридически значимую формулировку и не запускает ли система действия на основе непроверенного ответа.

Где заканчиваются возможности сканеров

Автоматические инструменты для тестирования LLM действительно полезны. NVIDIA garak прогоняет модель через большой набор атакующих проб, Microsoft PyRIT оркестрирует многоходовые атаки с помощью атакующей модели, promptfoo встраивает проверки в CI/CD с пресетами под OWASP, Giskard сканирует в том числе RAG-сценарии. Всё это хорошо работает как регрессия: после каждого изменения промпта или модели убедиться, что известные атаки не вернулись.

Ограничение не в том, что сканер в принципе не способен проверить авторизацию или многошаговую цепочку, а в том, что универсальный прогон этого не делает. Без знания продукта, ролевых учётных записей и специально написанных сценариев инструмент не знает, какие документы «чужие» для конкретного пользователя, какие у вас есть инструменты и что считается ущербом, поэтому межклиентскую утечку или цепочку «письмо → поиск → вызов инструмента → вывод данных» полноценно не покроет. Целевую автоматизацию с такими ролями и сценариями построить можно, и это ценное дополнение к ручной работе. Отдельно стоит помнить про код вокруг модели, как в случае LangGrinch, — его проверяют другими методами. Авторы garak в своей статье прямо пишут, что инструмент не покрывает выполнение кода и недостаточный контроль доступа. А независимое сравнение нескольких популярных сканеров показало, что автоматические оценщики заметно ошибаются в том, считать ли атаку успешной.

Ещё сильнее отрезвляет исследование «The Attacker Moves Second», подготовленное авторами из OpenAI, Anthropic, Google DeepMind и ETH Zürich. Они взяли двенадцать опубликованных защит от промпт-инъекций и джейлбрейков, большинство из которых заявляли почти нулевой успех атак, и атаковали их адаптивно — подбирая атаку под конкретную защиту. Для большинства защит успех превысил 90%. Это результат эксперимента на конкретных защитах и моделях, а не вероятность взлома любого продукта. Но вывод устойчивый: статический набор тестов и адаптивный атакующий — разные противники, и защита, хорошо выглядящая на первом, может не устоять перед вторым.

Есть и чисто техническая особенность — недетерминированность. Одна и та же атака может, например, сработать в трёх попытках из десяти. Это наблюдаемый результат в заданных условиях теста — конкретная модель, версия, настройки, контекст, — а не вероятность успеха атаки в продуктиве. Однократная неудача тоже ничего не доказывает, поэтому в корректной находке указывается число попыток, доля успешных, версия модели и дата. Отчёт, где этого нет, невозможно воспроизвести и невозможно проверить на ретесте.

Чтобы не путать разные виды работ, полезно их развести. Под AI red teaming в таблице понимается узкий вариант — проверка контентной безопасности, то есть склонности модели нарушать политики допустимого контента; на практике этим термином называют и более широкие учения, вплоть до полноценной атаки на систему.

Как проходит пентест LLM-приложения

Работа начинается не с атак, а с границ. Исполнитель вместе с командой фиксирует, из чего состоит система: какие модели и версии, какой оркестратор, какие инструменты и с какими правами, какие источники данных подключены к RAG, есть ли память и MCP-серверы, через какие каналы приходит ввод, какие роли и клиенты существуют, какие данные и действия критичны для бизнеса.

Затем строится модель угроз — карта потоков данных с отмеченными границами доверия. На ней видно, где недоверенный контент встречается с приватными данными и где у системы есть выход наружу. Угрозы сопоставляются с OWASP LLM Top 10, агентным списком и MITRE ATLAS — базой знаний о техниках атак на AI-системы, своего рода аналогом ATT&CK для машинного обучения.

Разведка в LLM-проекте имеет свою специфику: извлечение системного промпта и описаний инструментов, определение модели и фреймворка, перечисление API, поиск открытых панелей вроде той же Langflow. Дальше начинается основная ручная часть: инъекции под конкретную бизнес-логику, многоходовые сценарии, обход фильтров перефразированием, кодировками и переводом на другой язык — защиты, настроенные в основном на английский, стоит отдельно проверять на русском. Агентов проверяют на вызовы вне сценария, подмену параметров, обход подтверждений и передачу инъекции через вывод инструментов. RAG — на авторизацию поиска, изоляцию и возможность отравления.

Отдельно и обязательно проверяется классическая поверхность: аутентификация, загрузка файлов, SSRF через инструмент «получить страницу по URL», XSS в виджете чата, уязвимые зависимости. Тест, ограниченный промптами, оставляет эту поверхность непроверенной, а на ней тоже бывают критичные уязвимости — пример Langflow это наглядно показывает.

Формат доступа сильно влияет на результат. Чёрный ящик реалистичен, но дорог: промпт и инструменты приходится восстанавливать, а из-за недетерминированности трудно отличить «уязвимости нет» от «не повезло». Серый ящик — разумная база: учётные записи нескольких ролей и клиентов, описание архитектуры, список инструментов, системный промпт и доступ к трассировкам, где видно, что попало в контекст и какой инструмент был вызван. Белый ящик добавляет код оркестрации, настройки IAM и пайплайн RAG и помогает детально изучить интеграцию — как данные сериализуются, где проверяются права. Уязвимые версии библиотек вроде случая LangGrinch при этом выявляются и проверкой версий зависимостей, без полного доступа к коду; белый ящик позволяет понять, достижима ли уязвимость в вашем конкретном приложении.

1. ГраницыСистемы, роли и ограничения
2. СценарииРучные проверки и цепочки
3. НаходкиДоказательства и последствия
4. РетестПовторение после исправлений

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

Как оценивать критичность находок

CVSS хорошо подходит для «классических» уязвимостей вроде RCE в Langflow, но плохо передаёт вероятностную природу инъекций: атака, срабатывающая в одном случае из двадцати и ведущая к утечке всей базы клиентов, требует иной интерпретации, чем стабильный XSS. OWASP развивает отдельную систему оценки AIVSS, которая надстраивается над CVSS v4.0 и добавляет поправку на агентные факторы — автономию, доступ к инструментам, влияние на другие системы. Проект пока развивается, его ранние версии публиковались как черновые, поэтому, если вы на него опираетесь, уточняйте актуальную версию и помните, что коэффициенты могут меняться.

Практичный подход сегодня — сочетать несколько измерений: базовую оценку CVSS v4.0 с вектором, явную наблюдаемую частоту успеха (сколько попыток из скольких удались в условиях теста), бизнес-импакт (какие данные и действия стали доступны) и, для агентных находок, AIVSS как дополнительный ориентир. Главное, чтобы критичность была обоснована, а не выставлена на глаз.

Каким должен быть отчёт и зачем нужен ретест

Отчёт — основной документ, в котором фиксируются результаты пентеста, наряду с разбором находок с командой, сценариями для регрессионных тестов и ретестом. По нему лучше всего видна разница между работой и имитацией. В хорошем отчёте каждая находка воспроизводима: точные промпты и входные данные, полный лог с контекстом, вызовами инструментов и ответом, число попыток и доля успешных, версия модели и дата. Есть обоснованная оценка критичности, привязка к OWASP 2026 и 2025, агентному списку и MITRE ATLAS, понятное описание бизнес-последствий. Отдельно — резюме для руководства, описание границ и ограничений проверки.

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

Ретест — не формальность. Исправления в LLM-системах часто носят вероятностный характер: команда поменяла формулировку промпта, атака перестала срабатывать в трёх попытках из трёх, но на десятой прошла. Повторная проверка сопоставимым набором сценариев позволяет оценить, воспроизводится ли находка после исправления. Число попыток и условия фиксируют в отчёте: отсутствие успешных атак в конечной выборке само по себе не доказывает, что риск полностью устранён.

Когда заказывать проверку и как подготовить границы

Естественные поводы для пентеста LLM-приложения — публичный запуск, добавление агентов, инструментов, MCP, памяти или RAG, смена модели или провайдера, изменение защитных фильтров или пайплайна данных. Ещё один повод — требования клиентов и регуляторов, но здесь важно не преувеличивать. В Европе статья 15 AI Act требует от систем высокого риска надлежащего уровня точности, устойчивости и кибербезопасности, включая меры против отравления данных и состязательных атак; это не универсальное требование заказывать внешний пентест, но результаты проверки могут стать частью доказательств соответствия. В России требования к защите систем с ИИ содержатся в приказе ФСТЭК № 117 о защите информации в государственных информационных системах; применимость и конкретный набор мер зависят от вида и класса системы, поэтому их стоит уточнять у специалиста по соответствию.

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

Заранее согласуйте бюджет на токены и порог остановки, окна тестирования, контакты и порядок действий при критичной находке. Явно зафиксируйте запреты: никаких реальных писем и платежей (только заглушки), никакой нагрузки на продуктив, никакого отравления индексов без возможности отката, соблюдение правил использования провайдера модели. И обязательно дайте доступ к трассировкам — без них многие находки невозможно ни доказать, ни опровергнуть. Удобный шаблон для этой подготовки — форма описания границ пентеста.

Если вы планируете обсуждать проверку с Pentest.red, принесите на первую встречу схему архитектуры, список инструментов агента с правами, перечень источников RAG и описание ролей и клиентов. Этого обычно достаточно, чтобы вместе определить разумные границы и формат доступа.

Как выбрать исполнителя

Рынок AI-безопасности молодой, и под одним названием продают очень разные услуги. Спросите исполнителя о реальном опыте именно с агентами и RAG и попросите обезличенный пример отчёта: по нему быстро видно, есть ли там доказательства и бизнес-импакт. Уточните, по какой редакции OWASP он работает и учитывает ли агентный список и MITRE ATLAS. Узнайте, какая доля работ выполняется вручную, какими инструментами он пользуется и как проверяет их срабатывания, сколько попыток делает на один сценарий и как фиксирует долю успеха. Обязательно спросите, тестирует ли он авторизацию, изоляцию клиентов, API и зависимости, а не только промпты, как оценивает критичность, включён ли ретест и даёт ли архитектурные рекомендации. Отдельный вопрос — конфиденциальность: используются ли внешние модели для генерации атак и куда при этом уходят ваши промпты и данные.

Насторожиться стоит, если вам предлагают «прогнать бота через AI-сканер за день», если пример отчёта состоит из скриншотов без сценария ущерба, если на этапе обсуждения границ никто не спрашивает про права агентов и клиентов, если обещают, что «инъекции станут невозможны», если нет лимитов затрат и процедуры остановки и если исполнитель работает по нумерации 2023 года. Подробнее о том, как сравнивать предложения по объёму работ, методике и результату, — в нашем руководстве по выбору услуг оценки безопасности AI.

Чего мы пока не знаем

Честный разговор о безопасности LLM требует признать пробелы в данных. Надёжной публичной статистики о том, какая доля LLM-приложений уязвима к тому или иному риску, нет: вендорские цифры строятся на собственной клиентской базе и между собой несопоставимы. Исследование IBM и Ponemon о стоимости утечек за 2025 год часто цитируют, но его выборка — 600 организаций, уже переживших утечку данных. В этой выборке 13% сообщили об инциденте, затронувшем их AI-модели или приложения, и почти все из этих 13% не имели надлежащего контроля доступа к AI. Это указывает на проблему контроля доступа в изученной подгруппе, но не доля всех компаний и не вероятность инцидента для вашей.

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

Что запросить по итогам проверки

Если свести всё к одному решению, оно звучит так: проверять нужно не модель, а систему вокруг неё, и не в теории, а на вашем продукте с вашими правами, данными и инструментами. Сканеры оставьте для постоянной регрессии в CI/CD, а перед запуском и после каждого расширения полномочий заказывайте пентест с серьёзной ручной частью.

Если вы готовите запуск чат-бота, RAG-системы или агента с инструментами либо расширили полномочия уже работающего AI-продукта, границы и формат проверки можно обсудить с командой Pentest.red в рамках услуги тестирования на проникновение. По итогам стоит требовать то же, что описано выше и что мы советуем требовать от любого исполнителя: воспроизводимые находки с числом попыток и долей успеха, безопасные демонстрации бизнес-последствий на тестовых данных, обоснованную критичность с привязкой к OWASP и MITRE ATLAS, архитектурные рекомендации и ретест исправлений.