AI Red Teaming для LLM‑продукта начинается с понимания простой вещи: модель почти никогда не является единственной точкой риска. Риск живёт в системе вокруг неё - в том, какие данные подмешиваются в контекст, какие инструменты доступны, как устроены права, и как ответы превращаются в действия.
Возьмём типичный пример: внутренний помощник для службы поддержки. Он читает обращения клиентов, подтягивает подсказки из базы знаний и иногда готовит черновик ответа. Важно то, что такой помощник работает не в вакууме: он получает на вход тексты от пользователей, видит внутренние документы и может взаимодействовать с корпоративными системами. Поэтому тестирование здесь - это не про качество генерации текста, а про безопасность всей цепочки: какие данные помощник способен увидеть, чему он доверяет и какие действия может выполнить по чужой подсказке.
Отличия от классического пентеста
Классический пентест ищет уязвимости в реализации: ошибки авторизации, неверную обработку ввода, слабые конфигурации, опасные зависимости. В LLM‑сервисе ущерб может возникнуть без явного бага в коде. Часто слабое место появляется на границе смыслов: текст считался данными, но стал инструкцией, а модель решила, что ей действительно нужно этому следовать.Есть и отличие по воспроизводимости. Многое в LLM‑поведении читаемо, поэтому методология обязана опираться на устойчивые паттерны и повторяемые сценарии, а не на один удачный прогон. Это влияет и на отчётность: важны условия, контекст, конфигурация, а не только один “скрин с ответом”.
Scoping и методология
Scoping в AI red team - это наша практическая опора. Он нужен не ради отчёта, а чтобы заранее определить границы теста и критерии успеха: что считается компрометацией, какие активы защищаются, какие действия недопустимы, какие данные можно трогать только в тестовом виде. Без этих договорённостей редтим быстро превращается в спор о том, нормально ли конкретное “странное” поведение модели.Что входит в scope
Scope разумно описывать как карту системы. Для условного помощника саппорта это включает входные каналы (чат, импорт тикета, почта), системные инструкции и шаблоны, контекстные источники (база знаний, вложения, история диалога, память), инструменты (CRM, статусы тикетов, черновики писем) и выходные каналы (UI‑рендеринг, ссылки, логирование, телеметрия). Особое внимание стоит уделять тому, где внешний текст попадает внутрь контекста, потому что именно там часто рождаются косвенные инъекции.В scope полезно сразу прописывать границы ответственности. Обычно тестируется безопасность продукта при заданной модели и заданной архитектуре, а не абстрактная “надёжность” самой модели как исследовательского объекта. Зато всё, что относится к маршрутизации запросов, фильтрации документов в retrieval, правам инструментов и контролю действий, обязательно должно считаться частью тестируемой поверхности.
Threat model для LLM
Threat model удобно строить от активов и потоков данных. Сначала фиксируются активы: персональные данные клиентов, внутренние документы, ключи и токены, системные инструкции, сведения об инфраструктуре, доступы к внутренним API. Затем описываются потоки: откуда данные приходят, где и в каком виде сохраняются, куда уходят, какие роли имеют доступ.Поверх этого слоя добавляются LLM‑специфичные угрозы. Ключевой класс - инъекции через текст, когда атакующий пытается сместить приоритеты и заставить систему следовать недоверенным инструкциям. Причём критично учитывать косвенный вариант: вредная инструкция может оказаться в документе, письме или странице базы знаний, которую система сама подгрузит в контекст как “помогающий материал”. В RAG‑сценариях это особенно опасно: злоумышленнику достаточно внедриться в контентный слой, а не ломиться в интерфейс.
Rules of engagement
Правила engagement - это способ сделать тест безопасным и юридически чистым. В них фиксируется, какие типы атак разрешены (например, попытки обойти ограничения, попытки спровоцировать tool‑вызовы, попытки утечек), а какие запрещены (реальные платежи, массовые рассылки, удаление данных, агрессивная нагрузка). Там же описывается подход к чувствительным данным: тестовые аккаунты, тестовые документы, канарейки и маркеры вместо реальных секретов. И обязательно - формат доказательств: идентификаторы запросов, логи, условия, при которых сценарий стабильно воспроизводится.
Техники атак
Атаки на LLM‑продукт редко бывают одиночными. Обычно это цепочка: подготовить контекст, проверить границы, закрепиться в поведении системы, затем довести до утечки или до действия. Ниже техники описаны так, чтобы не превращать текст в набор “волшебных” промптов, но сохранить механику и инженерную проверяемость.Direct prompt injection
Direct prompt injection - это попытка заставить модель игнорировать ограничения и правила, заданные системными инструкциями. В условном помощнике саппорта это часто выглядит как давление на роль и приоритет: просьба действовать “как админ”, “как сотрудник”, “как внутренний консультант”, либо требование выполнить действие, даже если оно запрещено политикой.Тестировать стоит не только факт отказа. Намного важнее то, что происходит при частичном провале: модель может отказаться явно, но при этом пересказать внутренний документ так, что чувствительные детали всё равно окажутся в тексте. Либо модель может начать подсказывать, где лежит информация и как её добыть, переводя атаку из прямой в организационную.
Indirect prompt injection
Косвенная инъекция начинается там, где продукт подмешивает внешние данные в контекст и не различает, что это данные, а не инструкции. Условный пример: RAG‑бот суммаризирует страницу вики, и на этой странице спрятан блок текста, который выглядит как служебная пометка или системный комментарий. Модель “видит” этот текст, и если архитектура не защищена, начинает следовать ему.Практический тест строится как проверка доверенных и недоверенных источников. Создаётся документ‑приманка в одном из источников, которые попадают в retrieval, затем модель получает обычную задачу суммаризации или подготовки ответа, а успех фиксируется по факту: смог ли недоверенный контент повлиять на поведение так, будто он имеет высокий приоритет. Самая ценная находка здесь - место, где система вставляет retrieved‑фрагменты без явной маркировки происхождения и тем самым стирает границу доверия.
Jailbreak techniques
Jailbreak полезно рассматривать как промежуточный этап. Сам по себе выход за рамки политики может быть “контентным” риском, но в продуктовом контуре он часто становится усилителем других атак: облегчает раскрытие системных инструкций, повышает готовность модели обсуждать внутреннюю конфигурацию, снижает сопротивление опасным действиям.Поэтому проверка jailbreak должна отвечать на три вопроса. Насколько устойчиво нарушение, насколько глубоко оно уходит в систему, и можно ли превратить его в практический ущерб. Параллельно стоит проверять обратную проблему: чрезмерно жёсткие guardrails иногда блокируют нормальные запросы, и пользователи начинают искать обходы - это риск, который со временем превращается в эксплуатационный.
Data exfiltration
Экcфильтрация в LLM‑продукте часто начинается с малого. Один фрагмент внутреннего документа, один абзац из карточки клиента, кусок системной инструкции, идентификатор внутреннего сервиса - и атакующий уже получил материал для следующей фазы.Условный кейс: помощник саппорта формирует ответ и добавляет “полезные цитаты” из базы знаний. Если retrieval не фильтрует документы по уровню доступа пользователя, модель может процитировать внутреннюю статью, которую пользователь никогда не должен видеть. Это почти всегда архитектурная проблема: неправильная фильтрация и неправильная политика доступа на этапе retrieval, а не “плохая” модель.
Тестировать стоит утечки из контекста (скрытые инструкции, история, память), из retrieval (документы не того уровня доступа, черновики, служебные заметки), а также утечки через каналы вокруг текста: ссылки, рендеринг, телеметрию и логи. Даже если модель формально не выдаёт секрет, система может выдать его в артефактах обработки.
Model manipulation
Манипуляция моделью в продуктовом смысле - это управляемое смещение решения. Иногда атакующему не нужно добиваться запрещённого действия напрямую; достаточно подменить исходные предпосылки, на которых система принимает решения.Условный пример: агент для CRM делает резюме по клиенту и предлагает следующий шаг менеджеру. В исходных данных появляется заметка, которая выглядит как комментарий руководителя и утверждает, что клиент уже прошёл проверку, хотя это не так. Модель принимает это как факт и рекомендует действие, которое запускает нежелательный процесс. В такой атаке важно проверить, какие источники считаются более авторитетными, можно ли подделать внешний вид доверенного источника, и есть ли независимая верификация критичных утверждений вне модели.
Инструментарий
Инструменты нужны, чтобы ручные находки становились воспроизводимыми проверками. Хороший red team оставляет после себя не только текст отчёта, но и набор сценариев, которые можно гонять снова после изменений промптов, retrieval‑логики и фильтров.Garak удобен как широкая сетка пробников, которая помогает быстро просканировать типовые классы нежелательного поведения и затем повторять прогон как регрессию. PyRIT полезен там, где нужен итеративный подбор траектории атаки: следующий шаг зависит от ответа системы, и автоматизация экономит время. PromptFoo воспринимается как каркас для тестов: в нём проще хранить набор проверок, запускать их в CI и сравнивать результаты между версиями. Кастомные скрипты почти неизбежны, потому что у каждого продукта своя схема данных, свои источники контента, свои интеграции и своя телеметрия; они особенно нужны для генерации приманок под indirect injection и для сбора доказательств воспроизводимости.
Если хочется понять, почему без кода невозможно стабильно автоматизировать проверки и собирать артефакты для отчёта, стоит прочитать материал о роли программирования в пентесте и практических сценариях автоматизации.
Обход защитных механизмов
Guardrails часто строятся как фильтрация входа и выхода. На практике обходы ломают не фильтр, а контекст: меняют приоритеты, смешивают роли, размывают границы между данными и инструкциями. Если у продукта нет чётких границ доверия и контроля прав инструментов, фильтрация начинает работать как косметический слой.Encoding tricks
Encoding‑приёмы проявляются там, где система по‑разному нормализует текст на разных этапах обработки. В одном месте текст декодируется, в другом фильтруется, в третьем склеивается с другими блоками, и в результате опасная инструкция появляется только на позднем этапе. Инженерно это проверяется системным перебором упаковок и фиксацией не только финального ответа модели, но и промежуточных артефактов: что попало в retrieval, что реально ушло в prompt, какие аргументы сформировались для tool‑вызова, что оказалось в логах.Token smuggling
Этот класс чаще всего проявляется в системах со сложной сборкой промпта из нескольких блоков. Если границы между блоками с правилами, документами и историей диалога не маркированы и не защищены, часть контента может начать восприниматься как более приоритетная инструкция. В тесте полезнее всего не охотиться за редкими трюками, а делать методичный перебор: менять порядок блоков, объём истории, уровень шума, роли, а затем искать устойчивые случаи, где приоритеты “плывут”.Multi-turn attacks
Многоповоротные атаки ближе всего к реальности, потому что продукт живёт в диалоге и в цепочке действий. Сначала модель получает доверие и контекст, затем принимает спорные предпосылки, затем делает шаг, который без этого контекста не сделала бы.Условный кейс: агент для почты умеет создать черновик ответа. В начале диалога атакующий добивается более свободных правил поведения, затем подсовывает письмо, внутри которого спрятана косвенная инструкция добавить лишний получатель или включить скрытый блок текста, а финальным шагом просит просто сформировать черновик. Если у workflow нет явного подтверждения параметров действия, риск быстро становится практическим.
Типовые находки и severity
В LLM‑продуктах критичность почти всегда определяется двумя вопросами: можно ли превратить находку в действие с последствиями, и есть ли доступ к данным, которые не должны быть доступны. Самый тяжёлый класс - когда агент вызывает инструмент с реальными побочными эффектами без дополнительного подтверждения и с избыточными правами, а триггером может выступать недоверенный текст из письма или документа. Высокая критичность также у ситуаций, где retrieval подтягивает документы не того уровня доступа и модель раскрывает их содержимое, либо где раскрываются скрытые инструкции и конфигурация, упрощающие дальнейшие атаки. Средняя критичность чаще относится к устойчивым обходам политики без прямого доступа к данным и действиям, а низкая - к единичным сбоям формата и нестабильности фильтрации без влияния на безопасность.Remediation и отчётность
Ремедиация в LLM‑продуктах почти всегда требует инженерного изменения контуров доверия. Если модель имеет доступ к инструменту с широкими правами, переписывание системных инструкций даёт лишь иллюзию контроля. Поэтому рекомендации должны фиксировать не только что сказать модели, но и что запретить системе делать без проверок.Сначала выстраиваются границы доверия: недоверенный контент должен быть отделён как данные, а не как инструкции, и retrieved‑фрагменты должны явно маркироваться происхождением. Затем приводятся в порядок права: инструменты получают минимально необходимые разрешения, разделяются операции чтения и изменения, а критичные действия переводятся в режим с подтверждением человеком. Следом идёт политика на уровне данных: если документ нельзя показывать пользователю, он не должен попадать в retrieval для этого пользователя, и чувствительные данные не должны появляться в логах даже при ошибках. И наконец, любая серьёзная находка превращается в регрессионный тест, иначе она вернётся после следующего изменения промптов или RAG‑настроек.
Отчёт должен быть одновременно техническим и управленческим. Он описывает контекст продукта и интеграций, scope и ограничения, метод тестирования и покрытые классы атак. Каждая находка оформляется как воспроизводимый сценарий с условиями, фактическим результатом, оценкой ущерба и вероятности, уровнем критичности, и перечнем исправлений с критериями проверки. Отдельным приложением полезно хранить регрессионные кейсы и чек‑критерии готовности фикса, чтобы команда продукта могла быстро подтвердить, что исправление действительно работает.
Заключение
Сильный AI red team проверяет не интеллект модели, а дисциплину системы: где текст может управлять поведением, где недоверенные данные попадают в контекст, где агент получает слишком широкие права, и где отсутствуют подтверждения действий. Условные кейсы вроде саппорт‑ассистента, RAG‑бота по внутренней вики и агента для CRM хороши тем, что сразу заставляют думать в терминах архитектуры, а не трюков с промптами. Когда находки превращаются в регрессионные тесты и инженерные изменения контуров доверия, редтим перестаёт быть разовой акцией и становится способом удерживать безопасность продукта на траектории развития.Если вам сама по себе интересна тема пентеста и хотите изучить весь цикл пентеста - от разведки и эксплуатации до отчёта и практики в проектах - будет полезна программа обучения по тестированию на проникновение в информационные системы.
Вложения
Последнее редактирование:
