Безопасность

5.4. AI Incident Response Playbook

TozheBot: безопасная ОС для ИИ-сотрудников

Версия документа: 1.0

Дата: 2026-10-22

Область применения: платформа TozheBot, агентный слой, библиотеки OGL-Mini и QuarkDash Crypto, проекты клиентов (тенантов).

Связь с другими артефактами: OWASP AISVS Self-Assessment, Risk Register, Permission Matrix.

1. Зачем этот документ и чем он отличается от обычного IR

Традиционный инцидент-респонс предполагает, что есть детерминированная система, известное место доказательств и понятная цепочка «код → баг → патч». В агентной системе это ломается: поведение недетерминировано, доказательства рассеяны по промптам, трейсам вызовов инструментов и состоянию памяти, а один инцидент может каскадно затронуть другие проекты и агентов за минуты, а не за часы. Поэтому этот плейбук — не замена обычного IR, а AI-глава к нему. Там, где работает классический процесс, он сохраняется. Там, где агентная специфика меняет правила, это явно указано.

Документ описывает платформенную часть (то, что TozheBot делает независимо от клиента) и тенантскую часть (то, что делает клиент в своём проекте в рамках предоставленных платформой инструментов и границ).

2. Классификация инцидентов

2.1. Три структурных типа инцидентов

Для агентных систем недостаточно делить инциденты по «критичности». Важно понимать тип, потому что от него зависят сдерживание и eradication-путь.

Тип A. Runtime execution escape.

Агент выходит за пределы песочницы: кросс-контейнерные операции, доступ к хостовой файловой системе, злоупотребление capabilities. Индикаторы ближе к классической безопасности, сдерживание — изоляция workload.

Тип B. Privilege boundary escape.

Агент использует легитимно выданные credentials способом, на который они не были авторизованы. Классический пример для TozheBot: агенту в проекте выдан тул с правом записи, но он вызывает его в контексте, где должно было сработать подтверждение или эскалация. Сдерживание — сужение scope credentials и отзыв конкретных прав, а не полная остановка платформы.

Тип C. Reasoning compromise.

Промпты, retrieved context или описания инструментов были скомпрометированы, и агент действовал на основе отравленного ввода. Это тип, у которого нет прямого аналога в традиционном IR. Сдерживание — не только остановка агента, но и карантин заражённого контекста, памяти и источников, которые в него попали.

2.2. Уровни серьёзности и целевое время реакции

Уровни задают ожидания по времени, а не бюрократию. Для агентных инцидентов минуты и часы важнее, чем в классическом IR, потому что каскад происходит на скорости машины.

CRITICAL (Red). Активная эксплуатация в продакшене, подтверждённая эксфильтрация данных, компрометация системы в процессе, массовое развёртывание вредоносных skills. Целевое время реакции: 1 час

HIGH (Orange). Подтверждён вредоносный компонент или tool, потенциально широкое воздействие, активная кампания. Целевое время: 4 часа.

MEDIUM (Yellow). Подозрительное поведение агента, потенциальная уязвимость, ограниченное воздействие. Целевое время: 1 рабочий день.

LOW (Blue). Незначительная находка, нарушение политики без немедленного риска. Целевое время: 1 неделя.

Отдельно: если инцидент затрагивает более одного тенанта, он автоматически поднимается минимум до HIGH, независимо от технической серьёзности, потому что мультитенантная граница — это доверие платформы.

3. Роли и границы ответственности

3.1. Платформенная сторона (TozheBot)

Incident Commander (IC) платформы. Единая точка принятия решений по инциденту. Ведёт инцидент, координирует фазы, принимает решение о масштабе сдерживания и о том, когда инцидент переходит в тенантскую зону.

Security On-Call. Первый получатель алертов от OGL-Mini, мониторинга аномалий и внешних сигналов. Классифицирует инцидент по типу и серьёзности, инициирует сдерживание в пределах платформенных контролей.

Platform Engineer / SRE. Отвечает за техническое сдерживание на уровне инфраструктуры: изоляция workload, отзыв credentials, ограничение egress, остановка конкретных runs или tool-исполнений.

Data / ML Owner. Отвечает за состояние RAG-индексов, памяти агентов и моделей. Определяет, какие источники и embeddings нужно карантинировать при reasoning compromise.

