OWASP LLM Top 10 vs Agentic Top 10 vs ACS: Which One Applies to You

OWASP's GenAI Security Project now publishes three things a security team could reasonably mistake for each other: a Top 10 for LLM applications, a Top 10 for agentic applications, and a control standard. They answer different questions, two of them are risk lists rather than control frameworks, and one of them is still pre-1.0 and should not be built against yet.

This is the short version of which to pick up and when.

The boundary OWASP itself draws

The useful thing is that OWASP answered this directly in the 2026 LLM document rather than leaving it to readers:

"This list owns the risk when the model is a component inside your application. The moment that model becomes an actor, with tools it can call, memory it carries between sessions, and consequences it sets in motion downstream, the risk moves to the OWASP Agentic Top 10. Many of the incidents we read sit right on that boundary. Read an entry here for the model-as-component failure. When your model starts acting on its own, pair it with the Agentic list, because neither one covers that ground alone."

Three tests come out of that, and you can apply them in about a minute. Does the model call tools. Does it carry memory between sessions. Does its output set something in motion downstream without a person in between. Any yes puts you at least partly on the agentic side.

Note the last sentence of the quote. OWASP does not say pick one. For most enterprise deployments the honest answer is both, and the question is really which one you read first.

The LLM Top 10, 2026 edition

Published August 2026 and formally announced on 1 September. The entries:

One small accuracy point that trips up citations: LLM04 is Supply Chain, not Supply Chain Vulnerabilities.

The methodology changed this edition, and it is the more interesting story. Earlier lists were built on practitioner judgment alone. This one tested that vote against a corpus of 7,714 real incidents, of which 6,639 carried enough detail to classify. The community vote still carries three-quarters of the weight and the incident data the remaining quarter, which OWASP explains as a deliberate choice so that one noisy year of data cannot rewrite a consensus product.

Worth noting when people quote the figure: 6,639 is the classifiable subset, not the corpus. The corpus is 7,714. We go deeper on what moved and why in the layer-by-layer control map for LLM security.

The Agentic Top 10

A separate document, announced in December 2025, using ASI identifiers rather than LLM ones: Agent Goal Hijack, Tool Misuse and Exploitation, Identity and Privilege Abuse, Agentic Supply Chain, Unexpected Code Execution, Memory and Context Poisoning, Insecure Inter-Agent Communications, Cascading Agent Failures, Human-Agent Trust Exploitation, and Rogue Agents.

Read the two lists side by side and the overlap is obvious. Prompt Injection and Agent Goal Hijack describe related failures. Excessive Agency on the LLM list sits at number three precisely because the boundary is porous, and the LLM document's Appendix A maps every one of its entries to agentic entries for that reason.

So the porousness is acknowledged by the authors rather than being a flaw you have discovered. Our annotated read of the agentic entries, with attack patterns and controls per entry, is in ASI01 through ASI10 for enterprises.

The Agent Control Standard, and why not to build on it yet

This is the newest of the three and the one most likely to cause a wasted quarter.

The Agent Control Standard is an OWASP GenAI Security Project deliverable that debuted alongside the 2026 LLM list. It is not a risk list. It describes an instrumentation model: lifecycle hooks around agent actions, dispositions for what a control decides, and conformance profiles. Conceptually it is the thing people ask for when they say a risk list does not tell them what to implement.

The version story is the first thing to look at. The specification documents are headed v0.1.0, the repository's version file reads 0.1.2, and there are no published releases at all. The decision that sets which requirements are mandatory is still an open pull request, filed in June 2026 and updated in September, which the project's own contributing guide describes as the mandatory floor decision that gates everything behind it.

So the set of MUST requirements is itself unsettled. That is not a criticism, it is a version number doing its job, and the project is unusually direct about what it means.

Its conformance documentation states that nobody verifies a conformance claim in this release, that the profile fields are self-declaration on the wire, and that it ships no conformance test suite, no registry of conformant implementations, and no steward body to arbitrate a disputed claim. It goes further and explains what a claim would even mean:

"A permissive Guardian is a conformant but permissive deployment, not a violation."

Read that next to a vendor questionnaire. An item asking whether a supplier is ACS-Core conformant can be answered yes by a deployment that denies nothing, and no third party exists who could check.

The reference implementation carries the same candor. Its own documentation says the wire is not authenticated even though the core profile requires a signature on every envelope, and that the default failure posture is to proceed, so a component that crashes or hangs stops governing silently while the host carries on.

There is also nothing to map controls against. ACS has no numbered control identifiers, no control blocks and no control domains. It is a wire-format specification rather than a control catalog. The citable handles are hook method names, seven profile names and section numbers, and even the hook taxonomy is unsettled: the repository describes sixteen lifecycle hooks in one document and nineteen hook methods in another. A compliance matrix built on any of that would be rebuilt when the numbering arrives.

No OWASP-published mapping exists between ACS and the agentic list, NIST AI RMF, ISO 42001 or MITRE ATLAS, and ACS is absent from OWASP's own framework crosswalk. There is a single prose cross-reference to the Agentic Top 10 in the entire specification.

Independent commentary lands in the same place. The Cloud Security Alliance's research note in September 2026 recommended treating ACS as an architecture to plan around and pilot against rather than a control to deploy today, and even the team that originated it has publicly flagged the preview status.

Read it, pilot it, and let it shape how you instrument. Do not put it in a customer-facing compliance claim, and do not accept one from a vendor, because as of this release there is no one who could contradict them.

If what you actually need is agent controls a questionnaire can test against today, OWASP's Application Security Verification Standard is the better answer. It carries numbered, pass-or-fail requirements including chapters on agentic action and on MCP security, and those are already mapped to both the agentic and LLM entries.

Which one do you actually open?

The row most people get wrong is the fifth. Procurement questions and customer questionnaires need identifiers that will still mean the same thing in a year, which rules out ACS for now and makes the agentic list the right vocabulary, as we set out in agent procurement questions mapped to ASI entries.

What none of them give you

All three are risk and design artifacts. None of them is a control you can switch on, and none tells you whether the risk it describes is present in your environment right now.

That gap is the reason a list is a starting point rather than a program. A risk list tells you excessive agency is a problem. It does not tell you which of your agents holds a token scoped more broadly than its job requires. Turning any of these into something operational means binding each entry to a control you run and a signal you collect, which is the work behind the detection rules worth writing and, at the enforcement end, a policy that evaluates the action rather than describing it.

If you want the same agents read through a general-purpose control framework instead of an AI-specific one, the CIS Controls mapping is the other lens worth having.

The one-line answer

If your model only produces text that a person reads, use the LLM Top 10. If your model does anything, use the Agentic Top 10 and keep the LLM list beside it. If you are designing how to instrument agents, read the Agent Control Standard, and wait for a 1.0 before you build anything that depends on its numbering.