The OWASP LLM Top 10 (2026), Read From a Finance Seat

The 2026 OWASP GenAI/LLM Top 10, published 4 August 2026, runs: LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, LLM03 Excessive Agency, LLM04 Supply Chain, LLM05 Data and Model Poisoning, LLM06 Unbounded Consumption, LLM07 Misinformation, LLM08 Hidden Context Exposure, LLM09 Vector and Embedding Weaknesses, LLM10 Improper Output Handling. The codes are versioned and they moved this year, so a document citing a bare LLM08 without a release year is citing an unknown item.

This page is the list, verified against the project's canonical repository rather than a secondary write-up, with what changed since 2025 and — the part that is mine, not OWASP's — which entries a finance or treasury deployment actually meets first.

The list, and where each one moved

The renumbering is the practical trap. If your control matrix, your vendor questionnaire or your architecture review cites LLM08, it now means something different from what it meant last year — and the difference is not cosmetic, because System Prompt Leakage was a specific failure and Hidden Context Exposure is a broader class. Write the year with the code.

What is actually new about this release

The 2026 list is the first the project has checked against recorded incidents rather than practitioner judgement alone. The method is worth knowing, because it is the reason two entries sit where they do:

• A corpus of 7,714 real incidents was assembled from public vulnerability databases and an AI-harm database, of which 6,639 carried enough detail to classify.
• The community vote carries three-quarters of the weight; the incident data carries one quarter. That is enough to move an entry a tier where belief and evidence diverge sharply, and deliberately not enough to let one year of imperfect data rewrite a consensus list.

Two divergences came out of that, and both are more useful than the agreements.

Prompt Injection ranks first on the vote and falls out of the top ten entirely on raw incident count. The project reads that as a defence effect rather than an absence of risk: teams already spend real money holding it off, so fewer clean exploits reach a public database. That reading matches what I would expect from any mature control — the incidents you do not see are the ones somebody is paying to prevent — and it is exactly why injection is a blast-radius problem rather than a prevention problem.

Misinformation runs the other way: voters put it near the bottom, the incident record put it near the top, and it was seated in the middle. This is the widest gap in the direction that hurts — the field under-rates it relative to what has already gone wrong. For a finance audience I would treat that as the headline finding of the whole release, because a confident wrong number that drives a posting or a payment is not a content problem. It is a control problem.

The boundary the project draws, and why it matters here

The list owns the risk while a model is a component inside an application. The moment it becomes an actor — with tools it can call, memory carried between sessions, and consequences set in motion downstream — the project routes you to the separate OWASP Agentic Top 10.

That boundary is worth taking seriously, because most enterprise finance deployments are already on the far side of it or will be within a year. An assistant that reads open items is a component. Something that prepares a payment run is an actor. If your security review has only worked the LLM list, it has covered the model and not the thing that acts — which is where the placement decision and the authorization union live.

Which of these a finance deployment meets first

This half is my reading, not OWASP's. Ranked by what I would expect to actually bite in an SAP or treasury landscape, rather than by the list's own order.

LLM03 Excessive Agency — first, by a distance. In a finance landscape "excessive agency" is not an abstraction; it is a credential. It is the composite that lets one non-human identity create a vendor and release a payment to it, and it does not appear in the access review because technical users are excluded from the human one. The list's own movement agrees: this climbed to third because agentic deployments are where the damage lands. The mitigation is the oldest one there is — narrow the operation list, and do not connect the agent to the ERP directly.

LLM02 Sensitive Information Disclosure — second, and it arrives through retrieval scope. Enterprise content permissions were built assuming a person has to know where to look and has limited hours. Point retrieval at a share and neither limit holds. The exposure is usually not new; it is an old over-broad permission that nobody could exploit at scale until now.

LLM07 Misinformation — third, and under-rated exactly as the incident data says. A plausible wrong figure in a cash position or a reconciliation is not caught by a security control. It is caught by reconciliation, by an exception queue somebody actually works, and by output contracts that fail loudly rather than plausibly.

LLM04 Supply Chain — fourth, and it is the one your existing process half-covers. Vendor risk management already exists in every regulated finance function. What it does not yet cover is the model, the training data and the agent platform as supply-chain components, which is the gap GOVERN 6 of the NIST framework names in almost the same words.

LLM06 Unbounded Consumption — fifth, and it is the one that surprises people. The characteristic agent incident is not one clever action; it is the same wrong action four thousand times before anyone looked. In a finance context that is a duplicated instruction, not just a cloud bill, and the mitigation is a rate limit plus idempotency on every write.

LLM10 Improper Output Handling — last on the list, and I would not treat it as last in practice. It fell from fifth to tenth, but it now spans insecure code generated at scale, and the finance-specific version is narrower and sharper: a model output that reaches a system of record without passing a deterministic check. That is the entire argument for a control layer that is not a model.

What I would decide

Cite the codes with their release year, and re-check any control matrix written against the 2025 list — LLM08 in particular now means something else. Work LLM03 first regardless of its rank, because in a finance landscape excessive agency is a credential and the credential is the blast radius. Take the misinformation finding seriously: the incident record says the field under-rates it, and the finance version of "misinformation" is a wrong number that somebody acts on. And if what you are deploying can call a tool, pair this list with the Agentic one, because the project itself says neither covers that ground alone.

The framing the project leads open with is the same one this site has argued from the start, which is worth saying plainly rather than pretending at independence: build the system around the model so that when the model is fooled — and it will be — nothing important breaks.

See also security boundaries for enterprise AI agents and the NIST AI RMF functions and categories.