The standard IR runbook assumes the attacker is a person: an agent incident needs containment that revokes tokens and terminates sub-agents, evidence that includes prompts and tool traces, and a tabletop scored on what the agent’s identity can still do after the switch is pulled.

Before the mechanics, the clock. Amended Regulation S-P requires covered institutions (SEC-registered investment advisers, funds and broker-dealers) to maintain a written incident response program designed to detect, respond to and recover from unauthorized access to customer information, and to notify affected individuals as soon as practicable and no later than 30 days after becoming aware. Compliance dates were 3 December 2025 for larger entities (advisers at or above $1.5B AUM, fund complexes at or above $1B net assets) and 3 June 2026 for everyone else. Both are past. An agent that reads customer information and sends it somewhere is a Reg S-P incident with a 30-day clock, regardless of who built it or whether it was in the registry. The EU AI Act’s Article 73 serious-incident reporting, with its tiered 2/10/15-day deadlines, is the shape of coming regulation rather than a live duty here. The high-risk obligations moved to 2 December 2027, and Annex III excludes a US fund’s internal research and operations agents. Who decides whether a given incident is notifiable, the separate 72-hour clock running from the vendor’s awareness, and what counts as privileged during all of this are legal escalation, not this page.

The checklist

1. Extend the incident machinery already in place. ISO 27001 supplies five controls: planning, assessment and decision, response, learning, and evidence collection at A.5.28. Agent IR should attach to those, not run beside them. The gap is specific and worth stating internally: none of the 93 Annex A controls mentions AI or agents, so A.5.28’s evidence duties say nothing about prompts, tool-call traces or memory state. Writing the agent annex to A.5.28 is the single highest-value hour on this page.

2. Classify the incident by source before reaching for a playbook. Model, data, infrastructure, or the agent’s own behaviour, with predefined response steps for each. That four-way split is a BCG recommendation and it is sensible; it also could not be verified at the publisher, so adopt it as structure rather than citing it as authority. The classes have genuinely different first moves: a model regression is a rollback, an injected agent is a containment.

3. Contain in this order, and treat the steps as distinct. Disable the agent, revoke the connections, sweep the sub-agents, suspend the sessions. Microsoft’s own containment sequence lists “disable the agent” and “revoke connections” as separate steps, which is first-party support for the position that stopping a process does not end access; see kill switches and revocation. Prefer suspending a session to killing a process where the platform allows it. The MCP governance literature specifies suspend-the-session, notify affected users, preserve forensic logs, though as target-state architecture from vendor-affiliated authors rather than observed practice. Research systems demonstrate the two graduated moves executed through the registry rather than the endpoint: blocklist a specific counterparty agent, or ask the provider to deactivate the firm’s own outright.

4. Preserve the evidence classes ordinary IR never collects. Session transcripts, full tool-call traces with arguments and returns, memory and vector-store state, session identifiers and timestamps. Memory is the one people discover too late: killing the process leaves poisoned memory in place, so the ability to inspect and edit an agent’s memory during an incident is required. “Can we read and modify this agent’s memory right now?” is a tabletop question most firms answer no to. See memory and context poisoning and logging and audit. One discipline throughout: never work the incident inside an agent. Pasting the facts into a hosted AI tool is disclosure to a third party, and counsel advising this sector warn it can waive privilege over exactly the material a firm least wants disclosed.

5. Write the recovery half, not only the containment half. Point-in-time recovery to a known good state, integrity-checked backups, periodic recovery testing, and independently exercisable rollback paths for data and models. That formulation predates agents: it comes from an AWS framework its own publisher now marks historical-reference-only, so take it as lineage.

6. Name the person, and test their reachability. When something goes wrong, who is the named accountable individual, what is their authority to stop, roll back or redirect, and are they reachable at the operating tempo of the agents they answer for? Good test, though note that it circulates misattributed to Anthropic and belongs to a consultancy commentary; use it anyway.

