How to Build an AI Agent Incident Severity Playbook

Why Traditional Severity Models Fall Short for AI Agents

Most enterprise security teams already operate a severity classification model, typically adapted from SRE or SOC practice, that scores incidents by functional impact, information impact, and recoverability effort. This model, formalized in NIST SP 800-61, works well for deterministic systems where a vulnerability or breach has a fixed exploitation path. AI agents break this assumption. An agent's behavior can vary across sessions even with identical inputs, and the same underlying capability, such as a file-write tool, can produce a low-severity outcome in one context and an irreversible one in another depending on what permissions were active and what the agent decided to do with them. NIST's AI Risk Management Framework explicitly acknowledges that AI systems exhibit non-deterministic and emergent behavior that complicates one-time risk classification, which is why agent incident severity has to be evaluated at the moment of the event, using runtime context, rather than assigned solely from a static asset inventory or known vulnerability list.

Defining Severity Tiers Around Agent-Specific Impact

No standards body has published agent-native severity tiers equivalent to SEV1-4 definitions used in SRE practice, so security teams need to adapt the NIST 800-61 impact dimensions to agent behavior directly. A practical adaptation replaces generic functional and information impact scoring with three agent-specific questions: what was the scope of tool or API access invoked, what data or system state was altered, and can the action be reversed without external consequence.

OWASP's guidance on excessive agency reinforces that severity should scale with the degree of autonomy and permission scope granted to the agent at the time of the incident, not just the final outcome, since a near-miss with broad permissions carries different risk than a successful action with narrow permissions.

Technical Signals That Should Trigger Escalation

Effective triage depends on having the right signals available before an incident occurs, not reconstructing them after the fact. Anomalous tool-call patterns, such as an agent invoking functions outside its documented task scope or calling the same tool at an unusual frequency, are early indicators worth monitoring. Permission escalation attempts, where an agent requests or receives elevated scope beyond its baseline configuration, should be logged and treated as a distinct signal category from normal tool use.

Evidence of prompt injection, identified when agent output or behavior shifts in response to untrusted input in a way that triggers unintended tool calls, is flagged by OWASP as a top risk category specifically because it can be used to bypass safety controls. MITRE ATLAS catalogs these and related adversarial techniques against AI systems, and mapping detected signals to ATLAS technique categories gives security teams a shared vocabulary for classifying whether an incident is a policy violation, a security breach, or a safety failure, which in turn determines which escalation path applies.

Containment and Escalation Actions by Severity

Containment for agent incidents differs from traditional application incidents because the fastest control is often revoking or narrowing the agent's runtime permissions rather than patching code.

• Low severity (e.g. a blocked unauthorized tool call): logging and monitoring for repetition may be sufficient without full escalation.
• Mid severity (reversible unauthorized actions): suspend the specific agent session, review the permission grant that allowed the action, and revert any state change.
• High severity (irreversible actions or confirmed prompt injection): suspend the agent identity or credential across all sessions, conduct a full audit log review to reconstruct the decision path, and notify the incident owner responsible for AI-specific risk.

OWASP's recommendation to require human approval for high-impact actions is directly relevant here: agents that already require approval checkpoints for sensitive operations reduce both the frequency and blast radius of high-severity incidents, since the approval step itself becomes a containment control rather than an afterthought.

Governance Requirements That Support the Playbook

A severity playbook only works if the governance foundation behind it exists first. NIST's AI RMF requires organizations to pre-define risk tolerance and escalation protocols as part of its Govern function, which for agents means documenting what permission scope each agent is approved to hold before it is deployed, not after an incident reveals it. This creates an auditable baseline: when an incident occurs, the first triage question becomes whether the agent acted within its approved scope or exceeded it, which immediately informs severity.

Post-incident review processes, following the 800-61 lifecycle, should explicitly assess whether the agent's permission scope or autonomy level contributed to the incident and feed that finding back into policy updates rather than treating each incident as isolated. Because no binding regulatory standard currently defines AI agent incident severity, organizations should treat these frameworks as adaptable best practice, documenting their own thresholds clearly enough that they hold up during audit or post-incident review.