Communications / Legal. Подключается, когда инцидент затрагивает уведомления клиентов, регуляторные обязательства (ФЗ-152, EU AI Act Article 62/73) или публичные заявления.

3.2. Тенантская сторона (клиент в своём проекте)

Tenant Security Contact. Получает уведомления от платформы, принимает решения в рамках своего проекта: остановить ли конкретного агента, сузить ли список тулов, приостановить ли интеграцию.

Tenant Admin. Выполняет действия в интерфейсе или через API проекта: отключает агента, меняет Permission Matrix, отзывает тенантские секреты.

Tenant DPO / Compliance. Подключается, если инцидент затрагивает персональные данные в проекте клиента.

3.3. Совместная зона

Есть действия, которые платформа не может выполнить за тенанта, и наоборот. Платформа может отозвать credentials или изолировать workload, но не может решить за клиента, остановить ли его бизнес-процесс. Тенант может отключить своего агента, но не может изменить платформенные гарантии изоляции. Этот разрыв должен быть закрыт до инцидента: в контракте, в документации и в контактных данных, которые актуальны в 3 часа ночи.

4. Фаза 1: Подготовка (Prepare)

Подготовка — единственная фаза, которую можно сделать спокойно. Всё, что не сделано здесь, придётся импровизировать во время инцидента.

4.1. Инвентаризация и карта агентов.

Платформа должна иметь актуальный реестр агентов по каждому тенанту: Agent ID, проект, список тулов, уровень автономии, владелец. Без этого невозможно ни классифицировать инцидент, ни определить blast radius. Это же требование фигурирует в OWASP AISVS и в NIST AI RMF (реестр агентов и матрица прав).

4.2. Матрица эскалации и контакты.

Для каждого тенанта должны быть зафиксированы контакты для CRITICAL/HIGH инцидентов и порядок эскалации. Контакты проверяются не реже раза в квартал. Если контакт недоступен, платформа действует в пределах своих полномочий, но факт недоступности фиксируется как отдельный риск.

4.3. Предварительно согласованные сценарии сдерживания.

До инцидента должно быть решено, какие действия платформа может выполнять автоматически, а какие требуют подтверждения тенанта. Пример: остановка одного run или одного tool-исполнения — автоматически; приостановка всего проекта — с уведомлением тенанта; отзыв всех credentials проекта — только по решению IC с фиксацией причины.

4.4. Готовность доказательств.

Определить, какие артефакты сохраняются и как долго: prompt history, retrieved context с provenance, последовательность tool calls, agent identity assumptions, downstream invocations, LLM output trace. Это не «логи на всякий случай», а заранее определённый набор, без которого расследование reasoning compromise невозможно.

4.5. Тестирование.

Не реже раза в квартал — tabletop-упражнение по одному сценарию из этого плейбука. Не реже раза в полгода — технический прогон сдерживания: остановка агента, отзыв credentials, карантин RAG-источника. Результаты фиксируются, пробелы попадают в Risk Register. Ответственные со соторы платформы - технический директор проекта. Контакты для связи:

ilya@neurosell.top

5. Фаза 2: Обнаружение и первичный анализ (Detect & Triage)

5.1. Источники сигналов

Платформенные сигналы от OGL-Mini.

Срабатывания классификатора и эвристик: safe/risk, label, stage, latency. Это первый и самый быстрый слой, но не единственный. Один пропущенный prompt injection не означает, что инцидента нет; он означает, что сигнал пришёл из другого источника.

Поведенческие аномалии.

Аномальный вызов привилегированного тула, резкий рост глубины цепочки tool calls, зацикливание, аномалия стоимости (cost anomaly), дрейф eval-оценок. Для агентных систем поведенческие сигналы часто надёжнее сигнатур.

Сигналы целостности контекста.

Резкий сдвиг в retrieved context, несоответствие provenance источника, попытка агента передать большие объёмы данных во внешний endpoint через curl или аналогичный тул.

Внешние сигналы.

Сообщения от тенанта, исследователей безопасности, из threat intelligence. Для платформы с публичным лицом это важный канал, который нельзя игнорировать как «неподтверждённый».

5.2. Триаж: что определяем в первые 15 минут

