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

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

Стаття

ShieldAgent позиціонує себе як першого агента-запобіжника, розробленого спеціально для безпеки агентів, а не для безпеки LLM — це важлива відмінність. Запобіжники LLM перевіряють вхідні та вихідні дані ізольовано; запобіжники агентів повинні аналізувати траєкторії багатоетапних дій у динамічних середовищах, де один на перший погляд нешкідливий крок може бути частиною шкідливої послідовності. Основний аргумент статті полягає в тому, що існуючі підходи, включаючи GuardAgent, все ще занадто сильно покладаються на сирі міркування LLM, що є дорогим, непослідовним і не піддається верифікації.

Основним технічним внеском є імовірнісна схема правил на основі дій: документи політики парсяться у верифіковані правила, кожне правило отримує «м’яку» вагу (реалізовано як потенціали мережі марковської логіки), і правила групуються за допомогою спектральної кластеризації в схеми, специфічні для конкретних дій. Під час інференції ShieldAgent отримує відповідні схеми для кожної дії агента, виконує чотири формальні операції (Search, Binary-Check, Detect та Formal Verify за допомогою засобу перевірки моделей Stormpy) і обчислює імовірнісну мітку безпеки. Остаточне рішення використовує умову відносної безпеки — розрив між безпечною та небезпечною масами ймовірності повинен перевищувати поріг ε — що зменшує кількість хибнопозитивних результатів порівняно з абсолютними порогами ймовірності.

Ключові ідеї

• Імовірнісні схеми правил на основі мереж марковської логіки: м’які ваги правил дозволяють коректно обробляти суперечливі або неповні політики, чого не можуть зробити жорсткі підходи з генерацією коду, такі як GuardAgent, коли політики неоднозначні.
• Формальна верифікація як операція першого класу: перевірка моделей Stormpy є однією з чотирьох операцій захисту, а не додатком після факту. Це те, що насправді означає «верифіковане» у назві.
• Точність 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: основний агент пропонує зміни в реєстрі (ledger mutations), а запобіжник повинен перевірити ці зміни на відповідність політиці перед тим, як вони будуть зафіксовані. Ідея схем правил чітко накладається — правила політики 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; варто зрозуміти дизайн завдань та визначення метрик перед їх адаптацією для оцінки фінансових агентів.