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

Центральная проблема безопасности для любого агента с правом записи (write-back agent) заключается в следующем: как предотвратить действие, которое он не должен был совершать? GuardAgent (Xiang и др., ICML 2025) предлагает выделенного агента-ограничителя (guardrail agent) — отдельного LLM-агента, который проверяет каждое действие целевого агента на соответствие набору политик безопасности перед его выполнением. Для Bean Labs, где вопрос «может ли агент вносить записи в гроссбух, не нарушая правил бухгалтерского учета?» не подлежит обсуждению, эта статья находится в самом центре нашей исследовательской повестки.

О статье

Статья «GuardAgent: Safeguard LLM Agents by a Guard Agent via Knowledge-Enabled Reasoning», написанная Чжэнь Сяном и его коллегами из UIUC, Эмори и Калифорнийского университета в Беркли, представляет то, что авторы называют первым универсальным агентом-ограничителем для LLM-систем. Основная идея проста: вместо того чтобы встраивать ограничения безопасности непосредственно в промпт целевого агента (где их могут проигнорировать или забыть), GuardAgent работает как независимый агент, который перехватывает действия целевого агента и проверяет их на соответствие заданным политикам.

Механизм состоит из двух этапов. Сначала LLM считывает политику безопасности и предложенный ввод или вывод целевого агента, а затем составляет пошаговый план действий, описывающий, что именно нужно проверить. Во-вторых, она преобразует этот план в исполняемый код на Python, используя предопределенный набор вызываемых функций (toolbox). Внешний интерпретатор 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% в обоих сценариях.
• Жестко закодированные правила безопасности работают плохо. Встраивание политик непосредственно в системный промпт целевого агента дает лишь 81,0% / 77,5% точности на двух бенчмарках и приводит к тому, что целевой агент не справляется с 29,2% / 71,0% своих законных задач — это неприемлемый компромисс между полезностью и безопасностью.
• LlamaGuard здесь не подходит. Базовое решение для модерации контента достигает точности около 50% (на уровне случайного угадывания), так как оно разработано для выявления вредного текста, а не для рассуждений о том, нарушает ли действие агента конкретное правило управления доступом.
• Удаление набора инструментов (toolbox) снижает точность примерно на 8 пунктов. Без библиотеки вызываемых функций точность GuardAgent на EICU-AC падает с 98,7% до 90,8%, хотя это частично компенсируется автономным определением необходимых функций (68% ответов генерируют код даже без явных инструкций, что авторы рассматривают как подтверждение правильности архитектуры с генерацией кода).

Что заслуживает доверия, а что нет

Ключевое архитектурное решение — использование выполнения кода как детерминированной точки контроля — действительно полезно, а абляционные исследования (ablations) выглядят честными. Сравнение с жестко закодированными правилами безопасности особенно убедительно: оно показывает, что наивные попытки «просто добавить правила в промпт» снижают полезность агента, при этом не обеспечивая надежной безопасности.

Однако оценка имеет свои ограничения. Оба бенчмарка невелики (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 (2000 примеров в шести веб-средах); сообщает об улучшении на 11,3% по сравнению с GuardAgent и сокращении вызовов API на 64,7%.
• AGrail (arXiv:2502.11448) — предлагает адаптивные проверки безопасности, которые переносятся между задачами агента, а не требуют демонстраций для каждой задачи; напрямую решает проблему масштабируемости GuardAgent.
• ToolSafe (arXiv:2601.10156) — проактивные ограничители на уровне отдельных шагов с обратной связью для агентов, вызывающих инструменты; более гранулярная модель, чем перехват ввода/вывода в GuardAgent.