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