AI red teaming: как заказать проверку, которая что-то доказывает

Допустим, совет директоров прочитал новости об атаках на AI-ассистентов и попросил CISO «провести AI red teaming» до конца квартала. Через неделю на столе два ответа. Подрядчик А присылает образец отчёта: сотня скриншотов, на которых модель говорит то, чего говорить не должна. Подрядчик Б предлагает сначала две недели согласовывать цели, правила и среду и только потом начинать.

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

Этот сценарий условный. Однако он хорошо показывает главное: AI red teaming как услуга ценен не количеством «обходов», а тем, насколько проверяемо он отвечает на заранее согласованный вопрос о противнике.

Чем red teaming отличается от оценки безопасности

Цель вместо охвата

Оценка безопасности AI-продукта стремится к охвату. Она проходит по слоям системы — данным, модели, приложению, инструментам — и проверяет, держат ли меры защиты на каждой границе. Как выбирать такие рамки, мы разобрали в статье об оценке безопасности AI-продукта.

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

Поэтому полезный вопрос для red teaming звучит не «какие уязвимости есть в ассистенте», а, например, «может ли внешний пользователь без привилегий получить через ассистента данные другого клиента, и увидит ли это команда мониторинга».

Когда red teaming преждевременен

Red teaming имеет смысл, когда базовые меры защиты уже проверены. Если авторизация инструментов не тестировалась, а API ассистента отдаёт чужие данные по подменённому идентификатору, упражнение быстро найдёт эту дыру и потратит остаток бюджета на очевидное. В таком случае честнее сначала провести оценку безопасности, исправить найденное и только потом проверять, что сможет противник против уже укреплённой системы.

Второй признак преждевременности — отсутствие наблюдения. Если у системы нет журналов вызовов модели и инструментов, половина ценности red teaming, а именно проверка обнаружения, недоступна в принципе.

Согласованные adversarial-цели

Как сформулировать цель

Хорошая цель описывает результат, а не технику. «Попробовать prompt injection» — это техника. «Добиться, чтобы ассистент от имени пользователя А выполнил операцию над данными пользователя Б» — это результат, который можно проверить на стороне системы.

Примеры целей, сформулированных как результат, для условного продукта с ассистентом и базой знаний:

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

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

Модель нарушителя

Вместе с целью фиксируется, кто действует. Анонимный внешний пользователь? Зарегистрированный клиент? Сотрудник с доступом к базе знаний? Партнёр, чьи данные поступают в систему через интеграцию? От модели нарушителя зависят стартовые доступы, допустимые каналы воздействия и то, насколько реалистичен результат.

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

Что целью не является

Полезно явно записать, что не входит в цели. Генерация оскорбительного текста может быть отдельной задачей для команды по качеству и безопасности контента, но не обязательно целью проверки защищённости. Тестирование чужой инфраструктуры поставщика модели вне его правил — не цель. Нагрузка, способная остановить продакшн, — не цель, если её отдельно не согласовали. Чем точнее границы, тем меньше споров при приёмке результатов.

Допустимые действия и правила проведения

Разрешённое и запрещённое

Правила проведения — это документ, а не устная договорённость. В нём перечислены цели и системы в охвате, допустимые каналы воздействия (интерфейс ассистента, API, загрузка документов, письма в общий ящик, если он является источником данных), запрещённые действия и окна проведения работ.

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

Всё это возможно только при письменном разрешении владельца системы. Если модель или инструменты предоставлены третьими сторонами, нужно отдельно проверить, что их условия допускают такое тестирование.

Обращение с данными и находками

В ходе упражнения команда увидит запросы, ответы модели, фрагменты документов, иногда персональные данные. Правила должны определить, где эти материалы хранятся, кто к ним имеет доступ, как они передаются заказчику и когда удаляются. Отдельно стоит договориться, как оформляются и передаются промежуточные критичные находки: ждать финального отчёта, если обнаружен путь к данным всех клиентов, нельзя.

Условия остановки

Условия остановки отвечают на вопрос «что делать, если что-то пошло не так». Это может быть непредвиденное влияние на продакшн, доступ к данным, которые явно не входили в охват, обнаружение следов реального злоумышленника. Для каждого случая нужен контакт, канал связи и порядок действий. Стоп-кран, о котором знает только подрядчик, не работает.

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

Контроль среды

Где проводить упражнение

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

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

Тестовые учётные записи и данные

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

Если агент работает с инструментами через MCP или похожие протоколы, в охват среды входят и эти серверы: их права, токены и журналы. Как проверять такие серверы отдельно, разобрано в методике оценки MCP-серверов.

Фиксация версии и конфигурации

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

