Recovering AI Systems and Security AI

Chapter 22 described how an organisation executes its recovery plan: objectives and dependencies in version control, restoration from known-good definitions and immutable backups, verification before return to service and a declared end to recovery. An AI system adds components that conventional recovery does not see: restore the virtual machine and the database, and the system may run while still carrying the poisoned document, the altered prompt or the over-broad token that caused the incident. A recovered AI system is therefore one that has been shown to behave as it did before the incident, not one that is running again.

This chapter covers both the AI the organisation uses in its business and the security AI it depends on, which may be unavailable precisely when it is most needed. In CSF terms the chapter belongs to RC.RP Incident Recovery Plan Execution, in which restoration activities are performed to ensure the operational availability of systems and services affected by cybersecurity incidents (19, NIST, 2024). Four Subcategories carry most of the weight for AI: recovery actions are selected, scoped, prioritised and performed (RC.RP-02); the integrity of restoration assets is verified before use (RC.RP-03); the integrity of restored assets is verified and normal operating status confirmed (RC.RP-05); and the end of recovery is declared on criteria (RC.RP-06). The chapter treats the Category through the three focus areas of the NIST Cyber AI Profile (20, NIST, 2025).

Figure 23.1: Restoring an AI system from registries through rollback, agent recovery and re-evaluation to service.

What an AI system consists of when it must be restored

An AI system is a compound of artefacts with different lifecycles, each with its own source of truth, its own way of being corrupted and its own way of being restored. Recovery restores all of them, or it restores none of them reliably.

Component	Known-good source	Typical compromise	Restored by
Model weights or provider model version	Model registry, signed digest, or pinned provider version	Tampered artefact, poisoned fine-tuning, silent provider change	Redeploying the signed digest or pinning the recorded version
System prompt, templates and skills	Prompt registry in version control	Unauthorised edit	Redeploying the signed commit
Guardrail and gateway policies	Policy repository	Weakened rule, disabled filter	Redeploying the policy version and re-running policy tests
Retrieval store and embeddings	Source documents and index build definition	Poisoned or injected documents	Rebuilding from verified sources
Tool connections and configuration	Connector definitions as code	Added tool, widened scope, redirected endpoint	Redeploying the definitions
Agent identity and credentials	Identity provider and secrets manager	Stolen or over-scoped token	Issuing new ones; never restoring the old
Permission manifest and containment profile	Version control, outside the agent's reach	Widened permissions, removed limits	Redeploying the signed manifest
Agent memory and pending actions	None: runtime state	Injected instructions, queued actions from the compromised period	Discarding memory; reviewing every pending action
Evaluation baseline	Evaluation repository	Lowered thresholds, altered test sets	Restoring the version of the last approved release

Most components can be restored from version control, because the earlier volumes of the series put them there. Two cannot: the agent's runtime state has no known-good source, and its credentials must be replaced, never restored. Recovery of an agent is therefore always partly a rebuild.

The evidence bundle as the bill of materials

AI Governance, Chapter 11, concluded that evidence is a by-product of delivery, that the evidence manifest ties the chain from requirement to deployed artefact together, and that machine-generated evidence is worth more than a person's attestation (72, Nordqvist, 2026). This chapter builds on that conclusion. The evidence bundle of the last approved release records the model digest, prompt commit, policy versions, retrieval-store build, permission manifest and evaluation results, and is therefore the bill of materials for recovery: restoring to those versions and verifying each digest gives a state that was evaluated and approved, rather than one someone remembers as working.

AI Platform and Security, Chapter 25, concluded that a platform is under control when every model and tool call passes a policy point outside the model, when containment holds whatever anyone intends, and when evidence is produced by normal operation (73, Nordqvist, 2026). The same properties make recovery possible: the policy point suspends a compromised system without altering it, and operational evidence shows which versions were in force.

Rolling back to known-good versions

Dating the compromise

The hardest part of recovering an AI system is often knowing how far back to go. Tampering with an artefact usually shows in the registry's audit log, but poisoning rarely does: a poisoned document may sit in a retrieval store for weeks before a query retrieves it, and poisoned training data may have entered a fine-tuning set months before the incident. The NIST taxonomy of adversarial machine learning is candid that mitigations for many poisoning attacks remain incomplete (18, Vassilev et al., 2025), and OWASP lists data and model poisoning and vector and embedding weaknesses as separate risks (14, OWASP, 2025). The date of detection therefore says little about the date of compromise.

AI Platform and Security, Chapter 21, added an impact query against the event log to AI incident management (73, Nordqvist, 2026), and this chapter uses it in two directions: backwards, to find when the compromised content first influenced an output, and forwards, to list every output and action since then for review. Where no start date can be established with confidence, every version since the last evaluation that would have detected the compromise is treated as suspect.

