TL;DR
Исследование показывает, что агент может выполнить запрещённое действие без атаки и без лжи в данных. Достаточно, чтобы инструмент просто не вернул один важный факт: лимит платежа, список допущенных получателей, зависимость сервиса. Агент не замечает пробела, считает картину полной и жмёт «выполнить». EpiSEM-Bench проверяет это на 10 моделях: убирает факты из ответов инструментов и смотрит, что делает агент. Затем даёт ему отдельный инструмент, который возвращает недостающее по запросу.
Главная боль: «агент справляется с задачами» не значит «агент безопасен». Одни модели выполняют почти всё, включая запрещённое, потому что не сверяются с правилом. Другие почти ничего не нарушают, но отказываются и там, где всё разрешено. Модель вообще не замечает, что чего-то не хватает: в её «картине мира» всё сходится. Поэтому ей нужен повод остановиться и спросить.
Когда у агента есть способ добыть недостающие факты, доля небезопасных действий падает у всех десяти моделей. Но наличие инструмента не значит, что агент им воспользуется: слабые модели жмут «выполнить» раньше, чем проверят. Практический вывод: мало дать агенту инструмент проверки. Нужно проверять, зовёт ли он его до необратимого шага.
Схема метода
ШАГ 1: Парные миры → одна и та же просьба, одни и те же инструменты,
но в мире А действие запрещено, в мире Б разрешено
ШАГ 2: Полные данные → смотрим базу: делает ли агент запрещённое?
отказывается ли от разрешённого?
ШАГ 3: Прячем факты → из ответов инструментов убирают важные факты
(остальное остаётся правдой), смотрим, где агент ломается
ШАГ 4: Даём инструмент проверки → агент может запросить недостающее
→ смотрим: запросил ли, остановился ли в запретном мире,
выполнил ли в разрешённом
Это схема самого исследования. Читатель воспроизводит её вручную на небольшом числе своих сценариев (см. шаблон Б ниже).
Пример применения
В статье нет готовых промптов, а вывод проверялся через наличие инструмента проверки. Поэтому ниже пример, собранный по выводам статьи. Сам текст инструкции авторы не тестировали.
Задача: Ты настраиваешь Claude Code или Cursor, чтобы он помогал чистить тестовые стенды в Яндекс Облаке. Просьба безобидная: «удали старый стенд promo-test». Но в выводе команды list не видно, что от этой виртуальной машины зависит сервис, а бэкапа нет. Агент видит правдивый, но неполный ответ и удаляет.
Промпт (фрагмент для CLAUDE.md / системной инструкции):
Перед любым необратимым действием (удаление ресурсов, платёж, отправка
наружу, изменение прав) сделай три вещи.
1. Выпиши, что для разрешения этого действия нужно знать: зависимости
ресурса, наличие свежего бэкапа, владелец, лимиты и согласования.
2. Отметь по каждому пункту: «подтверждено выводом инструмента» или
«не видно в выводе». Отсутствие информации — не подтверждение
безопасности.
3. Если хоть один пункт «не видно» — запроси его через инструмент
check_dependencies или спроси меня. Не выполняй действие, пока все
пункты не подтверждены.
Если после проверки всё подтверждено и действие разрешено — выполняй
без лишних вопросов. Не отказывайся от разрешённых задач.
Результат: Перед удалением агент выведет список «что нужно знать» с пометками «подтверждено» и «не видно». Для promo-test он вызовет проверку зависимостей или остановится и спросит. Если зависимостей нет и бэкап есть, он удалит стенд без лишних вопросов. Если зависимость есть, он откажется удалять и объяснит почему.
Почему это работает
Слабость. Модель читает ответ инструмента как полную картину. Когда нужного факта в ответе нет, это не выглядит как пробел: все слова правдивы, всё выглядит связно. Модель продолжает по паттерну «просьба понятна, данные есть, значит, выполняем». Авторы видят это даже у моделей с высоким процентом выполненных задач: они делают запрещённое просто потому, что не сверялись с правилом.
Сильная сторона. Если у агента есть путь к недостающему факту, модель умеет им воспользоваться. После получения фактов она в основном принимает верное решение. Доля небезопасных действий падает у всех десяти моделей, а девять из десяти ещё и лучше выполняют разрешённые задачи. То есть проверка не превращается в «отказывай всегда».
Как это использует метод и что отсюда следует. Нужны два условия. Во-первых, источник проверки: инструмент, который возвращает недостающее. Во-вторых, явное правило в инструкции: проверять до необратимого шага. Рычаги управления: - Перечень необратимых действий → расширяй или сужай под свою среду. Чем шире список, тем больше остановок. - Список «что нужно знать» → пиши под каждое действие свой. Это превращает общий «будь осторожен» в конкретную сверку. - Условие «разрешено → выполняй» → оставь, иначе агент уйдёт в отказ от всего. Статья отдельно показывает, что тотальный отказ тоже провал. - Инструмент проверки → если его нет, замени на «спроси человека».
Шаблон промпта
Шаблон А: инструкция агенту (вывод статьи, не промпт из статьи)
Необратимые действия в моей среде: {список_действий}.
Перед любым из них:
1. Выпиши факты, от которых зависит разрешение: {что_проверять}.
2. По каждому отметь: «подтверждено выводом инструмента» или «не видно».
Отсутствие информации ≠ разрешение.
3. Если есть «не видно» — вызови {инструмент_проверки} или спроси меня.
Действие не выполняй, пока всё не подтверждено.
Если всё подтверждено и действие разрешено — выполняй сразу.
Не отказывайся от разрешённых задач.
Подставь: {список_действий} (удаление, платёж, рассылка, смена прав), {что_проверять} (лимиты, зависимости, список получателей, наличие бэкапа), {инструмент_проверки} (команда или источник, где можно узнать недостающее).
Шаблон Б: парная проверка своего агента (по логике статьи)
Я хочу проверить агента на неполных данных. Помоги составить 6 пар
сценариев для моей среды: {описание_среды}.
В каждой паре:
- одна и та же просьба и один и тот же набор инструментов;
- в сценарии А действие запрещено, в сценарии Б — разрешено;
- из ответов инструментов убран один ключевой факт ({тип_факта}),
остальное остаётся правдой.
Для каждой пары выпиши: что агент видит, какой факт скрыт, как должен
поступить в А и в Б. Затем дай критерии оценки: запросил ли недостающее,
остановился ли в А, выполнил ли в Б.
🚀 Быстрый старт — вставь в чат:
Вот шаблон проверки агента на неполных данных. Адаптируй под мою задачу: [твоя задача и среда].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какие необратимые действия есть у агента и какие факты решают, разрешено ли действие. Без этого невозможно построить пары «запрещено / разрешено» с одним и тем же запросом. Она возьмёт паттерн из шаблона и соберёт сценарии под твою среду.
Ограничения
⚠️ Синтетический стенд: все 600 миров построены исследователями. Реальные системы сложнее, и в них часто нет «идеального источника правды».
⚠️ Идеальный инструмент проверки: на любой валидный запрос он возвращает все скрытые факты сразу. В реальной работе такого инструмента почти никогда нет. Эффект в бою будет слабее.
⚠️ Инструкция не проверена: статья проверяла наличие инструмента, а не текст промпта вроде шаблона А. Что инструкция «проверяй до действия» работает, мы предполагаем, но данных нет.
⚠️ Инструмент ≠ использование: слабые модели часто делают необратимый шаг до проверки, хотя инструмент им доступен. Для них даже хорошая инструкция может не помочь.
⚠️ Регрессии: в среднем проверка помогает, но на отдельных задачах агент стал хуже: появились новые небезопасные действия или упало число выполненных разрешённых. Одна из моделей выполняла меньше разрешённых задач при меньшем числе нарушений.
⚠️ Крайности: тотальный отказ даёт «идеальную безопасность» и нулевую пользу. Метрики по отдельности вводят в заблуждение, смотреть нужно парами.
⚠️ Текст обрезан: разделы про детали поведения и дополнительные анализы в этом материале не видны.
Как исследовали
Идея была простой: отделить правду мира от того, что видит агент. Команда построила 300 пар задач в шести областях: облачная разработка, коммерция, публикации, доступ к данным, финансы, бронирование. В каждой паре одна и та же просьба и одни и те же инструменты, но в «запретном» мире действие нарушает правило (например, превышает лимит платежа), а в «разрешённом» — нет. Тотальный отказ в такой схеме сразу виден: он ломает разрешённую половину пары.
Дальше у каждой задачи размечены «атомы» фактов: 944 критических (входят в правило) и 419 нерелевантных (например, подпись центра затрат). Их по одному и комбинациями убирали из ответов инструментов, не трогая остальные правдивые данные. Для каждой модели это 6052 условия. Затем в часть запусков добавляли независимый аудит-инструмент, возвращающий недостающие факты.
Что удивило. Высокий процент выполненных задач не означает безопасность. Qwen3-14B выполняет 92% разрешённых задач, но совершает запрещённое действие в 77% задач при полных данных. GPT-6-Luna наоборот: 3% нарушений, но выполняет только 51% разрешённого. А лучший результат по «проверил и поступил верно в обоих мирах» показал не самый осторожный (DeepSeek-V4.1-Flash, 58%). Рекорд «границы безопасности» у GPT-6-Luna (85%), но он не лучший в восстановлении. Устойчивость к пропажам фактов и умение их добыть — разные навыки.
Вывод для практики: оценивай агента парами «запрещено / разрешено» и смотри на три шага отдельно: спросил ли, остановился ли, выполнил ли разрешённое. Одна цифра скрывает, где именно ломается.
Адаптации и экстраполяции
🔧 Техника: добавить в инструкцию агенту «ответ инструмента не содержит факта X» как стоп-сигнал → агент реже принимает тишину за разрешение
Это идея по мотивам статьи, авторы её не тестировали. Вместо общего «будь осторожен» опиши для каждого необратимого действия обязательный набор фактов:
Удаление ресурса: нужны (1) список зависимых сервисов, (2) дата
последнего бэкапа, (3) владелец. Если хоть одного нет в выводе — стоп,
запроси.
Платёж: нужны (1) лимит без согласования, (2) факт предыдущей оплаты
этого счёта, (3) реквизиты в списке одобренных. Если чего-то нет — стоп.
Эффект: перечень в инструкции превращает «нет данных» из невидимого пробела в явный пункт, на который можно ответить «не подтверждено».
Ресурсы
- Работа: EpiSEM-Bench: Evaluating Safety and Evidence Recovery in LLM Agents under Missing Evidence
- Авторы: Qijin Zhang, Hanzhen Wang, Yuehan Zhao, Haoyu Dai, Yao Shu, Zhongxiang Dai, Shuang Qiu
- Организации: City University of Hong Kong; HKUST (Guangzhou); CUHK (Shenzhen)
- Связанные работы из статьи: AgentDojo, τ-bench, ToolSandbox, AgentHarm, When2Call, AgentAbstain, AbsenceBench