OWASP Top 10 for LLM Applications (2026): A Compliance Checklist for Finance Teams

The List Just Changed — and the Methodology Changed With It

OWASP's GenAI Security Project published its 2026 Top 10 for LLM Applications in September 2026, and the ranking moved for a reason worth paying attention to on its own: for the first time, it isn't pure community opinion. The 2026 edition blends practitioner voting (75% of the weight) with evidence pulled from a corpus of 7,714 real-world AI security incidents, of which 6,639 carried enough detail to classify (25% of the weight). That's the difference between "what security researchers think is scary" and "what's actually been going wrong in production" — and it moved the list.

The biggest mover: Excessive Agency climbed from #6 to #3 — the largest jump on the list, driven by agentic systems (tool-calling, multi-step planning, code execution) generating real incidents rather than theoretical ones. Unbounded Consumption moved from #10 to #6. Improper Output Handling fell the furthest, from #5 to #10. And System Prompt Leakage was renamed Hidden Context Exposure — broadened from just the system prompt to any non-user-facing content assembled into a model's context: retrieved policy documents, tool schemas, workflow rules.

The Full 2026 List, Mapped to What a Finance Team Actually Runs

Each entry below is the official OWASP risk, with the concrete shape it takes when the "application" is a credit memo assistant, a claims-triage model, or an internal research agent rather than a generic chatbot.

• 1. Prompt Injection — a 10-K filing, email, or support ticket the agent is asked to summarize contains hidden text instructing it to take a different action (exfiltrate data, misclassify a transaction). Indirect injection, not a user typing something malicious, is the higher-risk path in a finance workflow.
• 2. Sensitive Information Disclosure — account numbers, SSNs, or non-public financials entering a model's context (via a document, a tool call, or a prior turn) and resurfacing in an unrelated output, a log file, or a third-party model provider's retained data.
• 3. Excessive Agency — an agent with tool access broader than the task needs: one scoped to "draft a wire confirmation email" that also has write access to the system that initiates wires. The fix is scope, not better prompting.
• 4. Supply Chain — a compromised MCP server, a poisoned third-party "skill," or a malicious hook in a cloned repository. See our coding agent hooks security coverage for the specific CVEs this has already produced.
• 5. Data and Model Poisoning — a RAG knowledge base or fine-tuning dataset seeded with manipulated content that skews the model's output on a specific class of question, e.g. credit risk assessments for a particular segment.
• 6. Unbounded Consumption — an agent loop that keeps calling tools or re-prompting itself without a hard stop, running up API cost or denial-of-service load. The most boring risk on the list and the easiest to miss until a bill arrives.
• 7. Misinformation — a hallucinated figure in a draft credit memo or earnings summary that looks exactly as confident as a correct one, and gets forwarded before anyone checks the source document.
• 8. Hidden Context Exposure (renamed from System Prompt Leakage) — an attacker gets the model to reveal its system prompt, tool definitions, or retrieved internal policy text, exposing proprietary underwriting logic or compliance rules.
• 9. Vector and Embedding Weaknesses — embedding-inversion or retrieval-manipulation attacks against an internal document-search RAG pipeline, potentially reconstructing source text from embeddings alone.
• 10. Improper Output Handling — a model's output gets passed unescaped into a downstream system (a SQL query, a shell command, an HTML report) and becomes an injection vector in its own right, one step removed from the model itself.

• "Walk through our [credit underwriting assistant / claims-triage tool / research agent] against each of the 10 OWASP LLM risks above. For each one, tell me: (1) is this plausible in our actual workflow given the tools and data it touches, (2) what's our current mitigation if any, (3) which risk is our weakest point right now. Be specific about data flows, not generic."

A Practical Checklist, Not Just a List of Risks

Enterprise LLM security guidance converges on a short set of concrete controls, and they map cleanly onto the risks above:

