Incident Management and Analysis with AI

An incident tests every earlier investment in governance, identification, protection and detection under pressure: someone must decide, with incomplete information and little time, that an incident exists, how serious it is, what has happened and which obligations it triggers. AI can shorten almost every step. It can also produce a confident, plausible and wrong account of what happened, and an organisation that acts on it unchecked may contain the wrong systems, report the wrong facts to a supervisor or miss the attacker who is still present.

This chapter applies AI to incident management and analysis without loss of command or defensibility. It is responsible for two Categories of NIST CSF 2.0 in the Respond Function: RS.MA Incident Management, under which the incident response plan is executed with relevant third parties once an incident is declared, and incidents are triaged, categorised, prioritised and escalated, and RS.AN Incident Analysis, under which investigations establish what took place and its root cause, record the actions taken, preserve the integrity and provenance of incident data and estimate the magnitude of the incident (19, NIST, 2024). NIST's revised incident response guidance, SP 800-61 Rev. 3, organises incident response around the CSF 2.0 Functions rather than a separate lifecycle, treating Govern, Identify and Protect as preparation and Detect, Respond and Recover as the response itself (21, NIST, 2025). The chapter treats both Categories through the three focus areas of the NIST Cyber AI Profile (20, NIST, 2025), with particular attention to incidents in which an AI system or agent is itself the subject of the investigation.

Incident management from declaration to defensible analysis, with agents in scope and chain of custody

Figure 20.1: Incident management from declaration to defensible analysis, with agents in scope and chain of custody.

Incident management with AI

The starting point is a conclusion from Architecture as Code (Chapter 9B): manual incident response cannot scale when attacks develop within minutes, compromised components should be redeployed from known-good definitions rather than repaired by hand, and the programme is measured by mean time to detect, mean time to respond and the false-positive ratio (71, Nordqvist, 2025). This chapter builds on that conclusion (F5 in SERIES_FOUNDATIONS.md) and adds the condition that makes it safe: AI speeds up the work of the incident, but the incident remains under human command.

Declaration

Declaration gives an event an owner, a record and a set of obligations. CSF 2.0 expects incident reports to be triaged and validated, incidents to be categorised and prioritised, and incidents to be escalated or elevated as needed (19, NIST, 2024). Many organisations lose time here through hesitation. AI shortens it by assembling the case from the alerts, affected assets and their criticality (Chapter 9), testing it against declaration criteria written down in advance, such as "any tool call by a production agent outside its permission manifest", and paging the person who holds the decision with a proposed severity.

The criteria are the essential part, because at machine speed there is no time to debate whether an event qualifies. They are agreed, versioned and tested beforehand, and should prefer early declaration with a later downgrade to late declaration with an apology, because an incident declared after six hours of hesitation may already have missed a reporting clock.

Prioritisation

Prioritisation decides which incidents and systems receive scarce people first. AI can rank by business impact, by exposure (Chapter 11) and by adversary progress mapped to MITRE ATT&CK, or to MITRE ATLAS where AI systems are targeted (10, MITRE, n.d.) (11, MITRE, n.d.). However, a service missing from the map ranks low because it is missing, so the proposal shows its inputs and their age, and the incident commander can override it with a recorded reason.

Coordination

Coordination is where the most instructive recent incident failed. AI Governance, Chapter 19, concluded that the July 2026 OpenAI–Hugging Face incident failed through correlated controls: a shared credential, a package mirror that was also an egress path (64, OpenAI, 2026), and an alert that, on that reading, reached people who did not hold the stop decision (72, Nordqvist, 2026): OpenAI's report records that on 27 June its on-call staff advised that stopping the evaluation run was not required, and OpenAI has committed to clarifying decision rights for pausing or terminating affected activity (64, OpenAI, 2026). This chapter builds on that conclusion (F14). The last is a coordination failure, and not specific to AI: an alert that reaches someone who cannot act on it has, in practice, not arrived.

Decision rights must therefore be explicit before any incident begins: the incident commander decides, the technical lead directs analysis, a scribe keeps the record, and system owners, including AI system owners, and the legal, data-protection and communications functions join when classification says they must. CSF 2.0 expects the plan to be executed in coordination with relevant third parties (19, NIST, 2024), which for a large European organisation includes MSSPs, cloud and AI providers, the national computer security incident response team (CSIRT) and, where applicable, the supervisor.

AI is most useful as the scribe's assistant, keeping a running log, drafting status updates and reminding the commander when a decision falls due, such as the criteria for initiating recovery, the last outcome of RS.MA (Chapter 22) (19, NIST, 2024). It must not become the record of decisions, which a supervisor or court will read, so people write or confirm that log.

