AGrail: Адаптивні захисні бар'єри для LLM-агентів, що навчаються в ході виконання завдань

Я уважно стежу за гонкою озброєнь у сфері захисних бар'єрів для LLM-агентів — GuardAgent у 2024 році, ShieldAgent на ICML 2025 — і AGrail (Luo et al., ACL 2025) став наступним важливим кроком. Він спрямований на подолання розриву в масштабованості, який не вирішив жоден із попередників: що відбувається, коли єдина система захисту повинна оберігати агентів у багатьох різних завданнях, кожне з яких має свій словник політик і поверхню ризику, без попереднього програмування для кожного з них?

Про статтю

Вейді Луо, Шенхон Дай, Сяоґен Лю, Суман Банерджі, Хуань Сунь, Мухао Чень та Чаовей Сяо представляють AGrail — "Безперервний захисний бар'єр для агентів з ефективним та адаптивним виявленням загроз", опублікований у треку ACL 2025. Основна проблема є подвійною: LLM-агенти стикаються з ризиками, специфічними для завдання, визначеними адміністратором (наприклад, "не видаляти файли в цій директорії"), та системними ризиками через вразливості дизайну (ін'єкції промптів, атаки на середовище), а існуючі захисні бар'єри в кращому випадку справляються лише з однією з цих категорій і потребують ручного налаштування політик для кожного завдання. Відповідь AGrail — це кооперативна система з двох LLM (Аналізатора та Виконавця), яка генерує, тестує та ітеративно вдосконалює перевірки безпеки під час інференсу за допомогою адаптації під час тестування (TTA), зберігаючи вдосконалені перевірки в модулі пам'яті для використання у майбутніх завданнях.

Основні ідеї

• Кооперація двох LLM: Аналізатор витягує відповідні перевірки безпеки з пам'яті, переглядає їх і пропонує оновлені набори перевірок. Виконавець оцінює кожну запропоновану перевірку — вирішуючи, чи викликати зовнішній інструмент, покладатися на власні міркування чи відхилити зайву перевірку. Цей цикл виконується ітеративно до конвергенції набору перевірок.
• Пам'ять із промптингом зворотного кроку (step-back prompting): Дії зберігаються як природною мовою, так і у вигляді команд інструментів за допомогою техніки step-back prompting. Під час виведення відображається лише форма на природній мові (щоб запобігти втручанню синтаксису сирих команд), але обидві форми використовуються для пошуку. Пам'ять стабілізується приблизно на четвертій ітерації TTA з косинусною подібністю понад 98% для різних випадкових значень (seeds).
• Бенчмарк Safe-OS: Автори представляють новий набір даних зі 100 сценаріїв, що імітують реальні взаємодії агентів з ОС через Docker — 23 ін'єкції промптів, 30 випадків системного саботажу, 20 атак на середовище та 27 нормальних випадків — оскільки жоден існуючий бенчмарк не об'єднував усі три типи системних ризиків.
• 96% збереження добронамірених дій при 0% успішних ін'єкцій промптів: На Safe-OS з Claude-3.5-Sonnet AGrail блокує лише 4,4% добронамірених дій (95,6% збереження), досягаючи при цьому 0% успішності атак (ASR) через ін'єкції промптів. Конкуруючі базові моделі блокують до 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% успішності ін'єкцій промптів. По-друге, модель загроз є вузькою: Safe-OS охоплює три типи атак, але стаття не оцінює змагальні ланцюжки міркувань, які повністю обходять Аналізатор, або випадки, коли достатньо довгий контекст схиляє модуль пам'яті до неправильних попередніх перевірок. По-третє, історія з безперервним навчанням вимагає від агента неодноразового повторення схожих дій для стабілізації пам'яті — результат про конвергенцію на четвертій ітерації справджується в контрольованих умовах статті, але не очевидно, як швидко пам'ять стабілізується при високій варіативності розподілу дій. По-четверте, обчислювальні витрати на запуск двох LLM плюс ітерації TTA на кожному кроці агента ніде не квантифіковані. У додатках, чутливих до затримки, ця вартість має значення.

Автори чесно визнають, що вони покладаються на загальні 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.