• Scope tool access per task, not per agent. The drafting tool and the execution tool should not be the same credential. This is the direct fix for Excessive Agency (#3).
• Mask or redact before the model sees it, not after. RBAC and field-level data masking on anything entering a prompt or tool response — PII, account numbers, non-public financials — addresses Sensitive Information Disclosure (#2) at the source instead of trying to catch it in the output.
• Validate and escape every model output before it reaches a downstream system. Treat model output the same as any other untrusted input — this is Improper Output Handling (#10), and it's cheap to fix once you remember it's a risk at all.
• Put a hard ceiling on agent loops and API spend per session. A timeout and a call-count cap address Unbounded Consumption (#6) directly.
• Review every third-party MCP server, skill, or hook before trusting it. See our hooks catalog for a working example (a hook that specifically warns on the auto-approve settings pattern behind a real 2026 CVE) and our third-party vendor risk guide for the broader Supply Chain (#4) process.
• Log every tool call independently of the chat transcript. An audit trail that survives even if the session log doesn't — directly useful for Misinformation (#7) and Hidden Context Exposure (#8) investigations after the fact.

• "Draft an internal LLM security control checklist for our [compliance / model risk] team, structured around the OWASP Top 10 for LLM Applications (2026). For each of the 10 risks, give: the control we should have in place, how to verify it's actually implemented (not just documented), and who owns it — security engineering, model risk, or the business unit deploying the tool."

Why This Isn't Theoretical for Financial Institutions Specifically

Attackers are already using AI to accelerate attacks on financial institutions, not just researchers theorizing about it. In 2026, South Korea's president said AI likely played a role in a series of cyberattacks on domestic banks, where an attacker reportedly combined an open-source AI penetration-testing agent with a commercial coding assistant — exposing records belonging to at least 65,000 customers. That's the attacker side of the same agentic-AI trend that pushed Excessive Agency to #3 on the defender's list: the tools that make an internal agent more capable also make an attacker's tooling more capable.

On the framework side, NIST is actively building out agentic-specific guidance to sit alongside the existing AI RMF — a draft Agentic Profile white paper was released in March 2026, and a formal public-comment draft of the broader Generative AI Profile is expected in mid-2026. Neither is finalized, but both point the same direction as OWASP's reranking: agentic behavior, not just generative output, is where the governance gap currently is.

Where to Start

If you've already mapped your AI tools against SR 11-7, the EU AI Act, or NAIC's AI bulletin, this list isn't a replacement — it's the technical-control layer underneath those governance frameworks. Start with an inventory: every LLM-connected tool, what data it touches, and what it's authorized to do, scored against the 10 risks above. See our AI agent identity & permissioning guide for the concrete fix to Excessive Agency specifically, prompt injection defenses, secure MCP deployment, and Security Hub for the deeper dive on each adjacent risk area, and our hooks catalog for controls you can put in place today rather than just document.

Frequently Asked Questions

What is the OWASP Top 10 for LLM Applications 2026?

It's the OWASP GenAI Security Project's ranked list of the ten most significant security risks in LLM-based applications, published September 2026. For the first time, the ranking combines practitioner voting (75% weight) with evidence from a corpus of 7,714 real-world AI security incidents (25% weight), rather than community opinion alone. The list: Prompt Injection, Sensitive Information Disclosure, Excessive Agency, Supply Chain, Data and Model Poisoning, Unbounded Consumption, Misinformation, Hidden Context Exposure, Vector and Embedding Weaknesses, and Improper Output Handling.

What changed most in the 2026 update?

Excessive Agency made the biggest move, climbing from #6 to #3, reflecting a real shift: agentic systems that call tools, execute code, and chain multi-step actions have started causing production incidents, not just hypothetical ones. Unbounded Consumption moved from #10 to #6. Improper Output Handling fell the furthest, from #5 to #10. System Prompt Leakage was renamed Hidden Context Exposure and broadened to cover any non-user-facing content assembled into a model's context — retrieved policy text, tool schemas, and workflow rules, not just the system prompt itself.

Does this apply if we only use Claude through Claude.ai or the API, not building our own LLM?

Yes. Most of the ten risks are about how an LLM is used inside your workflow, not about training or hosting a model. Prompt Injection, Sensitive Information Disclosure, Excessive Agency, Hidden Context Exposure, and Improper Output Handling all apply directly to a team that only calls a hosted model through an API or a chat interface and connects it to internal tools, documents, or data.

How is this different from the OWASP Top 10 for Agentic Applications?

OWASP maintains both as related but distinct lists. The LLM Top 10 covers the model-interaction layer — injection, disclosure, output handling. The Agentic Applications list (and the newer Agent Control Standard introduced alongside the 2026 LLM Top 10) focuses specifically on autonomous multi-step behavior: planning, tool orchestration, and multi-agent coordination. A system with real agentic behavior should be checked against both.