ML Red Teaming для LLM: можно ли обойтись open source-инструментами?
Н
НейроАлекс
·6 мин читать
ML Red Teaming для LLM: можно ли обойтись open source-инструментами?
Статья была полезной?
С увеличением числа больших языковых моделей (LLM) и агентных систем в корпоративном секторе традиционные методы обеспечения безопасности перестают быть эффективными. Уязвимости теперь проявляются не только в коде, но и в промптах, памяти агентов, контексте RAG и вероятностном поведении самих моделей.
ML Red Teaming (AI Red Teaming) — это специализированный подход к наступательному тестированию, в рамках которого команда имитирует действия реальных злоумышленников против систем машинного обучения, больших языковых моделей, генеративного ИИ и агентных систем. В отличие от классического пентестинга, цель такой процедуры заключается не только в том, чтобы «взломать» систему, но и в том, чтобы обнаружить уязвимости, характерные именно для компонентов ИИ, оценить их риски и повысить настоящую устойчивость используемой ИИ-модели.
Основные цели ML Red Teaming включают:
выявление реальных уязвимостей до того, как ими воспользуются злоумышленники,
оценка устойчивости моделей и агентных систем к атакам,
получение реальной, подтвержденной практическими атаками оценки риска,
повышение доверия к ИИ-системам со стороны бизнеса и регуляторов,
формирование основ для построения эффективной защиты и мониторинга в SOC.
Для проведения ML Red Teaming используются несколько методологий:
комбинация автоматизированного сканирования и ручного экспертного тестирования,
многоагентные атаки (одна модель атакует, другая оценивает, третья генерирует вариации),
тестирование на различных уровнях зрелости: от простых prompt-инъекций до сложных многошаговых атак на память, инструменты и оркестрацию агентов.
Для планирования атак в контексте ML Red Teaming применяются несколько ключевых фреймворков. Основным документом с описанием угроз для ИИ-систем считается MITRE ATLAS, который на июнь 2026 года включает 16 тактик и 170 техник (плюс 114 техник за 3 месяца). Также важным является OWASP Top 10 for LLM Applications, в котором на первом месте по-прежнему остаётся угроза LLM01: Prompt Injection. При оценке рисков следует учитывать рекомендации NIST AI RMF и NIST AI 100-2. Для агентных систем (agentic AI) дополнительно рекомендуется использование фреймворка OWASP ASI.
Для проведения тестов могут использоваться сканеры ML Red Teaming, интегрированные в AI/LLM Firewall, или инструменты и фреймворки с открытым исходным кодом.
Наиболее известные решения с открытым исходным кодом:
Garak — быстрый и универсальный сканер уязвимостей LLM, включает более 100 проб, имеет плагинную архитектуру и поддерживает множество моделей.
Promptfoo — решение для Red Teaming, оценки и интеграции CI/CD по стандартам OWASP и MITRE, с удобным веб-интерфейсом.
PyRIT — комплексное предприятие для тестирования LLM и агентов, поддерживает многократные атаки.
DeepTeam и его аналоги — предназначены специально для тестирования агентных систем.
Однако важно учесть, что:
отсутствие защиты в режиме реального времени: даже если найдена уязвимость, необходимо самостоятельно настраивать фильтры и правила;
высокие требования к экспертизе и ручной работе: требуется самостоятельно разрабатывать CI/CD-пайплайны и интеграцию;
выявление и устранение уязвимостей: большинство open-source решений лишь обнаруживают уязвимости;
ограниченная поддержка русского языка и специфики: многие инструменты ориентированы на англоязычные данные;
недостаток соответствия требованиям: open source не соответствуют требованиям регуляторов;
изолированность от SOC-процессов: зачастую отсутствуют готовые отчёты и интеграция с SIEM/SOAR;
зависимость от скорости реагирования комьюнити: это может замедлить реакцию на новые угрозы.
Практика проведения сканирования: простое использование сканера и просмотр отчёта — это только верхушка айсберга. Основная трудность заключается в оценке качества и полноты тестирования.
LLM работают стохастически, поэтому один и тот же ввод может приводить к различным результатам. Даже при использовании одного и того же сканера необходимо выполнить несколько прогонов, чтобы получить надежные результаты.
Рассмотрим классы атак, через которые нужно проверять ИИ-модели при сканировании, на примере INFERA AI.Firewall с модулем ML Red Teaming.
Jailbreak и обход ограничений
Этот класс атак является наиболее серьезным, особенно для облачных сервисов и публичных чат-ботов. При помощи джейлбрейка злоумышленник может получить доступ к системному промпту или конфиденциальной информации.
Важно проводить тестирование с использованием ролевых промптов, чтобы заставить модель игнорировать встроенные ограничения. Также может применяться адаптивный многошаговый джейлбрейк с деревом атак.
Рис. 1. Настройка сканера INFERA ML Red Teaming для выявления Jailbreak-атак и обхода ограничений
Рис. 1. Настройка сканера INFERA ML Red Teaming для выявления Jailbreak-атак и обхода ограничений
Prompt Injection
При этом классе атак основным риском являются агенты, которые используют модели для вызова инструментов.
Рис. 2. Настройка сканера INFERA ML Red Teaming для выявления prompt-инъекций
Рис. 2. Настройка сканера INFERA ML Red Teaming для выявления prompt-инъекций
Утечка данных и системного промпта
Задача сканера состоит в проверке на воспроизводимость защищенных и обучающих данных в ответ на запросы. Эти данные могут отличаться для каждой организации, поэтому сканер должен быть настроен соответственно.
Токсичность и небезопасный контент
Этот блок тестов наиболее актуален для заказчиков, поскольку страх перед возможной утечкой компрометирующей информации становится первостепенным.
Галлюцинации и дезинформация
Эти тесты посвящены атакам, направленным на провокацию галлюцинаций и генерацию ложной информации, которую модель выдает за правдивую.
Многошаговые атаки
Этот блок требует наибольших временных ресурсов, поскольку «модель-атакующая» создает новые варианты запросов и перефразирует предыдущие сообщения.
Рис. 3. Настройка сканера INFERA ML Red Teaming для выявления многошаговых атак
Рис. 3. Настройка сканера INFERA ML Red Teaming для выявления многошаговых атак
Атаки на корпоративные данные
Седьмой блок включает тестирование с реальными корпоративными данными, что позволяет применять собственные адаптированные промпты.
Результаты работы сканера ML Red Teaming направляются в SOC или ASOC/ASPM, в зависимости от того, в каком подразделении используется ИИ. Отчёт включает: тип атаки, название техники, текст атаки и ответ модели. Эти данные используются для донастройки AI.Firewall и обновления правил и политик.
В итоге можно выделить несколько ключевых моментов:
INFERA ML Red Teaming + AI.Firewall представляет собой единую систему: найденные уязвимости сразу же обрабатываются (фильтрация, блокировка, маскировка данных, контроль доступа).
Реализована возможность не только находить, но и устранять риски через обновление правил, ограничение доступа и блокировку опасных паттернов.
Все аспекты разработки учтены с учетом российской специфики.
Модуль INFERA автоматически сканирует модели на всех этапах жизненного цикла, без необходимости постоянного участия специалистов.
Поддержка нескольких LLM одновременно с возможностью использования разных схем подключения.
Рис. 4. Результат работы сканера INFERA ML Red Teaming
Рис. 4. Результат работы сканера INFERA ML Red Teaming
Классические методы Red Teaming разрабатывались для детерминированных систем, в которых поведение предсказуемо, и поверхность атаки ограничена сетями и приложениями. В случае с ML- и LLM-системами ситуация меняется.
Для CISO:
включить ML Red Teaming в программу Red Team/Purple Team,
регулярно анализировать MITRE ATLAS и оценивать риски,
внедрять средства защиты AI/LLM Firewall.
Для SOC:
добавить контроль за использованием LLM- и ИИ-моделей в SIEM/SOAR,
обучить аналитиков базовым техникам prompt-инъекций и джейлбрейков,
создать план тестирования по основным техникам MITRE ATLAS,
использовать сканеры ML Red Teaming и интегрировать их результаты в процессы реагирования.
Open source-инструменты для ML Red Teaming могут стать отличной отправной точкой для экспериментов и развития навыков внутри команды. Однако для зрелого промышленного использования ИИ, особенно в регулируемых отраслях и закрытых контурах, необходим комплексный подход и непрерывное тестирование. Это позволит перейти от «мы знаем, что риски существуют» к «мы активно ими управляем».
Комментарии (0)
Войдите или зарегистрируйтесь, чтобы оставить комментарий
Загрузка комментариев…