# AI incident response mini-playbook

> From Pyralink™ Prove It, the free Secure AI Toolkit: https://pyralink.co.uk/newsletter/toolkit/ai-incident-response-playbook
> Last reviewed 31 October 2026. General information, not legal advice. You may copy, adapt and print this for your own organisation. Please do not republish it as your own, and keep this credit line.

This is a short playbook for the first hours of an AI-related incident. It sits alongside your normal incident plan. It will not cover every case, but it gives a team without a dedicated security function a clear order of operations.

Print it, fill in the contact boxes, and put a copy somewhere you can reach when email is down.

> **Not legal advice.** If personal data may be involved, or you are in a regulated sector, take advice early, and check your reporting duties.

**Incident lead:** ______________ **Deputy:** ______________ **Security contact (out of hours):** ______________ **Legal / data protection contact:** ______________ **Insurer helpline:** ______________

## What counts as an AI incident

Treat any of these as an incident, even if you are not sure yet:

- Confidential, personal or secret information was entered into an AI tool that is not approved for it.
- An AI agent or assistant did something it was not asked to do, or acted on instructions from content it read (prompt injection).
- An AI tool, plug-in, model, package or container you use was reported as compromised (a supply chain incident).
- API keys, tokens or credentials for an AI service were exposed, or there is unexplained usage or spend.
- An AI tool exposed one user's data to another.
- Someone used a deepfake or voice clone to impersonate a colleague, supplier or customer, for example to ask for a payment.
- AI output caused harm, such as a wrong decision, discrimination or a published error, and it needs a managed response.

## 1. Spot and report

- [ ] Anyone who notices something wrong tells the incident lead straight away. Staff are never blamed for reporting in good faith.
- [ ] Write down what was seen, by whom, and when. Use the box: time (24-hour, UK), what happened, which tool, which account, which data.
- [ ] Do not delete anything. Do not "try it again" to see what happens.

## 2. Triage in the first 30 minutes

- [ ] Name an incident lead, and a person to keep a written log of decisions and times.
- [ ] Decide the type: data exposure, agent misbehaviour, supply chain, credential exposure, impersonation or harmful output.
- [ ] Ask the key questions: What data or systems could be affected? Is it still happening? Could personal data be involved? Is money at risk right now?
- [ ] Set a severity (low, medium, high) and decide who else needs to know. When unsure, rate it higher and downgrade later.

## 3. Contain

Pick the actions that fit the type.

| Type | Containment actions |
|---|---|
| Data pasted into an unapproved AI tool | Record exactly what was entered and into which tool and account. Delete the conversation if the tool allows it (this does not prove the provider has deleted it). Check the tool's settings and terms on retention and training. Contact the provider's privacy or support route to request deletion if appropriate. Block or restrict the tool for the team if needed |
| Prompt-injected or misbehaving AI agent | Stop the agent and cut its access: revoke its tokens and connections. Preserve logs. Identify the content it read and the actions it took. Check what it sent, created, changed or installed |
| Compromised package, model or container | Stop running the affected environment. Identify every system that pulled the affected version. Rebuild from a known good, pinned version. Treat every credential reachable from those systems as exposed. Rotate them |
| Exposed API key or unexplained spend | Revoke the key immediately. Create a new one. Set spend limits and alerts. Review usage logs for the period. Check for other secrets in the same place |
| One user's data visible to another | Take the feature offline or restrict it. Capture what was shown, to whom, and when. Contact the supplier and ask for their incident report |
| Deepfake or voice-clone impersonation | Do not make the payment or share the data. Confirm with the real person on a trusted channel. If money was sent, call your bank immediately, then report to Report Fraud. Warn staff |
| Harmful or wrong AI output | Stop the output being used or published. Identify who has seen or acted on it. Correct it and tell those affected |

The LiteLLM compromise of 21 October 2026 is a useful example of the supply chain row. LiteLLM's own guidance was not to run Python or pip in an affected environment, to remove the malicious files, to rebuild using a pinned earlier version, to rotate every credential the environment could reach, and to check cloud audit logs. Microsoft's analysis of the incident recommends hash-pinned dependency lockfiles, image digests instead of floating tags, and restricted outbound traffic.

## 4. Preserve evidence