Тип инцидента: A (runtime escape), B (privilege boundary), C (reasoning compromise) или комбинация.
Затронутые тенанты: один, несколько, все.
Активность: инцидент продолжается или уже прекратился.
Есть ли признаки эксфильтрации или необратимых действий (платёж, изменение данных, отправка наружу).
Требуется ли немедленное сдерживание до полного анализа. Правило: если есть сомнение между «подождать ещё пять минут» и «сдержать сейчас», выбирается сдерживание. Цена ложного сдерживания ниже цены каскада.

5.3. Фиксация решения о триаже

Решение о классификации и первые действия фиксируются в тикете инцидента с указанием времени и ответственного. Это не бюрократия: при пост-мортеме нужно отличать активность атакующего от активности responders.

6. Фаза 3: Сдерживание (Contain)

Сдерживание — самая время-чувствительная фаза. Главный принцип: не полагаться на скомпрометированного агента в деле собственной остановки. Использовать контроли, принадлежащие платформе, identity provider, очереди или downstream-сервисам.

6.1. Выбор минимально достаточного масштаба

Начинать с наименьшего scope, который реально сдерживает инцидент, и расширять только если это не сработало.

Уровень run. Остановить конкретный запуск агента. Подходит, если инцидент локализован одним выполнением.

Уровень agent. Остановить все runs конкретного агента, отозвать или сузить его credentials. Подходит при повторяющемся поведении.

Уровень tool. Отключить конкретный инструмент для агента или проекта. Подходит, когда проблема в одном канале воздействия.

Уровень tenant integration. Приостановить интеграцию (MCP-сервер, внешний API) для проекта. Подходит, когда затронут канал, общий для нескольких агентов.

Уровень project. Приостановить проект целиком. Применяется при риске кросс-агентного распространения внутри проекта или при неясном blast radius.

Уровень credential. Отозвать секреты проекта или конкретного агента. Применяется при подтверждённой компрометации или подозрении на privilege boundary escape.

6.2. Специфика по типам инцидентов

При runtime execution escape: изоляция workload, ограничение egress, отзыв capabilities. Доказательства собираются на уровне ядра и не должны прекращаться при убийстве пода, иначе теряется остаток цепочки.

При privilege boundary escape: сужение scope credentials, отзыв конкретных прав, проверка, не были ли действия выполнены до отзыва. Важно различать «агент пытался» и «агент выполнил».

При reasoning compromise: остановка агента недостаточна. Нужно карантинировать заражённый контекст, память и retrieved sources, иначе при перезапуске агент снова получит отравленный ввод. Проверить, не попал ли заражённый материал в общую RAG-базу проекта или в память других агентов.

6.3. Что фиксировать при сдерживании

Оператор, время, scope каждого действия. Это нужно, чтобы позже отличить действия responders от действий атакующего и чтобы аудит мог восстановить хронологию.

6.4. Уведомление тенанта

Уведомление отправляется параллельно сдерживанию или сразу после него, в зависимости от согласованного порядка. Для CRITICAL — немедленно, даже если полная картина ещё не ясна. В уведомлении: что известно, что уже сделано, что требуется от тенанта, когда будет следующее обновление.

7. Фаза 4: Расследование и устранение (Investigate & Eradicate)

7.1. Восстановление цепочки

Движение в две стороны. Назад: от нежелательного действия к первому управляемому входу — какой промпт, какой retrieved документ, какой tool description, какое сообщение пользователя или внешний источник. Вперёд: от этого входа через все использования затронутых credentials, ресурсов и сохранённой памяти — не затронуты ли sibling runs, другие агенты, другие проекты.

Для reasoning compromise это ключевая часть: без восстановления provenance невозможно понять, был ли агент скомпрометирован, манипулирован или действовал на основе отравленного контекста.

7.2. Шесть форензических артефактов

Для агентного инцидента минимальный набор, который нужно сохранить до изменения конфигурации: prompt history с таймстампами, retrieved context с указанием источника, последовательность tool calls, agent identity assumptions по цепочке, downstream invocations, LLM output trace. Если какой-то артефакт отсутствует, это фиксируется как пробел в доказательствах, а не игнорируется.

7.3. Eradication

Удаление root cause, а не только симптома. Если причина — дыра в гардрейле, патчится гардрейл. Если причина — over-privileged tool, меняется Permission Matrix и, при необходимости, платформенное ограничение сверху. Если причина — отравленный источник в RAG, источник удаляется или помечается, а затронутые embeddings пересчитываются.

