Prompt Injection & Enterprise AI Security: Why Your CVE Dashboard Is Lying to the Board

Your CVE Dashboard Is Lying to Your Board

A CISO who checks the vulnerability scanner, sees a low count for prompt injection, and moves the budget line elsewhere is reading the wrong instrument. Prompt injection has held the #1 spot on the OWASP Top 10 for LLM Applications for three years running. When two of the people who run that list checked the expert ranking against a database of real-world incidents, prompt injection came back at #12.

That's not a typo, and it's not the incident data proving the experts wrong. It's the two signals looking at different things.

Two witnesses, one contradiction

The comparison comes from Kyriakos "Rock" Lambros and Steve Wilson — both leaders of the OWASP GenAI Security Project — published on arXiv on August 18 as an exploratory analysis, not the official OWASP release. They built a real evidence base: 7,714 documented LLM security incidents pulled from CVE records, GitHub Security Advisories, OSV, and the AIAAIC AI-harm database, with 6,639 of them labeled against a 20-entry risk taxonomy.

The statistical agreement between the 29-person expert vote and that incident record: a Cohen's kappa of 0.20, with a confidence interval that crosses zero. In plain terms — you cannot rule out that the two rankings agree by chance alone. As Lambros put it, you have two witnesses to the same event, and they're contradicting each other. Neither one is automatically the truth.

Why the scoreboard misses the actual danger

The reason isn't that prompt injection got safer. It's that the attack is structurally invisible to the tools built to catch it.

Prompt injection hides instructions inside content a model reads — a support ticket, a log entry, a document pulled back through retrieval. The agent then executes the action the attacker wanted, using credentials it already legitimately holds. Nothing in that chain is a product defect. There's no patch to ship, no CVE to file. A scanner has nothing to find, because the vulnerability was never in the code — it was in the trust boundary between instructions and content.

Wilson's framing is the one worth pinning to a wall in your risk committee: incident data is backward-looking. It tells you what got observed, classified, and reported. It doesn't tell you what's dangerous in the systems you're deploying this quarter.

Where this gets expensive fast

The gap runs in the other direction too — and the entries where it runs widest are the ones enterprises are funding least.

Misinformation sits at #13 in the expert vote and #2 in the incident record — the widest disagreement in the whole comparison. The authors don't call it an expert error; they note the incident corpus is heavy with deepfake and AI-generated disinformation cases that describe harm produced by AI rather than a vulnerability inside an LLM. Different failure mode, same taxonomy bucket.

Persistent memory poisoning (expert #4) and MCP tool interface exploitation (expert #7) are the two newest categories, and the incident record can't place either one — the confidence interval on both spans most of the taxonomy. That's not because they're rare. It's because they're new enough that reporting hasn't caught up. Real 2026 CVEs already exist for both: a KQL-injection flaw in the Azure Data Explorer MCP Server (CVSS 8.3) that lets a prompt-injected agent run arbitrary queries, and an unauthenticated MCP bridge in an agent harness (CVSS 10.0) that exposed API keys and let an attacker poison the learning store.

Lambros's line on this is the one to bring into a budget conversation: a count of zero incidents measures your blindness, not your safety. Nobody files an advisory for a procurement agent quietly told once that invoices under a threshold clear without a second signature — because nobody knows it happened. Every approval after that looks like the process working.

The BFSI angle

That procurement example isn't hypothetical for lending and credit operations — it's the exact shape of exposure that shows up in decisioning workflows once an agent starts remembering exceptions instead of just executing rules. It's also precisely why control boundaries need to be architectural, not promptable. A rule written into a system prompt is a suggestion to the model. It is not an enforceable control, and it will not hold up to an examiner, an auditor, or an attacker.

What actually helps, starting Monday

Stop treating the OWASP Top 10 as a spend queue. It's a coverage map built from 29 votes and an incident corpus its own authors call weak. Build your priority order from your own exposure — production reach, what a failure touches, and which controls you've actually tested against your live system, not a hypothetical one.

Put the authorization gate outside the model. An agent can propose a high-impact action — a DNS change, a payment override, a limit exception — but it should not hold the authority to execute it unsupervised. That's the control Wilson names first, and the tradeoff is explicit: you lose some autonomous improvisation in exchange for keeping a human or a hard-coded boundary between "the model suggested this" and "this happened."

Log what the system actually did, not just what it output. The prompt, the retrieved context, the tool calls, the arguments passed, and — critically — the model's confidence score. A model executing on a poisoned instruction doesn't behave erratically. It behaves certain. Most monitoring treats certainty as the sign of a healthy system, which is exactly backwards when the certainty itself is the symptom.

Fund agent memory and MCP tool boundaries on architecture, not advisory volume. These are the entries with the thinnest incident record and the highest severity CVEs already on file. Wiring in the boundary now, while these systems are still being built, is a rounding error. Retrofitting it in two years is a re-architecture.

The question for your next board meeting

If your current AI risk ranking rests on a 29-person practitioner vote and an incident record its own authors say disagrees with that vote at a near-certain rate — what, exactly, is deciding which controls get funded next year?

Sources: Lambros & Wilson, "Prompt Injection: Rank #1 or #12?" (arXiv, Aug 18, 2026); OWASP Top 10 for LLM Applications 2026 (published Aug 4, 2026); CrowdStrike 2026 Global Threat Report; Ivanti 2026 State of Cybersecurity.