TL;DR: Rank an AI chat app's findings by what each one exposes, not by the label on the report. Known public exploits go first. Anything that reaches data people shouldn't see goes next. Then anything that changes what the app does, and last, bad text with no data behind it. Re-rank whenever the app's reach changes.
Key takeaways:
Severity follows reach. A jailbreak on an app that touches no data is minor. The same jailbreak is serious the day the app connects to a data warehouse.
Use four groups in this order: known public exploits, then reach to data, then changes to what the app does, then bad text.
A severity label can be argued down by management. What a finding exposes can't be argued with.
One guardrail product won't cover the whole OWASP Top 10 for LLM Applications, so sort the findings before you shop.
Re-rank every time someone connects the app to a new system.
Why does the label on a finding mislead you?
A label tells you what someone decided, not what the finding exposes. "Critical" and "high" are opinions. They move when a budget meeting moves them.
On October 19, 2026, I talked with the security team at a financial firm. They had built an internal chat app on an open-source front end and an open-source model router, running in Azure. They tested it themselves and found about 25 problems. Management then moved many of the criticals down to highs.
That didn't change one thing the app could reach. So I told them to stop arguing about labels. Rank by what each finding exposes, and the labels stop counting.
What order should AI app findings go in?
Use four groups, in this order.
Known public exploits. Someone has already published how to break it. These go first because the attacker needs no skill.
Reach to data people aren't entitled to. Missing role controls sit here. So does an app that treats every user as the same user.
Changes to what the app does. An app that browses the web or makes images can do things nobody planned for.
Bad text with no data behind it. A rude answer or a clever jailbreak. Annoying, and low on the list until the app can reach something.
Then add one rule. Re-rank when the app's reach changes. That's the whole method.
How did this play out on a real app?
The team's findings sorted fast once we asked what each one exposed.
Their sign-in had moved to Microsoft Entra two weeks earlier. But the identity of each person stopped at the front end. The model router saw every request as coming from the firm. So nothing could say which person was allowed to see which document. Missing role controls headlined the list.
The app also browsed the open web. Every control the firm had built for people was missing for the app. And every page it fetched could carry hidden instructions. The OWASP project calls that indirect prompt injection: the model reads outside content, and the content changes what it does.
Their guardrail product screened what went in. Output was set to watch only, and their tester kept pulling data past the input screen. Someone on the client team put it plainly: "it's kind of difficult to make a guardrail tool be a DLP tool." DLP is data loss prevention, the control that stops sensitive data from leaving.
Then came the clock. A data warehouse connection was about three months away, and agents for analysts after that. Every jailbreak on the list was minor today. Each one would be severe once that connection went live.
Patching told the same story. Management set quarterly or every six months. The open-source front end was publishing advisories weekly. Known exploits go first, so that cadence moved up the list.
Why won't one guardrail product cover the list?
Because AI apps fail in more than one place. The OWASP Top 10 for LLM Applications (2025 edition) names ten risks, from prompt injection to sensitive information disclosure to unbounded consumption. Runtime products and model-pipeline products cover different ones.
I saw this earlier in the year. On June 29, 2026, I wrote a review for a health system picking an AI security product. I scored products against the OWASP ten. Runtime products and pipeline products covered different risks, and none covered all ten.
The ledger I keep from client calls shows the app-security question on two entries so far: that June 29 review and the October 19 call. The "guardrail as DLP" problem appears in both. "Severity follows reach" is one datum, from October 19. I haven't checked it against earlier calls.
Sort first. Then buy for the group you're weakest in.
What should you do this week?
Before the next status meeting, write down every finding. Next to each one, write what it exposes today and what it would expose after the next planned connection. Then sort them into the four groups.
Add a second column, an owner. A finding in group two with no owner will sit there. If you want the access side, my post on giving an AI agent the right amount of access covers it. For the attack side, read what prompt injection is and how to protect AI agents from it.
Frequently asked questions
Should I ignore jailbreaks?
No. Put them in group four and fix them after the groups above. They climb the list the moment the app can reach real data.
Who decides the ranking?
Security proposes it and the data owner confirms it. The data owner knows what the app could reach. Security knows how to reach it.
What if management insists on the original labels?
Keep both columns. Show the label and show the exposure. Leaders can argue with a label. An exposure is a plain fact about what the app can touch.
How often should I re-rank?
Every time the app gets a new connection or a new group of users.
Your findings report is a list of opinions until you add what each one reaches. Add that column first.