Classify an AI agent incident by three facts: what data or systems the agent reached, whether it changed or sent anything, and whether it is still running. Reach plus impact plus ongoing activity maps to a severity level. Decide the scale before an incident, not during one.
Why agents need their own severity inputs
A normal severity scale asks about the system affected and the data exposed. For agents, add one more question: is the actor still acting? A compromised script stops when you kill the process. An agent driven by injected instructions can keep working through different tools, so "contained" has to be confirmed rather than assumed.
Three questions to answer first
- Reach: which identities, tools and data could the agent touch? Use the agent's registered scope, not what you hope it did.
- Action: did it only read, or did it write, delete, send or spend?
- State: is it running now, and can it still call tools?
You can answer the first from your registry and the second from tool call logs. The third needs a kill switch you have already tested.
A four level scale
| Level | Typical facts | First move |
|---|---|---|
| Sev 1 | Agent still active, wrote or sent data outside the company, or touched regulated or customer data | Disable the identity and tools now, open an incident bridge |
| Sev 2 | Agent acted outside its scope on internal systems, now stopped | Revoke credentials, preserve logs, scope the damage |
| Sev 3 | Out of scope read access only, no data left, no changes | Tighten permissions, review logs |
| Sev 4 | Policy violation or near miss, nothing reached | Fix the control, record the lesson |
Your own names and numbers may differ. The pattern holds: more reach, real writes and ongoing activity push the level up.
Adjusters that move the level up
- The agent held credentials for production systems or payment actions.
- Personal data of customers or staff was in scope. If personal data is involved, reporting clocks may start. The GDPR text sets a 72 hour limit from awareness for notifying the supervisory authority where a breach is likely to result in a risk to people, so involve privacy and legal early.
- You cannot tell what the agent did because logs are missing. Missing evidence is itself a reason to rate higher until proven otherwise.
- The trigger was untrusted content that other agents may also read.
Adjusters that move the level down
- The agent ran in a sandbox with synthetic data.
- All actions are in logs and match the intended scope.
- The tools it used cannot change or send anything.
Steps to adopt this
- Write the scale on one page and get security, engineering and legal to agree.
- Add the three questions to your incident intake form.
- Link each registered agent to its scope so reach is known in seconds.
- Test the scale in a tabletop exercise with a prompt injection scenario.
- Review it after the first real or practice incident.
Do not wait for certainty
You will rarely know everything in the first hour. Start at the higher plausible level and step down as evidence arrives. Stepping down is cheap. Stepping up late is not.
Safeguard's agent identity and asset discovery features help you know which agents exist and what they can reach, which is the input this scale needs. A free scan is at https://gold.safeguard.sh/scan.
Quick check
Who sets the severity?
The incident commander, using the agreed scale, with input from privacy and legal when personal data may be involved.
Should severity change during an incident?
Yes. Start high when unsure, then adjust as logs confirm what happened.
Sources
Last reviewed: 19 October 2026.
