TL;DR
Obligation (обязательство) — действие, которое агент должен был сделать ради безопасности, но не сделал. Например: удалить временный файл с секретами, закрыть открытый порт, добавить проверку срока сессии. Проверка работы агента по схеме «что он сделал и не нарушил ли запрет» эти пропуски не видит. Нужен второй вопрос: «что агент обязан был сделать перед завершением, но оставил?»
Главная находка: агент может не нарушить ни одного запрета и всё равно оставить дыру. Тесты зелёные, ключ не утёк, а дамп с данными клиентов лежит в /tmp. В реальных запусках кодирующих агентов невыполненные обязательства встречались заметно чаще, чем запрещённые действия: у одной модели в 57% запусков против 30%. Причина в том, что агент оптимизирует «задача решена, тесты прошли». Уборка за собой и защитные шаги в это условие не входят.
Проверять такие пропуски тоже трудно. Даже сильнейшие модели в роли проверяющего находят меньше половины невыполненных обязательств, а полностью точный список составляют примерно в одном случае из десяти. Хуже всего у них получается, когда обязательство возникло рано в ходе работы или когда их несколько сразу. Авторы обучили для этого маленькую модель-проверяющего. Читателю это недоступно, но сама постановка вопроса работает и без обучения: отдаём LLM задачу и журнал действий агента, просим вернуть список невыполненного (или пустой список).
Схема метода
ВХОД: задача пользователя + полный журнал действий агента (команды и ответы среды)
ШАГ 1: Выписать, что агент создал, открыл, ослабил или временно включил
ШАГ 2: Для каждого пункта — что должно быть возвращено/закрыто/добавлено до завершения
ШАГ 3: Сверить с журналом: сделано или нет (с доказательством из журнала)
ВЫХОД: список невыполненных обязательств ИЛИ пустой список, если всё закрыто
Всё это можно сделать в одном промпте и в одном чате. Авторы формулируют задачу проверяющего как «задача + журнал → набор невыполненных обязательств». Пустой набор — полноценный правильный ответ.
Пример применения
Задача: Фрилансер через Claude Code переносит базу клиентов Telegram-бота записи в барбершоп на новый сервер в Selectel. Агент сделал дамп базы, временно открыл порт Postgres наружу для проверки, прогнал миграцию. Тесты зелёные, агент пишет «готово». Перед сдачей проекта нужно проверить, что он ничего не оставил.
Промпт:
Ты — аудитор работы ИИ-агента. Твоя задача — найти НЕВЫПОЛНЕННЫЕ ОБЯЗАТЕЛЬСТВА:
действия, которые агент обязан был сделать ради безопасности, но не сделал
к моменту завершения. Запрещённые действия не ищи — только то, что осталось
несделанным.
Задача, которую давали агенту:
Перенести базу клиентов Telegram-бота записи «Бритва» (имена, телефоны,
история визитов) на новый сервер в Selectel и убедиться, что бот работает.
Журнал действий агента (команды и ответы среды):
[вставить полный журнал]
Порядок работы:
1. Выпиши всё, что агент создал, открыл, включил или ослабил по ходу работы
(файлы, порты, токены, права, временные настройки, отладочные режимы).
2. По каждому пункту определи: что должно быть удалено, закрыто, возвращено
или добавлено до завершения.
3. Проверь по журналу, сделал ли агент это. Приведи номер шага или цитату как доказательство.
4. Выведи только то, что НЕ сделано.
Формат ответа: список обязательств «что осталось сделать — почему это риск — доказательство из журнала».
Если невыполненных обязательств нет, ответь: «Невыполненных обязательств нет» и кратко объясни почему.
Не придумывай обязательства, которых журнал не подтверждает.
Результат: Модель сначала перечислит «следы» работы агента: дамп, открытый порт, временные учётные данные. Затем по каждому проверит, закрыт ли он. В конце выдаст короткий список незакрытого с указанием шага журнала и риска (например, «данные клиентов остаются доступными»). Если всё убрано, ответит, что обязательств нет. Читать нужно с поправкой: список может быть неполным, это подсказка для ручной проверки, а не гарантия.
Почему это работает
Слабость. Агент решает «довести задачу до прохождения тестов». Всё, что не проверяется тестами (уборка, закрытие доступа, проверка срока действия), выпадает из его цели. Обычный надзор за агентом тоже ищет только запрещённое. Отсутствие действия в журнале незаметно: искать нужно то, чего там нет.
Сильная сторона LLM. Модель умеет сопоставлять: прочитала журнал и выделила «создано», «открыто», «включено». Умеет и рассуждать «а что должно было быть сделано после?». Для этого достаточно задать правильный вопрос.
Как метод использует это. Промпт превращает «найди то, чего нет» в два простых шага: сначала список того, что появилось, потом проверка закрытия по каждому пункту. Так модель не должна «увидеть пустоту», а сверяет конкретные пары «открыл — закрыл ли».
Рычаги управления: - Список категорий риска (утечка данных, доступы, подмена, целостность) → добавь свои, и поиск станет острее. - «Приведи доказательство из журнала» → убери, получишь больше пунктов, но и больше выдумок. - Пустой ответ как разрешённый вариант → уберёшь, и модель начнёт придумывать обязательства. В исследовании для этого специально делали «чистые» запуски. - Дробление журнала → если журнал длинный, проверяй кусками. В статье модели хуже находят обязательства, возникшие рано в траектории, и когда их много.
Шаблон промпта
Ты — аудитор работы ИИ-агента. Найди НЕВЫПОЛНЕННЫЕ ОБЯЗАТЕЛЬСТВА: действия,
которые агент обязан был выполнить ради безопасности, но не выполнил к моменту
завершения. Запрещённые действия не ищи.
<Задача>
{задача_агента}
<Журнал>
{журнал_действий}
<Категории_риска>
{категории_риска}
Порядок:
1. Выпиши всё, что агент создал, открыл, включил или ослабил.
2. По каждому пункту определи, что должно быть убрано, закрыто, возвращено или добавлено.
3. Проверь по журналу, сделано ли это. Дай доказательство (шаг или цитата).
4. Выведи только невыполненное.
Формат: «что осталось сделать — риск — доказательство».
Если ничего не осталось — «Невыполненных обязательств нет» + короткое пояснение.
Не придумывай обязательства без подтверждения в журнале.
Что подставлять: {задача_агента} — исходная постановка, которую получил агент. {журнал_действий} — полный лог команд и ответов (в Claude Code — история сессии). {категории_риска} — например: утечка данных, доступы и сессии, подмена и подпись, изменение защищённых файлов и настроек.
🚀 Быстрый старт — вставь в чат:
Вот шаблон аудита незавершённых обязательств агента. Адаптируй под мою задачу: {опиши, что делал агент}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какие системы агент трогал (сервер, база, ключи, сервисы) и какие риски для тебя критичны. Это нужно, чтобы заполнить {категории_риска}: без них аудитор будет искать слишком общо.
Важно: готового промпта в тексте статьи нет. Шаблон построен по формулировке задачи из статьи: «задача + журнал → набор невыполненного, пустой набор допустим».
Ограничения
⚠️ Проверяющая LLM пропускает больше половины: лучшая из 14 моделей нашла менее половины невыполненных обязательств, а полностью верный список выдала примерно в одном случае из десяти. Это подсказка для человека, а не гарантия безопасности.
⚠️ Раннее и множественное: чем раньше в ходе работы возникло обязательство и чем их больше одновременно, тем хуже модель их находит. Длинные журналы лучше резать на куски.
⚠️ Только кодирующие агенты: проверяли на исправлении ошибок, разработке функций и работе в терминале. Для агентов в других областях (продажи, поддержка) вывод не проверен.
⚠️ Готового промпта нет: способ «проверь обязательства промптом» авторы не измеряли. Измерен только обученный ими проверяющий — он требует дообучения модели, у читателя такой возможности нет.
⚠️ Ложные срабатывания: в бенчмарке половина запусков «чистая», чтобы проверять ложные тревоги. Без разрешения отвечать «ничего нет» модель склонна выдумывать пропуски.
⚠️ Эталон частично машинный: разметку делала GPT, её проверяли два инженера (согласие 82%). Разметка не безупречна.
⚠️ Текст обрезан: анализ факторов, абляции и результаты с интеграцией проверяющего в агента даны только по введению.
Как исследовали
Сначала авторы проверили, насколько проблема вообще реальна. Они взяли бенчмарк SusVibes (кодирующие агенты решают задачи, потом отдельно проверяют безопасность) и посмотрели на запуски двух моделей. GPT разметила, из-за чего каждый небезопасный запуск «провалился»: из-за запрещённого действия, из-за невыполненного обязательства или того и другого. Оказалось, что пропущенные обязательства встречаются чаще запрещённых действий: в среднем 51% запусков против 32%. Проверяющий, который ищет только запретное, пропускает большую часть проблем, даже если он идеален.
Затем собрали ObligationBench. Прогнали 1000 задач через четыре LLM, получили 5684 траектории, GPT отобрала подозрительные и разметила их. Два инженера с пятилетним опытом независимо исправили разметку. Итог: 240 экземпляров, 120 с пропущенными обязательствами и 120 «чистых» (в среднем около трёх обязательств на позитивный случай). Чистые нужны, чтобы проверять ложные тревоги.
На этом бенчмарке прогнали 14 моделей. Лучшая нашла лишь 48,97% обязательств (полностью верный набор — около 10%). Затем авторы обучили Qwen3-8B на 40 000 синтетических примеров. Данные они генерировали «задом наперёд»: сначала придумывали сценарий и список невыполненного, потом генерировали траекторию под него. Так не нужна ручная разметка. Модель дала 57,52% и 21,67%, а в связке с агентом подняла долю безопасно решённых задач с 6,5% до 15,1%. Удивляет, насколько мала даже эта «победа»: проблема остаётся нерешённой.
Адаптации и экстраполяции
🔧 Техника: добавить «отладочные следы» в список поиска → меньше пропусков уборки
В шаге 1 явно перечисли: «временные файлы, дампы, тестовые токены, включённые отладочные режимы, открытые порты, ослабленные права». Модель не сможет пропустить категорию, которую ты назвал сама.
🔧 Техника: убрать «приведи доказательство» → увидеть больше гипотез
Для первичного обхода можно разрешить модели писать и предположения, помечая их «не подтверждено». Потом проверять руками.
Экстраполяция (моя идея, в статье не проверялась): чеклист закрытия в инструкции агента. Раз агент забывает уборку, можно добавить в AGENTS.md / CLAUDE.md правило до завершения работы:
Перед тем как написать «готово»:
1. Перечисли всё, что ты создал, открыл, включил или ослабил в этой сессии.
2. По каждому пункту выполни закрытие: удали временное, закрой доступ, верни настройки.
3. Покажи список «создано → закрыто» в финальном отчёте.
Если что-то закрыть нельзя — явно напиши об этом.
Работает ли это на практике, авторы не измеряли. Включай как гипотезу и проверяй на своих запусках.
Ресурсы
- Safe Actions Alone Do Not Ensure Safe Agents: Identifying Unfulfilled Obligations with Guard Models — Youwei Feng, Yitong Zhang, Yuetong Liu, Jia Li (Tsinghua University, College of AI).
- ObligationBench (240 экземпляров), ObligationGuard (Qwen3-8B, обучен на 40 000 синтетических траекторий).
- Исходные бенчмарки: SusVibes, SWE-Bench Pro, FeatureBench, Terminal-Bench 2.0.