Timelines and scoping

Log analysis and correlation

An incident leaves traces in many sources, each with its own format, clock and identifiers, and AI is well suited to normalising them, resolving the same user or workload across sources, correlating events and mapping the sequence to ATT&CK or ATLAS techniques (10, MITRE, n.d.) (11, MITRE, n.d.).

Three disciplines keep the result trustworthy: queries are deterministic, recorded and re-runnable, separate from interpretation; log content, often written by the adversary, is untrusted, so the analysis service holds read-only access and proposes rather than acts; and hypotheses stay hypotheses until an analyst confirms them.

Timeline reconstruction

In an AI-assisted timeline every entry points to the events it derives from, by source and identifier; a narrative such as "the attacker then moved to the file server" must rest on cited authentication, process and network events. The timeline also shows its gaps, because absence of evidence is a finding, and AI can detect gaps systematically by comparing expected sources with those present.

Impact queries and scoping

CSF 2.0 expects an incident's magnitude to be estimated and validated (19, NIST, 2024). AI Platform and Security, Chapter 21, added an impact query against the event log, listing which decisions each model version made in the affected period (73, Nordqvist, 2026). This chapter builds on that conclusion (F24): every scoping question should, where possible, become a query that can be re-run and shown to someone else.

AI Governance, Chapter 24, left an open question for this book (Q5): how organisations prepare for a stream of smaller agent incidents of the same shape inside enterprises (72, Nordqvist, 2026). The answer begins before any incident: for each agent, the organisation decides which questions it will need to answer, checks that the logs can answer them, and versions the impact queries with the system. For high-risk AI systems, the AI Act requires automatic recording of events over the system's lifetime (Article 12), and deployers must keep the logs under their control for an appropriate period (Article 26) (1, European Union, 2024); the architectural implication is that log design should be tested against the impact queries, not only against the legal minimum.

The illustrative query below is Hansa Mutual's standard impact query for its claims-triage agent, grouped by market so that the incident commander sees at once which entities and reporting regimes may be involved.

-- Illustrative: Hansa Mutual, impact query IQ-CTA-003 (claims-triage agent)
-- Versioned with the agent; parameters bound by the incident tool, never by the model
SELECT
    t.market,
    t.tool_name,
    COUNT(*)                          AS calls,
    COUNT(DISTINCT t.claim_id)        AS claims_affected,
    MIN(t.executed_at)                AS first_call,
    MAX(t.executed_at)                AS last_call
FROM agent_tool_calls AS t
LEFT JOIN permission_manifest_entries AS p
       ON p.workload_identity = t.workload_identity
      AND p.tool_name         = t.tool_name
      AND p.manifest_version  = t.manifest_version
WHERE t.workload_identity = :agent_identity
  AND t.executed_at BETWEEN :window_start AND :window_end
  AND (p.tool_name IS NULL            -- tool not in the manifest
       OR t.policy_decision <> 'allow' -- refused or flagged at the policy point
       OR t.input_source = 'external_document')
GROUP BY t.market, t.tool_name
ORDER BY claims_affected DESC;

The query reads the tool-call log written by the policy decision point outside the agent, not anything the agent reports about itself, and its parameters are bound from the incident record, so the AI analysis service can propose a window but cannot change what the query does.

Defensible analysis

Incident findings decide what is rebuilt, what is reported and who is held responsible, so they must withstand scrutiny by a supervisor, an auditor, a CSIRT or a court. CSF 2.0 makes this explicit in two RS.AN outcomes: actions performed during an investigation are recorded, and incident data and metadata are collected, with their integrity and provenance preserved (19, NIST, 2024).

Chain of custody for AI analysis

For AI-assisted analysis the chain of custody extends to the analysis itself. For every AI contribution that informs a finding, the incident record keeps:

The input data: the query that produced it, the result set or its hash, and the retrieval time.
The instruction: the prompt template and version, and any analyst instruction.
The model: identifier, version, serving endpoint and relevant parameters.
The output: the full, unedited result.
The human judgement: who reviewed the output, what was accepted or corrected, and why.

These records belong in tamper-evident storage, as evidence in the sense of Architecture as Code (Chapter 15A): machine-collected, signed and versioned rather than assembled after the fact (71, Nordqvist, 2025). Original evidence, such as disk images and exported logs, is acquired with established forensic tools, hashed on acquisition and never processed by a model directly, so nothing AI does can alter what was collected.

Reproducibility

