AGrail: Адаптивни защитни механизми за LLM агенти, които учат чрез задачите

Следя отблизо надпреварата във въоръжаването при защитните механизми за LLM агенти — GuardAgent през 2024 г., ShieldAgent на ICML 2025 г. — и AGrail (Luo et al., ACL 2025) е следващата стъпка, която трябваше да проуча. Тя е насочена към пропуските в мащабируемостта, които нито един от предшествениците не реши: какво се случва, когато една система за защита трябва да предпазва агенти в множество различни задачи, всяка със собствен речник от политики и повърхност на риска, без да бъде предварително програмирана за всяка една от тях?

Документът

Weidi Luo, Shenghong Dai, Xiaogeng Liu, Suman Banerjee, Huan Sun, Muhao Chen и Chaowei Xiao представят AGrail — „A Lifelong Agent Guardrail with Effective and Adaptive Safety Detection“ — публикуван в секцията за дълги доклади на ACL 2025. Основният проблем е двоен: LLM агентите са изправени пред специфични за задачата рискове, дефинирани от администратора (напр. „не изтривай файлове в тази директория“), и системни рискове от уязвимости в дизайна (prompt injection, атаки срещу средата), а съществуващите защитни механизми се справят в най-добрия случай с една от тези категории и изискват ръчно дефиниране на политики за всяка задача. Отговорът на AGrail е кооперативна система от два LLM модела — Анализатор и Изпълнител — която генерира, тества и итеративно прецизира проверките за безопасност по време на извеждане чрез адаптация по време на тест (TTA), съхранявайки прецизираните проверки в модул за памет, който пренася наученото към бъдещи задачи.

Ключови идеи

• Кооперация между два LLM: Анализаторът извлича подходящи проверки за безопасност от паметта, коригира ги и предлага актуализирани набори от проверки. Изпълнителят оценява всяка предложена проверка — като решава дали да извика външен инструмент, да разчита на собствено разсъждение или да отхвърли излишна проверка. Този цикъл се повтаря итеративно, докато наборът от проверки се стабилизира.
• Памет със step-back prompting: Действията се съхраняват както в представяния на естествен език, така и в команди за инструменти, използвайки step-back prompting. По време на извеждане се показва само формата на естествен език (за предотвратяване на смущения от суровия синтаксис на командите), но и двете форми се използват за извличане. Паметта се стабилизира около четвъртата TTA итерация с над 98% косинусова прилика при различни случайни семена.
• Бенчмарк Safe-OS: Авторите въвеждат нов набор от данни от 100 сценария, симулиращи реални взаимодействия на агенти с операционната система чрез Docker — 23 за prompt injection, 30 за системен саботаж, 20 за атаки срещу средата и 27 нормални случая — тъй като нито един съществуващ бенчмарк не комбинира и трите типа системни рискове.
• 96% запазване на легитимни действия при 0% ASR за prompt injection: В Safe-OS с Claude-3.5-Sonnet, AGrail блокира само 4,4% от легитимните действия (95,6% запазване), като същевременно постига 0% процент на успешни атаки (ASR) срещу prompt injection. Конкурентните базови модели блокират до 49,2% от легитимните действия.
• Резултати за специфични за задачите рискове: В Mind2Web-SC (уеб агент) AGrail постига F1=94,1 с 95,8% съвпадение. В EICU-AC (поверителност в здравеопазването) F1=98,5 със 100% съвпадение.
• Нестабилност на слабите модели: GPT-4o-mini като гръбнак показва нестабилност при различни входни последователности; Claude-3.5-Sonnet е необходим за надеждна производителност, което е имплицитна предпоставка за изчислителни ресурси, която докладът не подчертава достатъчно.

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

Резултатът, който ме впечатлява най-много, е сравнението на фалшиво положителните резултати: GuardAgent и LLaMA-Guard блокират до 49,2% от легитимните действия в Safe-OS. Това е катастрофа за използваемостта — защитен механизъм, който маркира половината от нормалната работа, е механизъм, който никой няма да остави включен. Коефициентът на блокиране на AGrail от 4,4% за добронамерени действия е наистина по-добър.