Агентные системы, где модель планирует и выполняет цепочки действий, требуют особенно аккуратной фиксации среды; подробнее — в руководстве по пентесту агентных AI-систем.

Проверяемые критерии успеха

Бинарные и статистические критерии

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

Для целей, связанных с поведением модели, критерий часто статистический. Модель может отказать девять раз и выполнить запрос на десятый. Поэтому формулировка «удалось в N из M попыток при такой-то конфигурации» информативнее, чем «удалось» или «не удалось». Число попыток и условия согласуются заранее, чтобы потом не спорить о том, сколько раз нужно было пробовать.

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

Недетерминизм и повторяемость

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

Наблюдение и восстановление

Что должна увидеть защита

Одно из главных отличий red teaming от оценки безопасности — проверка того, видит ли организация происходящее. Для AI-систем это значит: журналируются ли запросы и ответы модели с привязкой к пользователю, фиксируются ли вызовы инструментов с параметрами, есть ли сигналы на аномалии — резкий рост числа вызовов, обращения к данным другого клиента, необычные цепочки действий агента.

До начала упражнения стоит договориться, кто из защитной команды знает о нём. Если о red teaming знают все, проверяется только наличие журналов. Если не знает дежурная смена, проверяется ещё и реакция. Оба варианта легитимны, но выводы у них разные.

Восстановление после упражнения

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

Восстановление — это ещё и проверка. Если команда не может быстро найти и удалить внедрённый в базу знаний документ, это самостоятельная находка о зрелости процессов.

1. ЦельСформулировать результат нарушителя, актив и последствие для бизнеса, а также модель нарушителя.
2. ПравилаЗаписать допустимые действия, запреты, обращение с данными, окна работ и условия остановки.
3. СредаЗафиксировать модель, версию, конфигурацию, инструменты, тестовые учётные записи и мониторинг.
4. Попытки и наблюдениеВыполнять сценарии, фиксировать попытки и эффекты на стороне системы, сверять с журналами защиты.
5. Восстановление и выводыВернуть систему в известное состояние и описать результат с пределами применимости.

Как оценивать подрядчика

Зелёные и красные флаги

В феврале 2026 года в рамках OWASP GenAI Security Project вышли критерии оценки поставщиков услуг и инструментов AI red teaming. Документ помогает отличить содержательное состязательное тестирование от предложений, сведённых к обходу ограничений модели, и разделяет простые системы — чат-боты, RAG-приложения — и сложные, с агентами, вызывающими инструменты, MCP-архитектурами и многоагентными процессами. Ранее, в январе 2025 года, OWASP опубликовал руководство по red teaming генеративного AI, где предлагается целостный подход по четырём направлениям: оценка модели, тестирование реализации, проверка инфраструктуры и анализ поведения во время работы.

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

Отчёт как продукт

Отчёт red teaming — это то, что остаётся у заказчика после упражнения. В нём должны быть цели и модель нарушителя, правила и среда с версиями, хронология действий, достигнутые и недостигнутые цели с доказательствами, что увидела и чего не увидела защита, корневые причины, рекомендации и явный список того, что не проверялось. Находки прикладного уровня полезно привязывать к требованиям OWASP ASVS с указанием версии и к классам CWE: это делает их сопоставимыми с результатами других проверок и упрощает исправление.

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

Подрядчик должен также объяснить, как он обращается с материалами, полученными в ходе работ, и что из них хранится после сдачи отчёта.

Пределы выводов

Что можно утверждать после упражнения

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

Чего утверждать нельзя

Нельзя утверждать, что система «устойчива к атакам на AI». Недостигнутая цель означает, что её не удалось достичь в этих условиях, а не что это невозможно. Отказ модели выполнить действие не доказывает, что инструмент защищён авторизацией. Фильтр запросов, который остановил попытки команды, не является границей доступа. Системный промпт, который не удалось извлечь, всё равно не стоит считать секретом и хранить в нём чувствительные данные.

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

От отчёта к решениям

Куда идут находки

Находки должны попасть в процесс управления рисками, а не остаться отдельным документом. NIST AI RMF 1.0 строит управление AI-рисками вокруг четырёх функций — управлять, картировать, измерять, обращаться с рисками, — а профиль NIST AI 600-1 адаптирует эту рамку к генеративному AI. Red teaming естественно ложится в функцию измерения, но его результаты имеют смысл, только если по ним принимаются решения: кто владелец риска, какое исправление, к какому сроку, какой остаточный риск принимается.

Для находок прикладного уровня работает привычная логика: корневая причина по CWE, приоритизация с учётом активно эксплуатируемых классов слабостей, исправление класса дефекта, а не одного параметра.

Когда повторять

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

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