What does an AI security incident response plan look like?

It follows standard phases with four substitutions that break the existing playbook:

• Containment means revoking tool permissions and terminating sessions, not isolating a host

• Evidence means prompts, context sources, trajectories, and memory state, not disk images

• Root cause may be non-reproducible, because the same input can produce a different trajectory

• Blast radius is defined by every system the agent could reach, not by the system where you noticed the problem

Detection triggers need writing specifically. Anomalous tool-call sequences, an agent accessing data outside its normal scope, a spike in refusals, output containing system prompt fragments, and unexpected outbound destinations from an agent workload.

Containment steps, in order: revoke the agent's credentials and tool permissions, terminate active sessions, disable the affected agent or route to a restricted configuration, and preserve context and memory state before anything is reset. That last step is the one teams skip, and it is the only evidence of what happened.

Investigation requires trajectory reconstruction. You need the full sequence of context inputs, model decisions, tool calls, and results. If your logging captured prompts and responses only, the investigation stops at what the agent said rather than what it did.

Eradication has an AI-specific step: purge poisoned memory and retrained state. Restoring the application does nothing if the vector store still holds the injected instruction. Recovery should include a model or prompt version rollback path, treated with the same rigor as a code rollback.

Akto Argus supplies the runtime records these phases depend on, logging tool calls and enforcement decisions across agentic applications.

Write the runbook before you need it. Mid-incident is a poor time to discover you cannot reconstruct a trajectory.