#AI-агенты: инцидент-плейбук

Версия: 1.0 · Обновлено: 2026-05-28 · Теги: AI-агенты, incident response, prompt injection, отравление памяти, компрометация коннектора · Tier: 1-4

TL;DR. Первичная реакция на пять характерных сценариев: инъекция инструкций, неправильное использование инструмента, проблема с памятью, компрометация коннектора, потеря свидетельств. Каждый сценарий — фиксированные первые 60 минут, ответственный, артефакты.

#1. Общие принципы реагирования

Базовый процесс IR (триаж → сдерживание → eradication → recovery → lessons learned) остаётся. Дополнительно для агентов:

flowchart LR
    A[Сигнал /<br/>alert] --> T[Триаж<br/>≤ 15m]
    T --> C{Тип<br/>инцидента?}
    C -->|инъекция| I1[Pause + snapshot<br/>memory + logs]
    C -->|tool misuse| I2[Restricted +<br/>отзыв подтверждений]
    C -->|память| I3[Pause + freeze<br/>memory partition]
    C -->|коннектор| I4[Quarantine<br/>connector + rotate]
    C -->|evidence loss| I5[Лог-форензика +<br/>пакет подтверждений]
    I1 & I2 & I3 & I4 & I5 --> CONT[Сдерживание]
    CONT --> ER[Eradication +<br/>fix root cause]
    ER --> REC[Recovery +<br/>re-approval]
    REC --> LL[Lessons learned +<br/>update overlays]

    classDef alert fill:#ef4444,stroke:#dc2626,color:#fff
    classDef act fill:#f59e0b,stroke:#d97706,color:#1b1d22
    classDef rec fill:#10b981,stroke:#059669,color:#fff
    class A alert
    class T,C,I1,I2,I3,I4,I5,CONT,ER act
    class REC,LL rec

[!warn] Первое действие при любом подтверждённом инциденте — создать snapshot состояния памяти и журнала событий. Если это не сделать в первые 15 минут, дальше следы будут утеряны.

#2. Инъекция инструкций (prompt injection)

Признаки:

• ответ модели содержит признаки обхода системного промпта;
• появилось действие tool.call, не предусмотренное сценарием;
• появилась попытка отправить данные на внешний URL;
• зафиксированы Unicode-zero-width / homoglyph-маркеры во входных данных.

Первые 60 минут:

Шаг	Действие	Ответственный
1	Snapshot журнала событий за последние 24 часа	SecOps
2	Изоляция входящего канала (URL / документ / источник)	Владелец агента
3	Переход в Paused	Владелец / SecOps
4	Анализ цепочки: что прочитал агент, что попытался сделать	MLSec
5	Если выполнено write-действие — откат или компенсирующая операция	Владелец агента
6	Проверка не утекли ли данные через tool.call аргументы	MLSec + DLP

Eradication:

• санитизация входящих документов (вырезание prompt-маркеров);
• ограничение outgoing URL по allow-list;
• усиление защитных проверок: добавить пример в agent-security-evals-minimal.md;
• ревью системного промпта.

#3. Неправильное использование инструмента (tool misuse)

Признаки:

• агент использовал инструмент за пределами утверждённой области;
• множественные повторы одного действия (нет идемпотентности);
• действие выполнено без согласования, хотя требовалось;
• расходование квоты выше базового профиля.

Первые 60 минут:

Шаг	Действие	Ответственный
1	Перевод в Restricted: блок write-инструментов	Автомат / Владелец
2	Отзыв подтверждений согласования по затронутому действию	SecOps
3	Snapshot журнала и состояния инструмента	Владелец агента
4	Откат write-действий, где возможно	Владелец агента
5	Уведомить операторов согласования	MLSec

Eradication:

• сужение области действия в карточке инструмента;
• добавление идемпотентности или согласования;
• защитная проверка на «вызов вне области».

[!info] Tool misuse часто не вина инструмента, а нечётко описанная область действия. Если карточка инструмента позволяет «писать в любой namespace», ожидать «писать только в свой» — ошибка проектирования.

#4. Проблема с памятью (memory poisoning / leak)

Признаки:

• ответы агента ссылаются на факты, которых не было в текущей сессии;
• появились записи в памяти, не соответствующие назначению (off-purpose);
• межпользовательская утечка: пользователь А видит данные пользователя B;
• срок хранения нарушен.

