GuardAgent: Детерминистично прилагане на безопасността за LLM агенти чрез изпълнение на код

Централният проблем за безопасността при всеки агент с право на запис (write-back agent) е: как да го спрем да предприеме действие, което никога не е трябвало да предприема? GuardAgent (Xiang et al., ICML 2025) предлага специализиран предпазен агент (guardrail agent) — отделен LLM агент, който проверява всяко действие на целевия агент спрямо набор от политики за безопасност, преди то да бъде изпълнено. За Bean Labs, където въпросът „може ли агентът да пише в главната книга, без да нарушава счетоводните правила?“ е недискусионен, тази статия стои точно в центъра на нашата изследователска програма.

Статията

GuardAgent: Safeguard LLM Agents by a Guard Agent via Knowledge-Enabled Reasoning от Zhen Xiang и колеги от UIUC, Emory и UC Berkeley, представя това, което авторите твърдят, че е първият предпазен агент с общо предназначение за LLM системи. Основната идея е проста: вместо да се вграждат ограничения за безопасност директно в инструкциите (prompt) на целевия агент (където те могат да бъдат пренебрегнати или забравени), GuardAgent работи като независим агент, който прехваща действията на целевия агент и ги верифицира спрямо заявените политики.

Механизмът има два етапа. Първо, LLM прочита политиката за безопасност и предложените входни или изходни данни от целевия агент, след което съставя постоянен план за действие, описващ какво трябва да се провери. Второ, той преобразува този план в изпълним Python код, използвайки предварително дефиниран набор от извикваеми функции. Външен Python интерпретатор изпълнява кода, произвеждайки детерминирана присъда „да/не“. Модул за памет съхранява минали кортежи от задачи (политика, план, код) и извлича подобни предходни примери чрез разстоянието на Левенщайн, позволявайки обучение в контекст с малко примери (few-shot in-context learning) без необходимост от допълнителна фина настройка. Статията оценява подхода чрез два нови бенчмарка, въведени от авторите.

Ключови идеи

• Изпълнението на код превъзхожда присъдите на естествен език. Когато решенията за безопасност се представят като код, а не като текст от LLM, резултатът е детерминиран: Python ядрото или разрешава, или блокира, без риск от халюцинации в последната стъпка на вземане на решение. LLM трябва само да генерира правилен код, а не правилен краен отговор.
• Два персонализирани бенчмарка. EICU-AC (316 примера) тества контрола на достъпа за EHRAgent върху база данни за здравеопазване с три потребителски роли и десет бази данни. Mind2Web-SC (200 примера) тества шест политики за безопасност за уеб агента SeeAct. И двата са създадени от авторите специално за тази статия.
• 98,7% и 90,0% точност на етикетите (GPT-4) съответно за EICU-AC и Mind2Web-SC. Критично важно е, че точността на крайния отговор — дали целевият агент все пак завършва задачата си, когато тя трябва да бъде разрешена — остава 100% и в двата сценария.
• Твърдо кодираните правила за безопасност се провалят сериозно. Вграждането на политиките директно в системната инструкция (prompt) на целевия агент постига само 81,0% / 77,5% точност в двата бенчмарка и причинява неуспех на целевия агент в 29,2% / 71,0% от неговите легитимни задачи — неприемлив компромис между полезност и безопасност.
• LlamaGuard не е подходящият инструмент тук. Базовият модел за модериране на съдържание постига приблизително 50% точност — близо до случайността — защото е проектиран за вреден текст, а не за разсъждения относно това дали дадено действие на агент нарушава специфично правило за контрол на достъпа.
• Премахването на набора от инструменти (toolbox) струва около 8 пункта. Без библиотеката с извикваеми функции, GuardAgent пада от 98,7% на 90,8% при EICU-AC, въпреки че частично компенсира чрез автономно дефиниране на необходимите функции (68% от изходите генерират код дори без изрична инструкция, което авторите разглеждат като подкрепящо доказателство за дизайна, базиран на генериране на код).

