RIFT-Bench: как проверять безопасность AI-агентов

По состоянию на 24 июня 2026 года RIFT-Bench — это свежий arXiv-препринт Fujitsu Research о динамическом red teaming для agentic AI systems. Его идея простая: проверять не только ответ модели на вредный prompt, а всю агентную систему — код, инструменты, память, внешние ресурсы, действия и то, как защита влияет на полезность.

Это не «новый отраслевой стандарт» и не доказательство, что все AI-агенты небезопасны. Работа важна другим: она показывает, как можно сделать проверку безопасности переносимой между разными агентными архитектурами. Для команд, которые уже подключают агентов к почте, CRM, коду, поиску или внутренним базам, это гораздо ближе к реальности, чем обычный jailbreak-тест в одном чате.

Что такое RIFT-Bench

RIFT-Bench — методология динамического red teaming для AI-агентов, где система сначала описывается как граф, а затем проверяется адаптивными атаками в двух фазах: Discovery и Scanning. Препринт RIFT-Bench: Dynamic Red-teaming For Agentic AI Systems был отправлен на arXiv 22 июня 2026 года. Авторы связаны с Fujitsu Research of Europe и Fujitsu Research of India.

Главная идея RIFT-Bench — проверять не только текстовый ответ модели, а всю агентную систему: её структуру, инструменты, действия и устойчивость mitigations. Поэтому в центре работы не отдельный prompt, а NodeSpec: иерархическое представление системы с компонентами, связями, интерфейсами, конфигурацией, источниками кода и возможностями вроде доступа к данным или выполнения кода.

Именно поэтому RIFT-Bench хорошо дополняет материалы про prompt injection и supply-chain атаки на LLM-агентов. Prompt injection остаётся важным риском, но агент с инструментами ломается не только через текст. Он может вызвать не тот инструмент, прочитать не тот ресурс, изменить состояние среды или раскрыть данные через промежуточное действие.

Discovery и Scanning: две фазы проверки

В фазе Discovery RIFT-Bench получает кодовую базу и точку входа агентной системы. Затем Structure Identifier собирает ресурсы, строит граф компонентов, валидирует его статически и через исполнение, после чего дополняет узлы деталями: где компонент объявлен в коде, какие у него входы и выходы, какие инструменты и разрешения он использует.

В фазе Scanning эта структура становится картой атаки. RIFT-Bench фильтрует probes по применимости, генерирует конкретные попытки атаки, встраивает их в систему, запускает выполнение в изолированной среде и оценивает trace. Это важная деталь: если агент не произнёс вредную фразу, но всё равно вызвал опасный инструмент или изменил ресурс, такая ошибка не должна исчезнуть из отчёта.

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

Что именно проверили авторы

В препринте заявлен benchmark из 45 агентных систем и 105 adversarial probes. Четыре домена — travel, finance, medical и personal assistant — собраны в контролируемую матрицу: три фреймворка, три архитектуры и девять систем на домен. Пятый домен, wild, добавляет девять более разнородных систем: с выполнением кода, памятью, внешними реализациями и нестандартными агентными паттернами.

Для атак авторы используют пять поверхностей и десять attack suites. В тексте также указано, что 105 probes разворачиваются в более чем 10 000 отдельных attack tests. Метрик четыре: Attack Activation Rate, Attack Success Rate, Execution Drift и Utility. Utility считают только там, где есть ground truth для пользовательской задачи, например в personal assistant домене.

Важный вывод из раздела результатов: высокая активация атаки сама по себе ещё не равна успешной компрометации. Поэтому RIFT-Bench разделяет AAR и ASR. AAR отвечает на вопрос «атака вообще была задействована во время выполнения?», ASR — «добилась ли она цели?». Это практичнее, чем единая оценка «агент сломан / не сломан».

Mitigations надо оценивать вместе с полезностью

Самый полезный для практиков фрагмент — не сама цифра ASR, а демонстрация компромисса. RIFT-Bench позволяет сравнивать защиты не только по тому, как они снижают успешность атаки, но и по тому, насколько они ломают нормальную задачу.

На Figure 4 видно: без защиты ASR равен 0,276, а Utility — 0,440. Простые защиты снижают ASR примерно до 0,214-0,221. Но эффект разный: Description Removing даёт Utility 0,339, тогда как Prompt Sandwiching остаётся ближе к базовой полезности — 0,432. Это не универсальный рецепт, а хороший сигнал: защиту агента нельзя оценивать только по падению атак. Если агент перестал нормально выполнять работу, победа может оказаться бумажной.

Microsoft в документации AI Red Teaming Agent тоже разделяет scanning, evaluation и reporting, а для агентных рисков прямо пишет, что надо смотреть не только generated output, но и tool outputs. NIST CAISI в марте 2026 года отдельно подчёркивал, что agent hijacking растёт там, где агент обрабатывает внешние источники — письма, сайты, репозитории кода — и может выполнить вредные действия. RIFT-Bench попадает ровно в этот сдвиг: от промптов к поведению системы.

Что это значит для команд, запускающих AI-агентов

