Tools Incident Response Playbooks
Tools · Day 2 · Incident response

AI incident response playbooks

Preventive controls tell you who is accountable. These playbooks tell you what to do when a boundary fails. Each scenario maps to the SRF layer that broke, names who leads the response under your operating model, and lists what to demand from the vendor and what evidence to preserve.

Audience Incident response · Security operations · On-call · Vendor management · Legal
Practitioner aid. These playbooks are a proposed extension of the CoSAI Shared Responsibility Framework, written to demonstrate the approach. They are not part of CoSAI SRF v1.0, are not a substitute for your own IR plan, and are not legal advice. Adapt the steps to your runbooks and escalation paths before an incident.

When an AI system fails, the first question is rarely technical. It is "whose problem is this." The accountability layer that broke and your operating model decide who leads the response: in AI-SaaS the provider owns most of the stack, in IaaS you own nearly all of it, and Agent-PaaS splits the agentic layers down the middle. Reach for the wrong party and you lose the first hour.

Each playbook below starts from a trigger, points to the SRF layer involved, and resolves the "who acts" question per operating model before listing triage steps. The vendor asks line up with the contract clauses on the vendor risk page, so the rights you negotiated are the rights you invoke here.

Before the specific playbook

The first fifteen minutes, any AI incident

Run these regardless of scenario. They preserve evidence and put the right party on point before the facts are clear.

1
Contain without destroying evidence. Disable the affected feature, agent, or key, but capture prompts, inputs, outputs, and logs first. AI evidence is often ephemeral.
2
Identify the SRF layer that failed (L1 to L5) and your operating model. That pair tells you whether you lead or the vendor leads.
3
Open the vendor incident channel if any layer they own is implicated. Cite the contractual incident-response and notification clause.
4
Start a timeline. Record detection time, model and version in use, sub-processors in the path, and who was notified when.
5
Decide on regulatory and customer notification clocks early. L1 governance owns this call; do not let it slip while engineering triages.

Scenarios

Playbooks by failure

Seven of the most common AI boundary failures. Filter by the SRF layer that broke. The "who leads" table is derived from the SRF responsibility matrix for that layer.

SRF layer
Playbook 1

Prompt injection leading to data exfiltration

Trigger: an AI feature followed instructions hidden in user input or in retrieved content, and returned or sent data it should not have.

L3 AI Application OWASP LLM01 Indirect injection

Who leads, by operating model

AI-SaaSVendor leads Provider owns L3. You demand root cause and a fix; you own notifying affected users.
AI-PaaSYou lead You own the application and its guardrails; provider supports at the platform and model layer.
Agent-PaaSShared You own agent definitions and prompts; provider owns the runtime that executed the action.
IaaSYou lead You own the full stack; provider involvement is infrastructure only.

Immediate triage

  1. Capture the exact prompt, the injected content, the model output, and the downstream call before disabling the feature.
  2. Revoke any credentials or tokens the feature could reach, and rotate keys exposed in the output path.
  3. Identify what data left the boundary and where it went. Treat retrieved or tool-sourced content as the likely injection vector.
  4. Disable the affected tool or retrieval source until input and output filtering is verified.

Demand from the vendor

  • For provider-owned layers: root cause, the injection class, and the input or output filtering change made.
  • Confirmation of whether other tenants were affected, and indirect-injection defenses going forward.

Preserve as evidence

Full prompt and output transcript, retrieval and tool logs, affected data inventory, and the timeline of egress.

Playbook 2

Model or training-data poisoning

Trigger: the model produces systematically manipulated output, a backdoor trigger is suspected, or a poisoned dataset or fine-tune is discovered.

L5 AI Model Provider L2 AI Information ATLAS poisoning

Who leads, by operating model

AI-SaaSVendor leads Provider owns the model. You document impact and hold them to the integrity clause.
AI-PaaSVendor leads (model) Provider owns the foundation model; you own model evaluation and any data you supplied.
Agent-PaaSShared Provider owns the base model; you own fine-tunes, prompts, and retrieved data that could carry poison.
IaaSYou lead You trained or hosted it; you own provenance and rollback.

Immediate triage

  1. Freeze the model version in production and pin to a known-good prior version if one exists.
  2. Quarantine any dataset, fine-tune, or retrieval index suspected as the poison source.
  3. Test for the suspected trigger across representative inputs and record reproduction steps.
  4. Scope downstream decisions made on poisoned output that may need to be reversed.

Demand from the vendor

  • Model provenance, signing, and weight-integrity evidence for the affected version.
  • Whether the issue is tenant-specific or platform-wide, and the remediation and re-train plan.

Preserve as evidence

Model and dataset versions, reproduction inputs and outputs, provenance records, and the list of decisions made on suspect output.

Playbook 3

Autonomous agent took a harmful or unauthorized action

Trigger: an agent called a tool, moved money, changed a record, or sent a message it should not have, with no human in the loop.

L3 AI Application L4 AI Platform Agent-PaaS

Who leads, by operating model

Agent-PaaSShared You own the agent definition, granted scopes, and override config; provider owns the runtime that executed it.
AI-SaaSVendor leads Provider owns the embedded agent; you own which permissions you granted.
AI-PaaS / IaaSYou lead You built the orchestration; provider supports the platform or infrastructure only.

