How are teams prioritizing the LLM Top 10 risks using quantitative methods like FAIR?

[BillMartin04]

Hi everyone,

I'm an enterprise architect working in cyber risk management and AI governance, and I'm trying to connect the OWASP Top 10 for LLM Applications to quantitative risk prioritization. I'd really value the community's perspective.

Where I'm coming from: on the governance side we build a single source of truth for critical assets first, then use it to decide what actually matters most to monitor across the different risk types. I lean on a FAIR-style lens (Factor Analysis of Information Risk) to estimate loss exposure so limited resources go to the places that reduce the most risk.

My questions:

1. When you assess an application against the LLM Top 10 (for example LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, or LLM06 Excessive Agency), how do you decide what to remediate first? Is it mostly qualitative severity, or do you translate findings into business and loss terms?

2. Has anyone mapped LLM Top 10 categories to a quantitative model like FAIR (threat event frequency, vulnerability, loss magnitude)? If so, what worked and what didn't?

3. For systems handling sensitive data or with real-world agency (tool use, actions, transactions), how do you factor asset criticality and blast radius into prioritization so you aren't treating every use case equally?

4. On the governance/operating-model side, how are you giving the first line of defense visibility into the LLM risks and controls they actually own, so accountability is clear rather than sitting only with a central team?

5. What signals do you rely on for ongoing visibility once an LLM feature is in production, given how quickly the threat surface changes?

I'm exploring this as part of a cybersecurity course exercise on understanding an organization's critical systems and data, but it's also directly relevant to my day-to-day work. Any real-world experience is very welcome. Thanks!

[dev-rehaann]

I would not map LLM01 → one FAIR score. An OWASP category is a useful scenario-generation and control taxonomy, but it is not itself a loss event. The same category can produce very different loss exposure in two applications, and one loss scenario can span several categories.

A workable pattern is:

1. Define the AI use case and trust boundaries.
2. Turn each relevant Top 10 finding into one or more FAIR scenarios: threat actor + asset + method + business effect + timeframe.
3. Estimate Loss Event Frequency from Threat Event Frequency and susceptibility (the current FAIR term; often called vulnerability).
4. Estimate primary and secondary Loss Magnitude.
5. Compare current and residual loss distributions for each proposed control.

For example:

Over the next 12 months, an external attacker uses indirect prompt injection in documents processed by a support copilot, causing its CRM/email tools to disclose customer records.

That scenario involves:

• LLM01 as the attack method;
• LLM02 as the confidentiality effect;
• LLM06 as a major susceptibility/blast-radius driver if the agent has broad tools, permissions, or autonomy.

For TEF, I would use attacker sessions/campaigns rather than counting every malicious string as a separate event. Inputs can come from exposed sessions, volume of untrusted content processed, observed attempts, threat intelligence, and abuse telemetry.

For susceptibility, use representative adversarial evaluations: the proportion of attempted scenarios that cross the relevant trust boundary. Test direct and indirect injection, different modalities/languages, tool-call chains, and repeated attempts. Record a range, not a point estimate, and adjust for test coverage and control independence. A detector hit rate alone is not susceptibility; the important outcome is whether the attempt produced unauthorized access, disclosure, or action.

For Loss Magnitude, model what the connected system makes reachable:

• records/data classes accessible per event;
• incident response, forensics, notification, restoration, and business interruption;
• fraud or transaction value;
• contractual, regulatory, customer, and reputational secondary losses.

This is also how I would handle asset criticality and blast radius. I would not add a generic “criticality multiplier.” Put the real architecture into the scenario: tenant isolation, data sensitivity and reachable record count, tool privilege, transaction limits, action reversibility, egress paths, propagation to other systems, and whether high-impact actions require approval. A read-only assistant over public data and an autonomous agent with production write access should not inherit the same score merely because both have an LLM01 finding.

The most useful prioritization measure is then marginal risk reduction, not OWASP rank or finding count:

current loss exposure − residual loss exposure after control

Compare that reduction with implementation/operating cost and risk appetite. For the example above, removing the send tool, using user-scoped read-only credentials, enforcing downstream authorization, and requiring approval for consequential actions will usually reduce more exposure than another prompt filter. OWASP's own guidance notes that prompt injection cannot be assumed fully preventable and that impact depends heavily on business context and agency, so containment deserves explicit credit in the model.

For the operating model, I have seen the clearest accountability when there is one risk record per use case/scenario, not per model:

• First line/application owner owns the scenario and treatment decision.
• Data owner owns permitted data use and disclosure constraints.
• Tool/API owner owns scopes, authorization, limits, and reversibility.
• Model/platform team owns model, RAG, evaluation, and change evidence.
• Security/second line defines the method, challenges estimates, and sets minimum controls/risk appetite.

The first-line view can stay small: scenario, exposed assets, current/residual loss range, top control assumptions, failed evidence, owner, due date, and last material change. That is more actionable than a central dashboard of red/amber/green Top 10 labels.

For continuous visibility, I would keep signals tied to the FAIR inputs and scenario assumptions:

• attempts and unique attacker sessions per exposed channel;
• adversarial-evaluation success rate and coverage;
• denied and successful sensitive tool calls;
• permission/scope drift and new tool or egress destinations;
• sensitive-data output/DLP events;
• approval prompts, rejections, overrides, and bypasses;
• model, prompt, RAG corpus, connector, and policy changes;
• token/cost/rate anomalies, incidents, and near misses.

Normalize operational signals (for example, per 10,000 sessions or per million retrieved documents), retain the raw counts needed for frequency estimates, and re-run the analysis after a material architecture/control change rather than treating every telemetry fluctuation as a new FAIR assessment.

The main limitation is sparse loss data. I would handle that with calibrated ranges and sensitivity analysis: identify which uncertain input can change the decision, then spend measurement effort there. A Monte Carlo result with explicit assumptions and percentiles is more defensible than a precise-looking single ALE number.

Relevant references: OWASP LLM01:2025, OWASP LLM02:2025, OWASP LLM06:2025 in this repository, Open FAIR Body of Knowledge, and NIST AI 600-1.

[ottosulin]

Has anyone mapped LLM Top 10 categories to a quantitative model like FAIR (threat event frequency, vulnerability, loss magnitude)? If so, what worked and what didn't?

@rocklambros is the incident data that was used somewhere publicly available? If someone would like to combine LLM top 10 and FAIR I think that could be a possibly interesting resource for quantitative analysis, although obviously it is backward looking and with this particular technology not necessarily useful for decisions about the future...

When you assess an application against the LLM Top 10 (for example LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, or LLM06 Excessive Agency), how do you decide what to remediate first?

Top 10's order is a good starting point, but I would based on your application's use cases and threat model change the given impact/likelihood of each vulnerability. In my current company with our current products the Top 10's order isn't exactly as is how I would rank them for us.