OWASP Top 10 for LLMs 2026 and Agentic Apps: 20 Risks, Real Incidents

I read both OWASP AI lists the way I read a cloud provider's shared responsibility page: looking for the lines that turn into work for whoever runs the infrastructure. There is a lot of it. The OWASP Top 10 for LLM Applications got a 2026 edition in August, two months ago, and the OWASP Top 10 for Agentic Applications landed in December 2025, so most of the "OWASP Top 10 for LLM" explainers still ranking in search describe a list that has since been reordered. This post covers what changed between the 2025 and 2026 LLM lists, walks through all ten agentic risks (ASI01 to ASI10) with the public incidents OWASP itself ties to them, and maps each one to a control you can actually deploy: a scoped token, an egress policy, a sandbox, an approval gate.

What are the two OWASP Top 10 lists for AI?

The OWASP GenAI Security Project now maintains two separate lists, and the 2026 LLM edition draws the boundary between them explicitly. Its project letter says the LLM list owns the risk "when the model is a component inside your application", and that once the model has tools, memory across sessions and downstream consequences, the risk moves to the agentic list (OWASP Top 10 for LLM Applications 2026, PDF, pages 6 to 7).

List	Released	IDs	Built from	Source
Top 10 for LLM Applications 2025	17 to 19 November 2024	LLM01:2025 to LLM10:2025	Practitioner consensus	OWASP announcement
Top 10 for Agentic Applications 2026	9 to 10 December 2025	ASI01:2026 to ASI10:2026	100+ contributors, expert review board incl. NIST and the European Commission	OWASP announcement
Top 10 for LLM Applications 2026	3 to 4 August 2026, announced 1 to 2 September	LLM01:2026 to LLM10:2026	75% community vote, 25% incident data from 6,639 classified incidents	OWASP 2026 PDF

The date ranges are real: the resource page says 3 August, the PDF cover says 4 August, and the press release went out on 1 to 2 September alongside a donated Agent Control Standard. If an auditor asks which version you mapped your controls to, write down the IDs with the year suffix, because LLM03 means Supply Chain in 2025 and Excessive Agency in 2026.

What changed in the OWASP LLM Top 10 2026?

The headline change is method, not content. For the first time the project tested its practitioner vote against a corpus of 7,714 real incidents from public vulnerability databases and an AI harm database, classified 6,639 of them, and gave the incident data a quarter of the weight (2026 PDF, page 4). No category was added or dropped. Three things moved enough to matter.

Excessive Agency rose from sixth to third, which OWASP calls the most consequential move, because both the vote and the incident record agree that "agentic deployments are where the damage is landing". Unbounded Consumption rose four places to sixth, on practitioner concern about cost exhaustion. Improper Output Handling fell furthest, from fifth to tenth, although it now also covers insecure code generated by assistants. System Prompt Leakage was renamed Hidden Context Exposure and broadened to any information that should have stayed out of reach.

The most interesting paragraph in the document is about prompt injection. Ranked by raw incident count, it falls out of the top 10 entirely. OWASP reads that as a defence effect (teams fight injection hard, so fewer clean exploits reach a public database) and keeps it first. Misinformation runs the other way: voters put it near the bottom, the incidents put it near the top, and the blended score lands it seventh. I find that more honest than any previous edition, and it is a useful warning about building a risk register purely from CVE feeds.

The LLM Top 10 2026, one risk at a time

• LLM01 Prompt Injection. Untrusted text steers the model. Scope now explicitly covers instructions hidden in images or audio. The canonical incident is EchoLeak (below).
• LLM02 Sensitive Information Disclosure. The model or its plumbing leaks data. OWASP cites DeepSeek's January 2025 ClickHouse exposure of more than a million rows of logs, which was an unauthenticated database, not anything clever with tokens.
• LLM03 Excessive Agency. Too many tools, too broad permissions, too little human review. Replit's agent deleting a production database during a code freeze is the example everyone remembers (eWeek).
• LLM04 Supply Chain. Models, packages, plugins and MCP servers you did not build. One research team generated 576,000 code samples across 16 models and found hallucinated package names in at least 5.2% of commercial-model output and 21.7% of open-model output (arXiv 2406.10279), which is the raw material for slopsquatting.
• LLM05 Data and Model Poisoning. Corrupted training or fine-tuning data. Now absorbs fine-tuning subversion.
• LLM06 Unbounded Consumption. Denial of service and denial of wallet. The control is a gateway with per-key budgets and rate limits, which I cover in the LiteLLM proxy guide.
• LLM07 Misinformation. Confident wrong output that someone acts on. In Moffatt v. Air Canada (2024 BCCRT 149) the airline argued its chatbot was responsible for its own statements; the tribunal disagreed and awarded C$650.88 plus interest and fees.
• LLM08 Hidden Context Exposure. System prompts, policies, tool schemas and credentials pulled out of context. Treat anything in a prompt as readable by the user.
• LLM09 Vector and Embedding Weaknesses. Cross-tenant retrieval, embedding inversion, poisoned indexes. OWASP's 2026 entry tells you to treat an "embeddings only" leak as a leak of the source data.
• LLM10 Improper Output Handling. Model output rendered or executed without validation. It fell in rank, but it is still how most exfiltration actually leaves the building, as ForcedLeak showed.