7. Consider a circuit breaker. OpenAI’s governance paper proposes automatic shutdown when risk indicators cross a threshold, explicitly analogous to a market circuit breaker; an influx of jobs from unknown accounts is their example. It also names the redundant parties who can shut an agent down when the user won’t or can’t: the deployer and the operator of the hardware. Two limits: the paper excludes hijacking from its scope, and it concedes the ability to shut down can be lost entirely if no fallback exists.

8. Pre-build the intake path for outside notice. In both documented citizen-agent exposures, first notice came from outside the firm: the Moltbook leak of roughly 1.5 million agent API tokens was found and disclosed by an outside security vendor within days of launch, and the alleged Cal AI breach surfaced through a forum post and journalist investigation, so assume the journalist calls first and know who answers.

9. Close with corrective action rather than correction. The ISO vocabulary is exactly right here. Correction eliminates the detected nonconformity: the agent was killed. Corrective action eliminates the cause so it cannot recur: the gate that let it ship was fixed. A post-mortem that stops at the first is why the same incident arrives twice. Feed the finding into registry review and the tier score, and write the communications plan that ISO/IEC 42001’s A.8.4 requires, because incident comms is the part of agent IR almost nobody has drafted in advance.

How you’d know it’s working

Measured time from switch to zero capability, in a drill. Not whether the process died, but whether its tokens, sessions and children did; that number is the runbook’s actual strength.

Zero reported incidents treated as a detection failure. This is AWS’s line and it is the best observable on the page: expect incidents, be suspicious if none are reported, open a direct path for users to flag wrong results, and remember that the users a system fails hardest are under-represented in the data.

A triage test. Take a real alert and try to resolve it to the specific agent instance, then to its owner, then to its capabilities. Proposals for per-instance agent identity that make this one step exist only on paper, with no implementation and no adopted standard behind them, so the honest reading of that literature is inverted: because per-instance identity remains undeployed, triage today is guessing which of forty bots holds the leaked token.

Calibration against the base rates, cautiously. McKinsey’s 2026 trust survey (n≈496) finds roughly 8% of organizations reporting AI-related incidents while nearly 60% of those who had one rate their own response satisfactory or worse, with incident frequency flat and confidence falling. Read the 8% carefully: 92% answered “no or unknown,” which measures who has logging rather than who has incidents. An Infosys survey of 1,502 executives points the other way: 95% report at least one AI-related incident in two years, 77% with financial loss and 53% with reputational harm. The two are reconcilable rather than contradictory; they are measuring self-knowledge and experience respectively.

What this doesn’t solve

Response presumes detection. An agent whose compromise never trips a signal, or whose payload detonates three sessions later, is a monitoring problem before it is a response problem; see cross-session delayed detonation.

Per-deployer monitoring structurally misses cross-agent incidents. As Chan et al. put it, the deployer of agent A cannot observe the impact of infectious prompts given to agent B. The shared reporting infrastructure that would close this is missing: the civil-society databases collect from humans only, and no mechanism commits anyone in government or industry to respond. AI vendors’ own bug bounties are a different and narrower channel.

No runbook recalls data that already left, or unwinds an order already placed. Containment limits the next hour, not the last one.

And the cultural failure mode is documented as an anti-pattern by Microsoft’s own maturity guidance: teams assume they will deal with problems if they arise, so the response is reactive and inconsistent, the learning is public and expensive, and confidence in AI drops fast after the first incident. The counterweight worth adopting is blameless post-mortem, a position argued by the Partnership on AI’s chief executive rather than by a fund practitioner, so weigh it accordingly.

See also

• Kill switches and revocation — why SIGTERM falls short of containment, and what revocation requires.
• Logging and audit — the evidence this runbook depends on having collected in advance.
• Cross-session delayed detonation — the incident class that defeats session-scoped response.
• Multi-agent cascades — why containment must sweep beyond the first agent.
• Data exfiltration — the incident type where minutes of open egress decide the loss.
• Registry review cadence — where post-incident findings change the agent’s standing.