The NIST AI Risk Management Framework Playbook recommends treatment and response plans, contingency processes for deactivating systems, preservation of materials for review, root-cause analysis, and criteria for redeployment. The UK National Cyber Security Centre’s secure AI development guidance likewise calls for scenario-based incident, escalation, and remediation plans, trained responders, and useful audit logs.

Define the incident and the stop map

Not every low-quality answer needs an incident process. Declare an incident when a workflow may have created—or may still be creating—material impact outside the model response itself. Examples include:

• an unauthorized write, message, file change, approval, or status transition;

• unexpected access to confidential or personal data;

• a repeated action, retry loop, or queue that continues after a denial;

• a material difference between a proposed action and the recorded downstream result;

• a missing audit trail for a consequential action; or

• a quality failure affecting customers, employees, money, legal rights, safety, or business records.

Do not wait for a perfect root-cause theory before taking a reversible pause. The person on duty should know which signals permit an immediate stop and who owns the next decision.

“Turn it off” is rarely one switch. A workflow may restart from a schedule, webhook, queue, retry policy, delegated agent, user action, or vendor integration. For each material automation, record:

• Workflow pause: How to stop new runs without deleting history

• Queue and retry control: How to prevent delayed work from restarting the incident

• Tool permissions: Which write scopes or integrations can be removed independently

• Credential owner: Who can rotate or revoke the workflow’s identity

• Human fallback: How the business continues while automation is paused

• Downstream systems: Where messages, records, files, approvals, or transactions are confirmed

• Current release: Model, prompt, tool policy, workflow version, and last known-good reference

The OWASP AI Agent Security Cheat Sheet recommends least-privilege tools, approval for high-impact actions, interrupt and rollback capability, and audit trails of decisions, tool calls, and outcomes. Those controls reduce the blast radius and make the response plan executable.

Follow a six-step first-hour sequence

1. Declare, assign, and pause

Record when the issue was noticed, who declared it, which workflow or version is involved, and who leads the response. Pause new runs and every known continuation path. Prefer the narrowest reliable containment that stops harm without disrupting unrelated workflows.

Do not delete the workflow, purge its history, edit the prompt, or rebuild the environment before evidence is preserved unless an urgent safety need requires a different approved action.

2. Preserve a minimal evidence record

Capture enough evidence to reconstruct the sequence without copying sensitive content into a broad ticket or chat. Record detection time and source; workflow, model, prompt, policy, and tool versions; a run reference held in the restricted source system; approval outcomes; tools requested and executed; downstream audit references; containment changes; and the collector and restricted storage location.

Store raw prompts, responses, customer data, credentials, and tool arguments only when necessary, authorized, access-controlled, and covered by an appropriate retention rule. A general incident summary should use bounded metadata, not become a second sensitive-data store.

3. Verify effects from systems of record

Separate what the automation attempted from what happened. A model statement, orchestration log, or successful tool response may not prove that a CRM, mailbox, payment system, file store, or other destination committed the change.

Use one stacked action record for each consequential action so it remains usable on a phone:

Action record

• UTC time: [time]

• Proposed action: [bounded description]

• Authorization: [allowed/denied]

• Tool outcome: [attempted/completed/unknown]

• Downstream evidence: [restricted audit reference]

• Reversibility: [yes/no/partial]

• Responsible role: [role]

Use the destination audit trail or responsible system owner to confirm the effect. Keep unknown outcomes marked unknown until evidence resolves them.

4. Contain the smallest risky capability

Contain the path that can continue the impact: a schedule, queue, tool, identity, retrieval source, memory store, or integration. Review workflows that share the component. Containment is not remediation: revoking a tool can stop future writes, but it does not recall a message, restore a record, remove exposed data, or reverse a downstream process.

5. Assign communications and remediation

Bring in privacy, security, legal, HR, finance, support, or other specialists according to the data, people, systems, and obligations involved. This playbook does not decide whether a notification is legally required.

Separate the trigger from the failed control. A malicious document, ambiguous request, outage, or model behavior may be the trigger. The control failure may be overbroad permissions, missing approval, incomplete validation, unsafe retries, weak monitoring, or an untested fallback. Record the immediate fix, durable control change, owner, and closure evidence.

6. Recover in stages

Restarting a schedule is not proof of recovery. Reproduce the failure with sanitized or synthetic inputs in an isolated environment. Verify the fix without production write access, test read-only access and proposed actions, require explicit review during a limited restart, monitor a bounded set of runs with tighter alerts, and expand only after business and technical owners sign off on the evidence.

Preserve the last known-good reference and a tested fallback. NIST’s incident-response guidance places preparation, detection, response, and recovery within ongoing cybersecurity risk management rather than treating response as an isolated document.

Use a one-page response card and drill it

Complete this card for each material automation:

• Business purpose and owner

• Technical owner and incident lead

• Stop authority and workflow pause path

• Queue, retry, and schedule controls

• Tools, identities, and effective scopes

• Human fallback

• Evidence locations and access owner

• Downstream systems of record

• Irreversible or partly reversible effects

• Escalation route

• Last known-good release and rollback reference

• Synthetic drill scenario

• Restart evidence and sign-off owners

• Last review date

Run a harmless drill after completing the card. Confirm that the stop control works, queued work does not restart unexpectedly, evidence can be found, the human fallback is usable, and the team can explain the restart gate. Update the plan after material changes to models, prompts, tools, identities, data sources, vendors, retry behavior, or downstream systems.

Connect the plan to AI workflow observability, AI agent permissions, testing and evaluation, and AI automation maintenance. These controls provide the signals, containment boundaries, regression tests, owners, and recovery references the playbook needs.

If your team cannot name the owner, stop control, downstream evidence, and human fallback, treat that as a launch-readiness gap. Use the AI Automation Readiness Assessment to review the workflow, data, systems, and team capacity. If the automation needs a designed incident and recovery path, book a strategy session to scope it. Keep production data, credentials, raw prompts, incident evidence, and personal data in approved internal systems; do not paste them into the booking form.

Sources and methodology

This article synthesizes primary guidance from NIST, the UK National Cyber Security Centre, and OWASP as accessed on October 28, 2026. The first-hour sequence, stop map, action timeline, staged restart gate, and response card are practical synthesis for small teams, not a legal standard, compliance certificate, universal severity model, or guaranteed prevention method. Adapt the plan to the workflow, sector, jurisdictions, contractual obligations, and actual incident-response capability.