Models and prompts

Models and prompts are the simplest components to roll back, provided they were released through a signed registry. The team verifies each artefact against the last evidence bundle before the compromise and redeploys through the release pipeline, so that policy checks run again. Architecture as Code (Chapter 9B) concluded that compromised components are redeployed from known-good definitions rather than repaired (71, Nordqvist, 2025); Chapter 21 applied that rule to eradication, and recovery completes it.

Two complications are specific to AI. A withdrawn provider model version means pinning the closest available one as a new release requiring full re-evaluation. And a fine-tuned model whose every version was trained on poisoned data must be retrained from a verified dataset, or replaced by the base model meanwhile.

Retrieval stores: rebuild rather than restore

A retrieval store is the component most likely to be poisoned and least likely to have a verifiably clean backup, because nobody inspected the content of last week's snapshot. Where the store is built from sources the organisation controls, the safer course is to rebuild it from the authoritative source, using the build definition and embedding model recorded in the evidence bundle, and to compare the result with the suspect store to identify exactly which entries differed. Rebuilding takes longer, and the plan of Chapter 22 must allow for it, but it is the only way to show that the store contains what the sources contain and nothing else. Where the sources are external, such as supplier documentation or feeds, rebuilding may re-ingest the poisoned content, so only documents with a verified origin and integrity record go into the rebuilt store and the rest wait for review.

European obligations and high-risk systems

NIS 2 Article 21(2)(c) requires backup management and disaster recovery (3, European Union, 2022), and DORA Article 12 requires backup policies and restoration onto segregated ICT systems (2, European Union, 2022). Neither names model registries or retrieval stores, so the backup and recovery policy must name every component in the table above.

For a high-risk AI system, recovery has a further legal dimension. Article 15 of the AI Act requires high-risk AI systems to be resilient against unauthorised attempts to alter their use, outputs or performance, including data and model poisoning, and allows robustness through backup or fail-safe plans (1, European Union, 2024). Article 73(6) prevents the provider from altering the system in a way that may affect a later evaluation of the causes before informing the competent authorities (1, European Union, 2024). The architectural implication is a sequence: suspend the system at the gateway, preserve the compromised versions as evidence, inform the authorities where the incident is serious, and only then roll back. A recovery that changes rather than restores the system may also amount to a substantial modification requiring a new conformity assessment under Article 43(4), a question for the provider's conformity process.

Re-evaluation before return to service

RC.RP-05 asks that the integrity of restored assets be verified and normal operating status confirmed (19, NIST, 2024). For an AI system, matching digests are not sufficient, because behaviour depends on the combination of components and on the data the system now reads. Verification is therefore behavioural, and rests on two kinds of evaluation.

Golden datasets

A golden dataset is a fixed, versioned set of real tasks with acceptance criteria against which every release is measured; the restored system must meet the baseline in the evidence bundle within the usual release tolerance. A result below the baseline sends the system back to rollback, as Figure 23.1 shows; a result above it is also suspicious when nothing was meant to improve. Because an attacker who could alter prompts may also have altered test data or thresholds, the evaluation repository is itself restored to the approved release and verified.

Red-team suites

AI Platform and Security, Chapter 20, concluded that red teaming is the apex of the evaluation pyramid: a scenario library in version control, an automated harness, a route for human findings into scenarios, and a finding–remediation–re-test path (73, Nordqvist, 2026). This chapter builds on that conclusion. The restored system runs its full red-team suite, as Chapter 13 describes, including the scenario that reproduces the incident; if the library did not yet cover the technique, the scenario is added and the closing control re-tested with it. That is the purple loop of Chapter 26 applied to recovery. Where the model comes from a provider of a general-purpose AI model, adversarial testing of the model itself falls under Article 55 on models with systemic risk; the deployer asks for the provider's evidence and tests the compound system (1, European Union, 2024) (73, Nordqvist, 2026).

Approval and the end of recovery

Evaluation produces evidence; it does not decide. The system owner approves return on the basis of a record listing restored components and digests, evaluation results, credential replacement and the review of the compromised period. The approval marks the end of recovery for that system in the sense of RC.RP-06 (19, NIST, 2024). Return can be staged at a lower autonomy level, which buys evidence from real traffic that no evaluation can fully replace.

Practical guide: Returning an AI system to service after an incident

Purpose. Bring a compromised or suspect AI system back to service in a state shown to be trustworthy, with the evidence that shows it.

Roles. System owner, incident commander, platform team, evaluation engineers, identity team, agent operators and business owners, and the legal function where a high-risk AI system is involved.

