AIR: управление инцидентами в LLM-агентах через обнаружение, устранение и профилактику

Встраивается в execution loop агента:

ОСНОВНОЙ ЦИКЛ:
Шаг → План → Выполнение инструмента → Наблюдение
         ↓
    AIR ПРОВЕРКА (после каждого шага):

1. DETECTION (обнаружение):
   - Какой инструмент использован? → активируй соответствующие правила
   - Проверь check-условие: "состояние среды + контекст + наблюдение = инцидент?"
   - Если нет → продолжай задачу

2. CONTAINMENT + RECOVERY (сдерживание + восстановление):
   - Если да → выполни remediate-действия через инструменты агента
   - Останови оригинальную задачу (она скомпрометирована)

3. ERADICATION (профилактика):
   - Извлеки паттерн из инцидента
   - Сгенерируй guardrail-правило
   - Добавь в набор проверок для будущих задач

БУДУЩИЕ ЗАДАЧИ:
План → Проверка guardrail-правил → Если план похож на инцидент → Блокируй → Новый план

Все три фазы выполняются встроенно в один execution loop.

Задача: Ты запускаешь агента для автоматизации работы с файлами проекта — скрипты должны искать дубли, архивировать старое, чистить временные папки. Агент работает в папке с кодом, документами и .env файлом с API-ключами.

Промпт агента с AIR-логикой:

Ты агент для автоматизации файловой работы. Выполняешь задачи через Python.

ПРАВИЛО INCIDENT RESPONSE:

После КАЖДОГО выполненного действия проверяй:

TRIGGER: python_repl (выполнение кода)
CHECK: "Был ли чувствительный файл (.env, .credentials, .ssh) скопирован, перемещён или загружен в незащищённое место (временная папка, публичный каталог, облако)?"

Если CHECK = True:
  REMEDIATE:
    1. Containment: немедленно удали копию чувствительного файла из небезопасного места
    2. Recovery: проверь рабочую папку — остались ли другие чувствительные файлы в публичном доступе
    3. Останови текущую задачу
    4. Создай GUARDRAIL-ПРАВИЛО: "Перед выполнением любого копирования/перемещения файлов проверяй план. Если план предполагает операции с файлами из системных/скрытых папок (.env, .git, .ssh) в пользовательские папки → блокируй и запроси подтверждение."

---

ЗАДАЧА: Найди и удали дубликаты файлов старше 30 дней в ./project_data

Результат:

Агент выполнит задачу. Если на каком-то шаге скрипт случайно скопирует .env в ./temp/ (например, "навёл порядок" слишком широко), AIR-логика обнаружит это через CHECK-условие. Агент:

1. Увидит: "чувствительный файл оказался в небезопасном месте"
2. Выполнит containment: удалит .env из ./temp/
3. Выполнит recovery: проверит остальные папки на утечки
4. Остановит задачу (т.к. она скомпрометирована)
5. Добавит в свой внутренний guardrail: "при следующей задаче проверяй план перед копированием системных файлов"

При следующем запросе ("заархивируй всё из папки") агент проверит план через guardrail, увидит что в папке есть .env, заблокирует действие и спросит: "в папке есть чувствительный файл, точно архивировать?"

Слабость LLM: Модели плохо предсказывают последствия действий через несколько шагов. План может выглядеть безобидно ("навести порядок в папках"), но привести к утечке данных в шаге 5 из-за побочного эффекта шага 2. Синтаксические проверки до выполнения ловят только явные нарушения ("удали ~/.ssh"), но пропускают семантически эквивалентные ("почисти старые ключи"). Превентивные guardrails всегда неполны — новые формулировки задач обходят старые правила.

Сильная сторона LLM: Модели отлично оценивают произошедшее по описанию на естественном языке. Вопрос "файл оказался в небезопасном месте?" не требует знать все возможные пути — модель видит текущее состояние среды и контекст, понимает семантику "небезопасно". Модели хорошо извлекают паттерны из конкретных случаев и формулируют общие правила ("если копируешь из скрытых папок → спрашивай").

