Одной проверки шага недостаточно для защиты ИИ-агента от распределённой атаки

Кратко

Авторы проверили систему, которая хранит сведения о безопасности между последовательными шагами работы ИИ-агента. На специально заданных сценариях она снизила долю успешных атак до 0,1% и сохранила выполнение 96,9% безвредных задач; неизвестно, сохранится ли этот результат в реальных системах.

Зачем это знать

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

Разбор

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

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

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

Эксперимент построили не на случайных примерах, а на парах одинаковых чистых и атакованных эпизодов из Agent-SafetyBench. В специальном наборе атак решающие признаки появлялись только между итерациями; авторы также по очереди отключали отдельные модули и запускали адаптивную проверку «белого ящика», где атакующая сторона знает устройство защиты. При увеличении длины цикла с 5 до 10 итераций у базового варианта доля успешных атак выросла с 2,9% до 6,2%, а к 20 итерациям не снизилась — это иллюстрирует, почему простое наблюдение за отдельными запусками не решает проблему.

Ключевые цифры

200 эпизодов на каждое семейство атакКаждый тип атаки проверили на отдельной группе из двухсот запусков, а не на единичных примерах.

1 000 эпизодов на конфигурациюКаждый вариант защиты прошёл через тысячу атакованных запусков, что позволяет сравнивать результаты устойчивее.

N = 5, 10 и 20 итерацийАвторы отдельно проверили, как меняется защита, когда один автономный цикл становится в четыре раза длиннее.

6,2%У базовой защиты успешные атаки встречались уже примерно в шести случаях из ста при длине цикла 10 итераций; при 20 итерациях показатель не улучшился.

Можно ли доверять

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

Пересказано ИИ по научной статье. Как это устроено

Источник и детали

ЖурналarXiv (cs.AI)

Дата публикации у нас28 августа 2026 г.

Дата источника27 августа 2026 г.

ОригиналОткрыть

АвторыChenhao Wu, Haoxuan Jia, Yang Liu, Yingguang Yang, Yuhan Lin, Chongyang Zhang, Hao Zheng, Yulin Huang, Jianshen Zhang, Yongzhi Qi