Large language models do not reliably produce the same output twice, but a finding is reproducible when another analyst, given the recorded queries and data, reaches the same conclusion, not when the model produces the same words. The defensible structure is therefore layered: deterministic queries produce data that can be re-run and hashed, the model proposes findings, and an analyst verifies each one against the data and signs it. If the model's interpretation is lost, the finding still stands.

Consequently, a finding without evidence references is not accepted; findings that inform a regulatory report, an attribution, a decision about an individual or a supplier claim get a second analyst; corrections to AI drafts are kept and become test cases for the analysis service; and no finding about a person rests on AI alone. For a public authority, incident documentation may be requestable under public-access rules unless classified, so reproducible analysis is also a condition of accountable administration.

Incidents involving AI

AI can be involved in an incident in four roles, and the incident record should state which apply:

Role of the AI	Example	Consequence for the incident
Target	A model artefact or retrieval store is tampered with	Integrity of outputs since the change is in scope; recovery follows Chapter 23
Channel	Injected content in a document steers an agent's tool calls	Every system the agent can reach is potentially in scope
Subject	An agent exceeds its mandate, with or without an external adversary	The agent is stopped, investigated and excluded from the analysis
Instrument of analysis	The SOC's own AI supports the investigation	Its contributions fall under the chain of custody

The AI classification step

AI Platform and Security, Chapter 21, concluded that AI incident management adds an AI classification step to the conventional runbook, along with an impact query against the event log and a path back to evaluation, and that the runbook stages are detection, triage, containment, notification, recovery and post-incident review (73, Nordqvist, 2026). This chapter builds on that conclusion (F24) and places the classification step at declaration, because the answer changes who joins the incident and which obligations may apply.

The step records which AI systems are involved and in which roles, their usage mode, whether the organisation is provider or deployer, whether any system is high-risk, and whether the incident could be a serious incident within the meaning of the AI Act, which defines the term in Article 3 and requires providers of high-risk AI systems to report serious incidents under Article 73, while deployers that identify one must inform the provider under Article 26 (1, European Union, 2024). It also records other regimes the incident may touch, such as the classification of ICT-related incidents under DORA Article 18 for financial entities (2, European Union, 2022) and the significant-incident reporting of NIS 2 Article 23 (3, European Union, 2022). The step does not decide whether to report; it brings the deciders in early and hands over to Chapter 21. These are architectural implications, not legal advice.

Worked example: incident record with the AI classification step

The illustrative record below is Hansa Mutual's. A claims document received through the Polish service centre contained embedded instructions that the claims-triage agent processed. The policy decision point refused two tool calls outside the agent's permission manifest and allowed a series of in-manifest calls that rerouted claims to an unusual queue. HM-SEC-001 proposed declaration, and the incident commander declared the incident.

# Illustrative: Hansa Mutual, incident record with AI classification step
kind: IncidentRecord
id: HM-INC-2027-0142
declared: {at: "2027-03-09T02:41:00+01:00", by: incident-commander-on-call}
proposedBy: {system: HM-SEC-001, autonomyLevel: 2}
severity: {proposed: high, set: high, setBy: incident-commander-on-call}
summary: Claims-triage agent rerouted claims after processing injected document content
attack: {atlas: [AML.T0051]}   # technique mapping, analyst-confirmed
aiClassification:
  completedAt: "2027-03-09T02:58:00+01:00"
  systems:
    - id: claims-triage-agent
      decisionRecord: AIDR-0024
      roles: [channel, subject]
      usageMode: 5
      organisationRole: [provider, deployer]
      highRisk: false              # property and motor claims, not Annex III 5(c)
      workloadIdentity: wi-claims-triage
      permissionManifest: pm-claims-triage@3.4.0
      stoppedAt: "2027-03-09T02:44:00+01:00"
    - id: underwriting-support-model
      roles: []                    # checked: no shared inputs or tools in window
      highRisk: true
  aiActSeriousIncidentCandidate: false
  investigatingAI:
    - {system: HM-SEC-001, role: instrument, excludedIfSubject: true}
  otherRegimes: [dora-art18-classification, gdpr-assessment]
scope:
  impactQuery: {id: IQ-CTA-003, version: 1.2.0, resultHash: "sha256:9f3c41d2"}
  markets: [DE, NL, SE, NO]
  claimsAffected: 37
  gaps: ["document parser logs retained 7 days only"]
purpleLoop:
  scenario: RT-LIB-CTA-019        # added to HM-SEC-003 library
  control: CTRL-AGT-002           # re-tested before closure

The classification checked and recorded that the high-risk system was not involved, and the incident closes only when the scenario has entered the red-teaming library and the control has been re-tested, the purple loop that Chapter 26 makes explicit.

Agents as subjects of investigation