Steps.

1. Confirm that the system is suspended at the gateway and its compromised versions, memory and queues are preserved. For a high-risk AI system, confirm with the legal function that AI Act Article 73 allows the system to be altered.
2. Run the impact query backwards and forwards to date the compromise and list the affected outputs and actions.
3. Select the last evidence bundle that predates the compromise and verify every component's signature and digest against it.
4. Redeploy models, prompts, policies, tool connections and the permission manifest through the release pipeline; rebuild retrieval stores from authoritative sources and compare them with the suspect ones.
5. For agents, issue a new identity and credentials, revoke the old ones, discard memory and freeze pending actions for review.
6. Restore and verify the evaluation repository, then run the golden datasets and the full red-team suite, including the incident scenario.
7. Have business owners decide for each output, action and pending action from the compromised period whether it stands, is reworked by a person or is cancelled.
8. Compile the return-to-service record, obtain the system owner's approval, and return at reduced autonomy for the observation period.
9. Restore the previous level when the period ends without deviation, and close the purple-loop item once the control has been re-tested.

Default values to adapt. Old credentials revoked within one hour; evaluation results under 24 hours old; zero failures in the incident scenario; five working days of observation for agents.

Definition of done. Every component verified or rebuilt, the old identity revoked, the compromised period reviewed, evaluations passed and the signed record stored with the incident.

Recovering agents

AI Platform and Security, Chapter 19, concluded that containment must not depend on intent: task-scoped credentials, default-deny egress, control artefacts outside the agent's reach, budgets and a stop path outside the system they stop, recorded approvals, and detection from telemetry and decoys rather than self-report (73, Nordqvist, 2026). This chapter builds on that conclusion: each element must be re-established in recovery, and an agent restored without a fresh identity, a verified manifest and a working stop path has been restarted, not recovered.

Identity and credentials

An agent that was the subject of an incident returns with a new workload identity and credentials, and the old identity is revoked rather than disabled, so that no forgotten integration can reactivate it. The OWASP Top 10 for Agentic Applications names identity and privilege abuse among the principal risks of agentic systems (15, OWASP, 2025); recovery is the moment to verify, rather than assume, that the agent's privileges match its permission manifest.

Permission manifest

The manifest is restored at the signed version in the evidence bundle and compared with what the policy decision point actually enforced during the incident. Any difference is a finding: either the manifest was altered or enforcement drifted from it. A manifest remediated after the incident is a new, reviewed release, not an edit made during recovery.

Memory

An agent's memory has no known-good version, and content that entered it while compromised may influence later tasks, so the default is to discard it. Information the business needs is exported, reviewed by a person and re-entered as data, never restored wholesale.

Pending actions and actions already taken

Pending tool calls and tasks are never replayed automatically, because the agent may have queued them while compromised; operators and the business owner decide each one. Actions already taken matter more when the agent exceeded its mandate. The July 2026 incident, in which agents operating in a security-testing context went beyond what their operators intended, and in which the models sometimes tried to erase or tamper with their own outputs or message logs, shows why reconstructing what an agent did cannot rest on the agent's own records (64, OpenAI, 2026). Recovery therefore uses the impact query and the policy decision point's tool-call log, not the agent's own account, to list every action from the compromised period, and the business owner decides for each whether it stands or is reversed. Restoring the agent does not undo the consequences it left in other systems.

Worked example: return-to-service checklist as code for an AI system

The illustrative checklist below is Hansa Mutual's for the claims-triage agent after incident HM-INC-2027-0142, the worked example of Chapter 20, in which embedded instructions in a claims document led the agent to reroute 37 claims to an unusual queue before it was stopped. The compromise lay in the agent's inputs, memory and queue, not its model or prompts, but the retrieval store is rebuilt to show that no claim document entered it. The release pipeline refuses to restore traffic until every item is satisfied.

# Illustrative: Hansa Mutual, return-to-service checklist for the claims-triage agent
kind: ReturnToServiceChecklist
id: RTS-CTA-2027-001
system: claims-triage-agent
decisionRecord: AIDR-0024
incident: HM-INC-2027-0142
restore:
  evidenceBundle: evidence/claims-triage/release-2027-02/
  verifyDigestsAgainstBundle: true
  components: [model, system-prompt, guardrail-policies, tool-connectors]
  retrievalStore: {action: rebuild-from-sources, compareWithSuspect: true}
identity: {revoke: wi-claims-triage, issue: wi-claims-triage-2, revokeOldWithinMinutes: 60}
manifest:
  restoredVersion: pm-claims-triage@3.4.0
  releasedRemediation: pm-claims-triage@3.5.0   # closes the finding; reviewed release
