ML Red Teaming для LLM: можно ли обойтись open source-инструментами?

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

ML Red Teaming (AI Red Teaming) – это специализированная форма наступательного тестирования, при которой команда имитирует действия реальных злоумышленников против систем машинного обучения, больших языковых моделей, генеративного ИИ и агентных систем. В отличие от классического пентеста, здесь цель не просто «взломать», а найти уязвимости, присущие именно ИИ-компонентам, оценить риск и повысить реальную устойчивость используемой ИИ-модели.

Цели ML Red Teaming:

• выявить реальные уязвимости до того, как это сделают злоумышленники,

• оценить устойчивость моделей и агентных систем к атакующим воздействиям,

• получить не теоретическую, а подтверждённую практическими атаками оценку риска,

• повысить доверие к ИИ-системам со стороны бизнеса и регуляторов,

• сформировать основу для построения эффективной защиты и мониторинга в SOC.

К основным задачам ML Red Teaming относится симуляция атак по техникам MITRE ATLAS, проверка устойчивости моделей к prompt-инъекциям и jailbreak, а также тестирование защиты от таких угроз, как извлечение модели и отравление данных. Отдельное внимание уделяется выявлению уязвимостей в агентных системах, в частности, в механизмах использования инструментов, работы с памятью и оркестрацией. Об этом и расскажем в данной статье. 

Начнем с методологий. При проведении ML Red Teaming их используется несколько:

• комбинация автоматизированного сканирования + ручного экспертного тестирования,

• многоагентные атаки (одна модель атакует, вторая судит, третья генерирует вариации),

• тестирование на разных уровнях зрелости: от простых prompt injection до сложных многошаговых атак на память, инструменты и оркестрацию агентов.

Для планирования атак в рамках 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, или open source-инструменты и фреймворки.

Самые известные open source-решения:

• Garak – быстрый широкий сканер уязвимостей LLM, содержит более 100 проб, имеет плагинную архитектуру и поддерживает множество моделей.

• Promptfoo – Red Teaming + evaluation + CI/CD-интеграция по OWASP и MITRE, удобный веб-интерфейс.

• PyRIT – глубокое enterprise-тестирование LLM и агентов, поддержка multi-turn атак.

• DeepTeam и аналоги – заточены под тестирование агентных систем.

Но!

PyRIT – это жесткая инфраструктурная привязка к Azure AI Foundry и он бесполезен в закрытом российском контуре. Garak / Promptfoo содержат только базовые лингвистические тесты, поэтому не пригодны для сложных семантических инъекций на кириллице и российских форматов ПДн.

Open source-инструменты отлично подходят для разовых исследований, но имеют серьёзные ограничения в реальной корпоративной среде, особенно в наших российских компаниях:

• только тестирование, без защиты в реальном времени: нашли уязвимость, а дальше сами руками настраиваете фильтры, правила и guardrails;

• высокие требования к экспертизе и ручной работе, т.к нужно самостоятельно выстраивать CI/CD-пайплайны, мониторинг и интеграцию на всём жизненном цикле модели;

• выявление + устранение уязвимостей: большинство open-source решений только детектят;

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

• отсутствие compliance, т.к. open source не закрывают требования регуляторов и не могут использоваться на объектах КИИ без существенной доработки;

• изолированность от SOC-процессов: нет готовых отчётов, удобной интеграции с SIEM/SOAR и мониторинга аномалий, при этом open-source инструменты обычно изолированы и требуют высокой экспертизы для интеграции;

• скорость реакции на новые угрозы зависит от комьюнити и вашей собственной экспертизы.

В результате многие приходят к выводу: open source – отличный инструмент для исследований, но для промышленной эксплуатации нужен комплексный подход, где тестирование тесно связано с реальной защитой.

Практика проведения сканирования: почему всё сложнее, чем кажется

Запустить сканер и посмотреть отчёт только верхушка айсберга. Главная сложность – оценить качество и полноту тестирования.

LLM работают стохастически или вариативно. Один и тот же вход при одинаковых параметрах может давать разные выходы. Поэтому даже при использовании одного и того же сканера необходимо делать несколько повторных прогонов. В одном запуске модель может «правильно» отреагировать и уязвимость не проявится. В другом – та же уязвимость всплывёт. Без статистического подхода вы рискуете получить ложное ощущение безопасности.

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

Рассмотрим классы атак, через которые нужно проверять ИИ-модели при сканировании, на примере INFERA AI.Firewall с встроенным модулем ML Red Teaming.

Существует довольно большое количество классов атак на LLM-модели. Специальных рекомендаций по подготовке данных для атак мы здесь не будем приводить, т.к. они достаточно стандартны. Наборы правил для сканирования широко доступны в открытом доступе. В решении INFERA AI.Firewall мы используем собственные правила, адаптированные под реальные корпоративные сценарии.