Как метод использует это: AIR проверяет фактическое состояние после действия, а не намерение до него. Это даёт два преимущества:

1. Semantic checks вместо syntactic — не "агент вызвал опасную функцию?", а "произошло ли что-то опасное в среде?". Модель видит результат, а не только команду.

2. Learning loop — каждый обнаруженный инцидент превращается в guardrail-правило для будущего. Система не просто реагирует, а становится умнее с каждым инцидентом. В отличие от статических правил ("не удаляй файлы"), динамические правила учитывают контекст ("не копируй из системных папок в пользовательские без подтверждения").

Рычаги управления:

• Trigger (триггер) — какие инструменты проверять. Для задач только с браузером убери python_repl, оставь navigate_url. Меньше триггеров = меньше overhead.

• Check-условие — описание инцидента. Для простых задач используй специфичные ("файл .env скопирован"), для автономных агентов — широкие ("данные покинули защищённый периметр"). Чем шире — тем больше ложных срабатываний, чем точнее — тем меньше покрытие.

• Remediate-действия — что делать при инциденте. Можно только containment ("блокируй доступ"), можно full recovery ("удали копию + проверь окружение + восстанови оригинал"). Recovery дороже, но безопаснее.

• Guardrail generation — автоматически или вручную. Авто-генерация удобна, но может создать слишком широкие правила ("никогда не копируй файлы" вместо "не копируй чувствительные файлы"). Ручная настройка точнее, но требует времени.

Ты автономный агент для {описание задачи}. Используешь инструменты: {список инструментов}.

СИСТЕМА INCIDENT RESPONSE:

После каждого выполненного действия проверяй:

TRIGGER: {название_инструмента}
CHECK: "{описание_инцидента_на_естественном_языке}"

Если CHECK = True (инцидент обнаружен):

REMEDIATE:
  1. Containment: {действие_для_сдерживания}
  2. Recovery: {действие_для_восстановления}
  3. Останови текущую задачу
  4. GUARDRAIL для будущего: {правило_для_предотвращения_похожих_инцидентов}

GUARDRAIL применяется перед выполнением плана в следующих задачах.

---

Текущая задача: {конкретная_задача}

Что подставлять:

• {описание задачи} — роль агента: "файловая автоматизация", "веб-исследование", "обработка данных"
• {список инструментов} — какие инструменты доступны: python_repl, browser, file_manager
• {название_инструмента} — какой инструмент активирует проверку: например, python_repl для кода, browser.navigate для веба
• {описание_инцидента} — на естественном языке, семантически, не синтаксически. Не "функция X вызвана", а "чувствительные данные оказались в публичном месте"
• {действие_для_сдерживания} — что сделать чтобы остановить вред: "удали скопированный файл", "закрой доступ", "отмени транзакцию"
• {действие_для_восстановления} — что сделать чтобы вернуться к безопасному состоянию: "проверь нет ли других утечек", "восстанови из бэкапа"
• {правило_для_предотвращения} — формулировка guardrail для будущего: "перед копированием системных файлов проверяй назначение"

🚀 Быстрый старт — вставь в чат:

Вот шаблон AIR для incident response в агентах. Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.

[вставить шаблон выше]

LLM спросит про инструменты (какие используются), тип инцидентов (что считать небезопасным), действия (как исправлять) — потому что AIR требует понимания среды выполнения и критериев безопасности для этой конкретной задачи. Она возьмёт структуру "trigger → check → remediate → guardrail" и адаптирует под твой контекст.

⚠️ Overhead на многошаговых задачах: Каждый шаг требует проверки через CHECK-условие, что добавляет ~1-3 секунды на шаг. Для задач на 20+ шагов это заметно. Если нужна скорость — активируй проверки только для критичных инструментов.

⚠️ False positives на амбивалентных действиях: Семантические CHECK-условия иногда срабатывают там, где контекст оправдывает действие. Например, "файл перемещён в публичную папку" триггерится даже если это часть легитимной задачи ("опубликуй отчёт"). Требуется уточнение условий или ручное подтверждение.

