Чем опасен «слой управления» для LLM-агентов
Современные языковые модели редко работают в одиночку. Чаще они разворачиваются внутри агентного харнеса — прослойки, которая даёт модели доступ к инструментам, расширениям, долговременной памяти, разрешениям и внешним действиям. Именно эта прослойка решает, что модель может сделать, а что нет.
Проблема в том, что существующие бенчмарки безопасности обычно проверяют лишь отдельные сценарии атак или ограниченный набор операционных условий. Из-за этого сложно понять, на каком именно этапе работы харнеса возникает сбой: при настройке, в момент вызова инструмента или при восстановлении после инцидента. Исследователи предложили HarnessRisk — бенчмарк, который смотрит на безопасность агентного харнеса целиком, на всех стадиях его жизненного цикла.
Шесть фаз жизненного цикла харнеса
Авторы работы разбили безопасность харнеса на шесть операционных фаз:
- Harness Configuration — настройка параметров и прав доступа;
- Capability Extension — подключение новых возможностей и расширений;
- Runtime Operation — выполнение задач в реальном времени;
- State Persistence — сохранение и восстановление состояния;
- Action Control — контроль над действиями и инструментами;
- Incident Recovery — реакция на сбои и восстановление после инцидентов.
Каждая фаза отвечает за свою зону ответственности, и уязвимости могут проявляться в любой из них. Именно такое разделение позволяет сравнивать, как разные харнесы справляются с атаками в одинаковых условиях.
Что внутри HarnessRisk: сценарии и метрики
В бенчмарке собрано 128 изолированных сценариев. Каждый сценарий устроен хитро: перед моделью ставится безопасная пользовательская задача, но внутри недоверенного артефакта рабочего процесса спрятана враждебная инструкция. Модель должна выполнить легитимную цель, не поддавшись атаке, встроенной в артефакт.
Каждая траектория оценивается по четырём метрикам:
- Utility — насколько хорошо выполнена исходная задача;
- Attack Success Rate — доля успешно проведённых атак;
- Persistence — насколько долго сохраняется эффект атаки;
- Detection — насколько эффективно система замечает риски.
Такой подход позволяет увидеть не только «взломали или нет», но и цену безопасности для полезности модели.
Что показало тестирование
Эксперименты проводились на трёх харнесах, шести языковых моделях и 14 комбинациях моделей и харнесов. Результаты оказались неоднородными: успешность атак варьировалась от 12,6% до 80,9%, а Utility оставалась в диапазоне от 75,0% до 97,6%. Простыми словами, одна и та же модель может быть почти неуязвимой в одной конфигурации и откровенно слабой в другой.
Самая уязвимая фаза во всех трёх харнесах — Harness Configuration. Атаки часто срабатывают не из-за сложных эксплойтов, а потому, что в рамках «разрешённого» рабочего процесса можно изменить параметры, влияющие на безопасность. Это тревожный сигнал: даже корректно выглядящий харнес может позволить злоумышленнику поменять правила игры.
Любопытный результат связан и с распознаванием рисков. Некоторые конфигурации обнаруживают атаки более чем в 90% запусков, но при этом всё равно допускают значительную долю успешных атак. То есть модель «понимает», что происходит что-то опасное, но не превращает это понимание в безопасное поведение. Осознание угрозы само по себе не защищает систему.
Выводы: безопасность нельзя измерять «в среднем»
Главный урок HarnessRisk в том, что безопасность агентных систем сильно зависит от конкретной связки модели и харнеса. Усреднённые оценки «модель безопасна» или «харнес безопасен» мало что говорят, если не учитывать, в какой конфигурации они работают.
Нужно оценивать агентов сразу по нескольким зонам ответственности харнеса — от начальной настройки до восстановления после инцидентов. И отдельно проверять, как модель ведёт себя при атаке, встроенной в обычный рабочий артефакт. Только так можно заметить слабые места, которые в классических бенчмарках остаются за кадром.
