Перейти к контенту

ShieldAgent: Верифицируемое обоснование политик безопасности для LLM-агентов

· 6 мин чтения
Mike Thrift
Mike Thrift
Marketing Manager

После обзора GuardAgent на прошлой неделе — инструмента, который переводит политики безопасности в исполняемый код — я захотел изучить статью, которая прямо заявляет о превосходстве над ним: ShieldAgent (Chen, Kang, and Li, ICML 2025, arXiv:2503.22738). Улучшение, которое GuardAgent показал по сравнению с гардрейлами на основе промптов, уже было значительным; однако вопрос о том, действительно ли вероятностные логические схемы ShieldAgent закрывают оставшийся пробел или просто меняют правила игры, заслуживал тщательного изучения, прежде чем принимать решение об архитектуре безопасности обратной записи (write-back) для агентов Beancount.

Статья

2026-05-28-shieldagent-verifiable-safety-policy-reasoning-llm-agents

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; стоит изучить дизайн задач и определения метрик перед их адаптацией для оценки финансовых агентов.