Why Existing Incident Response Runbooks Fall Short for AI Agents
NIST SP 800-61 Rev. 2 defines a four-phase incident response lifecycle: preparation, detection and analysis, containment/eradication/recovery, and post-incident activity. Most enterprise security teams already run this lifecycle for endpoints, applications, and network infrastructure. The gap is not the lifecycle itself but the missing agent-specific assets within it.
An AI agent typically has no independently defined identity object, no documented tool-permission scope, and no established behavioral baseline that a SOC analyst can reference during containment, eradication, and recovery. NIST AI 600-1 flags autonomous or agentic behavior as a risk category that existing monitoring practices may not adequately cover, and CISA’s AI Roadmap confirms the intended approach is to integrate AI considerations into existing cyber defense programs rather than build a parallel framework.
Practically, this means containment for a compromised agent should reuse the 800-61 lifecycle, but every phase needs an agent-specific runbook entry defining exactly which credential, session, or endpoint gets acted on.
Detection Signals for a Hijacked or Compromised Agent
There is currently no industry-standard behavioral baseline for normal AI agent tool-use patterns, which makes anomaly-based detection less mature than traditional endpoint EDR baselining. In the absence of a universal standard, detection triggers must be predefined before an incident occurs rather than derived ad hoc during one.
Reasonable trigger categories include:
- Anomalous tool-call volume relative to the agent’s typical task pattern
- Requests for permission scopes beyond an allow-listed tool set
- Deviation from expected tool sequences for a given workflow
OWASP’s Top 10 for LLM Applications names “Excessive Agency” as a distinct risk category, describing harm that results when an agent’s functional permissions or autonomy exceed what a task actually requires. MITRE ATLAS catalogs adversarial techniques against AI systems, including prompt injection and supply-chain compromise, that can produce exactly these kinds of scope or sequence anomalies. Detection logic should run separately from the agent’s own runtime so a compromised agent cannot suppress or falsify the signals used to contain it.
Designing for Containment: Agent Identity and MCP Session Considerations
Containment speed and completeness depend heavily on architectural decisions made before an incident. Agent identity should be modeled as a distinct, independently revocable credential rather than permissions embedded directly in the model or application layer; this is what allows revocation without a full system shutdown.
Because MCP session state and negotiated tool capabilities persist server-side for the life of the session, termination logic needs to be triggerable centrally, not only by the client, so a security team can stop in-flight tool calls during an active incident rather than waiting on the agent’s own process to disconnect.
Since tool-call chains can span multiple downstream MCP servers, containment planning should include a current map of those dependencies and predefined coordination points with the owners of downstream tools or services, so that containment does not stop at the first hop while calls continue further downstream.
Model agent identity as an independently revocable credential, and ensure MCP session termination can be triggered centrally. Downstream tool-call chains will otherwise outlive a partial containment action.