AGrail: адаптивные защитные барьеры для LLM-агентов с обучением на разных задачах

Я внимательно следил за гонкой вооружений в области защитных барьеров (guardrails) для LLM-агентов — GuardAgent в 2024 году, ShieldAgent на ICML 2025 — и AGrail (Luo et al., ACL 2025) стал именно тем следующим шагом, о котором мне нужно было прочитать. Эта работа нацелена на устранение разрыва в масштабируемости, который не решили предшественники: что происходит, когда единая система защиты должна оберегать агентов в множестве различных задач, каждая из которых имеет свой словарь политик и поверхность рисков, не будучи заранее запрограммированной под каждую из них?

О статье

Вэйди Ло, Шэнхун Дай, Сяогэн Лю, Суман Банерджи, Хуань Сунь, Мухао Чэнь и Чаовэй Сяо представляют AGrail — «Пожизненный защитный барьер для агентов с эффективным и адаптивным обнаружением угроз» — опубликованный в основной программе ACL 2025. Проблема носит двойственный характер: LLM-агенты сталкиваются с рисками, специфичными для задачи, определенными администратором (например, «не удалять файлы в этой директории»), и системными рисками, возникающими из уязвимостей архитектуры (промпт-инъекции, атаки на среду). Существующие решения справляются максимум с одной из этих категорий и требуют ручной настройки политик для каждой задачи. Ответ AGrail — это кооперативная система из двух LLM (Анализатора и Исполнителя), которая генерирует, тестирует и итеративно уточняет проверки безопасности во время вывода с помощью адаптации во время теста (TTA), сохраняя уточненные проверки в модуле памяти для переноса знаний на будущие задачи.

Ключевые идеи

• Кооперация двух LLM: Анализатор извлекает соответствующие проверки безопасности из памяти, пересматривает их и предлагает обновленные наборы проверок. Исполнитель оценивает каждую предложенную проверку, решая, вызвать ли внешний инструмент, положиться на собственные рассуждения или отбросить избыточную проверку. Этот цикл выполняется итеративно до сходимости набора проверок.
• Память с техникой step-back prompting: Действия сохраняются как на естественном языке, так и в виде инструментальных команд с использованием step-back prompting. Во время инференса отображается только форма на естественном языке (чтобы предотвратить помехи от синтаксиса необработанных команд), но обе формы используются для поиска. Память стабилизируется примерно к четвертой итерации TTA с косинусным сходством более 98% при разных случайных начальных значениях.
• Бенчмарк Safe-OS: Авторы представляют новый набор данных из 100 сценариев, имитирующих реальное взаимодействие агента с ОС через Docker: 23 промпт-инъекции, 30 случаев системного саботажа, 20 атак на среду и 27 нормальных случаев. Это было необходимо, так как ни один существующий бенчмарк не сочетал все три типа системных рисков.
• 96% сохранения легитимных действий при 0% успеха промпт-инъекций: В Safe-OS с использованием Claude-3.5-Sonnet AGrail блокирует только 4,4% нормальных действий (95,6% сохранения), достигая при этом нулевого успеха атак через промпт-инъекции. Конкурирующие базовые модели блокируют до 49,2% легитимных действий.
• Результаты по рискам, специфичным для задач: На Mind2Web-SC (веб-агент) AGrail достигает F1=94,1 при 95,8% согласованности. На EICU-AC (конфиденциальность в здравоохранении) F1=98,5 при 100% согласованности.
• Нестабильность слабых моделей: Использование GPT-4o-mini в качестве основы демонстрирует нестабильность при изменении входных последовательностей; для надежной работы требуется Claude-3.5-Sonnet, что является неявным требованием к вычислительным мощностям, которое в статье несколько преуменьшено.

Что подтверждается, а что — нет

Результат, который впечатлил меня больше всего — это сравнение ложноположительных срабатываний: GuardAgent и LLaMA-Guard блокируют до 49,2% легитимных действий в Safe-OS. Это катастрофа с точки зрения удобства использования — защитный барьер, который помечает половину нормальной работы как опасную, никто не оставит включенным. Показатель блокировки 4,4% у AGrail на легитимных действиях действительно на порядок лучше.

