LLM security is the practice of securing the model, the data around it, and the actions it can take. In 2026 the actions became the hard part. This guide gives you a layer-by-layer map of where each risk is exploited and what can actually enforce anything at that layer.
Where each risk lives: a layer map for LLM and agent stacks
A list of ten risks tells you what can go wrong. It does not tell you where to put a control. Mapping each class to the layer it is exploited at is what turns a list into an architecture.
| Layer | Risk classes that land here | What actually reduces it |
|---|---|---|
| Input | Direct prompt injection, unbounded consumption | Per-user rate and spend caps, authenticated identity on every request |
| Retrieval | Indirect prompt injection, vector and embedding weaknesses, poisoned corpora, memory poisoning | Source trust tiers, entitlement-aware indexes, and a rule that untrusted retrieved content cannot reach a privileged tool call |
| Model and build pipeline | Supply chain, data and model poisoning | Model and dataset provenance, artifact scanning, pinned dependencies |
| Context assembly | Hidden context exposure | Classifying tool schemas as sensitive, and assembling the minimum context the task needs |
| Output | Improper output handling, misinformation, sensitive information disclosure | Output validation at the consuming system, not at the model |
| Tool and action | Excessive agency, tool misuse, identity and privilege abuse | Authorization per tool call against a downscoped token, evaluated before execution |
| Orchestration | Cascading failures, insecure inter-agent communication | Write-scope allowlists, spend caps, and human approval gates on irreversible action classes |
Last verified: September 12, 2026.
The layer view explains why no single product category covers the list. A gateway in front of the model never sees what a tool call does after the model decides to make one. Output scanning does nothing about an agent holding a long-lived token. Two of those rows sit outside the model entirely, which is why buying one control and calling the problem addressed does not work.
One row deserves more attention than it usually gets. The most common real finding in enterprise retrieval deployments is not an exotic embedding attack; it is that the index returns chunks the requesting user was never entitled to see, because document permissions were flattened at ingest time. If your RAG pipeline does not carry entitlements through to query time, every downstream control is operating on data the user should not have.
Authorising the action, which is where the risk went
Everyone agrees an agent should run with least privilege. Almost nobody says what that means mechanically, and the gap is where most real exposure sits.
The first decision is delegation. An agent either acts as its own service principal, holding a standing identity with its own permissions, or it acts on behalf of the user who invoked it. The first is simpler to build and is how most deployments start, which is also why an agent ends up with broader access than any individual person who uses it. The governing rule is that an agent's effective authority should never exceed the authority of the user who invoked it for that task. If a support agent can read any account because its service principal can, then a user who can read one account has just been handed the ability to read all of them by asking nicely.
The second decision is scope duration. A standing credential with a broad scope is a credential an injected instruction can spend. The alternative is exchanging the caller's context for a downscoped token at the moment of the call, so the token issued for a refund lookup carries the entitlement to look up that one account and nothing else, and it expires in minutes rather than months. Token exchange and on-behalf-of flows already exist in your identity provider for exactly this pattern; the work is wiring the agent runtime to use them per call instead of once at startup.
The third is what the authorization decision consumes. A meaningful per-call check evaluates the invoking user, the specific tool and its arguments, the sensitivity of what the call touches, and whether the action is reversible, then decides before execution rather than logging after it. That last distinction is the whole game. An audit trail that records a destructive call is evidence; a check that refuses it is a control.
The list moved, and the movement is the point
OWASP published a new Top 10 for LLM Applications in early August 2026, then announced it by press release on September 1. The list had been out for four weeks by the time most coverage began, which is part of why secondary write-ups disagree about it. They disagree about the contents too: at least one security news site published a 2026 ordering with Supply Chain at five and Hidden Context Exposure at nine, neither of which matches the canonical repository. Go to the repo rather than a summary.
The vendor pages ranking for this term cite the 2025 edition, cite OWASP with no year, or cite no framework at all. If you built a control map from one of those, you built it against a list OWASP has since reordered.
| ID | Risk | 2025 position |
|---|---|---|
| LLM01:2026 | Prompt Injection | 1 (unchanged) |
| LLM02:2026 | Sensitive Information Disclosure | 2 (unchanged) |
| LLM03:2026 | Excessive Agency | 6 |
| LLM04:2026 | Supply Chain | 3 |
| LLM05:2026 | Data and Model Poisoning | 4 |
| LLM06:2026 | Unbounded Consumption | 10 |
| LLM07:2026 | Misinformation | 9 |
| LLM08:2026 | Hidden Context Exposure | 7, as System Prompt Leakage |
| LLM09:2026 | Vector and Embedding Weaknesses | 8 |
| LLM10:2026 | Improper Output Handling | 5 |
Two movements carry the story. Excessive Agency climbed from sixth to third while Improper Output Handling fell from fifth to tenth, which is the ranking catching up with the layer map: the risk of a model producing bad text went down, and the risk of a model being allowed to act on it went up.
The methodology changed to make that possible. For the first time the ranking is incident-weighted. OWASP states that "the community vote carries three-quarters of the weight" and "the incident data covers the remaining quarter," drawn from 7,714 real incidents in public vulnerability databases and an AI-harm database, of which 6,639 carried enough detail to classify.
OWASP is also explicit about where its own list stops. Its 2026 preface draws the boundary: the LLM list owns the risk while the model is a component inside your application, and the moment that model becomes an actor, the risk moves to the OWASP Agentic Top 10. That companion list, published in December 2025, uses identifiers ASI01 through ASI10 for agent-specific risks such as tool misuse, memory poisoning and identity abuse, and LLM03:2026 now points directly at three of them. We annotated it separately in our OWASP Agentic Top 10 walkthrough. A third list covers the wiring between them: the OWASP MCP Top 10, still at beta, running from token mismanagement and secret exposure through context injection and over-sharing, with its next update due in October 2026.
System Prompt Leakage became Hidden Context Exposure, and tool schemas came with it
That rename is not a style edit. The 2025 entry was about your system prompt escaping. The 2026 entry covers "developer instructions, retrieved policy text, the schemas of tools and functions the application exposes to the model, and other rules, directives, and materials the application assembles into the model's context window."
Tool schemas are the addition that changes threat models, and it is worth sitting with why. To call a function, a model has to be told the function exists, what it is for, and what arguments it accepts. That description is written in natural language because the model consumes natural language. So the context window of any agentic application contains a plain-English catalogue of your internal capabilities: which systems it can reach, which operations are available on them, what each parameter means, and often enough what the valid values are. An attacker who extracts that catalogue has your internal API surface documented better than most of your own teams have it, without sending a single packet at your network, and they now know exactly which call to aim a subsequent injection at. Most teams treat the system prompt as the secret and the tool definitions as plumbing. OWASP now treats both as one exposure, and the practical implication is that the minimization argument applies to tools as much as to data: an agent that is handed forty tool definitions when the task needs three has leaked thirty-seven capabilities it never needed.
LLM02 moved in the same direction. It now names tool-call arguments, reasoning traces, retrieved chunks, logs, telemetry, embeddings, and inference side-channels such as timing and token length as disclosure surfaces. The things your observability stack captures by default are on that list.
When this stopped being research
Almost everything on the 2025 incident record was a responsible disclosure. EchoLeak in Microsoft 365 Copilot, CVE-2025-32711, was a zero-click indirect injection that exfiltrated data through a crafted email; SecurityWeek reported that Microsoft fixed it server-side and had seen no exploitation in the wild. ShadowLeak in ChatGPT Deep Research, ForcedLeak in Salesforce Agentforce, the two Cursor CVEs, the GitHub MCP cross-repo leak: researchers found them, vendors fixed them, and none has a public report of exploitation.
That changed. Four markers from the last twelve months, each verifiable:
An AI gateway CVE reached CISA's Known Exploited Vulnerabilities catalog. CVE-2026-42271 in LiteLLM, a command injection through two MCP preview endpoints that let any authenticated user run commands on the proxy host, was added to KEV on June 8, 2026 with a June 22 remediation due date. Inclusion in KEV means confirmed active exploitation, which is a different category of evidence from a research blog.
A maximum-severity flaw in an agent-building platform sat exploitable for seven months. CVE-2025-59528, a code-injection path through the CustomMCP node in Flowise, was published in September 2025 at CVSS 10.0 and fixed in version 3.0.6 that same month. VulnCheck observed the first confirmed in-the-wild exploitation in early April 2026, with somewhere between 12,000 and 15,000 instances still exposed. The advisory existed the whole time. Nobody applied it.
A package compromise in the AI stack reached customer data. Malicious versions of LiteLLM went live on PyPI on March 24, 2026; the vendor's advisory puts the exposure window at roughly forty minutes. LiteLLM's postmortem says the team believes the compromise "originated from the Trivy dependency used in our CI/CD security scanning workflow," and Datadog Security Labs independently traced that Trivy compromise to March 19. The security tooling was the entry point. Mercor later confirmed it was hit by "a supply chain attack involving LiteLLM" affecting a subset of its experts, and investigated with Mandiant.
An AI-orchestrated campaign got its own ATT&CK entry. Anthropic disclosed in November 2025 that it had disrupted an espionage operation in which the model performed most of the work across roughly thirty targets. The framing drew scepticism, and the share of work attributed to the model is the company's own assessment. What is not in dispute is that MITRE now tracks it as Campaign C0062, alongside every other catalogued intrusion set your detection engineering references.
OWASP's own Q1 2026 exploit round-up counted eight incidents in the first fourteen weeks of the year. Four were exploited in the wild. One had a CVE.
Why your vulnerability pipeline misses most of this
That last ratio is the operationally important number. Most of those incidents were not code defects at all. They were excessive permissions, unsafe defaults, injection through a legitimate feature, and supply chain compromise. None of those produces an advisory your scanner ingests, so none of them arrives through the channel your vulnerability management programme is built around.
Severity is unreliable too, in a way that is easy to check yourself. Microsoft scored EchoLeak 9.3; NIST scored the same vulnerability 7.5. For CVE-2026-54316 in Claude Code, NIST published 9.1 under CVSS 3.1 while the CNA-published CVSS 4.0 score is 6.0. If your process routes on severity, the same flaw is either a drop-everything or a backlog item depending on which feed reaches you first.
The cost side is now measurable. IBM's Cost of a Data Breach 2026, conducted with Ponemon across 602 breached organizations, found that one in four malicious breaches were AI-enabled, a 56% increase year over year, and that those breaches cost an average of $6 million against a global average of $4.99 million. The two leading vectors were compromised APIs, applications or plug-ins at 27%, and cloud misconfigurations affecting AI workloads at 27%. Both of those are configuration and permission findings, not vulnerabilities. You find them by inventory and access review, not by waiting for a CVE.
What the standards say, and when each one bites
| Framework | Status, September 2026 | When it bites |
|---|---|---|
| OWASP Top 10 for LLM Applications 2026 and Top 10 for Agentic Applications | Both current | Immediately, as your risk vocabulary; the split above decides which applies |
| MITRE ATLAS v2026.08, the technique matrix for attacks on AI systems | Released September 1, 2026: 16 tactics, 114 techniques, 83 sub-techniques, 39 mitigations, 72 case studies | When you map detections; several vendor pages still quote counts from late 2025 |
| NIST AI RMF 1.0 and the Generative AI Profile | Current. NIST says the framework "is being revised," with no draft published | Now, for governance structure. There is no AI RMF 2.0 to wait for |
| NIST IR 8596, the Cyber AI Profile | Preliminary draft, December 2025 | Not yet. Worth reading to see where CSF 2.0 mapping is heading |
| CISA and partners on agentic AI adoption; NSA information sheet on MCP | Published spring 2026 | Now, as procurement and architecture guidance |
| EU AI Act GPAI obligations | Applied since August 2, 2025; Commission enforcement powers from August 2, 2026 | Now, if you build on general-purpose models |
| ISO/IEC 42001:2023 | Current; the AI management-system standard to certify against | When a customer asks for certification |
| ISO/IEC 27090, AI-specific security | At final draft stage, not published | Not yet |
One deadline is widely misreported. The EU's Digital Omnibus, the 2026 package that reopened parts of the AI Act, deferred the high-risk obligations to December 2027 and August 2028. It left the general-purpose AI articles untouched. If you build on a general-purpose model, that deferral did not move your date.
One item is new enough to be missing from most guides: an Agent Control Standard was donated to OWASP's GenAI Security Project on September 1, 2026, covering declarative hooks, policy enforcement points and observability across agent frameworks, plus an agent bill of materials, meaning a machine-readable inventory of an agent's models, tools and data sources. It is early, and it is the first serious attempt at a vendor-neutral interface for the layer the 2026 list just promoted to third place.
Testing, and a reality check on the tools
Any tooling list is worth checking for maintenance before adoption. As of September 2026:
- garak (NVIDIA) shipped v0.17.0 on September 9, 2026, adding EU AI Act mapping tags.
- promptfoo shipped 0.123.0 on September 10, 2026, including MCP tool calls in response metadata.
- PyRIT (Microsoft) moved repositories. The Azure organization's copy is archived; active development is under microsoft/PyRIT, latest v1.1.0 on September 4, 2026. If your pipeline pins the old path, it is pinned to an archive.
- DeepEval shipped v4.2.0 on August 24, 2026. Giskard restructured into a monorepo.
- LLM Guard was archived in July 2026. It still appears in recommendation lists across the industry. Do not adopt it as maintained software.
On benchmarks, treat published attack-success rates with care. AgentDojo, a widely cited agent-security benchmark, defines 97 realistic tasks and 629 security test cases, and its own abstract reports that models "fail at many tasks (even in the absence of attacks)" while existing injection attacks "break some security properties but not all." The scores usually quoted from it were measured against 2024-era models. Its design is useful for building your own harness; its numbers are not a current statement about your stack.
The market consolidated while you were evaluating it
If your shortlist is a year old, some of it no longer exists independently. Between July 2025 and the end of that September: Palo Alto Networks completed its acquisition of Protect AI, SentinelOne agreed to acquire Prompt Security, Cato Networks acquired Aim Security, Check Point agreed to acquire Lakera, CrowdStrike agreed to acquire Pangea, and F5 completed its acquisition of CalypsoAI. Six AI security companies spoken for in about three months. Most deal values were not disclosed in the releases, so treat the figures in trade press as reported rather than confirmed.
We are an independent vendor and you should read the previous paragraph knowing that. The practical point stands on its own: AI security controls are being folded into platforms you already run, and the roadmap for a tool you bought standalone may now belong to an acquirer with different priorities. It is a reasonable question at renewal either way.
What to do this quarter
Inventory first, and include what nobody procured. Models embedded in SaaS you already pay for, assistants your engineers enabled in an IDE, MCP servers someone added to a config file, agents running under a service account created for something else. You cannot apply a layer map to systems you have not enumerated. Our MCP field guide covers enumeration at the tool layer, and the shadow AI hub covers the workforce side.
Then work the map downward rather than the risk list in order. For each system, ask what it retrieves, what it can call, whose identity it uses, and what happens if it is wrong. OWASP names three root causes for excessive agency: excessive functionality, excessive permissions and excessive autonomy. The middle one is answerable from an access review this month.
Then decide what you log, because the recommendation is easy and the specification is not. A tool-call record that supports reconstruction needs the invoking user, the agent identity, the tool and its arguments, what the authorization decision was and why, what came back, and the correlation ID that ties the whole chain together. If your logs cannot answer who initiated an action, what data it touched, and why it was permitted, you have telemetry rather than an audit trail. Treat prompt injection as an input-validation problem you cannot fully solve, and make sure the record survives it.
Inline inspection of what agents do at runtime is the control spanning the bottom rows of the map. AI Agent Security is our implementation, inspecting each tool call and enforcing policy before the action executes.
The uncomfortable finding in all of this is that the incidents which actually caused harm in 2026 were not defects anyone could have scanned for. They were decisions about what an agent was allowed to reach, made once at build time and never revisited. That is a review you have to schedule, because nothing will generate a ticket to remind you.
Questions teams ask about LLM security
Is LLM security different from application security?
It extends it. Improper output handling produces the same XSS, SSRF and RCE outcomes your AppSec programme already covers, and the fix is unchanged: validate at the consuming system. What is new is that instructions and data arrive through the same channel, so there is no parser boundary to enforce, and that the system can take actions on its own. Those two facts are what the tool and orchestration rows of the map exist for.
Can prompt injection be solved?
Not filtered away, no. Vendors have said so directly. Responding to a prompt-injection report in October 2025, Anthropic noted that its Claude Code Security Review GitHub Action "is not designed to be hardened against prompt injection," and GitHub closed the equivalent report against its Copilot agent as a known architectural limitation. Both responses are documented in researcher Aonan Guan's April 2026 disclosure. The defensible posture is to assume injection succeeds and constrain what it can reach: authority bounded by the invoking user, authorization per tool call, and human approval on irreversible actions.
Which list applies to us, the LLM Top 10 or the Agentic Top 10?
Both, usually in the same product. OWASP's rule is that the LLM list owns the risk while the model is a component inside your application, and the Agentic list takes over once it becomes an actor that calls tools.
Do we need an AI gateway, a firewall, or a platform?
Those names describe placement more than capability. A gateway sits between your application and the model, and for the input and output rows of the map it is the right answer: centralized rate limiting, cost control, request logging and response inspection all belong there, and putting them anywhere else duplicates work. What a gateway cannot do is see what a tool call does after the model decides to make one, because that traffic does not pass through it. Ask a vendor which rows they enforce and which they do not, and treat a straight answer about the gaps as a better signal than a datasheet claiming all of them.
Standards, incident and tool details in this guide were verified against primary and named secondary sources on September 12, 2026. This area moves quickly: OWASP, MITRE ATLAS and the open-source testing tools all shipped releases within the last five weeks. Check current versions before relying on any specific number here.