AI Incident Response

Enterprise AIでは、従来のサーバ／アプリ障害や侵害だけでなく、モデル挙動劣化、prompt injection、RAG汚染、agentの誤実行、外部tool/API悪用、モデル／prompt／workflow更新による品質退行などが「AIシステムとしてのincident」になり得る。通常のCSIRT/SREを置換するのではなく、既存IRへAI固有の観測性、制御性、provenance、評価再現性、モデル・データ・tool・agent経路の隔離を追加する必要がある。

Enterprise AI Core / Operations / Security / Governance / AgentOps / AI-SRE / provider mapping / organization overlay / interoperability / implementation

• AI Incident Responseは既存cyber incident responseと何を共有し、何を追加すべきか。
• AI incidentを検知・分析・封じ込め・復旧・事後分析するために、どのtelemetry/provenance/controlが最低限必要か。
• 2026-09-14時点でAI固有IRは確立済み標準なのか、それとも複数のguidance／draftが収束中の段階か。

• Source class: official standard/guidance Exact title: NIST SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile Author/org: Alexander Nelson, Sanjay Rekhi, Karen Scarfone, Murugiah Souppaya / NIST Canonical URL: https://csrc.nist.gov/pubs/sp/800/61/r3/final Publication/update/access: published April 2025; accessed 2026-09-14 Version: SP 800-61r3 Final; DOI 10.6028/NIST.SP.800-61r3 Supporting locator: abstract / final publication status / CSF 2.0 integration Evidence label: VERIFIED_SPEC Relation: support/context Claim supported: incident responseは組織のcybersecurity risk management全体へ統合され、detection, response, recoveryを含む基礎IRとして使用できる。Rev.3はRev.2をsupersedeする。

• Source class: official AI risk management guidance Exact title: NIST AI RMF Playbook — MANAGE 4.1 Author/org: NIST Canonical URL: https://airc.nist.gov/airmf-resources/playbook/manage/ Publication/update/access: current page accessed 2026-09-14 Version: AI RMF Playbook associated with NIST AI RMF 1.0 Supporting locator: MANAGE 4.1, post-deployment monitoring; decommissioning, incident response, recovery, change management Evidence label: VERIFIED_SPEC Relation: support/context Claim supported: post-deployment monitoring plans should connect monitoring with incident response, recovery and change management; degradation, attacks, unexpected behavior and near-misses are monitoring targets.

• Source class: official AI risk management profile Exact title: Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile Author/org: NIST Canonical URL: https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf Publication/update/access: July 2024; accessed 2026-09-14 Version: NIST AI 600-1 Supporting locator: Appendix A.1.8 Incident Disclosure, pp.55ff.; incident definition; logging/reporting/version history/metadata discussion Evidence label: VERIFIED_SPEC Relation: support/context/limit Claim supported: AI incident情報の記録・報告・共有、change records、version history、metadataはincident managementを支える。一方、文書刊行時点のincident reporting ecosystemは未成熟と記述されており、2026年の現行状態へそのまま外挿してはならない。

• Source class: official national guidance / AI-specific IR approach Exact title: AI Incident Response Approach Book / AI-IRS v1.0 Author/org: AI Safety Institute, Japan (J-AISI) Canonical URL: https://aisi.go.jp/activity/activity_security/260109/ ; full text https://aisi.go.jp/assets/pdf/ai-irs_v1.0_ja.pdf Publication/update/access: 2026-01-09; accessed 2026-09-14 Version: AI-IRS v1.0 Supporting locator: pp.3-7, 9, 12ff.; observability/controlability; mapping to NIST SP 800-61r3; model/RAG/agent/API paths Evidence label: SOURCE_REPORT / VERIFIED_SPEC Relation: support/context Claim supported: AI-IRSは既存IRを置換せず、AI特有のunobservable/uncontrollable状態へ「観測性」と「制御性」を追加する。観測対象にはmodel, data, external API, RAG, agent decision path等が含まれる。

