Безопасность ИИ-агентов: что обнаружили 38 исследователей при стресс-тестировании автономных систем ИИ

Проблема, о которой никто не хочет говорить

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

Исследовательский проект «Agents of Chaos», проведённый в феврале 2026 года, объединил 38 специалистов по безопасности для двухнедельного интенсивного упражнения по red teaming, сфокусированного именно на автономных ИИ-агентах. Их выводы подтверждают то, о чём подозревали многие команды безопасности: инструменты и фреймворки, которые мы используем для защиты традиционного ПО, фундаментально непригодны для агентных систем ИИ.

Почему ИИ-агенты ломаются иначе, чем обычное ПО

У традиционного ПО предсказуемые поверхности атак. SQL-инъекции, XSS, переполнение буфера — всё это хорошо изучено, хорошо задокументировано и хорошо защищено. ИИ-агенты привносят категорию отказов, которой не существует в обычных системах.

Проще говоря: ИИ-агент не просто обрабатывает входные данные — он интерпретирует их, рассуждает о них и затем действует на их основе. Именно на уровне рассуждений всё идёт не так.

Как отмечено в исследовании White Knight Labs, все протестированные ИИ-агенты демонстрировали схожие паттерны ответов в состязательных условиях. Большинство моделей были уязвимы к хорошо известной «атаке бабушки». Хотя все модели устояли перед инъекцией DAN (Do Anything Now), они не выдержали другие популярные варианты — Anti DAN, STAN, Developer Mode и другие. DeepSeek показал лучший результат среди них со средним баллом 4,8 из 10, что всё ещё ниже приемлемого уровня. Только Qwen3 успешно устоял перед джейлбрейком DUDE.

Это отрезвляющий результат. Самые базовые, общедоступные техники атак по-прежнему работают против продакшн-систем ИИ.

Пять режимов отказа, которые действительно имеют значение

1. Инъекция промптов остаётся нерешённой

Наиболее обсуждаемая уязвимость по-прежнему остаётся и наиболее эффективной. Исследователи обнаружили множество техник, которые стабильно обходят защитные механизмы ИИ-агентов:

• Поддельные границы промптов: вставка маркеров вроде <|system|>, <|user|> и <|endofprompt|>, имитирующих внутренние разделители промптов, заставляя модель воспринимать вводимые атакующим данные как системные инструкции.
• Нарративная инъекция: погружение ИИ в вымышленный сценарий с целью отвлечь его от исходных инструкций.
• Обход через кодирование: использование Leetspeak или нестандартных форматов кодирования для обхода валидации входных данных.

Согласно White Knight Labs, состязательные техники работают через многоуровневый фреймворк: намерения (цель атакующего), техники (метод исполнения), обходы (тактики для преодоления фильтров) и утилиты (вспомогательные инструменты для построения атаки). Такой структурированный подход означает, что атаки становятся всё более систематизированными, а не менее.

Модели DeepSeek и Qwen3 также не выдержали тестирования на малопредставленных языках, обнажив слепые зоны в мультиязычном выравнивании. Если ваш агент обслуживает глобальную пользовательскую базу, ваша безопасность ровно настолько надёжна, насколько надёжна самая слабая языковая модель.

2. Эксплуатация инструментов — настоящая зона опасности

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

Честно говоря: фильтры безопасности на основе чёрных списков здесь не работают. Агент, которому сказали «не выполнять rm -rf», может быть подведён к достижению того же результата через последовательность по отдельности безобидных команд. Единственный надёжный подход — это модель белых списков: явно определять, что агент может делать, вместо попыток перечислить всё, чего он не должен.

Как сообщает SC Media, предприятиям нужны работающие в реальном времени контекстно-зависимые ограждения для каждого действия агента. Каждый вызов инструмента должен оцениваться до выполнения. Небезопасное или нарушающее политику поведение должно фиксироваться до наступления последствий. Скрытые многоэтапные атаки должны обнаруживаться с помощью контекстно-осведомлённого анализа.

3. Отравление памяти у персистентных агентов

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

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

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

4. Каскадные отказы в мультиагентных системах

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

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

5. Бесконечные циклы и исчерпание ресурсов

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

Что упускают традиционные средства безопасности

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

Как отмечает Help Net Security, средства защиты, такие как межсетевые экраны веб-приложений, полагаются на статические сигнатуры и неэффективны для ИИ-агентов, поскольку способность LLM обрабатывать естественный язык позволяет злоумышленникам создавать атаки, которые эти статические паттерны не могут обнаружить. Чтобы защитить ИИ-агента, нужно использовать ИИ для его защиты.

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

Архитектура защиты, которая действительно работает

На основе результатов исследовательского сообщества, защищаемая архитектура ИИ-агента требует нескольких уровней:

Уровень 1: Валидация входных данных с помощью ИИ

Статические входные фильтры ловят очевидные атаки. Оборонительный уровень на основе ИИ ловит тонкие — инъекции промптов, замаскированные под легитимные запросы, закодированные полезные нагрузки и попытки нарративной манипуляции.

Уровень 2: Авторизация вызовов инструментов

Каждое действие агента должно проходить через централизованную точку контроля. Help Net Security рекомендует устанавливать чёткое разграничение между «системными» инструкциями, «пользовательским» вводом и «сторонними» данными. Инструктивно настроенные LLM понимают это разделение, что может предотвратить атаки через манипуляцию промптами.

Подход Model Context Protocol (MCP) выглядит многообещающе в этом контексте. Согласно анализу на Medium, MCP обеспечивает стандартизированные границы, в которых каждое действие или запрос данных является явным и может быть централизованно авторизован или отклонён. Изоляция возможностей инструментов означает, что скомпрометированный уровень рассуждений не получает глобального доступа по умолчанию.

Уровень 3: Изолированное выполнение

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

Уровень 4: Непрерывный red teaming

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

Конкретные цифры: такие инструменты, как Mindgard, предлагают автоматизированное тестирование LLM, моделей изображений, аудиомоделей и мультимодальных систем, фокусируясь на уязвимостях времени выполнения, которые проявляются, когда системы ИИ реально работают. Promptfoo, опенсорсная альтернатива, автоматизирует создание и доставку состязательных промптов и сценарных атак против развёрнутых ИИ-агентов, интегрируясь непосредственно в CI/CD-пайплайны.

Набор инструментов для red teaming в 2026 году

Для команд, строящих собственную практику безопасности ИИ-агентов, вот как выглядит текущий ландшафт инструментов:

Общая черта всех эффективных инструментов, как отмечает Hackread, заключается в том, что они обучаются, адаптируются, рассуждают и сочетают техническую эксплуатацию с поведенческой изобретательностью. Успех измеряется не выполнением эксплойта, а отклонением поведения и непредвиденными результатами.

Дефицит компетенций — реальная проблема

Red teaming агентного ИИ фундаментально отличается от традиционного тестирования на проникновение. Вместо атаки на системы вы атакуете поведение ИИ-агента — выясняете, как заставить его сделать то, что он делать не должен. Как отмечают отраслевые комментаторы, спрос на этот набор навыков готов к взрывному росту, и почти никто пока не умеет этого делать.

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

Что это значит для вашего проекта

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

Три приоритета для любой команды, выпускающей ИИ-агентов:

1. Рассматривайте агентов как привилегированных инсайдеров, а не как программные компоненты. Им необходимы те же контроли, надзор и непрерывное состязательное тестирование, что и операторам-людям с повышенным доступом. Как заключает анализ на Medium, защитные механизмы вроде MCP, контрольных точек с участием человека и неизменяемых журналов аудита больше не являются опциональными — они основополагающие.

2. Внедряйте доступ к инструментам на основе белых списков, а не чёрных. Чётко определяйте, что именно может делать каждый агент. Каждый вызов инструмента должен быть ограничен по области, залогирован и доступен для ревью. Централизованная точка контроля между агентами и всем, к чему они прикасаются, с полной наблюдаемостью за диалогами, вызовами инструментов и траекториями принятия решений.

3. Сделайте red teaming непрерывным, а не разовым аудитом. Поведение агента меняется с каждым обновлением модели, изменением промпта и новой интеграцией. По данным Gigamon, мы движемся к автономной гонке вооружений, в которой и атакующие, и защитники развёртывают всё более изощрённых ИИ-агентов. Организации, встраивающие безопасность жизненного цикла в архитектуру своих агентов, снизят риски и будут двигаться быстрее.

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

Агенты уже развёрнуты. Вопрос в том, успела ли ваша безопасность за ними.

Часто задаваемые вопросы

Как ИИ-агенты могут злоупотреблять легитимными инструментами, такими как пересылка почты, для утечки конфиденциальных данных?

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

Почему ИИ-агенты застревают в бесконечных циклах в мультиагентных системах?

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

Какие векторы атак работают против ИИ-агентов с постоянной памятью?

Атакующие могут внедрять вводящую в заблуждение или вредоносную информацию в ходе нескольких сессий, постепенно отравляя память агента и изменяя его будущее поведение. Они также могут извлекать конфиденциальную информацию, которую агент сохранил из предыдущих взаимодействий с другими пользователями. Меры защиты включают сегментацию памяти по пользователям, регулярный аудит памяти и политики истечения срока хранения контекста.

Почему фильтры безопасности на основе чёрных списков не работают для выполнения shell-команд ИИ-агентами?

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