ShieldAgent: Проверимо аргументиране на политики за безопасност за LLM агенти

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

Статията

ShieldAgent се позиционира като първия агент за защитни прегради (guardrail agent), проектиран специално за безопасност на агенти, а не за безопасност на LLM — съществена разлика. Защитните прегради за LLM проверяват входовете и изходите изолирано; защитните прегради за агенти трябва да разсъждават върху многостъпкови траектории на действия в динамични среди, където една на пръв поглед добронамерена стъпка може да бъде част от вредна последователност. Централният аргумент на статията е, че съществуващите подходи, включително GuardAgent, все още разчитат твърде много на сурово LLM аргументиране, което е скъпо, непоследователно и непроверимо.

Основният технически принос е вероятностната схема с правила, базирана на действия (action-based probabilistic rule circuit): документите с политики се анализират в проверими правила, всяко правило получава меко тегло (реализирано като потенциали в логическа мрежа на Марков), а правилата се групират чрез спектрално клъстеризиране в схеми, специфични за конкретни действия. По време на извеждане (inference), ShieldAgent извлича съответните схеми за всяко действие на агента, изпълнява четири формални операции (Търсене, Бинарна проверка, Откриване и Формална проверка чрез инструмента за проверка на модели Stormpy) и изчислява вероятностен етикет за безопасност. Крайното решение използва условие за относителна безопасност — разликата между вероятностните маси за „безопасно“ и „опасно“ трябва да надвишава праг ε — което намалява фалшиво положителните резултати в сравнение с абсолютните прагове на вероятност.

Ключови идеи

• Вероятностни схеми с правила върху логически мрежи на Марков: меките тегла на правилата се справят елегантно с противоречиви или непълни политики, което твърдите подходи за генериране на код като GuardAgent не могат да направят, когато политиките са двусмислени.
• Формалната проверка като операция от първи ред: проверката на модели чрез Stormpy е една от четирите операции за защита, а не допълнение след факта. Това е истинското значение на „проверимо“ (verifiable) в заглавието.
• 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 съдържа 3 110 проби в 6 уеб среди и 7 рискови категории, с 1 080 проверени правила за безопасност — истински полезен артефакт, независим от самия метод.

Кое е основателно — и кое не

Основната идея е солидна: замяната на суровата преценка на LLM със структурирани вероятностни схеми прави защитната преграда по-евтина, по-бърза и по-подлежаща на одит. Ползите от ефективността (64,7% по-малко API повиквания) не са просто приятна добавка — те са от огромно значение в производствена среда, където всяко извикване на защитна преграда добавя латентност към основния агент.

Дизайнът на бенчмарка също заслужава признание. ShieldAgent-Bench е конструиран с използване на реални алгоритми за софтуерни атаки (AgentPoison, AdvWeb) върху реални уеб среди, което е много по-достоверно от синтетичните набори от данни за безопасност.

Но няколко неща ме карат да се замисля. Първо, системата зависи от GPT-4o за извличане на политики, прецизиране на правила и планиране — което означава, че тя наследява разходите и латентността на GPT-4o в етапа на конструиране на политиките. Авторите отбелязват, че „се препоръчва преглед от човешки експерт по време на първоначалното изграждане на модела на политиката“, което мълчаливо признава, че автоматизираното извличане не е достатъчно надеждно за внедряване без надзор. Второ, статията признава по-слаби резултати при рискове, свързани с халюцинации, които изискват фактически знания извън документа с политики. За счетоводните агенти, където един запис може да изглежда в съответствие с политиката, но да е аритметично грешен или да препраща към несъществуваща сметка, това е истинска празнина. Трето, всички бенчмаркове са в среди за уеб агенти (пазаруване, GitLab, Reddit). Липсва оценка на финансови или счетоводни задачи. Впечатляващите цифри може да не са приложими в област със строги изисквания за аритметична коректност и по-ниска толерантност към фалшиво отрицателни резултати.

Забелязвам също, че цифрата „11,3% подобрение спрямо предишни методи“ (цитирана в анотацията) и цифрата „7,4% подобрение“ (цитирана в основния текст за съществуващи бенчмаркове) се различават. По-голямото число вероятно включва самия ShieldAgent-Bench, където авторите контролират както бенчмарка, така и метода — често срещано объркване при оценката.

Защо това е важно за финансовия AI

Проблемът с безопасността при запис в 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; заслужава си да разберете дизайна на задачите и дефинициите на метриките, преди да ги адаптирате за оценка на финансови агенти.