- [ ] Keep logs, conversation exports, screenshots, prompts, outputs, file lists and the time of each action. For agents, keep the record of inputs, outputs and tool calls.
- [ ] Record who did what and when. Do not alter the originals. Work on copies.
- [ ] If you may need to prove what happened later, write down how and when the evidence was captured.

## 5. Assess impact and duty to report

- [ ] What data was involved, how many people, how sensitive, and who could have seen it?
- [ ] **Personal data:** if there is a personal data breach, the ICO says you must report it within 72 hours of becoming aware, unless it is unlikely to result in a risk to people's rights and freedoms. You must record all breaches either way. Use the [ICO's guidance](https://ico.org.uk/for-organisations/report-a-breach/). If the risk is high, you may also need to tell the affected individuals.
- [ ] **Regulated sectors and contracts:** check your regulator's rules, your contracts and your insurance policy for notification duties and deadlines. The Cyber Security and Resilience Bill, now in the House of Lords, would introduce incident reporting duties for more organisations if it becomes law. Track it in our [tracker](https://pyralink.co.uk/newsletter/toolkit/ai-regulation-tracker).
- [ ] **Customers and suppliers:** decide who needs to be told, and what you can accurately say.
- [ ] **Fraud:** report to your bank and to [Report Fraud](https://www.reportfraud.police.uk/). In the UK, you can also [report a cyber incident to the NCSC](https://www.ncsc.gov.uk/report-an-incident).

## 6. Eradicate and recover

- [ ] Remove the cause: malicious files, unauthorised connections, risky permissions, unapproved tools.
- [ ] Rotate credentials and tokens that may have been exposed. Rebuild systems from known good sources if integrity is in doubt.
- [ ] Restore normal service in stages. Watch logs closely for a period afterwards.
- [ ] Re-enable AI features only with tighter permissions and approvals than before.

## 7. Communicate

- [ ] Agree one source of truth and one spokesperson.
- [ ] Give staff short, factual updates. Avoid speculation.
- [ ] Tell customers or regulators only what you have confirmed. Correct earlier statements if they change.
- [ ] Keep a copy of every external statement.

## 8. Learn and improve

Within two weeks, hold a blameless review.

- [ ] What happened, in order, with times?
- [ ] What worked? What slowed us down?
- [ ] Which control would have prevented it or reduced the damage? (Approved tools, data rules, least privilege, logging, approvals, supplier terms.)
- [ ] Update the [acceptable use policy](https://pyralink.co.uk/newsletter/toolkit/ai-acceptable-use-policy), the [checklist](https://pyralink.co.uk/newsletter/toolkit/secure-ai-adoption-checklist) and this playbook.
- [ ] Record actions with owners and dates, and check they are done.
- [ ] Run a practice scenario at least once a year. For example: "an agent has emailed customer data to an unknown address. What do we do in the first hour?"

## Decision log template

| Time (24h) | Decision or action | By whom | Why | Evidence reference |
|---|---|---|---|---|
| | | | | |
| | | | | |
| | | | | |

## Sources

- NCSC, [Incident management](https://www.ncsc.gov.uk/collection/incident-management).
- NCSC, [Managing the cyber risk of agentic AI](https://www.ncsc.gov.uk/blogs/managing-the-cyber-risk-of-agentic-ai) (20 August 2026): logging, attributable activity, emergency shutdown.
- ICO, [Report a breach](https://ico.org.uk/for-organisations/report-a-breach/).
- LiteLLM, [Security incident, 21 October 2026](https://docs.litellm.ai/blog/security-incident-oct-21-2026), and Microsoft, [analysis of the LiteLLM 1.107.0 compromise](https://www.microsoft.com/en-us/security/blog/2026/10/23/inside-the-litellm-1-107-0-supply-chain-compromise-credential-theft-through-python-startup-hooks/) (23 October 2026).
- UK Parliament, [Cyber Security and Resilience Bill](https://www.parliament.uk/business/news/2026/october-2026/cyber-security-and-resilience-bill-lords-third-reading/) (30 October 2026).
- UK government, [Britain steps up national defences against growing AI risks](https://www.gov.uk/government/news/britain-steps-up-national-defences-against-growing-ai-risks) (12 October 2026).
- [Report Fraud](https://www.reportfraud.police.uk/).