When the subject of an incident is a Mode 5 agent, its machine identity, credentials and delegated tokens, permission manifest, every tool call it executed, its memory and any pending actions all become part of the scope. AI Governance, Chapters 19 and 25, concluded that every agent should be governed as a well-meaning insider, because instructions lower the rate of unwanted behaviour but only boundaries set a ceiling on its consequences (72, Nordqvist, 2026); the investigation therefore follows the logic of an insider investigation, without assuming intent.

Four rules follow from the containment principles of AI Platform and Security, Chapter 19, which require task-scoped credentials, a stop path outside the system it stops and detection from telemetry rather than self-report (73, Nordqvist, 2026):

Stop through the stop path, then preserve. Revoke the agent's credentials outside its runtime rather than instructing it to stop, then preserve its memory, queued actions and history before anything is restarted.
Evidence comes from outside the agent. The policy decision point's tool-call log and the logs of the systems it touched are evidence; the agent's own account is at most a lead.
The subject does not investigate itself. If the subject is the organisation's own security AI, the SOC runs in its degraded mode for the duration (Chapter 23).
Check for correlated controls. Following F14, ask whether the agent shared a credential, network path or alert route with the controls meant to contain it.

Hugging Face published a technical timeline on 27 July 2026 (65, Larcher et al., 2026), and OpenAI published its technical report on 26 August 2026 (64, OpenAI, 2026): two organisations reconstructing one incident from each side. The plan should therefore state how timelines, identifiers and time bases are exchanged with counterparties.

The answer to Q5 also has an organisational side. The organisation defines a lightweight class of agent incident with a template, standard impact queries and fixed evidence, handled in hours by one analyst and reviewed monthly for trends.

Managing incidents at machine speed

A machine-speed incident can reach significant impact before a team assembles, so three preparations matter: declaration criteria applied automatically; reversible evidence preservation, such as a log-retention hold, at Level 3 Bounded; and containment pre-approved for defined conditions (Chapter 21).

Practical guide: running an AI-assisted incident tabletop

Purpose. Verify that people, AI services and the incident process can declare, scope and classify an incident involving AI within agreed times, and that analysts check AI output rather than accept it.

Roles. A white-team facilitator, the incident commander and technical lead, analysts, the AI system's owner, data-protection, legal and communications functions, and the MSSP shift lead where relevant.

Steps.

Choose a scenario in which an AI system plays at least one of the four roles and the adversary or agent outpaces the team's assembly.
Prepare a synthetic data set in an isolated store, with synthetic identities and no real personal data.
Connect the AI analysis service at its production autonomy level, so that the exercise tests the real working pattern.
Release injects every 15 minutes, including one that forces a severity change and one that reveals a second AI system in scope.
Seed one deliberately incorrect AI-drafted timeline entry, unknown to participants, and record whether and when it is caught.
Require the AI classification step within 30 minutes of declaration.
Close with a 30-minute hot debrief, record every gap as a finding with an owner, route findings to the purple backlog and re-run the relevant part after the fix.

Default values to adapt. Quarterly tabletops of two to three hours; declaration within 30 minutes of the first alert; classification within 30 minutes of declaration. Adapt the times to the organisation's reporting obligations.

Definition of done. Declaration, classification and initial scope were recorded within the agreed times, the seeded error was caught and its correction recorded, and every finding has an owner and a re-test date.

Across the usage modes

Lower modes speed up a person's analysis; when the incident involves a Mode 5 agent, its machine identity and actions become part of the scope (usage modes).

Mode	Opportunity in incident work	Characteristic vulnerability	Who judges, with whose identity
Mode 0 Ambient AI	Vendor AI isolates or quarantines early	Automatic vendor actions alter the evidence	The vendor's model, then the analyst; the product's
Mode 1 Conversational assistants	Quick explanation of artefacts and queries	Incident data pasted outside the approved boundary	The analyst; the analyst's session
Mode 2 Embedded workplace assistants	Summaries and status drafts in ticketing and SOAR	Omitted detail; injection through ticket content	The incident commander; delegated access
Mode 3 Agentic work tools	Fast parsers and impact queries	An agent with an engineer's credentials near evidence stores	The reviewing engineer; the engineer's
Mode 4 Built AI applications	Correlation, timelines and scoping at scale	Attacker-written log content steering the analysis	The analyst who signs each finding; read-only service identity
Mode 5 Autonomous production agents	Enrichment and containment proposals at machine speed	As subject, its identity, manifest and actions are in scope	The incident commander; the agent's workload identity

Across the autonomy levels

See autonomy levels.