Итак, классы атак при сканировании ML Red Teaming:

1. Jailbreak и обход ограничений

Самый большой и опасный класс. Особенно критично для облачных сервисов и публичных чат-ботов. Через джейлбрейк злоумышленник может получить доступ к системному промпту, конфиденциальным данным или заставить модель работать в своих целях.

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

2. Prompt Injection

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

 3. Утечка данных и системного промпта

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

Сканер должен проверять именно те данные, с которыми работает модель в вашей организации (RAG-контекст, дообученные данные). Если тесты построены на абстрактной информации – модель просто не сможет «слить» то, чего у неё нет, а вы получите неверный результат тестирования. Поэтому сканер должен проверять данные, на которых обучена модель и с которыми она работает, только тогда результат тестирования можно будет считать релевантным.  

4. Токсичность и небезопасный контент

На текущий момент это самый запрашиваемый и активно используемый блок в сканере ML Red Teaming у заказчиков. Все опасаются возможной выдачи в публичную среду информации, которая может дискредитировать компанию. Сюда относятся ругательства, политические высказывания и т.п.

5. Галлюцинации и дезинформация

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

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

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

Важно учитывать специфику корпоративных LLM-систем. Например, чат-бот медицинской компании в соответствии с внутренними политиками безопасности должен отказываться от выполнения запросов на написание кода или решения математических задач. В таких случаях «модель-судья» расценивает отказ как корректное и безопасное поведение и не квалифицирует его как уязвимость.

6. Многошаговые атаки

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

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

7. Атаки на корпоративные данные

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

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

Результат работы сканера ML Red Teaming отправляется в SOC или ASOC/ ASPM, в зависимости от того, в каком подразделении компания использует ИИ. Отчёт содержит: тип атаки, название техники, текст атаки и ответ модели. Эти данные напрямую используются для донастройки AI.Firewall, обновления правил и политик. Именно поэтому важно чтобы используемый AI/LLM Firewall содержал сканер ML Red Teaming, чтобы все работало как единый механизм.

В итоге:

• INFERA ML Red Teaming + AI.Firewall это одна связанная система: нашли уязвимость и сразу применили защиту (фильтрация, блокировка, маскировка данных, контроль доступа).

• Встроена возможность не только находить, но и устранять риски через политики в AI.Firewall: обновление правил, ограничение доступа, блокировка опасных паттернов.

• Все реализовано с учетом российской специфики.

• Модуль INFERA автоматически сканирует модели на этапах разработки, внедрения и эксплуатации без постоянного участия специалистов по ML.

• Реализована поддержка нескольких LLM одновременно, можно использовать различные схемы подключения (Proxy, API Gateway, Guardrails), а готовые отчёты покажут статистику по всем взаимодействиям пользователей с ИИ.

Почему классические подходы Red Teaming не работают для ИИ

Классические методы Red Teaming создавались для детерминированных систем, где поведение предсказуемо, а поверхность атаки ограничена сетями, приложениями и инфраструктурой. В случае с ML- и LLM-системами всё меняется принципиально. Поведение моделей носит вероятностный, стохастический характер. Поверхность атаки расширяется до моделей, данных, промптов, RAG-компонентов и агентных систем.

Требования к специалистам также возрастают: вместо классической комбинации сетевой безопасности и AppSec необходимы глубокие знания в области машинного обучения, информационной безопасности и специфического Red Team-мышления. Тестирование перестаёт быть периодическим мероприятием и должно проводиться непрерывно. Критерии успеха смещаются от бинарной оценки «эксплойт достигнут или нет» к статистическим показателям эффективности атак. Меры реагирования уже не ограничиваются патчами и изменениями конфигурации, они включают переобучение моделей, внедрение guardrails и пересмотр архитектуры решений.

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

Практические рекомендации

Для CISO:

• включить ML Red Teaming в программу Red Team / Purple Team,

• регулярно анализировать MITRE ATLAS и оценивать риски,

• внедрять инструменты защиты AI/LLM Firewall.

Для SOC:

• добавить контроль за использованием LLM- и ИИ-моделей в SIEM / SOAR,

• обучить аналитиков базовым техникам prompt-инъекций и jailbreak,

• создать план тестирования по топ-техникам MITRE ATLAS,

• использовать сканеры ML Red Teaming и интегрировать их результаты в процессы реагирования.

Open source-инструменты для проведения ML Red Teaming – отличная отправная точка для экспериментов и развития экспертизы внутри команды, но для зрелого промышленного использования ИИ, особенно в регулируемых отраслях и закрытых контурах, требуется комплексный подход и непрерывное тестирование. Только тогда можно перейти от «мы знаем, что риски есть» к «мы реально ими управляем».