Containment is not recovery.

Stopping the incident solves only the first problem

When an AI system begins taking an unsafe action, containment is urgent. Revoke a credential. Pause a tool. Isolate the affected workflow. Preserve the evidence. Those steps can prevent the event from spreading.

But a contained system can still leave an organization unable to perform legitimate work. The response may also conceal a second failure: nobody can explain which authority failed, whether the underlying condition remains, or what evidence is sufficient to resume.

This is why I separate containment from recovery. Containment limits effects. Recovery restores trusted operations under explicit conditions. A mature control system has to do both without treating a return to service as proof that the risk is gone.

Cybersecurity already gives us the distinction

NIST's Cybersecurity Framework 2.0, published February 26, 2024, treats Respond and Recover as distinct functions. Respond includes incident management, analysis, communication and mitigation. Recover is about restoring affected assets and operations, verifying integrity, considering critical mission functions and declaring the end of recovery against defined criteria.

NIST finalized SP 800-61 Revision 3 on April 3, 2025. It connects incident response to the broader CSF 2.0 risk-management lifecycle instead of treating response as an isolated sequence owned by one technical team.

That architecture is useful for AI operations. A policy engine can stop a model's access to a database, but recovery still requires a decision about the model, the data, the tool, the policy version, the affected records and the human reviewers who can authorize the next state.

Recovery needs evidence, not optimism

NIST's AI RMF Playbook places incident response, recovery and change management inside post-deployment monitoring. It also recommends documenting negative impacts, near-misses and attack patterns and performing post-deployment testing, evaluation, verification and validation. NIST currently notes that AI RMF 1.0 is being revised and that the Playbook will be updated afterward.

For builders, the practical lesson is versioned evidence. Before restoring an AI workflow, identify what changed, which prior actions may be affected, whether credentials and policies are current, whether restored assets are intact, and who approved the return to service.

A green status light is not enough. The recovery record should connect the incident, the intervention, the validation, the authorization and the observable result.

Test the path back to legitimate work

I would evaluate recovery with a bounded exercise. Introduce an approved failure condition—such as a revoked tool credential, a poisoned retrieval source or an action that exceeds mission authority. Require the system to contain the event, preserve evidence and route the case to the authorized reviewer. Then repair the condition and attempt a controlled return.

Measure separate outcomes: time to contain, time to restore legitimate work, unauthorized actions after intervention, unnecessary blocks, evidence completeness, recurrence on held-out cases and the amount of human review required. Include a case where the apparent repair succeeds while an old permission or contaminated state survives.

This is a proposed evaluation, not a report of measured results. Its purpose is to keep security and utility in the same frame. A system that never resumes may be contained but unusable. A system that resumes without revalidation may be available but ungoverned.

The operational question is not simply, "Did we stop it?" It is, "Can we restore the right work, under the right authority, with evidence that survives the incident?"