• Source class: official NIST current-state report Exact title: Challenges to the Monitoring of Deployed AI Systems Author/org: NIST Canonical URL: https://www.nist.gov/news-events/news/2026/03/new-report-challenges-monitoring-deployed-ai-systems Publication/update/access: published 2026-03-09; updated 2026-03-18; accessed 2026-09-14 Version: 2026 report/news release Supporting locator: monitoring gaps: degradation/drift detection, fragmented logging, lack of trusted guidelines/standards, immature information-sharing ecosystem, scaling human monitoring Evidence label: SOURCE_REPORT / RESEARCH Relation: counter/limit Claim supported: AI incident detectionの前提となるpost-deployment monitoring自体に2026年時点で未解決の技術・運用gapが残る。

• Source class: official standards-development workshop Exact title: NIST Workshop on AI Incident Management Author/org: NIST Canonical URL: https://www.nist.gov/news-events/events/2026/05/nist-workshop-ai-incident-management Publication/update/access: created 2026-03-31; updated 2026-05-27; workshop 2026-05-14; accessed 2026-09-14 Version: 2026 workshop/roadmap activity Supporting locator: scope/agenda — definitions, lifecycle, taxonomy, gaps in current cyber/AI guidance, future guidelines Evidence label: SOURCE_REPORT Relation: limit/context Claim supported: NIST自身が2026年にAI incident managementの定義・lifecycle・taxonomy・guidance gapを検討中であり、AI固有IRの単一・完成済み国際標準が確立したとは言えない。

• Source class: international standard under development Exact title: ISO/IEC AWI 25870 — Information technology — Artificial intelligence — Data elements for reporting AI system incidents Author/org: ISO/IEC JTC 1/SC 42 Canonical URL: https://www.iso.org/standard/91804.html Publication/update/access: project approved 2025-07-07; status checked 2026-09-14 Version/status: Edition 1, stage 20.00 / Working Draft preparation Supporting locator: ISO project status page Evidence label: VERIFIED_SPEC / PROPOSAL Relation: context/limit Claim supported: AI incident reporting data elements are being standardized, but 25870 is not yet a published final International Standard.

• Enterprise AIのIRは、NIST SP 800-61r3等の既存IRを基礎にするのが安全であり、別物として独立運用する根拠は弱い。
• AI固有追加層の中核は、(a) observability、(b) controllability、(c) model/prompt/data/RAG/tool/workflow/version provenance、(d) AI-specific impact and behavior assessment、(e) supply-chain/provider coordinationである。
• Detection対象をsecurity alertだけに限定してはいけない。品質劣化、drift、unexpected behavior、near-miss、policy violation、tool misuse、agent trajectory異常もincident candidateになり得る。
• 証拠保存では、input/output全文を無条件保存する設計ではなく、privacy/securityを踏まえつつ trace ID, model/version, prompt/config version, retrieval source/index version, tool/action/result, policy decision, actor/delegation, timestamps, evaluator version, deployment/workflow revisionを相関可能にすることが重要。
• containmentはmodel停止だけではなく、model endpoint、tool/API、credential、RAG source/index、agent module、workflow routeなど複数のcontrol pointを持つべきである。
• recoveryは「モデルを戻す」だけでは完了しない。外部へ既に生じた副作用、汚染されたindex/data、credential漏洩、queue中の未処理action、downstream system状態を別途確認する必要がある。
• post-incident reviewでは従来のroot causeだけでなく、model/prompt/tool/data/config/evaluatorのversion provenanceと再現可能なtrajectory/evaluationを残すと、再発防止の検証可能性が上がる。

• AI固有IRは2026-09-14時点で単一の完成済み国際標準に収束していない。J-AISI AI-IRSは有力な現行guidanceだがbinding standardではない。ISO/IEC 25870は開発中。
• NIST 2026 monitoring reportは、drift/degradation detection、logging fragmentation、guideline不足、information sharing未成熟を挙げる。したがって「十分なtelemetryを入れれば必ずincidentを検出できる」とは書けない。
• GenAI profileの2024年時点の「formal reporting channels不足」は歴史的contextであり、2026年の現況主張には再確認が必要。
• provider public docsは特定tenantのlogging retention、regional availability、admin controls、forensic export能力の証明にはならない。
• incident判定thresholdが厳しすぎるとnoise/alert fatigue、緩すぎるとsilent failureを招く。AI evaluator自体にも誤判定があるため、自動judgeだけをincident ground truthにしない。

