Ред-тиминг ИИ: что проверяет ред-тим и что остаётся после него

Большинство проектов по red teaming ИИ оценивают по не тому артефакту. Неделя работы даёт презентацию, в презентации говорится, что ассистента можно склонить написать фишинговое письмо, и потом никто не может сказать, было ли поведение воспроизводимым, насколько серьёзным оно было или какой контроль его остановил бы. У этой дисциплины есть настоящий результат, и это не презентация: это набор выводов, которые выдерживают повторный запуск, каждый из них привязан к пересечённой границе и к доказательствам, которые её пересекли. Такова же и структура записей, которые ведёт the AI incident archive — 400 записей, охватывающих период с декабря 2024 года по октябрь 2026 года, взятых из 743 разных источников, и вердикт по каждой из них о том, был ли кому-то фактически причинён вред.

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

Основной вопрос: кому принадлежит тест

Прежде чем говорить об охвате, возникает вопрос о том, кто проводит учения и против чего. Microsoft публикует одну из наиболее полных открытых позиций по этому вопросу, и её стоит читать как карту, а не как страницу продукта. Её центр AI Red Team отделяет концепцию ред-тиминга ИИ от практического руководства, а затем выстраивает эту практику в порядке, который сам по себе является аргументом: обзор, затем руководство по созданию ред-команды для LLM, затем справочные материалы — планку багов для триажа атак на системы машинного обучения, таксономию отказов машинного обучения, модель разделённой ответственности и руководство по моделированию угроз для разработчиков.

Прочитайте последовательность — и методология вытекает сама. Таксономия определяет, что считается сбоем. Порог багов определяет, какие из этих сбоев стоит исправлять. Модель разделяемой ответственности определяет, кто за это отвечает, когда это обнаружено. Моделирование угроз определяет, где искать дальше. Без этих четырёх red team порождает анекдоты с прикрученной колонкой критичности, а колонка критичности — это то, что тестировщик почувствовал в тот день.

Открытый фреймворк автоматизации Microsoft, PyRIT, стоит на той же полке, и именно это соседство полезно. Оркестрационный набор — не методология; это то, на что вы направляете атаку, когда таксономия и планка багов уже существуют. Команды, которые начинают с фреймворка, обычно приходят к большому корпусу подсказок и отсутствию способа ранжировать результаты.

Две красные команды, два разных вопроса

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

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

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

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

Какой становится поверхность атаки, когда у модели появляются инструменты

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

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

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

Почему расшифровка — это не вывод

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

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

Четыре аспекта, в которых ред-тиминг ИИ отличается от ред-тиминга сетей

Команды, приходящие из сетевой или прикладной безопасности, приносят хорошие инстинкты и четыре неверных допущения.

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

• Целевой объект недетерминирован. Один и тот же вход может сработать во вторник и не сработать в среду. Это нарушает стандарт доказательства «одного чистого воспроизведения» и вынуждает сообщать о частотах.

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

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

Как определить рамки первого проекта

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

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

Что добавляет запись об инциденте

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

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

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