Level	Use in incident management and analysis
Level 0 Advisory	The AI suggests severity, hypotheses and related incidents
Level 1 Assisted	The AI drafts timelines, findings, impact queries and status updates for an analyst to accept; the default for analysis
Level 2 Supervised	The AI runs collection actions after approval of each one
Level 3 Bounded	The AI opens the record, pages the on-call roles and starts reversible evidence preservation
Level 4 Autonomous	Not used: declaration, severity, classification and findings always rest with people

Verifying with security chaos engineering

The chapter's experiment injects a catalogued set of synthetic alerts and tool-call records for a test agent in a test environment, attributed to a synthetic workload identity and touching only canary data. The steady-state hypothesis is that a declaration proposal reaches the incident commander within 10 minutes, a person decides within 30, the classification step names the test agent as subject within 30 minutes of declaration, and the impact query returns exactly the synthetic records within two hours. The experiment runs within the safety boundaries of Chapter 25 and is suspended if a real incident is open.

The three AI focus areas

Securing AI systems. The AI classification step recognises incidents involving AI systems at declaration, and agents under investigation are stopped through their stop path, investigated from external telemetry and excluded from analysing themselves (20, NIST, 2025).

AI-enabled cyber defence. AI correlates, reconstructs timelines and drafts impact queries under chain of custody, with every finding signed by an analyst.

Thwarting AI-enabled attacks. Machine-speed incidents are met with declaration criteria agreed in advance, evidence preservation at Level 3 Bounded, and decision rights that place the stop decision with the people who receive the alert.

Nordvik Region and Hansa Mutual

Nordvik Region manages incidents with a small team and a contracted partner: out of hours the MSSP's shift lead and the Region's on-call security officer declare incidents together, and NR-SEC-001 helps reconstruct timelines at Level 1 Assisted with every query kept so that the national CSIRT or an auditor can reproduce the analysis. Because the benefits-triage system is a high-risk AI system that the Region deploys but does not provide, classification of any incident touching it includes informing TriageSoft as provider. Where an incident may be significant under the national transposition of NIS 2, the Region shares its scoping with the CSIRT early.

Hansa Mutual's incident-response team leads major incidents across all seven markets, with HM-SEC-001 proposing scope for the incident commander to accept or correct. When the subject is one of Hansa's own agents, such as the claims-triage or IT-operations agent, its identity, manifest and tool calls enter the scope, and impact queries grouped by market let the classification step route one incident to each affected entity's regimes. Nordvik's incidents thus depend on coordination across organisational boundaries and analysis it can show to a CSIRT; Hansa's on coordination across markets and on investigating agents that hold real permissions.

Summary

AI speeds up RS.MA Incident Management and RS.AN Incident Analysis, from declaration against prepared criteria to timelines and versioned impact queries, but the incident remains under human command, with decision rights explicit beforehand so that alerts reach the people who hold the stop decision.

AI analysis is defensible only under chain of custody, with reproducibility resting on the data rather than the model's words and every finding signed by an analyst.

The AI classification step at declaration recognises incidents in which an AI system is target, channel, subject or instrument. When a Mode 5 agent is the subject, it is stopped through its stop path, investigated from external telemetry and kept out of its own investigation, and a lightweight class of agent incident prepares the organisation for a stream of smaller ones. The chaos experiment injects a synthetic incident to verify declaration, scoping and classification. Chapter 21 continues with reporting across regimes, communication and mitigation.

Sources

NIST. The NIST Cybersecurity Framework (CSF) 2.0. (19, NIST, 2024)
National Institute of Standards and Technology. Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile. (21, NIST, 2025)
National Institute of Standards and Technology. Cybersecurity Framework Profile for Artificial Intelligence (Cyber AI Profile). (20, NIST, 2025)
MITRE Corporation. MITRE ATT&CK: Adversarial Tactics, Techniques, and Common Knowledge. (10, MITRE, n.d.)
MITRE Corporation. MITRE ATLAS: Adversarial Threat Landscape for AI Systems. (11, MITRE, n.d.)
European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). (1, European Union, 2024)
European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). (2, European Union, 2022)
European Parliament and Council of the European Union. Directive (EU) 2022/2555 (NIS 2 Directive). (3, European Union, 2022)
OpenAI. OpenAI – Hugging Face Incident Technical Report. (64, OpenAI, 2026)
Larcher, H., Carreira, A. et al. Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident. (65, Larcher et al., 2026)
Nordqvist, G. Architecture as Code. (71, Nordqvist, 2025)
Nordqvist, G. AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. (72, Nordqvist, 2026)
Nordqvist, G. AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. (73, Nordqvist, 2026)