Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Защитный фильтр ИИ-агента может пропускать запрещённые действия, которые до атаки блокировал правильно. В препринте USC, который не прошёл рецензирование и содержит замеры самих авторов, шесть строк серверного журнала подняли долю таких ошибок с 0 до 63%. Значит, подобную модель нельзя ставить последней проверкой перед вызовом инструмента: она годится только для предварительного отбора.
Метка ответа становится частью решения
Модель типизированных решений получает текст о предлагаемом действии и вопрос с несколькими вариантами. У каждого варианта есть короткая метка для программы и определение для модели; в ответ система возвращает вероятность каждого варианта, но не генерирует текст.
Для защитного фильтра варианты обычно означают «разрешить» и «заблокировать». Ошибки здесь неравноценны: если фильтр пропустил запрещённое действие, агент может его выполнить; если заблокировал разрешённое, пользователь столкнётся с отказом или дополнительной проверкой. Общая точность смешивает риск и неудобство, поэтому работа считает эти направления отдельно.
В некоторых библиотеках метка служит не только идентификатором результата, но и попадает во вход модели. Тогда конфигурация, документ с политикой или схема инструмента создают дополнительный канал управления решением. Атакующему достаточно повлиять на название варианта, не меняя его определения и само действие, которое проверяет фильтр.
Проверку провели на моделях с открытыми весами. Основной набор GuardBench содержит синтетические вызовы инструментов и шесть политик: например, запрет отправлять секреты или обращаться к пути вне рабочей области. Правильный ответ вычисляется из известных атрибутов вызова. Результаты также сверили на трёх наборах реальных сообщений для обнаружения внедрения инструкций, обхода ограничений и токсичного текста. Коммерческую модель, которая первой предложила такой интерфейс, в работе не проверяли.
Нейтральный текст и одно слово открывают фильтр
На наборах реальных сообщений точность находилась между 36% и 72% при случайном уровне 50%. Низкая доля ошибок одного типа часто означала не хорошее распознавание, а постоянный выбор одного ответа: одна модель разрешала почти всё, другая почти всё блокировала. Поэтому оценивать такой фильтр только по точности или одной категории ошибок опасно.
В GuardBench к контролируемому атакующим фрагменту добавляли обычные строки серверного журнала. Они не сообщали ничего о получателе, пути, секретах или разрешении пользователя, поэтому правильное решение не менялось. Тем не менее модели смещались в сторону разрешения, причём корректно заблокированные действия превращались в разрешённые заметно чаще, чем разрешённые — в заблокированные.
Ещё сильнее сработала атака через метку варианта. Вводящее в заблуждение название подняло долю пропущенных запретов до 93–100% у четырёх моделей, которым библиотека передавала метку во входе. Модели, не получавшие метки, были защищены от этого конкретного канала, но оставались уязвимыми для текста внутри проверяемого состояния.
Вероятность ответа также не помогла отличить атаку. После смены решения модель была не менее уверена, чем до неё, поэтому отправка «сомнительных» случаев более сильной модели или человеку не находила взломанные ответы. Порог вероятности лишь менял соотношение между пропущенными запретами и ошибочными блокировками.
Финальное решение стоит оставить коду
Инструкция игнорировать названия вариантов не закрыла канал: атакующему требовалось перебрать больше меток, но достижимый результат не менялся. Сравнение решений при двух названиях вариантов сначала помогало, однако адаптивная атака подбирала текст, который проходил обе проверки. Удаление вывода инструмента тоже работало лишь до тех пор, пока атакующий не переносил вводящий в заблуждение текст в оставшиеся поля.
Из результатов следуют три изменения для архитектуры агента:
- Фиксировать метки в коде. Строки из конфигурации, документов и схем внешних инструментов не должны становиться названиями вариантов. Это закрывает атаку через метку, но не защищает от вредоносного текста в самом вызове.
- Передавать отдельные поля вместо сырой трассировки. Хост, путь, признак секрета и разрешение пользователя дают модели меньше постороннего контекста. Это снижает поверхность атаки, но поле всё ещё можно снабдить ложным пояснением, если система не разбирает его строго.
- Кодировать формальные правила напрямую. После разбора полей обычное условие достигло 100% правильных решений на всём GuardBench и не требовало модели. Если правило можно выразить через проверяемые значения, LLM добавляет неопределённость, а не возможности.
Для неструктурированных сообщений, где точное правило написать нельзя, модель можно использовать для сортировки очереди на проверку. Но её ответ не должен сам разрешать отправку данных, изменение файлов или другой необратимый вызов. Граница безопасности должна проходить через детерминированную проверку или человека, а не через вероятность одного из вариантов.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