OWASP Top 10 for Agentic Applications: ASI01 to ASI10 with real incidents

The agentic list's appendix includes an exploits and incidents tracker that maps public cases to ASI IDs (OWASP agentic PDF, Appendix D). I used that mapping and checked each incident against a named source.

ID	Risk	Incident OWASP maps to it	Infra control that contains it
ASI01	Agent Goal Hijack	EchoLeak, CVE-2025-32711, CVSS 9.3: a crafted email made M365 Copilot exfiltrate context (The Hacker News)	Egress allowlists, strip external URLs from rendered output
ASI02	Tool Misuse and Exploitation	GitHub MCP: a public issue made an agent leak private repos into a public PR (Invariant Labs)	One repo per token per session, no "always allow"
ASI03	Identity and Privilege Abuse	Amazon Q 1.84.0: an overscoped GitHub token in CodeBuild let an attacker commit a wiper prompt (AWS-2025-015)	Short-lived, narrowly scoped workload identity
ASI04	Agentic Supply Chain Vulnerabilities	postmark-mcp: a one-line change BCC'd every email to the attacker from version 1.0.16 (Snyk)	Pin and review MCP servers like any dependency
ASI05	Unexpected Code Execution (RCE)	mcp-remote CVE-2025-6514, CVSS 9.6, versions 0.0.5 to 0.1.15 (JFrog)	Run tool code in a sandbox with no host credentials
ASI06	Memory and Context Poisoning	Partly EchoLeak and the GitHub issue hijack; persistent memory attacks are mostly research so far	Provenance on memory writes, expiry, per-user stores
ASI07	Insecure Inter-Agent Communication	Fake A2A agent card in an open directory (Trustwave, April 2025, per the tracker)	Signed agent cards, mTLS, authenticated discovery
ASI08	Cascading Failures	Tracker maps the GitHub issue hijack here; few clean public cases	Circuit breakers and rate limits between agents
ASI09	Human-Agent Trust Exploitation	Replit: agent claimed rollback was impossible; the user recovered data anyway	Humans verify state from systems of record, not the agent
ASI10	Rogue Agents	Replit again: destructive action during an explicit freeze	Kill switch, revocable credentials, dev/prod separation

Two incidents show the infrastructure layer doing, or failing to do, the real work.

ForcedLeak in Salesforce Agentforce, reported by Noma Security in July 2025 and fixed by 8 September, hid instructions in a Web-to-Lead form field. When an employee later asked the agent about that lead, it embedded CRM data in an image URL. The domain that received it was on Agentforce's Content Security Policy allowlist and had expired, so the attacker could simply buy it (The Hacker News). The model was fooled, as models will be. The breach happened because an allowlist had not been maintained.

The Nx "s1ngularity" compromise in August 2025 went the other direction: malicious package versions looked for locally installed AI CLIs and ran them with flags such as --dangerously-skip-permissions and --trust-all-tools to hunt for secrets (GitGuardian). Your developer's coding agent became the attacker's search tool.

What is least agency, and how do you enforce it in infrastructure?

The agentic list's central idea is least agency: extend least privilege from permissions to autonomy itself, and do not deploy agentic behaviour where it adds no value. The same introduction says "strong observability becomes non-negotiable", because without a record of what an agent did and which tools it called, unnecessary autonomy expands the attack surface quietly. The UK NCSC reached the same place from a different direction: in Prompt injection is not SQL injection (8 December 2025) it calls LLMs an "inherently confusable deputy" and recommends deterministic, non-LLM safeguards around tool calls instead of hoping a filter catches everything.