• AI-IRSは公開guidanceであり利用可能だが、個々のproviderで必要なtrace/log/control pointが取得可能かはproduct/plan/region/admin setting依存。
• 規制上の「serious incident reporting」はjurisdiction/system classification/適用時期で変わるため、将来本文では法域別overlayとしてcurrent consolidated lawを再確認すること。
• ISO/IEC 25870は未完成のため、published standardとして引用しない。

推奨Core runbook構造（PROPOSAL, evidence-backed design）: DETECT -> TRIAGE -> PRESERVE -> CONTAIN -> ERADICATE/CORRECT -> RECOVER -> VERIFY -> POST-INCIDENT. AI追加チェックポイント: 1. model/prompt/workflow/tool/RAG/data/evaluator version固定 2. trace/actor/delegation/credential/tool-action chain相関 3. local containment target特定 4. provider/dependency/supply-chain連絡経路確認 5. known-good revisionでreplay/eval 6. external side effectsとdata/index汚染を個別確認 7. postmortemからmonitor/policy/eval/runbookへfeedback

Incident Response自体に単一benchmarkは適用しにくい。評価はtabletop/game-dayで行い、少なくとも MTTD, MTTA, MTTC(containment), MTTR, evidence completeness, affected-action scope, rollback/recovery success, false positive/false negative, policy escape count を測る案が妥当。これはPROPOSALであり、NIST/J-AISIが共通SLO値を保証しているわけではない。

incident時にagent/tool credential revoke、endpoint/tool isolation、policy denyを独立経路から実行できること。

forensic logへprompt/output/PII/secretsを過剰保存しない。必要なprovenanceとcontent retentionを分離する。 AUDIT: immutable/tamper-evidentなevent correlation、変更履歴、version metadataが望ましい。

full-content logging、long retention、continuous evalは大きなstorage/eval costになり得るためrisk tierで調整。

human escalation owner、severity分類、provider escalation、evidence capture、containment authorityを平時にrunbook化する。

「AI Incident Responseは既存のサイバーIRを置き換える別制度ではない。2026年時点の有力な実務方向は、既存IRへAIシステムの観測性・制御性・version provenance・model/data/tool/agent経路の分析を追加することである。ただしAI固有incident managementの標準化は進行中であり、特定のtaxonomyやreporting schemaを普遍的完成標準として扱うべきではない。」

• 公開後更新時、NIST AI incident managementの正式guideline、ISO/IEC 25870 status、主要providerのincident/export/trace controlsを再確認。
• EA-051 Telemetry、EA-052 AgentOps/AI-SRE、EA-054 Kill Switch/Rollbackとcross-reference。
• provider mappingでは「ログがあるか」「containmentできるか」「revisionを指定して戻せるか」「credential/toolを切れるか」「forensic exportできるか」を別欄にする。
• organization overlayとしてseverity/authority/escalation/reporting obligationを定義する。

• NIST AI Incident Management workshopから正式guidanceへ移行する時期・最終taxonomy。
• ISO/IEC 25870 final schemaとpublication date。
• provider横断で共通化できるAI incident evidence minimum set。

上記標準・guidanceがfinal化、または主要provider control mappingを更新する必要が生じた時点で再採集。現時点の初回Packetは採否判断に十分。

---

---

AI Incident Response extends existing cyber IR with AI-specific observability, controllability, provenance and model/data/tool/agent-path analysis; it is not a completed universal AI incident-response standard. ISO/IEC 25870 status must use the audit revision: Committee Draft consultation stage 30.20 as of 2026-09-21, still under development, superseding the authority packet's older stage-20.00 snapshot. Preserve NIST/J-AISI guidance boundaries and all OPEN_UNKNOWN.