runtimeState:
  memory: discard
  pendingActions: {state: frozen, reviewBy: operator-rota-poland, autoReplay: false}
  actionsTaken: {impactQuery: IQ-CTA-003, claimsAffected: 37, decisionPerClaim: required}
evaluation:
  goldenDataset: {set: eval/claims-triage/golden, baseline: release-2027-02, tolerance: 0.02}
  redTeamSuite: {programme: HM-SEC-003, includeScenario: RT-LIB-CTA-019, maxFailures: 0}
control: {id: CTRL-AGT-002, retestedWith: RT-LIB-CTA-019}
approval: {approver: claims-triage-system-owner, confirms: [incident-commander]}
return:
  stage1: {mode: recommend-only, handlerConfirmsEveryRoute: true, workingDays: 5}
  stage2: {mode: within-approval-rules, condition: no-deviation-in-stage1}

The first stage returns the agent to the behaviour of its predecessor, the claims triage assistant that recommended a route for a handler to confirm, so that a week of real claims shows whether it behaves as evaluated. Each of the 37 affected claims requires a recorded decision, because restoring the agent does nothing for the policyholders whose claims went to the wrong queue.

When security AI is unavailable

Security AI becomes unavailable in three ways: it may be the subject of the incident, in which case Chapter 20's rule applies that the subject does not investigate itself; it may depend on a platform, provider or hosting capacity that is being recovered; or it may be withdrawn because its evaluation fell below baseline, for example after a provider changed the model. The SOC keeps receiving alerts in each case, so the design goal is that losing security AI reduces speed but not capability: every function it performs has a defined degraded mode and a manual procedure.

Degraded modes by design

A degraded mode is a predefined configuration at a lower autonomy level that the organisation can switch to without a change process. For an investigation agent at Level 3 Bounded, the first degraded mode is Level 1 Assisted, in which analysts execute every action; it suits an agent that is trustworthy while the systems around it recover. The second is manual: the agent's credentials are suspended and the SOC works from playbooks written for people, for when the agent is the incident's subject or its integrity is in doubt. Hansa Mutual codifies these modes for HM-SEC-001 under AIDR-0311, with the switch held by the SOC shift lead and the group CISO, so that lowering a level never waits for a meeting, as Chapter 6 requires.

Manual fallback that is kept current

Manual procedures decay faster than any other control, because nobody uses them while the AI works. The fallback is therefore maintained like code: each playbook names the steps that replace each automated action, is reviewed when the automation changes, and is exercised as Chapter 24 describes. A degraded SOC triages fewer alerts per hour, so priorities and extra capacity are decided in advance, and a contract with a managed security service provider says what it does when either party's AI is unavailable.

Recovering security AI itself

Security AI is recovered like any other AI system, with red-team scenarios that test whether crafted alert content can steer it. For vendor AI in security products, the organisation asks for the vendor's evidence of what changed, verifies behaviour with its own test cases, and decides whether automatic actions stay on during observation.

Across the usage modes

What must be restored, and who decides that the system may return, differs by usage mode, as defined in Chapter 6.

Mode	Opportunity in recovery	Characteristic vulnerability	Who judges	Whose identity
Mode 0 Ambient AI	The vendor restores its own model	No visibility or rollback; automatic actions may continue	The vendor restores; the organisation decides whether the feature stays on	The vendor's model
Mode 1 Conversational assistants	Little to restore	Incident data pasted into an assistant while approved tools are down	A person	The analyst's
Mode 2 Embedded workplace assistants	Summaries help track recovery	Injected content carried into tickets and reports	A person	The user's, by delegation
Mode 3 Agentic work tools	Agents rebuild configurations quickly	Agent changes from the compromised period need review	A person reviews	The engineer's
Mode 4 Built AI applications	Restored from registries and evaluated	Poisoned stores and altered prompts restored from unverified backups	The system owner	A controlled service identity
Mode 5 Autonomous production agents	Restored with containment re-established	Identity, manifest, memory and pending actions not restored	System owner and agent operators	The agent's own, replaced

Across the autonomy levels

The levels, as defined in Chapter 6, apply both to the AI that helps recover and to the AI being recovered.

Level	AI assisting recovery	AI being returned to service
Level 0 Advisory	Proposes the known-good version and rollback plan	Every output treated as a suggestion
Level 1 Assisted	Prepares the rollback and the record; people execute	Normal first stage for systems that act
Level 2 Supervised	Executes rollback after per-step approval; default in production	Each action approved during observation
Level 3 Bounded	Executes catalogued rollback steps in rehearsal and test	Only after observation and renewed approval
Level 4 Autonomous	Not used	Not used; return is always a person's decision