Если агент просто отвечает в чате без инструментов, RIFT-Bench может выглядеть избыточным. Но как только агент получает доступ к внутренним документам, браузеру, API, файловой системе или рабочим инструментам, проверка должна стать системной.

• Сначала описывайте структуру агента: какие компоненты есть, где инструменты, память, внешние источники и привилегированные действия.
• Проверяйте не только ответ модели, но и trace: tool calls, изменения состояния, доступ к ресурсам, побочные эффекты и логи.
• Разводите метрики: активация атаки, успех атаки, drift поведения и полезность задачи отвечают на разные вопросы.
• Запускайте атаки в изолированной среде или «purple» окружении, а не на боевых ресурсах.
• Проверяйте mitigations на регрессию: защита, которая убирает риск ценой поломки рабочего сценария, не готова к боевому запуску.
• Не сводите agent security к системному prompt. Prompt нужен, но он не заменяет контроль инструментов, прав, данных и трассировки.

Похожий сдвиг виден в кейсе MosaicLeaks про утечки deep-research агентов через внешние запросы: риск проявляется не в финальном ответе, а в промежуточном поведении агента. А статья про системный контроль сильных AI-агентов показывает тот же вывод на более высоком уровне: чем больше автономии и инструментов, тем важнее измеримые защитные меры, а не общие обещания безопасности.

Короткие ответы по RIFT-Bench

Чем RIFT-Bench отличается от обычных jailbreak-тестов?

Обычный jailbreak-тест чаще проверяет, можно ли заставить модель дать запрещённый ответ. RIFT-Bench проверяет агентную систему целиком: структуру, инструменты, память, внешние ресурсы, действия и execution traces.

Что делают Discovery и Scanning?

Discovery извлекает NodeSpec — графовое представление системы с компонентами и связями. Scanning берёт этот граф, подбирает применимые adversarial probes, запускает атаки и оценивает результат по нескольким метрикам.

Что можно выводить из проверки 45 agentic systems?

Можно говорить, что авторы показали применимость подхода на разнородном наборе систем, доменов, фреймворков и архитектур. Нельзя говорить, что RIFT-Bench доказал небезопасность всех AI-агентов или стал отраслевым стандартом.

Почему это важно для компаний?

Потому что агент с инструментами может ошибиться не только текстом. Он может вызвать API, изменить файл, раскрыть данные, потратить ресурс или выполнить действие в неправильном контексте. Это надо проверять через поведение системы, а не только через финальный ответ.

Ограничения препринта

RIFT-Bench пока стоит читать как исследовательский препринт, а не как готовую сертификацию безопасности. В тексте указано, что RIFT-Bench и benchmark artifacts будут опубликованы для AI security community после acceptance. До отдельной проверки нельзя писать, что это уже готовый open-source tool или боевой фреймворк.

Второе ограничение — benchmark не покрывает все реальные агентные продукты. 45 систем и 105 probes дают хороший исследовательский масштаб, но боевая среда добавляет свои зависимости: права доступа, сетевые политики, реальные данные, скрытые инструменты, человеческие процессы и инцидент-реакцию.

Третье — защита не сводится к одному графику ASR. Даже если конкретный mitigation снижает успешность атаки в benchmark, его надо проверять на ваших сценариях, данных и требованиях к полезности. Иначе можно получить «безопасного» агента, который не делает работу.

Главное

RIFT-Bench полезен не тем, что даёт ещё один набор jailbreak-промптов. Он переводит проверку AI-агентов на уровень системы: сначала понять структуру, потом атаковать применимые поверхности, затем смотреть trace, ASR, AAR, drift и полезность. Для разработчиков и security-команд это правильная рамка: агент — это уже не чат-бот, а программный актор с инструментами и последствиями.

Практический вывод жёсткий: если компания запускает AI-агентов с доступом к инструментам, ей нужны проверки уровня системы. Prompt-политика, контент-фильтр и ручная проверка нескольких ответов не покажут, что агент делает во внешних ресурсах и как ведут себя mitigations. RIFT-Bench пока не закрывает весь вопрос безопасности, но хорошо показывает, где именно этот вопрос теперь находится.

Источники и проверка фактов

Факты, даты, числа benchmark и изображения проверены 24 июня 2026 года. RIFT-Bench — свежий препринт: перед публикацией или существенным обновлением текста нужно перепроверить arXiv-страницу, наличие новой версии и появление кода или benchmark artifacts.

• arXiv: RIFT-Bench: Dynamic Red-teaming For Agentic AI Systems, submitted 22 Jun 2026; использовано для даты, авторов, abstract, 45 systems, 105 probes, 23 evaluators, двух фаз Discovery/Scanning и ограничений.
• arXiv HTML version; использовано для Figure 1, Figure 4, деталей NodeSpec, attack surfaces, metrics и defense-компромисса.
• OWASP Agentic AI – Threats and Mitigations, 17 февраля 2025 года; использовано как контекст по agentic threats и mitigations.
• Microsoft Learn: AI Red Teaming Agent; использовано для контекста automated scans, ASR, reporting и agentic risk categories.
• NIST CAISI: Insights into AI Agent Security from a Large-Scale Red-Teaming Competition, 23 марта 2026 года; использовано для контекста agent hijacking и необходимости адаптивных security evaluations.