Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Проверять защитный слой ИИ-агента только по числу остановленных опасных действий недостаточно: операция может не пройти из-за сломанного ответа, а не из-за отсутствия права. Команда Huihao Jing представила AuthorizationPairs и показала, что исправление формата ответа меняет набор разрешённых запросов; работа вышла как нерецензированный препринт, а все числа получили сами авторы. Для команд это превращает сохранение законных операций в отдельный приёмочный тест.
Одна операция, разные права
AuthorizationPairs проверяет защитный слой (guardrail), который решает, разрешить ли агенту действие. В обычном тесте можно получить высокий результат, если блокировать все возвраты денег, изменения записей или развёртывания кода. Такой слой останавливает угрозы, но заодно делает агента бесполезным.
В языковой части бенчмарка операция остаётся неизменной вместе с аргументами: суммой платежа, получателем или артефактом развёртывания. Меняются только доказательства полномочий. Активное поручение может разрешать действие, отозванное — запрещать, а передача полномочий — открывать другой законный путь к тому же результату.
Набор включает 50 сценариев, в каждом есть два разрешённых и два запрещённых контекста. Решения сверяли специалисты по безопасности, а разрешённые операции запускали в локальной среде. Затем отдельная проверка подтверждала фактический эффект: изменение баланса, запись в базе, появление файла или подписи.
Вторая часть использует 1 594 запроса из публичных примеров OpenFGA и Cedar. Эталонный ответ здесь дают сами движки политик доступа. Языковая часть проверяет операции в смоделированной среде, а часть с формальными политиками — только отдельные решения о доступе; многошаговые процессы агента работа не охватывает.
Исправный формат ещё не означает правильного решения
Бенчмарк разделяет три исхода. Защитный слой может правильно или ошибочно оценить полномочия, вернуть непригодный для обработки ответ либо допустить реальное выполнение операции. Без такого разделения любой технический сбой выглядит как успешная блокировка.
Структурированный запрос к Qwen3.5-9B оставлял до 124 из 160 входов без пригодного решения: модель генерировала ответ, который интерфейс не мог разобрать. Декодирование по заданной схеме JSON устранило такие сбои во всех шести повторах. Но оно не просто восстановило прежние решения в читаемом виде — набор разрешённых законных запросов изменился.
Дополнительный проверяющий тоже не гарантирует улучшения. В тесте с формальными политиками Safeguard после Qwen3.5-27B устранил одну ошибочную выдачу разрешения, но одновременно отклонил 171 законный запрос. Последовательность из нескольких проверяющих с правилом «разрешить должны все» снижает риск пропущенного нарушения ценой новых ложных отказов.
Поэтому общая доля блокировок скрывает разные проблемы. Непригодный ответ требует исправить интерфейс. Ошибочное разрешение указывает на неверную проверку полномочий. Законный запрос, остановленный явным отказом, становится регрессионным тестом для конкретного пути авторизации.
Командам нужен список прав, которые нельзя сломать
Работа меняет план испытаний, но не предлагает готовый защитный слой для промышленной системы. Перед заменой модели, формата ответа или цепочки проверяющих команде стоит зафиксировать критичные разрешённые запросы: например, возврат по действующему поручению или обновление записи после принятой передачи полномочий.
Каждый такой запрос нужно проверять парой. При действительном разрешении операция должна выполняться, а после отзыва или при неподходящей области полномочий — останавливаться с пригодным для обработки решением. Рост общего числа успешных задач не компенсирует отказ именно в том сценарии, ради которого агент подключили к процессу.
Идентификаторы запросов также нужно сохранять между версиями. Тогда отчёт покажет не только итоговую точность, но и конкретные права, которые новая конфигурация восстановила или потеряла. Это защищает от ситуации, когда одинаковый общий результат складывается из разных наборов ошибок.
Для внедрения вывод практический: отдельно измерять ошибочные разрешения, ложные отказы и технически непригодные ответы. После любого изменения следует повторно запускать обе стороны каждой важной границы доступа. Только так можно отличить более точную проверку полномочий от безусловного запрета, который случайно выглядит безопасным.
Источники
Иллюстрация: рисунок из статьи «Same Operation, Different Permission: Evaluating Whether Guardrails Honor Authorization», Huihao Jing, Shaojin Chen, Wenbin Hu и др., CC0 1.0
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
