Triage is where AI security programmes actually stall
Most organisations discover their AI security process is broken at triage rather than at testing. Findings arrive that nobody knows how to score. A convincing jailbreak demo gets escalated to the executive committee while a quiet retrieval-path finding with real reach sits in a backlog. The queue fills with model-behaviour curiosities and the genuinely dangerous items are the ones nobody could rank, because the ranking instrument was built for software with deterministic exploits and a patch at the end.
The fix is not a new number. It is a change in what severity is about. Severity is not a measure of how badly the model behaved, how surprising the technique was, or how impressive the demo looked in the room. It is a measure of what the finding chains to: what data it reaches, what action it can cause, whether a human had to help, and whether it persists.
Microsoft's published rubric, and the two decisions to copy 8 min live
There is no industry-standard severity scheme for AI findings. What exists is a handful of vendor bug-bar documents, and Microsoft's Vulnerability Severity Classification for AI Systems is the most usable of them, because it commits to specific pivots rather than adjectives. Two of those commitments are worth lifting wholesale into your own process, whatever else you keep.
Look at what the first pivot does. The same technique, causing the same impact, is Critical if it needs no user interaction and Important if it needs some. Nothing about the model changed between those two rows. What changed is how much of the attack the victim has to perform on the attacker's behalf, which is a property of your architecture rather than of the language model. That is the whole point: the rubric ranks on things you can design.
The second pivot does the same job on the data side. Inferential information disclosure is keyed to data classification, not to technique. Model theft runs Critical when the model is Highly Confidential and slides down to Low when it is Public. System-prompt and input extraction is Important when the content is Confidential and Low otherwise. So the question at triage is not "did they get the system prompt out", it is "what classification was in the system prompt". Two organisations can get the identical finding and correctly assign it two different severities.
LiveThe blank in the content column is the most instructive part3 min▶
Content-related issues, in that rubric, are classified only as In Scope or Out of Scope, with no severity rating. It would have been easy to give them a scale. The decision not to is a deliberate separation of the safety track from the security track, and it solves a problem most organisations feel acutely without being able to name.
When harmful-content findings and exfiltration findings share one severity scale, they share one queue, one owner and one set of service-level targets. They then compete for the same engineering time, and the comparison is not meaningful, because a content harm and a data-exfiltration path are answered by different teams with different tools on different clocks. Splitting the rails does not say content matters less. It says it is a different kind of thing, with a different route to a fix, and it should not be ranked against a scope-changing exfiltration path on a single number.
Practical consequence for you: define the boundary before the first engagement, not while triaging its output. Session b1 puts this in the rules of engagement for exactly that reason. A boundary drawn at three in the morning under an incident is a boundary drawn by whoever is most tired.
The same jailbreak, three severities 8 min live
Here is the principle that generalises past any one vendor's bug bar, and the sentence to take out of this session if you take nothing else. A jailbreak in a system with no tools, no private data and no egress is informational. The same jailbreak in a Rule-of-Two agent holding untrusted input, sensitive data and the ability to act is critical. The model behaved identically in both. Only what it was wired to changed.
OWASP's LLM08:2026 entry gives the ladder in worked form, and although it is written for hidden context exposure the shape transfers to almost any finding: Informational where nothing depends on confidentiality, Medium where internal rules meaningfully aid an attacker, High where credentials are embedded or secrecy is being relied on for authorization, and Critical where it chains to remote code execution, broad exfiltration or privilege escalation. Notice that every rung is defined by consequence. Not one of them mentions the technique.
This also resolves an argument your team is probably having about bug bounties. Vendors scope bare jailbreaking out of their security programmes not because they think jailbreaks are unimportant, but because a jailbreak with no chain is not a security finding under a consequence-based rubric. Google's AI Vulnerability Reward Program treats direct injection, jailbreaks and alignment failures as out of scope for security bounties, while paying for indirect injection with production impact. That is the cleanest published statement of the security-versus-content boundary available, and it is worth reading as a scoping decision rather than a dismissal. This detail is secondary-sourced in our source map, so verify it against the live programme page before you cite it in a policy.
Two teams bring you findings on the same Tuesday. Team one has a beautiful multi-turn jailbreak against a marketing copy assistant with no retrieval, no tools and no outbound network. Team two has a mundane, unglamorous finding that untrusted content in a shared document reaches an agent which can send email. Under a consequence-based rubric, the second one is your emergency and the first one is a note. Under an impressiveness-based rubric, which is what most organisations run without admitting it, you would spend the week on the first.
Where CVSS breaks, and the five axes to use instead 7 min live
You already have a scoring instrument, a triage queue built around it, and years of institutional habit. None of that has to be thrown away. But four specific things about AI findings do not fit it, and knowing exactly which four is what stops your process quietly producing wrong rankings while looking healthy.
| Where it breaks | What goes wrong in practice |
|---|---|
| No exploit-reliability dimension | A finding that fires 40% of the time and one that fires every time score identically. Session a3's evidence makes this the sharpest gap: NIST measured average attack success moving from 57% to 80% purely by repeating identical attacks, so reliability is a real, measurable, decision-relevant quantity your score cannot express. |
| Non-determinism breaks the reproducibility gate | Most triage processes require a finding to be reproduced before it is accepted. Against a stochastic system, "I could not reproduce it" is an expected outcome for a genuine defect. Teams then close real findings as unreproducible, in perfectly good faith. |
| Patch semantics differ | Classic triage assumes a fix exists that closes the class. Here there is frequently no such fix, only mitigations that lower a rate. "Remediated" is often the wrong word, and a queue whose only exits are fixed or accepted has no state for the thing that actually happened. |
| Agent autonomy and tool scope are unmodelled | Nothing in the vector expresses how many irreversible actions the agent can take, or how deep a chain it runs unattended. For agent findings this is the dominant variable, and it is entirely invisible to the score. |
None of that means CVSS is useless here. It scores consequence well, and there is a real example worth keeping on the wall for calibration. CVE-2025-32711, the EchoLeak finding in Microsoft 365 Copilot, is scored CVSS 3.1 9.3 Critical, with S:C for scope changed and UI:N for no user interaction required. That vector is a well-formed AI finding: the scope change captures that the impact crosses the component boundary, and the no-user-interaction flag is precisely Microsoft's own Critical pivot from Part 1. When the consequence is clear, the existing instrument does its job.
Run every finding through all five, in writing, before it gets a rank. Reachability, meaning zero-click versus one-click versus requires-a-cooperative-user. Reliability, expressed as k of N with N stated, from session a3. Blast radius on data, meaning the highest classification reachable. Blast radius on action, meaning which irreversible tools come into play. And durability, meaning whether it persists through memory, a poisoned tool or a poisoned index, or evaporates when the session ends.
The rule that follows, and the one your triage board should have written on the wall: for agents, the dominant term is action blast radius, not model behaviour. Once a system can act, what it can irreversibly do is the risk. What it says is a much smaller part of the picture than the demo culture around this technology suggests.
Triage three Beacon findings, out loud ★ 12 min · in groups of three
Three findings land from the Beacon engagement on the same morning. Rank them, then defend the ranking using only the five axes. The disagreements this produces are the point, and they are almost always disagreements about architecture rather than about severity.
Finding A. A multi-turn jailbreak makes the Insight Bot produce disallowed content. The Insight Bot has no tools, no retrieval over private data and no outbound network. It fired 22 of 25 trials, so it is highly reliable. Where does it rank, and which axis is carrying your answer?
Finding B. Untrusted content placed in a shared document causes the Support Bot to attempt a refund credit to an attacker-controlled account. It fired 3 of 25 trials. The blast-radius limits in the rules of engagement meant no refund was actually issued, so it was recorded and stopped there. Where does it rank?
Finding C. The Analyst Bot's system prompt can be extracted. It fired 25 of 25 trials, perfectly reliable. Before ranking it, ask the only question that matters here and notice that nobody in the room can answer it yet.
Now say the missing question out loud. For C it is: what is the data classification of what is in that system prompt? Important if the content is Confidential, Low otherwise. The finding's reliability is 25 of 25 and it changes nothing about the severity. That is Microsoft's second pivot doing its work.
Compare A and B honestly. A is more reliable, more reproducible, more impressive in a demo and easier to explain to an executive. B is the one that reaches money through untrusted content with no user interaction. If your queue would have surfaced A first, the queue is ranking by impressiveness, and now you know where to fix it.
Write down what would change each ranking. Give the Insight Bot retrieval over customer records and A moves up immediately. Put per-action human approval in front of the refund tool and B moves down. Severity is an architectural output, which means it is something you can act on before the next engagement rather than only after it.
Decide your security-versus-safety boundary, in writing ★ 6 min · whole room
This is a decision, not an analysis, and it has to be made before findings arrive rather than during the argument about a specific one. Draft it now in four lines and take the draft to whoever owns the incident process.
Line 1 · what goes on the security rail. The candidate rule, drawn from the rubrics above: anything that chains to another user's data, to a privileged action, or to an irreversible external effect. These get a severity, an owner and a service-level target.
Line 2 · what goes on the safety and content rail. The candidate rule: harmful, disallowed or reputationally damaging output with no chain. These get classified in scope or out of scope with no severity rating, and go to a different owner on a different clock. Say explicitly that this is not a statement that they matter less.
Line 3 · the promotion rule. Name the condition under which a content finding becomes a security finding. Usually this is the moment it chains: the same output rendered somewhere that executes it, or reaching a tool. Write the condition down, because without it every borderline case becomes a negotiation.
Line 4 · who arbitrates, by name. Not a team, a person, with a named deputy. Every rubric in this session produces edge cases. An unowned edge case sits in a queue for six weeks and then gets escalated by whoever is angriest.
Try it yourself - this week ◐ 45-60 min total
- Take the last ten AI findings in your queue and re-rank them on the five axes. Compare against the existing order. The findings that move furthest tell you what your current instrument is actually measuring.
- Add two fields to your finding template that almost certainly are not there: user-interaction requirement and data classification of what is reachable. Those are Microsoft's two pivots, and they are cheap to capture and expensive to reconstruct later.
- List every irreversible tool each of your agents can call, and mark which ones require per-action human approval. That list is the action blast-radius axis, and for agent findings it is the dominant term.
- Find one finding in your history that was closed as unreproducible. Ask whether it was tested more than once. Against a stochastic system, a single failed reproduction is not evidence of absence.
- Write the four-line security-versus-safety boundary from the second exercise and get it signed off. Then check what your queue does with a content finding that later chains to a tool, because that is the case the rule exists for.
Official sources covered
Every framework, figure and quotation on this page traces to a primary source catalogued in this course's source map, verified 2026-08-14. This page covers:
Three questions before you go 🎯 ◐ 90 seconds
1 · Two findings describe the identical prompt-injection technique with the identical impact. One needs no user interaction, the other needs the victim to click. What separates them?
The pivot matters because it ranks on something you can design. How much of the attack the victim has to perform on the attacker's behalf is a property of your architecture, not of the language model, which means it is a lever you can pull before the next engagement. The rubric's second pivot works the same way: inferential information disclosure is keyed to the data classification of what is reachable, so two organisations can receive the identical finding and correctly assign it two different severities.
2 · Your team brings you a highly reliable jailbreak against a system with no tools, no private data and no egress. How should it be ranked?
Option A is the sharpest trap, because reliability really is one of the five axes. But reliability modifies a consequence, it does not create one, and a rate of 25 of 25 multiplied by nothing reachable is still nothing reachable. This is also the reason vendors scope bare jailbreaking out of security bounty programmes: under a consequence-based rubric, a jailbreak with no chain is not a security finding. The useful move is the architectural one - the ranking changes the moment you give that system retrieval over private data or an outbound path.
3 · Which limitation of CVSS bites hardest on AI findings, and why?
Option C is simply false, and EchoLeak is the counter-example: CVE-2025-32711 scored 9.3 with S:C for scope changed and UI:N for no user interaction, a well-formed vector that captures the consequence properly. CVSS scores consequence well. What it cannot express is reliability, and three other things: non-determinism breaks the reproducibility gate most triage assumes, patch semantics differ because often no fix closes the class and only mitigations lower a rate, and agent autonomy and tool scope are unmodelled entirely. OWASP AIVSS aims at this gap but sits at v0.8, pre-1.0, with its formula described only in secondary sources.