Первые 60 минут:

Шаг	Действие	Ответственный
1	Заморозка партиции памяти (read-only)	SecOps
2	Snapshot всей долгосрочной памяти на момент инцидента	SecOps
3	Переход в Paused	Владелец агента
4	Сравнение фактических записей с agent-memory-governance-template	MLSec
5	Идентификация скомпрометированных записей: источник, время, автор	MLSec
6	Уведомление subject'ов (если PII утекли)	Compliance + Legal

Eradication:

• удаление скомпрометированных записей с фиксацией в журнале;
• усиление политики записи: проверка назначения, источника, классификации;
• добавление детектора отравления (аномалия в распределении записей);
• ревью прав сервисной УЗ на запись в память.

[!ru] При утечке ПДн через память — требуется уведомление субъектов согласно 152-ФЗ ст. 21. Уведомление РКН в течение 24 часов о факте инцидента, 72 часа — отчёт о принятых мерах.

#5. Компрометация коннектора

Признаки:

• активность коннектора вне обычного профиля (время, объём, регион);
• использование коннектора в обход агента (прямые вызовы извне);
• появление новых grants/permissions у сервисной УЗ;
• срабатывание DLP на исходящем трафике коннектора.

Первые 60 минут:

Шаг	Действие	Ответственный
1	Карантин коннектора по runbook-connector-quarantine.md	SecOps
2	Ротация сервисной учётной записи	SecOps + IAM
3	Перевод агента в Paused или Kill-switch	Владелец агента
4	Snapshot журнала коннектора и связанных платформенных логов	SecOps
5	Поиск горизонтальных движений (что ещё мог использовать атакующий)	IR
6	Оценка scope утечки	MLSec + Compliance

Eradication:

• сужение области сервисной УЗ до минимально необходимой;
• введение secondary-проверки IP-allowlist / mTLS на стороне коннектора;
• усиление мониторинга профиля поведения;
• ревью всех делегированных полномочий с этим коннектором.

#6. Потеря свидетельств (evidence loss)

Признаки:

• разрыв в журнале событий runtime;
• расхождение между SIEM и реестром инцидентов;
• отсутствие записи согласования для выполненного действия;
• не сохранён snapshot памяти на момент существенного изменения.

Первые 60 минут:

Шаг	Действие	Ответственный
1	Идентификация окна потери (от/до)	SecOps
2	Поиск альтернативных источников: метрики, traces, логи коннекторов	SecOps
3	Если действие выполнено без свидетельств — откат, если возможно	Владелец агента
4	Уведомление аудита	Compliance
5	Регистрация потери в IR-системе с тегом evidence-loss	IR

Eradication:

• ревью пайплайна доставки событий (буферы, потери под нагрузкой);
• введение pre-commit-проверки наличия записи согласования перед action.execute;
• регулярная контрольная подача agent.start / agent.stop для проверки канала.

#7. Сводная таблица

Тип инцидента	Сразу	Первый час	Eradication
Инъекция	Snapshot + Paused	Анализ цепочки, откат write	Санитизация ввода, allow-list URL
Tool misuse	Restricted + отзыв подтверждений	Snapshot, откат	Сужение области, идемпотентность
Память	Freeze memory + Paused	Сравнение с шаблоном, идентификация	Удаление, политика записи, детектор
Коннектор	Quarantine + ротация	Поиск горизонтальных движений	Сужение УЗ, mTLS, мониторинг
Evidence loss	Регистрация в IR	Поиск альтернативных источников	Pre-commit проверка, контрольные события

#8. Подтверждения после инцидента

Перед возвратом в Production требуется evidence pack:

• хронология событий;
• snapshot до/после;
• список выполненных и откатанных действий;
• список затронутых субъектов (если PII);
• root cause + меры по предотвращению;
• обновлённые защитные проверки;
• статус согласований;
• статус мониторинга и алертов.

#9. Связь с другими документами

• Базовый процесс IR — внешний документ (не подменяется этим).
• Переходы Paused / Kill-switch — Runtime Procedure §6-7.
• Защитные меры — Security Overlay.
• Возврат в Production — Production Readiness Checklist.

[!ok] Самое ценное после инцидента — это обновлённый набор защитных проверок. Если по итогам не появилось новой проверки в agent-security-evals-minimal.md — eradication не завершён.