Since February 1, DryRun's classifier has labeled 202,700 security findings across customer codebases. 24,514 of them, roughly 12%, fall into AI-specific risk categories: prompt injection, excessive privileges, LLM tool misuse, resource exhaustion, intent redirection, and LLM agent communication.
That number matters for a simple reason. AI-generated and AI-integrated code is no longer a hypothetical risk category teams plan for someday. It is already 1 in 8 findings in production code review data, and the shape of that risk is not evenly distributed.
We built our own fine-tuned classifier because we needed consistent, stable labels across a 54-class taxonomy to make sense of what our analyzers were finding at scale. Once you have consistent labels, you can finally ask the question every AppSec team wants answered: what does AI risk actually look like in real repositories, not in a vendor's threat model slide.
Here is what six months of labeled data shows.
The AI risk breakdown
Two categories, prompt injection and excessive privileges, account for 91% of every AI-related finding we label. Everything else in the taxonomy, four more categories built specifically to catch AI and agentic risk, adds up to under 9% combined.
That is not a balanced distribution. It is a signal about where the actual attack surface is concentrated right now.
Prompt injection is the largest single AI risk category we track
At 12,194 findings, prompt injection is not just the top AI-specific label, it is roughly 6% of every security finding our platform produces across all categories, AI-related or not. For a label that did not meaningfully exist in most SAST taxonomies three years ago, that is a fast climb to the top of the board.
The volume tracks with what we would expect from adoption patterns. Prompt injection shows up wherever untrusted input (e.g., user text, scraped content, retrieved documents, third-party API responses) flows into a prompt that an LLM treats as instructions rather than data. As more services wire LLM calls directly into request handling, that boundary gets crossed constantly, often without the developer treating it as a trust boundary at all.
Most of what we see is not exotic. It is the same pattern repeated: a prompt template concatenates system instructions with unsanitized user or external input, and there is no structural separation between what the model should trust and what it should treat as untrusted content. Traditional SAST tools built on regex and syntax patterns largely miss this, because the vulnerability is not in the syntax. It is in the data flow and the trust relationship between the input source and the prompt construction, which is exactly the kind of context-dependent issue our Contextual Security Analysis approach was built to catch.
Excessive privileges is close behind, and it is an agent problem
At 10,200 findings, excessive privileges is the second-largest AI risk category and the one we expect to keep growing as agentic workflows spread. This label captures LLM agents operations, tool-calling frameworks, and orchestration code that grants a model or its tool integrations more capability than the task requires: broad filesystem access when read-only would do, unscoped API tokens handed to an agent that only needs one endpoint, database credentials with write access for a task that only reads. We know where that leads.
This is a classic example of failing least-privilege design principles, except now the entity you are scoping access for is a language model making autonomous decisions about which tools to call and when. The failure mode is not new; the blast radius is different when a compromised or misled agent with excessive privileges does not need a human in the loop to act on that access.
Combined, prompt injection and excessive privileges point to the same underlying story: the two biggest AI risks in code today are not exotic model-level attacks. They are input handling and access control, the same two problems AppSec has worked on for two decades, now showing up in a new execution context with a new set of blind spots for tools that were not built to look for them.
The long tail: tool misuse, resource exhaustion, and the rare but serious findings
LLM tool misuse (1,276 findings) and resource exhaustion (822 findings) sit well below the top two categories but are far from noise. Tool misuse covers cases where an agent's function-calling surface can be manipulated into invoking tools in unintended sequences or with unintended parameters, effectively using the agent's own capabilities against the application. Resource exhaustion covers unbounded loops, unconstrained recursive agent calls, and missing limits on token consumption or tool invocation counts,. These are the kind of issues that create a cost or availability incident rather than a data breach.
Intent redirection (19 findings) and LLM agent communication (3 findings) are the rarest labels in the set. Low volume here is not evidence that these risks do not matter. Ihese patterns require more specific architectural conditions to appear (multi-agent systems, agent-to-agent handoffs, complex planning loops), and those architectures are still a smaller share of what is in production today. As multi-agent systems become more common, we expect these numbers to move, and having a stable classifier in place means we will be able to actually measure that shift as it happens.
Why pattern-based scanners miss most of this
Prompt injection and excessive privileges are both context problems, not syntax problems. Whether a piece of user input reaches a prompt unsanitized, and whether an agent's credentials exceed what its task requires, depends on how data flows across files, how routes and middleware are constructed, and what the surrounding application actually does. None of that is visible from a single line of code in isolation, which is exactly why regex and signature-based tools struggle here.
DryRun's platform is built around a hybrid architecture for this reason: deterministic systems establish application boundaries, data flows, and execution context first, then specialized semantic analyzers reason within that narrowed, evidence-backed scope. Our High Signal Analyzers narrow each candidate finding through applicability and reachability checks before verification, and our General Security Analyzer runs bounded, isolated investigations across categories like authorization and injection rather than asking a single model to review a pull request unconstrained. That structure is also why authorization and privilege findings, the second-largest category in this data set, are a named focus of our patent portfolio, including our patent application for context-aware authorization verification across API endpoints.
his data is only possible with a consistent classifier
None of these numbers mean anything if the labels underneath them are inconsistent. That was the entire reason we moved off frontier model prompting for classification in the first place: asking a large model to sort findings into 54 categories produced different labels for the same finding depending on when you asked it. A trend analysis built on a classifier that disagrees with itself run to run is not a trend analysis, it is noise dressed up as data.
The fine-tuned classifier we run in production now holds those labels stable, which is the only reason we can say with confidence that prompt injection findings outnumber excessive privileges findings by roughly 2,000, rather than that number being an artifact of which day we happened to sample. It also scores above 0.95 F1 on excessive privileges and resource exhaustion specifically, two of the six categories in this data set, so the counts above reflect high-confidence labels, not a model guessing on hard cases.
What this means if you are shipping AI features
A few things fall out of this data directly.
If you are integrating LLM calls into request handling, treat every external input reaching a prompt as an untrusted input, the same way you would treat user input reaching a SQL query. Prompt injection is not a future risk category to plan for. It is already the single largest AI finding type we see.
If you are building or deploying agents with tool access, audit scope before auditing output. Excessive privileges findings are almost always fixable by scoping credentials and tool access to the specific task, not the general capability. This is a design-time decision, not a runtime patch and should always be part of your threat modelling.
If your AppSec tooling was built before agentic AI was common, check whether it has categories for these findings at all. Pattern-based scanners built for a pre-LLM threat model will not have a taxonomy entry for prompt injection or excessive agent privileges, which means they cannot find what they were never built to look for, regardless of how the underlying vulnerability actually behaves in your code.
See where AI risk shows up in your own code
These numbers come from real findings across real customer codebases, not a synthetic benchmark. If you want to know what your own prompt injection and excessive privilege exposure looks like, get a demo and we will show you what DryRun Security finds in your repositories.
.jpg)