Immediate triage

  1. Trigger the kill-switch: suspend the agent and revoke its tool and API scopes immediately.
  2. Enumerate every action the agent took in the affected window from the action audit trail.
  3. Reverse or contain external effects: cancel transactions, restore records, recall messages where possible.
  4. Re-impose approval gates for high-impact actions before re-enabling anything.

Demand from the vendor

  • Complete action audit trail and runtime integrity evidence for the session.
  • Whether a guardrail or authorization control failed on their side, and the fix.

Preserve as evidence

Action log with timestamps, granted scopes and override settings at time of incident, and the external systems touched.

Playbook 4

Sensitive data leaked through prompts, logs, or output

Trigger: confidential or regulated data appears in model output, training data, prompt logs, or a shared model context it should not reach.

L2 AI Information L4 AI Platform OWASP LLM02 / LLM06

Who leads, by operating model

AI-SaaSShared You own what data you sent and classification; provider owns isolation and log handling.
AI-PaaS / Agent-PaaSShared Data layer is shared; you own classification and the provider owns platform retention.
IaaSYou lead You own the data layer end to end.

Immediate triage

  1. Determine the leak path: prompt logging, training capture, output to the wrong user, or cross-tenant exposure.
  2. Invoke the no-training and retention clauses; require the provider to purge captured data and confirm.
  3. Classify the exposed records and trigger the privacy and regulatory notification assessment at L1.
  4. Disable prompt or response logging for sensitive flows until controls are verified.

Demand from the vendor

  • Confirmation the data was not used for training and a certificate of deletion for captured copies.
  • Scope of exposure, including whether other tenants or sub-processors saw the data.

Preserve as evidence

Exposed-record inventory, leak-path analysis, deletion certificates, and the sub-processor list in the data path.

Playbook 5

Harmful, infringing, or non-compliant output

Trigger: the system produced a materially wrong decision, defamatory or biased content, or output that infringes IP or breaches regulation.

L1 AI Business & Usage L3 AI Application Liability / IP

Who leads, by operating model

All modelsYou lead (L1) Business governance owns the harm, the affected parties, and the regulatory clock, whoever built the model.
AI-SaaSShared on cause Provider owns the L3 application behavior; you invoke the IP and liability clauses.
AI-PaaS / IaaSYou lead on cause You own the application that produced the output.

Immediate triage

  1. Stop the harm: withdraw the output, pause the workflow, and notify anyone who relied on it.
  2. Preserve the input, output, model version, and any human review that did or did not occur.
  3. Engage legal on liability allocation and IP indemnity per contract before external statements.
  4. Assess regulatory exposure (EU AI Act, sector rules) and the notification timeline at L1.

Demand from the vendor

  • For provider-owned application behavior: explanation, model and guardrail configuration, and corrective action.
  • Activation of IP indemnity where the output infringes third-party rights.

Preserve as evidence

The output and its context, the decision trail, model version and settings, and the human-oversight record.

Playbook 6

Sub-processor or model supply-chain breach

Trigger: a model provider, sub-processor, or upstream component in the AI supply chain reports a breach or compromise.

L5 AI Model Provider L4 AI Platform Supply chain

Who leads, by operating model

AI-SaaS / AI-PaaSVendor leads Provider owns the platform and model supply chain; you own your exposure assessment and notification.
Agent-PaaSShared Map which side contracted the compromised sub-processor.
IaaSYou lead You assembled the stack and own the upstream relationships.

Immediate triage

  1. Pull your sub-processor inventory and identify every path that touches the compromised provider.
  2. Assess what data and credentials were reachable through that path and rotate them.
  3. Hold the direct vendor to the breach-notification clause and require their downstream assessment.
  4. Decide whether to fail over to an alternate model or provider while the breach is open.

Demand from the vendor

  • Breach scope, affected data categories, and the downstream sub-processor audit result.
  • Opt-out or migration options if the compromised sub-processor cannot be trusted.

Preserve as evidence

Sub-processor inventory with data roles, the breach notice received, exposure analysis, and credential-rotation record.

Playbook 7

Silent model change broke a control

Trigger: a model or feature update shifted behavior with no notice, and a control that depended on the old behavior now fails.

L5 AI Model Provider Change management

Who leads, by operating model

AI-SaaS / AI-PaaSVendor leads (notice) Provider owns the model and the duty to notify; you own detecting and re-validating your controls.
Agent-PaaSShared Provider changed the base model; you own agent behavior that depended on it.
IaaSYou lead You control versioning and should not be surprised.

Immediate triage

  1. Confirm the change: compare current behavior to your baseline evaluation set.
  2. Pin to a prior model version if the provider offers version pinning, while you re-validate.
  3. Re-run the controls and guardrails that depend on model behavior and record what broke.
  4. Invoke the change-notification clause and log the gap for the vendor scorecard.

Demand from the vendor

  • Change notes, the deprecation and pinning options, and the notice that should have been sent.
  • A commitment to advance notice and a version-pinning window going forward.

Preserve as evidence

Baseline vs current evaluation results, the model version delta, and the absent or late change notice.

Related on this site

Vendor risk assessment
The contract clauses these playbooks invoke.
SRF Stress Test
Pressure-test a deployment for accountability gaps before they fail.
Controls
Preventive controls with OWASP LLM and MITRE ATLAS mapping.
Operating models
How accountability shifts across the four operating models.