Въпреки това, няколко пропуска заслужават да бъдат споменати. Първо, цифрите за атаки чрез инжектиране в средата (EIA) са по-неубедителни от основните твърдения: ASR при генериране на действия е 28% — повече от една на всеки четири атаки преминава. Докладът прикрива това в сравнение с резултата от 0% за prompt injection. Второ, моделът на заплаха е тесен: Safe-OS обхваща три типа атаки, но документът не оценява състезателни вериги от разсъждения, които заобикалят Анализатора изцяло, или случаи, в които достатъчно дълъг контекст тласка модула за памет към грешни предходни проверки. Трето, историята за учене през целия живот изисква агентът да среща подобни действия многократно, за да може паметта да се стабилизира — резултатът за стабилизиране до четвъртата итерация важи в контролираната среда на документа, но не е ясно колко бързо се стабилизира паметта, когато разпределенията на действията са силно вариращи. Четвърто, изчислителните разходи за изпълнение на два LLM модела плюс TTA итерации на всяка стъпка на агента никога не са количествено определени. В приложения, чувствителни към забавяне (latency), тези разходи са от значение.

Авторите честно признават, че разчитат на общи LLM модели, а не на специализирани модели за безопасност, и че използването на инструменти е минимално. Това, което не обсъждат, е как предложенията за проверка на политики от Анализатора биха могли сами да бъдат компрометирани от противник, който разбира конвейера на step-back prompting.

Защо това е важно за финансовия изкуствен интелект

Таксономията на специфичните за задачата рискове и системните рискове се пренася директно към счетоводните агенти. Един агент за записване в Beancount е изправен пред специфични за задачата рискове (правила на администратора: „никога не публикувай в заключен период“, „винаги изисквай одобрение от две страни за транзакции над $10 000“) заедно със системни рискове (злонамерена бележка в мемо на транзакция, която инжектира инструкции). Рамката на AGrail е по-естествена за този случай на употреба от формалните вериги от правила на ShieldAgent, тъй като счетоводителите формулират политиките на обикновен език, а не чрез логика от първи ред.

Аспектът на ученето през целия живот е особено подходящ. Едно внедряване може да защитава десетки отделни главни книги — всяка с различни политики за сметкоплана, различни граници на фискалната година, различни йерархии на одобрение. Способността за прехвърляне на проверки за безопасност от една книга в друга, прецизирайки ги чрез TTA, вместо да се започва от нулата, би могла значително да намали тежестта по конфигуриране за всяка отделна книга. Дали текущата реализация действително постига това в мащаба на реална мулти-тенант счетоводна платформа е въпрос, на който документът не отговаря — неговите оценки обхващат три отделни задачи на агенти, а не десетки.

Процентът на неуспех от 28% при генериране на действия при EIA е цифрата, към която постоянно се връщам. За един счетоводен агент успешна атака чрез генериране на състезателни действия означава, че се потвърждава некоректен счетоводен запис. Това не е възстановимо без ръчен одит. Защитен механизъм, който се проваля при 28% от EIA атаките, би изисквал вторичен слой за проверка — което ни връща към дебата за мулти-агентни дискусии и дизайните за формална проверка от по-ранните материали в този списък за четене.

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

• M3MAD-Bench (arXiv:2601.02854) — най-изчерпателният одит на това дали мулти-агентните дискусии действително помагат при различни модалности и задачи; пряко свързано, ако кооперативният LLM дизайн на AGrail се разглежда за финансови конвейери.
• ShieldAgent (arXiv:2503.22738, ICML 2025) — подходът за формална проверка, с който AGrail се сравнява имплицитно; четенето на двете паралелно изяснява компромиса между адаптивност и формални гаранции.
• Towards Verifiably Safe Tool Use for LLM Agents (arXiv:2601.08012, ICSE 2026) — комбинира STPA анализ на процесите с MCP за създаване на приложими спецификации за безопасност за агенти, които извикват инструменти — най-систематичното съществуващо допълнение към проверките по време на работа на AGrail.