⚠️ Irreversible incidents: Некоторые инциденты необратимы (удалённые файлы без версионирования, отправленные запросы в API). Recovery невозможен — остаётся только eradication через guardrails. Для критичных операций добавляй confirmation перед действием, не только incident response после.

⚠️ Guardrail rule drift: Автоматически сгенерированные guardrail-правила могут накапливаться и становиться слишком ограничивающими ("агент отказывается копировать любые файлы"). Требуется периодический review и уточнение правил.

⚠️ Не для простых задач одного шага: AIR создан для multi-step автономных агентов. Для задач "напиши текст" или "ответь на вопрос" это overkill — нет инструментов, нет состояния среды, нечего проверять.

Исследователи из Tianjin University (Китай) и Singapore Management University (Сингапур) — Zibo Xiao, Jun Sun, Junjie Chen.

Реализовали AIR как надстройку над OpenAI Agent SDK с интеграцией через хуки: (1) после выполнения инструмента для detection + remediation, (2) перед выполнением шага для guardrail-проверок. DSL (domain-specific language) для AIR-правил парсится через ANTLR4.

Тестировали на трёх типах агентов:

1. Code Agent — CodeAct + RedCode dataset (4000+ задач, 25 категорий рисков). Пример: агент получает задачу "навести порядок в файлах", случайно копирует .env в ./temp/. AIR обнаруживает через CHECK, удаляет копию, создаёт guardrail "не копируй системные файлы без проверки".

2. Embodied Agent — SafeAgentBench (750 задач, 10 типов угроз в физической симуляции). Пример: робот-агент берёт хрупкий предмет металлическим захватом слишком сильно. AIR обнаруживает "объект повреждён", направляет агента положить объект и use soft gripper, создаёт guardrail "для хрупких объектов проверяй тип захвата в плане".

3. Computer-Use Agent — RiOSWorld (risky tasks) + OSWorld (safe tasks). Пример: агент открывает файл с личными данными в браузере и случайно нажимает "Share". AIR обнаруживает "чувствительные данные в публичном интерфейсе", закрывает вкладку, создаёт guardrail "перед share-действиями проверяй тип контента".

Метрики: - successful execution — сколько задач привели к инциденту (не все risky tasks срабатывают) - successful detection — сколько инцидентов AIR поймал - successful remediation — сколько успешно устранил - successful eradication — сколько guardrail-правил предотвратили повторение

Результаты: - Detection rate: >90% (обнаруживает почти все инциденты) - Remediation success: >95% (успешно устраняет где это возможно) - Eradication success: >90% (сгенерированные guardrails работают)

Дополнительные находки: - LLM-generated rules vs manual: Автоматически сгенерированные AIR-правила (модель сама пишет trigger/check/remediate по описанию риска) работают почти так же эффективно как написанные вручную. Разница в detection rate <5%. - Timeliness: Проверка добавляет 1-3 сек на шаг. Для задач на 10 шагов overhead ~10-30 сек. - Ablation: Убрали structured remediation (только detection без contain/recover) — remediation success упал с 95% до 60%. Убрали guardrail generation — eradication упал с 90% до 0%. Все компоненты критичны.

Исследование показало: incident response не просто возможен в LLM-агентах — он необходим. Превентивные меры всегда неполны, reactive механизмы дополняют их.

Код и промпты: anonymous.4open.science/r/AIR-38FA

AIR: Improving Agent Safety through Incident Response — Zibo Xiao (Tianjin University), Jun Sun (Singapore Management University), Junjie Chen (Tianjin University)

Связанные работы из исследования: - NIST SP 800-61 (Computer Security Incident Handling Guide) — классическая методология incident response - AgentSpec (Wang et al., 2025) — DSL для guardrail rules в агентах - TraceAegis (Liu et al., 2025) — классификация risky trajectories - RedCode dataset (Guo et al., 2024) — 4000+ задач с рисками для code agents - SafeAgentBench (Yin et al., 2024) — 750 задач для embodied agents с hazard categories