Какво е устойчиво и какво — не

Основното архитектурно прозрение — че изпълнението на код осигурява детерминирана точка на прилагане — е наистина полезно, а аблационните изследвания са честни. Сравнението с твърдо кодираните правила за безопасност е особено убедително: то показва, че наивните дизайни от типа „просто добавете правила в инструкцията“ влошават полезността на целевия агент, като същевременно не успяват да наложат безопасността надеждно.

Но оценката има реални ограничения. Двата бенчмарка са малки (316 и 200 примера) и авторите са конструирали и двата, което създава очевиден риск от пренастройване (overfitting). EICU-AC е по същество матрица за контрол на достъпа (роля × база данни), което е структуриран, изброим проблем — видът задачи, в които кодът естествено е добър. Mind2Web-SC е по-неясен и цифрата от 90,0% там е значително по-малко впечатляваща, отколкото изглежда на пръв поглед: авторите признават, че правило 5 (обхващащо „филми, музика и видеоклипове“) причинява най-много неуспехи, тъй като изисква широки разсъждения за реалния свят. Това е видът правило, с който един истински финансов агент би се сблъсквал постоянно.

Модулът за памет извлича демонстрации чрез текстово сходство, което работи добре за повтарящи се типове политики, но ще се влоши при наистина нови политики. И цялата рамка предполага „доверена среда“ — самите политики за безопасност трябва да бъдат предоставени от доверен администратор. Ако нападател може да промени политиките или ако наборът от инструменти съдържа небезопасни функции, GuardAgent не предлага защита. Статията не моделира злонамерено манипулиране на политиките. Последващи работи (ShieldAgent, arXiv:2503.22738; AGrail, arXiv:2502.11448) вече подчертаха тези пропуски, като ShieldAgent отчита средно подобрение от 11,3% спрямо GuardAgent в по-широки бенчмаркове.

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

Агентът за запис в Beancount се нуждае от нещо повече от инструкция за безопасност — той се нуждае от механизъм за налагане на счетоводни правила, който е структурно отделен от агента, вършещ работата. Архитектурата на GuardAgent се вписва директно в това: предпазен агент, който проверява всяко предложено счетоводно записване спрямо счетоводните правила (дебит == кредит, без осчетоводяване в заключени периоди, без модификация на изравнени трансакции), преди записът да бъде изпълнен. Слоят за прилагане чрез изпълнение на код е особено привлекателен тук, тъй като аритметиката на двойното записване е точно онзи вид структурирана, изброима проверка, с която кодът се справя надеждно, а текстът на LLM — не.

Честното ограничение е, че GuardAgent предполага, че можете да изброите вашите политики за безопасност предварително и да ги кодирате в набор от инструменти. В реални внедрявания на Beancount някои ограничения са имплицитни (следвайки конвенциите на главната книга, които потребителят е изградил в продължение на години), а някои са динамични (бюджетите се променят, структурите на сметките се рефакторират). GuardAgent не казва как да се справяме с ограничения, които не могат да бъдат предварително специфицирани. Това е по-трудният проблем и той остава отворен.

Какво да прочетете след това

• ShieldAgent (arXiv:2503.22738, ICML 2025) — надгражда над GuardAgent с верифицируеми разсъждения за политиките за безопасност и ShieldAgent-Bench (2 хиляди примера в шест уеб среди); отчита 11,3% подобрение спрямо GuardAgent и 64,7% намаление на API повикванията.
• AGrail (arXiv:2502.11448) — предлага адаптивни проверки за безопасност, които се пренасят между задачите на агента, вместо да изискват демонстрации за всяка задача; директно адресира ограничението на мащабируемостта на GuardAgent.
• ToolSafe (arXiv:2601.10156) — проактивни предпазни механизми на ниво стъпка с обратна връзка за агенти, извикващи инструменти; по-детайлен от модела за прехващане на входа/изхода на GuardAgent.