Генеративный ИИ вышел далеко за рамки обычного чат-бота. Теперь он пишет код, ищет информацию во внутренних базах знаний, проверяет контракты, открывает обращения в службу поддержки и в некоторых случаях выполняет действия через подключенные инструменты. Эта расширенная роль меняет подход к безопасности. Тестировщик больше не ищет только модель, которая скажет что-то недопустимое. Настоящая проблема заключается в том, может ли манипулируемый текст получить доступ к защищенным данным или инициировать несанкционированное бизнес-действие.
Это делает приложение на базе LLM ближе к графу атак, чем к отдельной конечной точке. Промпты, сервисы поиска, векторные базы данных, идентификаторы, плагины, шлюзы моделей и нижестоящие API — все это влияет на конечный результат. Традиционное тестирование веб-приложений по-прежнему важно, но оно упустит пути, уникальные для систем, в которых инструкции и данные поступают по одному и тому же каналу.
Начинайте с приложения, а не с модели
Полезное взаимодействие начинается с обзора архитектуры. Документируйте системные и пользовательские промпты, конечные точки моделей, резервные модели, уровень поиска, сервис встраивания, векторное хранилище, память, определения инструментов, API-шлюз, средства модерации, секреты, этапы утверждения и логирование. Отметьте каждое место, где контент меняет уровень доверия или где один компонент передает полномочия другому.
Эта карта выявляет пути, которые стоит протестировать. Документ, загруженный обычным пользователем, может впоследствии стать доверенным контекстом поиска для руководителя. Ответ модели может быть обработан как параметр для SQL-запроса или API возврата средств. Результат работы инструмента может быть возвращен модели без фильтрации. Ни один из этих переходов не выглядит опасным при рассмотрении в изоляции; именно цепочка создает уязвимость.
Текущее руководство OWASP по инъекциям промптов различает прямое манипулирование со стороны пользователя и косвенные инструкции, скрытые во внешнем контенте. Оно также отмечает, что генерация с дополненным поиском (RAG) и дообучение не устраняют базовый риск. На практике это означает, что поверхность тестирования включает электронную почту, тикеты, веб-страницы, PDF-файлы, репозитории кода, электронные таблицы и любой другой контент, который может читать приложение.
Установите правила, предотвращающие превращение теста в инцидент
Агентные системы могут вызывать побочные эффекты во время тестирования. Они могут отправлять сообщения, редактировать записи, вызывать внешние службы, раскрывать регулируемые данные или потреблять неожиданно большое количество платного трафика для инференса. Поэтому правила взаимодействия должны определять разрешенные арендаторов, тестовые идентификаторы, модели, ограничения скорости, потолок затрат, разрешенные инструменты и условия аварийной остановки. Разрушительные функции должны находиться в симуляторе или одноразовой среде.
Используйте “канареек” вместо реальных секретов. Создавайте синтетические записи клиентов, тестовые ключи API и фразы, специфичные для арендатора, которые легко распознать в логах. Определите критерии успеха до начала кампании: получение “канарейки” от другого арендатора, вызов инструмента без разрешения, изменение защищенного значения транзакции, сохранение инструкции в памяти или вызов измеримого условия исчерпания ресурсов. Отказ на очевидный “джейлбрейк” не является значимым критерием прохождения.
Рассматривайте инъекции промптов как кампанию
Одноразовые промпты, такие как “игнорировать предыдущие инструкции”, полезны для первичной проверки, но опытные злоумышленники не полагаются на одну фразу. Тестировщики должны варьировать язык, форматирование, кодирование, ролевые игры, Unicode, вложения и историю диалогов. Им также следует разделять намерение на несколько шагов, поскольку средства контроля, блокирующие явный запрос, могут не сработать, когда цель достигается постепенно.
Тестирование уклонения от моделей должно ставить практический вопрос: сможет ли злоумышленник сохранить вредоносную цель, изменив ее внешнюю форму? Попробуйте перефразирование, перевод, размещение в большом контексте, цитирование, вложенные инструкции и контент, который якобы исходит из доверенного рабочего процесса. Повторите ту же цель после сводки сеанса, сжатия контекста, отката модели или ошибки инструмента. Эти изменения состояния часто влияют на то, какая инструкция получает приоритет.
Самое сильное обнаружение связывает инъекцию с наблюдаемым эффектом. Может ли “отравленный” документ заставить помощника извлечь второй ограниченный документ? Может ли бот поддержки передать измененную сумму возврата инструменту? Может ли сгенерированный моделью SQL, текст оболочки, HTML или параметр API попасть в интерпретатор без детерминированной проверки? Отчет должен показывать полную цепочку, включая использованный идентификатор, извлеченные записи, аргументы инструмента и результирующее изменение состояния.
Таксономия NIST по состязательному машинному обучению за 2025 год обеспечивает прочную основу для этой работы, поскольку она организует атаки по типу модели, этапу жизненного цикла, цели злоумышленника, возможностям и знаниям. Этот более широкий взгляд не позволяет свести каждую проблему GenAI к метке “джейлбрейк”.
Тестируйте RAG и векторные базы данных как средства контроля безопасности
Система RAG вводит дополнительный уровень принятия решений: какой контент видит модель. Даже хорошо себя ведущая модель может дать скомпрометированный ответ, если конвейер поиска предоставляет “отравленный” или несанкционированный контекст. Оценка должна охватывать загрузку, парсинг, разбиение на части, встраивание, индексирование, метаданные, построение запросов и фильтры авторизации.
Начните с контролируемого “отравления”. Вставьте синтетический документ, содержащий скрытую инструкцию, и наблюдайте, индексирует ли конвейер, извлекает и следует ли ей. Перемещайте инструкцию через видимый текст, метаданные, комментарии, текст на белом фоне, слои OCR, ячейки электронных таблиц и комментарии к исходному коду. Измеряйте, насколько последовательно “отравленный” объект появляется для целевых запросов и остается ли он доступным для поиска после изменения или удаления источника.
Тестирование изоляции так же важно. Создайте двух арендаторов или группы безопасности с различными “канареечными” данными, затем отправьте семантически схожие запросы с обеих сторон. Проверяйте идентификаторы извлеченных документов, а не только конечный текст. Авторизация должна ограничивать набор для поиска до того, как конфиденциальный контент попадет в контекст модели. Тестируйте пустые метаданные, некорректные фильтры, различия в регистре, подстановочные знаки, устаревшие кэши контроля доступа и изменения разрешений, сделанные после индексирования.
Руководство OWASP по векторным представлениям и встраиванию указывает на несанкционированный доступ, утечку между контекстами, инверсию встраивания и “отравление” данных. Оно рекомендует хранилища с учетом разрешений, логическое разделение, проверку источника и подробные неизменяемые журналы поиска. Эти рекомендации легко преобразуются в утверждения для пентеста: докажите, что фильтр нельзя обойти, что недоверенный контент отслеживается, и что каждый конфиденциальный поиск может быть реконструирован.
Отслеживайте конвейер ML вверх по потоку
Некоторые компрометации происходят до инференса. Проверяйте данные для обучения и дообучения, ноутбуки, код встраивания, реестры моделей, объектные хранилища, рабочие процессы CI/CD, адаптеры, зависимости пакетов и манифесты развертывания. Протестируйте, может ли неавторизованный пользователь заменить набор данных, отредактировать набор для оценки, опубликовать новую версию модели или изменить используемый набор промптов и политик.
Для компонентов предиктивного ML ограниченные состязательные примеры могут выявить уклонение вблизи порогов принятия решений. Для генеративных систем используйте контролируемое “отравление” в непроизводственном корпусе и измеряйте, сохраняется ли целевое поведение после переобучения, повторного индексирования или отката. Хэши артефактов, подписи и разделение обязанностей должны быть протестированы, а не приняты на основе диаграммы. Надежный откат также должен восстанавливать промпты, индекс поиска, политику инструментов и версию модели как единый согласованный релиз.
Секреты заслуживают отдельного трека тестирования. Ищите учетные данные или конфиденциальный контекст в ноутбуках, шаблонах промптов, переменных среды, трассировках и логах моделей. Используйте “приманки” при попытке извлечения. Доказательства должны демонстрировать путь без копирования реального производственного секрета в отчет.
Используйте Python для обеспечения повторяемости атак
Ручное зондирование ценно для обнаружения, но является плохим методом регрессионного тестирования. Небольшой Python-фреймворк может определить цель, сгенерировать одобренные мутации, отправить их через тот же интерфейс, который используют клиенты, захватить трассировки поиска и инструментов, оценить результат и сохранить доказательства. Код должен выполняться только против авторизованных целей и останавливаться при неожиданных побочных эффектах.
for case in approved_cases:
for prompt in mutate(case.seed):
result = sandbox.send(
prompt, identity=case.test_identity,
trace=True, max_cost=case.cost_limit,
)
finding = score_outcome(result, case.objective, case.canaries)
evidence.write(case.id, prompt, result, finding)
if finding.critical or result.unexpected_side_effect:
emergency_stop()
Публичная эталонная реализация этого цикла выполняет те же четыре функции против локальной, намеренно уязвимой RAG и вызывающей инструменты цели, поэтому каждое обнаруженное в ней уязвимость воспроизводимо путем запуска набора тестов, а не просто заявлено.
Фреймворк вокруг цикла важнее самого цикла. Храните начальные данные и мутации под контролем версий. Записывайте версии модели и промптов, идентификаторы извлеченных источников, идентификатор, вызовы инструментов, задержку, использование токенов и состояние политики. Оценивайте конкретные результаты — извлечение запрещенной записи, запись файла, вызов инструмента или обход утверждения — вместо того, чтобы полагаться только на другую модель для оценки того, звучит ли ответ небезопасно.
Текущая документация Microsoft по PyRIT использует сравнимый модульный дизайн, построенный вокруг наборов данных, сценариев, техник атак, исполнителей, конвертеров, целей и оценщиков. Он полезен для масштабирования кампаний красной команды, но не может определить модель угроз организации или бизнес-критичность обнаруженной уязвимости. Эта оценка по-прежнему остается за тестировщиком и владельцем системы.
Отчитывайтесь об эксплуатируемости, а не о “театре”
Сильный отчет разделяет некорректное поведение модели и компрометацию системы. Критичность должна учитывать требуемый доступ, повторяемость, устойчивость, затронутых пользователей, конфиденциальность данных, привилегии инструментов и наличие значимого шага человеческого утверждения. Драматичный запрещенный ответ может быть менее серьезным, чем обычный ответ, который незаметно извлекает контракт другого арендатора.
Поскольку поведение модели вероятностно, повторяйте каждую существенную цепочку. Сообщайте о частоте успешных атак, требуемых шагах, предполагаемой стоимости, времени до воздействия и о том, сохраняется ли результат при новой сессии или пересмотре модели. Для RAG отслеживайте несанкционированное извлечение и влияние “отравленных” документов. Для агентов отслеживайте несанкционированные вызовы инструментов и сбои в воротах утверждения. Для конвейера ML записывайте, обнаружили ли средства контроля целостности измененный артефакт и предотвратили ли его продвижение.
Каждая высокорисковая находка должна стать регрессионным тестом. Формулировка промпта сама по себе редко является надежным исправлением. Эффективная коррекция обычно сочетает инструменты с минимальными привилегиями, поиск с учетом разрешений, проверку происхождения источника, валидацию вывода, песочницы, детерминированные проверки политик, утверждение необратимых действий, ограничения скорости, мониторинг и протестированный откат.
Тестируйте цепочку всякий раз, когда она меняется
Тестирование на проникновение GenAI должно начинаться до запуска и возобновляться всякий раз, когда меняется модель, системный промпт, инструменты, корпус поиска, правила идентификации или разрешения. Конечный результат — это не набор хитроумных промптов. Это набор воспроизводимых путей, показывающих, где манипулируемый контент пересек границу доверия и какие бизнес-последствия это повлекло.
Практическая цель — не сделать языковую модель невозможной для сбивания с толку. Это не реалистичная граница безопасности. Цель состоит в том, чтобы спроектировать и проверить окружающее приложение таким образом, чтобы сбитая с толку модель не могла извлечь то, что ей не следует видеть, выполнить то, что ей не следует контролировать, или незаметно изменить состояние бизнеса.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Sunil Gentyala