Для платформенных контролей: если инцидент выявил пробел в OGL-Mini или в изоляции, это изменение проходит через обычный процесс версионирования и тестирования. Не «тихий хотфикс в продакшене», а изменение с записью в Risk Register.

7.4. Проверка, что инцидент не продолжается

Перед восстановлением доступа убедиться, что активные runs остановлены, credentials отозваны или перевыпущены, очереди и scheduled continuations проверены. Остановка чат-интерфейса не останавливает другие execution paths.

8. Фаза 5: Восстановление (Recover)

8.1. Критерии возврата

Восстановление доступа происходит только когда: root cause устранён, доказательства сохранены, затронутые credentials перевыпущены, заражённый контекст карантинирован или очищен, и есть подтверждение, что инцидент не воспроизводится в контролируемых условиях.

Для тенантских агентов возврат в строй согласуется с тенантом. Платформа может восстановить техническую возможность, но решение о возобновлении бизнес-процесса принимает клиент.

8.2. Постепенный возврат

Предпочтителен поэтапный возврат: сначала один агент или один run, затем расширение. Это позволяет поймать остаточную проблему до полного восстановления нагрузки.

8.3. Мониторинг после восстановления

Усиленный мониторинг на период не менее 72 часов для CRITICAL и HIGH: аномалии tool calls, cost anomaly, дрейф eval, повторные срабатывания OGL-Mini по тем же паттернам.

9. Фаза 6: Пост-инцидентный разбор (Post-Incident Review)

9.1. Что разбирается

Не «кто виноват», а «какой контроль не сработал и почему». Для агентных инцидентов отдельно разбирается: был ли сигнал обнаружен вовремя, было ли сдерживание минимально достаточным, сохранились ли доказательства, не пострадали ли другие тенанты, сработала ли граница платформа/тенант.

9.2. Результаты, которые должны появиться

Обновление Risk Register. Обновление Permission Matrix, если инцидент связан с правами. Обновление этого плейбука, если сценарий не был покрыт. Запись в реестр инцидентов для аудита (это же требование фигурирует в OWASP AISVS 12.6.1). При необходимости — уведомление регулятора или клиентов в сроки, установленные законом и договором.

9.3. Сроки

Для CRITICAL — разбор в течение 5 рабочих дней после закрытия. Для HIGH — 10 рабочих дней. Для MEDIUM и LOW — в рамках обычного цикла улучшений. Просроченный разбор сам по себе является риском и фиксируется.

10. Специфика мультитенантности: что нельзя терять из виду

10.1. Граница проекта — это граница доверия.

Если инцидент начался в одном проекте, первый вопрос: не вышел ли он за пределы проекта. Изоляция проекта не должна зависеть от корректности конфигурации агента клиентом; она должна обеспечиваться платформой.

10.2. Общие ресурсы — источник каскада.

Общая RAG-база, общие MCP-серверы, общие очереди и общие embeddings — потенциальные пути распространения. При reasoning compromise проверяются не только агенты тенанта, но и всё, что использует тот же источник.

10.3. Уведомление нескольких тенантов.

Если затронуто более одного тенанта, координация уведомлений становится отдельной задачей. Шаблон уведомления должен быть готов заранее, с местами для конкретики, а не сочиняться в момент инцидента.

10.4. Ответственность за действия агента тенанта.

Платформа обеспечивает технические границы и обнаруживает инциденты, но решение о бизнес-последствиях в проекте принимает тенант. Это должно быть явно записано в договоре и в документации, иначе в момент инцидента начнётся спор о зоне ответственности вместо сдерживания.

11. Минимальный чек-лист готовности (для быстрой проверки)

Реестр агентов по тенантам актуален.
Контакты эскалации по тенантам проверены в этом квартале.
Сценарии автоматического и требующего подтверждения сдерживания зафиксированы.
Набор сохраняемых форензических артефактов определён и работает.
Tabletop-упражнение проведено не позже квартала назад.
Технический прогон сдерживания (остановка агента, отзыв credentials, карантин источника) проведён не позже полугода назад.
Шаблон уведомления тенанта готов.
Ответственный за AI Security назначен и известен on-call.

Если хотя бы один пункт не выполнен, это не блокирует запуск плейбука, но фиксируется как известный пробел в готовности.