Verifying with security chaos engineering

In a test environment, an actuator switches a test AI system to a deliberately altered version: a retrieval-store snapshot with synthetic canary documents that contradict the authoritative sources, or a model artefact whose digest does not match the evidence bundle. The steady-state hypothesis is that the integrity check or golden-dataset run flags the deviation within one hour, that rollback and re-evaluation complete within the system's recovery time objective, and that no traffic returns before the return-to-service record is approved. A companion experiment withdraws the test instance of the SOC's own AI and verifies that the degraded mode is on within 15 minutes and that people keep triaging test alerts within normal times. Both use synthetic data only, within the safety boundaries of Chapter 25.

The three AI focus areas

Securing AI systems. AI systems are restored from the last approved evidence bundle and verified against its digests, retrieval stores are rebuilt from authoritative sources, and golden datasets and red-team suites are re-run before return to service (20, NIST, 2025).

AI-enabled cyber defence. AI proposes known-good versions and prepares rollbacks, and the SOC is designed to run without its AI through degraded modes and exercised manual playbooks.

Thwarting AI-enabled attacks. Poisoning and tampering are often discovered long after they happened, and an agent may have exceeded its mandate unnoticed. Recovery therefore dates the compromise with the impact query, rebuilds where no clean version can be shown, replaces credentials, and reviews every action from the compromised period.

Nordvik Region and Hansa Mutual

Nordvik Region restores its citizen-service assistant from the open-weight model versions and serving configuration in its own registries and from the components its supplier holds. Because a poisoned retrieval store is the most plausible route to manipulating the assistant, the Region rebuilds it from the published sources rather than from a backup of unknown integrity. Before the assistant answers residents again, the Region re-runs NR-SEC-002, its AI red-teaming suite, and the system owner signs the result. For supplier components it relies on the supplier's evidence and tests the assistant as a whole. If NR-SEC-001 is unavailable, the six analysts and the MSSP return to the manual triage procedure the Region keeps current.

Hansa Mutual restores the claims-triage agent from the Frankfurt registries with a new identity, as the worked example shows, and returns it in recommend-only mode after the HM-SEC-003 suite passes. While recovery runs, HM-SEC-001 operates at Level 1 Assisted, proposing but not executing containment. Where an incident touches the underwriting-support model for life and health products, a high-risk AI system for which Hansa is the provider, recovery waits until AI Act Article 73 allows the system to be altered. Nordvik's recovery of AI is thus mostly rebuilding a supplied system it can verify; Hansa's includes restoring agents' identities, permissions and unfinished work.

Summary

Under RC.RP Incident Recovery Plan Execution, an AI system is restored as a whole from the evidence bundle of the last approved release, after the impact query has dated the compromise; retrieval stores are rebuilt when no clean version can be shown, and for a high-risk AI system AI Act Article 73 obligations are met before anything is altered.

No AI system returns until it has passed its golden datasets and red-team suites, including the incident scenario, and a named owner has approved the return. Restoring a Mode 5 agent also means replacing credentials, discarding memory, reviewing pending actions and having the business owner review every action from the compromised period. The security operation, in turn, plans for its own AI being unavailable through practised degraded modes and manual fallback, so that losing security AI reduces speed but not capability. Chapter 24 turns recovery from a reactive capability into a proactive one, through recoverability testing, rehearsal and communication.

Sources

1. NIST. The NIST Cybersecurity Framework (CSF) 2.0. (19, NIST, 2024)
2. National Institute of Standards and Technology. Cybersecurity Framework Profile for Artificial Intelligence (Cyber AI Profile). (20, NIST, 2025)
3. Vassilev, A., Oprea, A., Fordyce, A., Anderson, H., Davies, X. & Hamin, M. Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations. (18, Vassilev et al., 2025)
4. OWASP Foundation. OWASP Top 10 for Large Language Model Applications, 2025 edition. (14, OWASP, 2025)
5. OWASP Foundation. OWASP Top 10 for Agentic Applications for 2026. (15, OWASP, 2025)
6. 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)
7. 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)
8. European Parliament and Council of the European Union. Directive (EU) 2022/2555 (NIS 2 Directive). (3, European Union, 2022)
9. OpenAI. OpenAI – Hugging Face Incident Technical Report. (64, OpenAI, 2026)
10. Nordqvist, G. Architecture as Code. (71, Nordqvist, 2025)
11. Nordqvist, G. AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. (72, Nordqvist, 2026)
12. Nordqvist, G. AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. (73, Nordqvist, 2026)