ShieldAgent: Верифицируемое обоснование политик безопасности для LLM-агентов
После обзора GuardAgent на прошлой неделе — инструмента, который переводит политики безопасности в исполняемый код — я захотел изучить статью, которая прямо заявляет о превосходстве над ним: ShieldAgent (Chen, Kang, and Li, ICML 2025, arXiv:2503.22738). Улучшение, которое GuardAgent показал по сравнению с гардрейлами на основе промптов, уже было значительным; однако вопрос о том, действительно ли вероятностные логические схемы ShieldAgent закрывают оставшийся пробел или просто меняют правила игры, заслуживал тщательного изучения, прежде чем принимать решение об архитектуре безопасности обратной записи (write-back) для агентов Beancount.
Статья
ShieldAgent позиционирует себя как первый агент-гардрейл, разработанный специально для безопасности агентов, а не просто LLM — и это важное различие. Гардрейлы для LLM проверяют входные и выходные данные изолированно; гардрейлы для агентов должны анализировать многошаговые траектории действий в динамических средах, где один на первый взгляд безобидный шаг может быть частью вредоносной последовательности. Основной аргумент авторов заключается в том, что существующие подходы, включая GuardAgent, по-прежнему слишком сильно полагаются на «сырое» рассуждение LLM, которое является дорогим, непоследовательным и не поддается верификации.
Основной технический вклад заключается в вероятностной логической схеме на основе действий: документы политик парсятся в верифицируемые правила, каждому правилу присваивается «мягкий» вес (реализованный как потенциалы марковских сетей логики), а правила группируются с помощью спектральной кластеризации в схемы, специфичные для конкретных действий. Во время инференса ShieldAgent извлекает соответствующие схемы для каждого действия агента, выполняет четыре формальные операции (Search, Binary-Check, Detect и Formal Verify с использованием Stormpy) и вычисляет вероятностную метку безопасности. Финальное решение использует условие относительной безопасности — разрыв между массами вероятности «безопасно» и «небезопасно» должен превышать порог ε — что снижает количество ложноположительных результатов по сравнению с абсолютными порогами вероятности.
Ключевые идеи
- Вероятностные логические схемы поверх марковских сетей логики: мягкие веса правил позволяют гибко обрабатывать противоречивые или неполные политики, что невозможно при жестких подходах с генерацией кода (как в GuardAgent), когда политики двусмысленны.
- Формальная верификация как первоклассная операция: проверка модели с помощью Stormpy является одной из четырех операций экранирования (shielding), а не дополнением после выполнения. Это именно то, что на самом деле означает «верифицируемый» в названии.
- Точность 90,4% при атаках на уровне агентов и 91,7% при атаках на уровне среды на бенчмарке ShieldAgent-Bench, при уровне ложноположительных результатов 4,8% — самом низком среди всех оцениваемых базовых решений.
- Среднее улучшение на 7,4% по сравнению с GuardAgent на трех существующих бенчмарках: ST-WebAgentBench (91,1% против 84,0%), VWA-Adv (94,1% против 89,9%), AgentHarm (86,9% против 78,4%).
- На 64,7% меньше запросов к API и на 58,2% быстрее инференс, чем у лучшего предыдущего метода, так как логические схемы позволяют выполнять целевой поиск вместо передачи всей траектории в LLM на каждом шаге.
- Значительный рост комплаенса в реальном времени: при развертывании в качестве монитора в реальном времени комплаенс в среде Shopping вырос с 46,8% до 65,3%, а в GitLab — с 22,8% до 50,7%.
- ShieldAgent-Bench содержит 3110 образцов в 6 веб-средах и 7 категориях риска, с 1080 верифицированными правилами безопасности — это действительно полезный артефакт, независимый от самого метода.
Что подтверждается, а что — нет
Основная идея здравая: замена «сырых» суждений LLM структурированными вероятностными схемами делает гардрейл дешевле, быстрее и более проверяемым. Выигрыш в эффективности (на 64,7% меньше вызовов API) — это не просто приятное дополнение; это критически важно в продакшене, где каждое срабатывание гардрейла добавляет задержку к работе основного агента.
Дизайн бенчмарка также заслуживает признания. ShieldAgent-Bench был построен с использованием реальных алгоритмов состязательных атак (AgentPoison, AdvWeb) в реальных веб-средах, что гораздо более убедительно, чем синтетические наборы данных по безопасности.
Однако некоторые моменты вызывают вопросы. Во-первых, система зависит от GPT-4o для извлечения политик, уточнения правил и планирования — это означает, что она наследует стоимость и задержки GPT-4o на этапе построения политик. Авторы отмечают, что «рекомендуется проверка экспертом-человеком при начальном построении модели политик», что косвенно признает: автоматизированное извлечение недостаточно надежно для развертывания без контроля. Во-вторых, в статье признается более слабая производительность при рисках, связанных с галлюцинациями, которые требуют фактических знаний, выходящих за рамки документа политики. Для бухгалтерских агентов, где запись может казаться соответствующей политике, но быть арифметически неверной или ссыл аться на несуществующий счет, это серьезный пробел. В-третьих, все бенчмарки представляют собой среды веб-агентов (покупки, GitLab, Reddit). Оценка на финансовых или бухгалтерских задачах отсутствует. Впечатляющие цифры могут не перенестись в домен с более строгими требованиями к арифметической точности и меньшей толерантностью к пропускам нарушений.
Я также заметил, что цифра «улучшение на 11,3% по сравнению с предыдущими методами» (указанная в аннотации) и цифра «улучшение на 7,4%» (указанная в тексте статьи для существующих бенчмарков) различаются. Большая цифра, предположительно, включает сам ShieldAgent-Bench, где авторы контролируют и бенчмарк, и метод — обычная проблема при оценке.
Почему это важно для ИИ в финансах
Проблема безопасности обратной записи в Beancount структурно похожа на то, что решает ShieldAgent: основной агент предлагает мутации гроссбуха, а «страж» должен проверить эти мутации на соответствие политике перед их фиксацией. Идея логических схем ложится здесь идеально — правила политик Beancount (отсутствие расхождения дебета и кредита, обязательное существование счета, положительная сумма, авторизация транзакции пользователем) — это именно те структурированные ограничения, которым формальное представление дает больше преимуществ, чем свободное рассуждение LLM.
Прирост эффективности для бухгалтерии важнее, чем для веб-агентов. Агент обратной записи в гроссбух может предложить десятки журнальных записей за одну сессию; гардрейл, сокращающий вызовы API на 64,7%, может сделать верификацию в реальном времени осуществимой. Однако пробел в борьбе с галлюцинациями остается главной открытой проблемой: ShieldAgent не может поймать записи, которые соответствуют политике, но фактически неверны (ошибочные суммы, неверно классифицированные счета). Для Beancount этот сценарий отказа является, пожалуй, самым распространенным и дорогостоящим. Гибридный гардрейл — ShieldAgent для соблюдения политик и отдельный арифметический верификатор для числовой корректности — кажется наиболее подходящей архитектурой.
Что почитать дальше
- AGrail: A Lifelong Agent Guardrail with Effective and Adaptive Safety Detection (Luo et al., ACL 2025, arXiv:2502.11448) — предлагает дополняющий подход: адаптивную генерацию проверок безопасности, которая обучается в процессе выполнения задач, вместо предварительного извлечения фиксированной модели политики. Сравните с ShieldAgent, чтобы понять компромисс между фиксированной и адаптивной политикой.
- Towards Verifiably Safe Tool Use for LLM Agents (arXiv:2601.08012, ICSE 2026) — использует системно-теоретический анализ процессов (STPA) для создания формальных гарантий безопасности для агентов, вызывающих инструменты, переходя от вероятностной к детерминированной верификации, где это возможно.
- ST-WebAgentBench: A Benchmark for Evaluating Safety and Trustworthiness in Web Agents (arXiv:2410.06703) — самый строгий из трех существующих бенчмарков, использованных для оценки ShieldAgent; стоит изучить дизайн задач и определения метрик перед их адаптацией для оцен ки финансовых агентов.
