Чистый отчет о джейлбрейке означает лишь то, что ваша система сопротивлялась атакам, записанным до начала тестирования. Он не говорит вам, что произойдет, когда злоумышленник адаптируется после отказа, скроет инструкцию внутри ответа инструмента или заставит агента действовать на основе данных, которым он никогда не должен был доверять. Статический набор тестов не может этого подсказать, поскольку он проверяет только то, что есть в списке.
Выявление подобных сбоев требует непрерывного состязательного тестирования: входных данных или цепочек входных данных, созданных для того, чтобы заставить ИИ-систему совершить ошибку, например, допустить утечку данных, которые не следовало раскрывать, выполнить нежелательное действие или выдать контент, который должен был быть заблокирован. Для команд безопасности важно не только то, что обнаруживает тест, но и где он выполняется. Наше решение работает прямо в вашей собственной среде, поэтому промпты и данные остаются в пределах вашего периметра безопасности.
Мы берем известные паттерны атак и мутируем их в тысячи вариаций, чтобы увидеть, какие из них проскальзывают мимо защиты, а затем передаем адаптивную работу автономным агентам. Они продолжают действовать после того, как система перестает давать сбои предсказуемым образом: меняют тактику после отказа — то, чего не умеет фиксированный скрипт. Ниже мы подробно рассмотрим, где останавливается статическая библиотека, как с этого места начинают действовать наши агенты, почему тестирование должно охватывать не только текст (включая изображения, аудио и вызовы инструментов) и как каждый найденный уязвимый элемент оценивается по стандартам соответствия вашей команды.
Библиотека паттернов атак как отправная точка
Любое тестирование начинается с библиотеки известных паттернов атак. Она включает варианты инъекций промптов, шаблоны джейлбрейка (оформление под ролевую игру, гипотетические обертки, попытки перехвата инструкций) и приемы кодирования, предназначенные для обхода ключевых фильтров. Мы постоянно обновляем ее по мере появления новых техник в исследованиях, на практике или в прошлых проектах, где сработал новый подход. Библиотека структурирована на основе каталога состязательных тактик и техник ИИ от MITRE ATLAS, что позволяет нам отслеживать покрытие системно, а не бессистемно.
Но статическая библиотека имеет свои пределы. Тестирование, выявляющее самые серьезные пробелы, основано на политиках. Тесты настраиваются под сценарии рисков и модель угроз конкретного развертывания, а не под стандартный список, который запускается одинаково против любой цели. Глобальному потребительскому бренду необходимо тестировать своего чат-бота на языках, на которых говорят его клиенты, а не только на английском. Для агента в сфере финансовых услуг требуются иные сценарии, чем для ритейл-агента.
Запуск статической библиотеки — это лишь база. Система, которая успешно проходит каждый паттерн в ней, доказала лишь свою безопасность от атак, существовавших на момент последнего обновления библиотеки.
Автономные агенты берут на себя адаптивную работу
Именно на это уходит большая часть нашего инженерного времени. Этот процесс напоминает действия квалифицированного специалиста из команды red team, но выполняется непрерывно, параллельно и в машинном масштабе.
Автономный агент для red-teaming не выполняет фиксированный скрипт. Он формирует рабочую гипотезу о том, где цель уязвима, тестирует ее, считывает результат и обновляет гипотезу перед тем, как решить, что делать дальше. Промпт, который вызывает частичное раскрытие информации, уклончивый ответ вместо четкого отказа или защитный механизм, срабатывающий на третьем предложении абзаца, а не на первом, — все это становится информацией, которую агент использует для создания более точного последующего запроса.
Несколько факторов кардинально отличают этот подход от обычного фаззинга:
- Переключение стратегии прямо во время сессии. Допустим, агент просит бота техподдержки раскрыть свой системный промпт и получает прямой отказ. Фаззер (который генерирует тысячи вариаций известных промптов атак, чтобы проверить, какие из них проскользнут) стал бы повторять тот же запрос другими словами. Агент вместо этого меняет тактику. Он может замаскировать запрос под ролевую игру или начать многошаговый диалог с безобидных вопросов и постепенно повышать ставки. Если один подход дает частичный ответ, агент продолжает копать в этом направлении. Если нет — переходит к другому.
- Память сеанса. Агент отслеживает, что он уже попробовал против конкретной цели в рамках одной проверки, поэтому не повторяет неудачные подходы и не тратит время на повторное открытие одного и того же тупика разными способами.
- Параллельное исследование. Несколько потоков агентов одновременно преследуют разные гипотезы против одной и той же цели: один исследует тему утечки данных, другой зондирует поведение при вызове инструментов, третий отрабатывает многошаговую манипуляцию. Таким образом, тестирование охватывает сразу несколько векторов атак, не дожидаясь исчерпания одной стратегии перед началом следующей.
- Самокритика перед эскалацией. Прежде чем результат будет помечен как реальная уязвимость, агент оценивает собственный вывод: был ли это действительно обход защиты или просто ответ, который выглядит подозрительно, но не пересекает границу, проверяемую тестом. Именно это защищает адаптивную систему от заваливания отчетов ложными срабатываниями, чем часто грешит обычный фаззинг.
- Связывание через разные интерфейсы. То, что агент узнает при прямом зондировании модели, может подсказать, как исследовать инструменты и данные, к которым у этой модели есть доступ, и наоборот. Слабое место, обнаруженное в синтаксическом анализе метаданных инструмента, может повлиять на следующую попытку на уровне промпта, а то, что сработало на уровне промпта, может быть использовано повторно в качестве полезной нагрузки, внедренной через ответ инструмента.
Ничто из этого не заменяет человеческое суждение — процесс идет под его контролем. Каждая уязвимость, обнаруженная агентом, проходит оценку баллов и проверку человеком до того, как попадет в отчет для клиента. Автономные агенты меняют объем и глубину по-настоящему новых попыток, которые совершаются до того, как результаты увидит человек, — а это та область, которую фиксированная библиотека, какой бы большой она ни была, никогда не смогла бы закрыть сама по себе.
Тестирование должно охватывать всю систему
Тест на джейлбрейк, использующий только текст, ничего не говорит о том, как система справляется с состязательным изображением, аудиофайлом со встроенной инструкцией или вызовом инструмента, который возвращает измененные данные обратно в контекст модели. Мультимодальным системам требуется тестирование, созданное для каждой модальности, а не текстовая методология, примененная ко всему остальному.
В ходе одного из тестов клиентского чат-бота в сфере гостеприимства было обнаружено, что модель может подтвердить несуществующее бронирование, порекомендовать объект конкурента вместо собственного и назвать разные цены на один и тот же номер отеля в зависимости от демографических сигналов в разговоре. Ничто из этого не является джейлбрейком в традиционном понимании. Это система, которая делает именно то, о чем попросил пользователь, но таким образом, который создает реальные репутационные, юридические и финансовые риски, не учтенные командой как «уязвимость безопасности».
Агентные системы порождают схожую проблему. Как только модель получает возможность вызывать инструменты, особенно через такие протоколы, как Model Context Protocol (MCP), поверхность тестирования расширяется от того, «что говорит модель», до того, «что ее можно заставить сделать». На практике выявляемые нами сбои группируются вокруг нескольких конкретных паттернов:
- Цепочки с «запутанным доверенным лицом» (confused-deputy): инструмент с широкими законными разрешениями вызывается на основе входных данных, которым модель изначально не должна была доверять.
- Отравление описаний инструментов: метаданные, которые инструмент передает модели (его имя, описание, параметры), сами по себе являются вектором инъекции, поскольку модель считывает эти метаданные как контекст.
- Непрямая инъекция через вывод инструмента: вызов инструмента возвращает данные из ненадежного источника, и эти данные содержат инструкции, которым затем следует модель.
- Избыточные права доступа: инструмент работает в точном соответствии с назначением, но ему предоставлено гораздо больше прав, чем требовалось для задачи, что превращает незначительную ошибку на уровне промпта в серьезную проблему на уровне действий.
Это уровень, на котором мы сосредоточили большую часть нашей разработки агентов в последнее время. Наши агенты исследуют описания инструментов, внедряют состязательный контент в ответы инструментов и отслеживают, передает ли модель ненадежные данные в последующий вызов инструмента без проверки, адаптируя каждый следующий шаг в зависимости от того, что только что сделала цель. Это та же базовая возможность, которая обнаружила уязвимости в 73% из 25 000 серверов MCP, оцененных нами за двухмесячный период, охватывающий более 268 000 просканированных инструментов — реальное доказательство того, что эта поверхность атаки недостаточно определена во всей экосистеме, а не только в изолированных системах.
Каждая находка оценивается
Сам по себе необработанный список успешных атак не полезен ни клиенту, ни инженерной команде. Каждая находка оценивается по степени серьезности, классифицируется по типу сбоя и сопоставляется с системами соответствия требованиям, которые важны для клиента: системой управления рисками ИИ NIST, OWASP LLM Top 10 и Законом ЕС об ИИ.
Последовательная оценка — это то, что позволяет сравнивать одно тестирование с другим, а также повторно запускать тот же набор тестов для новой версии модели или перенастроенной конфигурации защитных барьеров, чтобы проверить, не открылся ли ранее закрытый пробел.
От лаборатории к платформе
Эта лаборатория и стоящие за ней автономные агенты обеспечивают безопасность ИИ и защитные барьеры в Anaconda Platform: red teaming по более чем 300 категориям атак перед выпуском, адаптивные агенты, которые выходят за рамки статической библиотеки, и та же система оценки и сопоставления с фреймворками, перенесенная в защитные барьеры времени выполнения, когда система уже запущена. Все это работает внутри вашей собственной среды, поэтому промпты и тестируемые данные остаются внутри вашего периметра безопасности.
Если вы решаете, где у вашего тестирования наибольший пробел, уровень вызова инструментов может стать следующей областью внимания для вашей команды. Узнайте больше.
Часто задаваемые вопросы
Как вы создаете состязательный тест для системы ИИ? Начиная с библиотеки известных паттернов атак, а затем передавая адаптивную работу автономным агентам red-teaming от Enkrypt AI, которые формируют гипотезы об уязвимостях цели, корректируют стратегию на основе каждого ответа и объединяют полученные знания в более точные последующие попытки.
Чем автономные агенты red-teaming отличаются от более масштабного фаззинга? Фаззинг мутирует и запускает известные паттерны в больших объемах, но каждая попытка независима от предыдущей. Автономные агенты сохраняют память на протяжении сессии, меняют стратегию, когда один подход заходит в тупик, запускают несколько гипотез параллельно и критически оценивают свои собственные результаты перед тем, как пометить находку — это адаптивная глубина, которой фиксированная библиотека паттернов сама по себе достичь не может. Узнайте больше.
Почему системы MCP и вызова инструментов сложнее тестировать, чем обычный чат-бот? Поверхность атаки смещается с того, что говорит модель, на то, что ее можно заставить сделать. Конкретные паттерны включают цепочки «запутанного заместителя» (confused-deputy), отравление описаний инструментов, непрямую инъекцию через вывод инструмента и избыточные права доступа к инструментам — ни один из них не проявляется при тестировании джейлбрейка только текстом.
Как оцениваются результаты red-teaming? Находки оцениваются по степени серьезности и классифицируются по типу сбоя. Базовые методы атак структурированы в соответствии с таксономией тактик состязательного ИИ MITRE ATLAS, а сами находки сопоставляются с системами соответствия требованиям, такими как NIST AI RMF, OWASP LLM Top 10 и Закон ЕС об ИИ, поэтому результаты являются одновременно технически исчерпывающими и непосредственно применимыми для команды по обеспечению соответствия требованиям.
