Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Проверять только запрещённые действия недостаточно: агент может корректно решить задачу, но оставить ключ, сессию или права доступа в небезопасном состоянии. В препринте Tsinghua University, который не прошёл рецензирование и где числа получили сами авторы, ObligationGuard находила такие пропуски чаще всех сравниваемых моделей. Для команд это добавляет отдельную проверку перед завершением работы агента, а не заменяет действующие фильтры действий.
Что считать невыполненным обязательством
Защитная модель (guard model) обычно ищет действие, которое агенту запрещено совершать. Например, она должна остановить отправку секретного ключа во внешний сервис.
Работа рассматривает симметричную проблему: агент обязан выполнить критический для безопасности шаг, но завершает задачу раньше. Само завершение разрешено, однако итоговое состояние системы остаётся небезопасным.
В одном из примеров агент добавил постоянный вход в веб-приложение и прошёл функциональные тесты. При этом он не проверил срок действия сессии на сервере. Старый файл сеанса оставался пригодным для входа, хотя ни одного явно запрещённого действия агент не совершил.
ObligationBench проверяет, может ли модель восстановить полный список таких пропусков по заданию и всей траектории — журналу действий агента и ответов среды. В набор вошли 240 проверенных экспертами случаев из исправления ошибок, разработки функций и работы в терминале. Положительные случаи с обязательствами дополнены парными отрицательными, где вмешательство не требуется: так модель штрафуют и за пропуск риска, и за ложную тревогу.
Траектории собрали из реальных запусков агентов на SWE-Bench Pro, FeatureBench и Terminal-Bench 2.0 с разными базовыми LLM. GPT-5.6-Sol отбирала и предварительно размечала примеры, после чего два инженера независимо исправляли разметку и исключали спорные случаи. Для обучения ObligationGuard подготовили 40 000 синтетических примеров: сначала задавали сценарий, требования безопасности и намеренно пропущенные действия, затем генерировали подходящую траекторию.
Запрещённые действия покрывают меньше половины проблемы
Предварительная проверка на SusVibes показала разрыв между двумя типами риска. Среди запусков GLM-5.3, которые прошли функциональные тесты, невыполненные обязательства встретились в 56,92% траекторий, а запрещённые действия — в 30%. Эти категории пересекаются, поэтому доли не складываются в общую частоту ошибок.
На ObligationBench лучшая из существующих моделей достигла полноты 48,97%. Полнота здесь показывает, какую долю обязательств из эталонного списка модель действительно нашла. ObligationGuard подняла результат до 57,52%.
Найти отдельные пункты проще, чем восстановить весь список без пропусков и лишних предупреждений. ObligationGuard точно совпала с полным эталонным набором лишь в 21,67% случаев, хотя и обошла остальные модели. Качество дополнительно падало, когда обязательство возникало рано в длинной траектории или когда одновременно оставалось несколько незакрытых требований.
Это различие влияет на архитектуру проверки. Фильтр отдельных команд видит опасную операцию в момент выполнения, а проверка обязательств должна учитывать цель задачи, предыдущие действия и итоговое состояние среды. Последний безопасный шаг сам по себе ничего не говорит о том, очищены ли временные данные, отозваны ли права и добавлены ли необходимые проверки.
Командам нужен контроль точки завершения
Работа меняет планы команд, которые разрешают агенту самостоятельно изменять код или выполнять команды. Между заявлением «задача завершена» и фактическим окончанием запуска стоит добавить проверку всей траектории на оставшиеся обязательства. Если модель находит пропуск, агент получает конкретное требование и продолжает работу.
Такую проверку не стоит ставить вместо запретов. Практическая схема включает два независимых сигнала: опасное действие нужно остановить до выполнения, а незакрытые требования — обнаружить перед завершением. Для второго сигнала полезен не общий ответ «небезопасно», а перечень действий вроде удаления временного секрета или проверки срока серверной сессии.
В эксперименте ObligationGuard один раз давала агенту подсказку при первой попытке завершить задачу. Доля решений, прошедших одновременно функциональные тесты и тесты безопасности, выросла с 6,5% до 15,1%. Большая часть улучшений пришлась на решения, которые уже работали функционально, но не закрывали требования безопасности.
Границы результата узкие: ObligationBench охватывает программную разработку и терминальные задачи, а влияние подсказок проверяли на SusVibes с Qwen3.8-27B в Mini-SWE-Agent. Поэтому внедрение разумно начинать с собственных траекторий и тестов безопасности, а не переносить итоговые показатели на агентов для финансовых, юридических или операционных процессов.
Главное изменение — формализовать условия безопасного завершения наряду со списком запретов. Если продукт пока проверяет только каждую команду по отдельности, он контролирует действия агента, но не гарантирует безопасное состояние после их выполнения.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