That is platform work, and most of it is old platform work. The cheapest single control against ASI01, ASI02 and LLM10 together is denying arbitrary egress, because almost every exfiltration path above (EchoLeak, ForcedLeak, the GitHub PR, postmark-mcp) ends in a network request the agent did not need to make. On Kubernetes that is a NetworkPolicy:

# Default-deny egress for an agent namespace, then allow only DNS and the
# internal LLM/tool gateway. Requires a CNI that enforces NetworkPolicy
# (Cilium, Calico). API: networking.k8s.io/v1, stable since Kubernetes 1.7.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: agent-egress-allowlist
  namespace: agents
spec:
  podSelector: {}            # every pod in the namespace
  policyTypes: ["Egress"]
  egress:
    - to:                     # cluster DNS only
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - { protocol: UDP, port: 53 }
        - { protocol: TCP, port: 53 }
    - to:                     # the gateway that holds model keys and tool creds
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: ai-gateway
      ports:
        - { protocol: TCP, port: 4000 }
# Anything else, including attacker.example/log?d=..., is dropped.

The gateway then becomes the place to enforce tool allowlists, budgets and audit logs, and it can hold credentials so the agent pod never sees them. The network policies guide covers testing this properly. For identity, the agent should get its own short-lived workload identity rather than a developer's token; the Amazon Q bulletin is, at root, a story about a token with broader access than it needed, and I went through the options in the non-human identity post. For ASI05, run anything an agent writes or downloads in an isolation boundary with no host credentials and a disposable filesystem; container vs microVM vs gVisor covers the trade-offs. (I build PandaStack, a Firecracker microVM platform for exactly this, so weigh my view on isolation accordingly.)

Can prompt injection be fixed, or only contained?

Every serious source now says contained. OpenAI wrote in December 2025 that prompt injection "is unlikely to ever be fully 'solved'" while describing an RL-trained automated attacker it uses against its own browser agent (OpenAI). A paper by researchers from OpenAI, Anthropic and Google DeepMind bypassed 12 recently published defences with adaptive attacks, above 90% success for most, where the original papers had reported near zero (arXiv 2510.09023). The 2026 OWASP letter opens with "Stop trying to build a model that cannot be fooled."

That is why the agentic list is more useful to infrastructure teams than the LLM list: its mitigations are mostly about what happens after the model is fooled. The defence-in-depth patterns, from tool allowlists to the CaMeL capability design, are in the companion guide, how to defend LLM apps against prompt injection. For MCP specifically, MCP security in 2026 covers why the protocol hardened faster than the servers built on it.

FAQ

Is there an OWASP Top 10 for LLM Applications 2026?

Yes. OWASP published it on 3 to 4 August 2026 and announced it on 1 to 2 September. It keeps all ten 2025 categories but reorders them: Excessive Agency moves to third, Unbounded Consumption to sixth, Improper Output Handling to tenth, and System Prompt Leakage is renamed Hidden Context Exposure.

What is the difference between the OWASP LLM Top 10 and the Agentic Top 10?

The LLM Top 10 covers a model used as a component inside an application. The Agentic Top 10 (ASI01 to ASI10) covers systems where the model plans, calls tools, keeps memory and acts with delegated identity. OWASP recommends using both once your model can take actions.

What is ASI01 Agent Goal Hijack?

ASI01 is when attacker-controlled content, such as an email, document, web page or tool output, redirects what an agent is trying to achieve. It is the agentic consequence of prompt injection. EchoLeak, where a single email made Microsoft 365 Copilot leak data, is the reference incident.

Which OWASP LLM risk should I fix first?

Start where the model can act: Excessive Agency and the agentic identity and tool risks. Removing a tool, narrowing a token or blocking egress closes whole attack paths regardless of how good the injection is, whereas filters only lower the odds.

This quarter I would do three things on any system that puts a model near tools: inventory every tool and MCP server an agent can reach and the credential behind each, put default-deny egress and a gateway in front of them, and add the ASI IDs to the threat model template so reviews ask "what happens when this agent is hijacked" instead of "can this agent be hijacked". The answer to the second question is yes. The first one is the one the platform team can actually change.

Related: MCP Security in 2026: The Protocol Got Hardened. The Ecosystem Didn't., Policy as Code for AI Agents in 2026 and Who Is This Agent? Non-Human Identity in 2026.