Тем не менее, стоит отметить несколько пробелов. Во-первых, показатели атак через внедрение в среду (Environmental Injection Attack, EIA) выглядят хуже громких заявлений: частота успеха генерации действий (ASR) составляет 28% — то есть проходит более чем каждая четвертая атака. В статье этот факт скрыт за результатами 0% успеха промпт-инъекций. Во-вторых, модель угроз довольно узкая: Safe-OS охватывает три типа атак, но в работе не оцениваются состязательные цепочки рассуждений, которые обходят Анализатор целиком, или случаи, когда чрезмерно длинный контекст склоняет модуль памяти к неверным ранее усвоенным проверкам. В-третьих, концепция непрерывного обучения требует от агента многократного повторения похожих действий для сходимости памяти — результат сходимости к четвертой итерации получен в контролируемых условиях статьи, но неочевидно, как быстро стабилизируется память при сильно варьирующихся распределениях действий. В-четвертых, вычислительные затраты на запуск двух LLM плюс итерации TTA на каждом шаге агента никак не квантифицированы. В приложениях, чувствительных к задержкам, эта стоимость имеет значение.

Авторы честно признают, что они зависят от LLM общего назначения, а не от специализированных моделей защиты, и что использование внешних инструментов минимально. Однако они не обсуждают, как предложения Анализатора по проверке политик сами могут быть отравлены злоумышленником, понимающим конвейер step-back prompting.

Почему это важно для финансового ИИ

Таксономия «риски задачи + системные риски» напрямую переносится на бухгалтерских агентов. Агент записи в Beancount сталкивается с рисками задачи (правила администратора: «никогда не вносить записи в закрытый период», «всегда требовать согласования двумя сторонами для транзакций свыше $10 000») наряду с системными рисками (вредоносная заметка в комментарии к транзакции, внедряющая инструкции). Подход AGrail более естественен для этого случая, чем формальные схемы правил ShieldAgent, потому что бухгалтеры формулируют политики на обычном языке, а не на языке логики первого порядка.

Аспект непрерывного обучения (lifelong learning) особенно актуален. Один и тот же экземпляр системы может защищать десятки различных учетных книг — каждая со своими политиками плана счетов, разными границами финансового года и иерархиями утверждения. Возможность переносить проверки безопасности из одной книги в другую, уточняя их через TTA вместо того, чтобы начинать с нуля, могла бы существенно снизить нагрузку на настройку каждой отдельной книги. Достигает ли текущая реализация этого в масштабе реальной мультитенантной бухгалтерской платформы — вопрос, на который статья не дает ответа, так как ее оценка охватывает три различных типа задач агентов, а не десятки.

28% неудач при генерации действий против EIA — это та цифра, к которой я постоянно возвращаюсь. Для бухгалтерского агента успешная атака на генерацию состязательного действия означает фиксацию некорректной бухгалтерской проводки. Это невозможно исправить без ручного аудита. Защитный барьер, который пропускает 28% атак EIA, потребует вторичного уровня верификации — что возвращает нас к дискуссиям о мультиагентных спорах и дизайнах формальной верификации из предыдущих материалов.

Что читать дальше

• M3MAD-Bench (arXiv:2601.02854) — наиболее полный аудит того, помогают ли мультиагентные споры в различных модальностях и задачах; напрямую применимо, если кооперативный дизайн AGrail рассматривается для финансовых конвейеров.
• ShieldAgent (arXiv:2503.22738, ICML 2025) — подход с формальной верификацией, с которым неявно сравнивается AGrail; чтение обеих работ бок о бок проясняет компромисс между адаптивностью и формальными гарантиями.
• Towards Verifiably Safe Tool Use for LLM Agents (arXiv:2601.08012, ICSE 2026) — сочетает анализ процессов STPA с MCP для создания контролируемых спецификаций безопасности для агентов, вызывающих инструменты; наиболее системное существующее дополнение к проверкам во время выполнения в AGrail.