Инцидент с AI-агентом — это инцидент с данными и доступом, но без привычных артефактов. Нет файла на флешке, есть промпт в TLS; нет «кто нажал», есть trace цепочки tool-вызовов. Без готового playbook расследование превращается в гадание, а повтор — вопрос времени.
Чем инцидент агента отличается
Три отличия от классического:
- Нет файла — есть промпт. Утечка — текст в JSON-поле
promptвнутри шифрованного вызова к LLM, а не файл на egress. - Нет человека — есть lineage. Агент действует по цепочке
человек → агент → tool, и атрибуция должна пройти всю линию. - Нет детерминизма — есть журнал. Два прогона одной задачи дают разный след, поэтому единственный источник правды — identity-bound журнал каждого вызова.
Если журнал не писался до инцидента, расследовать нечего.
Подготовка до инцидента
Готовность — это не документ, а данные:
- Журнал каждого tool-вызова с
trace_idзадачи, identity, scope/audience (RFC 8707), классификацией DLP и решением (allow/redact/route/block), latency и ошибкой/ретраем; - SLO на задачу (успешность, p95 латентности, стоимость, безопасность) — чтобы заметить деградацию до жалобы;
- Golden-набор с ловушками — кейсы, где правильный ответ «отказаться» (PII, секреты, деструктивные действия).
Без этого IR стартует с «кажется, что-то случилось», а не с trace_id.
Playbook 5 шагов
- Зафиксировать
trace_idи identity. Остановите агента для этого scope (circuit breaker), сохраните трейс, не трогайте логи. - Восстановить цепочку по журналу. Пройдите по
trace_id: какие tool-вызовы, с какими scope/audience, какие данные затронуты, какие DLP-решения. Свяжите каждый вызов с человеком-инициатором. - Отозвать доступ в одном месте. Отзовите access и refresh токены у authorization server, закройте scope, почистите каталог. Если секреты на ноутбуках — это обход команды; если в шлюзе — одна операция.
- Поставить блок на правило, которое не сработало. Добавьте DLP/политику, которая должна была остановить промпт, и включите её в monitor→block.
- Добавить кейс в golden-набор и в CI. Чтобы следующий агент упал в тесте, а не в проде. Без шага 5 цикл не замкнут.
Как не повторить: от IR к prevention
Каждый инцидент должен оставить артефакт в системе предотвращения:
- новый кейс в golden-наборе с ожидаемым
trace(какие инструменты должны / не должны вызываться); - метрика безопасности (доля попыток выйти за scope) в SLO;
- обновление runbook с деградацией (таймаут → fallback → human-in-the-loop).
Так IR кормит prevention, а не отчёт ради отчёта.
Где Codenik
Codenik — источник identity-bound журнала для IR: каждый вызов с проверенным audience, scope и DLP-решением, связанный в трейс задачи. На этом журнале строятся и расследование, и отзыв, и добавление кейса в CI — без сборки логов по каждому MCP-серверу вручную. Подробнее про жизненный цикл — в статье «Жизненный цикл AI-агента», про DLP — в «DLP для AI-агентов».
Короткий вывод
Готовьтесь до инцидента: пишите трейс каждого вызова с identity и scope, держите SLO и golden-ловушки. При инциденте — фиксируйте trace_id, восстанавливайте цепочку, отзывайте в одном месте, ставьте блок и добавляйте кейс в CI. Без журнала расследовать нечего.