Перейти к основному содержимому
Продвинутый•10–16 часов

Учения по локализации инцидента безопасности ИИ

Отработайте специфичный для ИИ инцидент, где prompt injection или скомпрометированный инструмент уже повлиял на production workflow. Постройте сохраняющую доказательства локализацию, reconciliation, ограниченный rollback и закрытие регрессии.

реагирование на инцидентылокализацияфорензикаreconciliationrollbackрегрессия безопасности

Сценарий

Задача

После indirect prompt injection production-агент вызвал write tool, а timeout оставил финальное состояние неизвестным. Недостаточно просто отключить модель: сохраните доказательства, ограничьте blast radius, проверьте авторитетный system of record, отзовите скомпрометированную capability и безопасно восстановите сервис.

Пошаговое выполнение

1. Классифицируйте инцидент и зафиксируйте доказательства

Результат: Команда знает, что произошло и какой runtime envelope был активен.

Задачи

  • →Зафиксируйте версии модели, prompt, retrieval и tools
  • →Сохраните traces без лишних secrets
  • →Определите user, session и tool identities
  • →Отделите подтвержденные эффекты от предполагаемых

Проверки

  • ✓Audit trail не переписывается задним числом
  • ✓Чувствительные доказательства имеют контроль доступа

2. Ограничьте только необходимый blast radius

Результат: Опасная capability остановлена без ненужного полного отключения системы.

Задачи

  • →Отключите затронутый write tool или scope
  • →Отзовите скомпрометированный credential
  • →Переведите workflow в degraded или read-only mode
  • →Заблокируйте известный вредоносный источник

Проверки

  • ✓Локализация не зависит от поведения модели
  • ✓Критический action path больше недоступен

3. Выполните reconciliation до retry

Результат: Неизвестные side effects сверены с авторитетным источником до любого повторного выполнения.

Задачи

  • →Проверьте system of record
  • →Сопоставьте idempotency keys
  • →Найдите частичные или дублированные записи
  • →Отметьте ожидающий ручной ремонт

Проверки

  • ✓Нет blind retry после timeout
  • ✓Каждое неопределенное действие имеет подтвержденное финальное состояние или явного ручного владельца

4. Восстановите known-good и закройте регрессию

Результат: Сервис возвращается контролируемо, а причина инцидента не может незаметно повториться.

Задачи

  • →Откатите затронутый behavior envelope
  • →Запустите security replay
  • →Проведите canary и failback
  • →Минимизируйте exploit
  • →Добавьте постоянный regression case

Проверки

  • ✓Восстановление проверено postconditions
  • ✓Регрессия блокирует повтор критического attack path

Критерии приёмки

  • Хронология инцидента содержит runtime fingerprint
  • Локализация ограничена и независима от model compliance
  • Reconciliation неизвестных side effects завершена до retry
  • Known-good восстановление подтверждено авторитетными postconditions
  • Production exploit стал постоянным regression test