OWASP Top 10 for Agentic Applications, in Plain Language
For four days you have been finding attack chains by structure. The lethal trifecta checklist gives you the shape. The loop tells you where each stage sits. The protocol tells you which fields to touch. What you do not have yet is a shared vocabulary, the standard names that reports, defenders, and other researchers use for the same things you have been finding.
That vocabulary is the OWASP work on agentic applications. In December 2025 OWASP published a Top 10 aimed specifically at agentic systems, and it now sits alongside the older LLM Top 10 as a reference for defenders. Today we walk it in plain language, and more importantly, we map each category back to the loop and the trifecta so it is not just a list you memorize but a set of labels you can attach to real chains.
One honest caveat before we start. The agentic security space is young and the frameworks are still moving. Category names and numbering have shifted between drafts and may shift again. Treat the names below as the concepts to understand, not as fixed identifiers to quote in an exam. Always pull the current version from the OWASP site before you cite a specific category code in a report. The concepts are stable. The labels are not, yet.
Why a separate Top 10 exists
The original OWASP LLM Top 10 was about models that produce text. Jailbreaks, training data leakage, insecure output handling. All still relevant. But an agent is not just a model, it is a model with tools, memory, autonomy, and often other agents. That adds failure modes that simply do not exist for a chat completion.
An agent can be tricked into taking an action, not just saying something. It can accumulate poisoned memory across sessions. It can be handed excessive permissions and then talked into using them. It can be one of several agents where the compromise of one cascades. None of that fits neatly in the LLM Top 10, which is why a dedicated agentic list was needed.
If Day 1 through 4 taught you to think in trifectas and loops, this list is what happens when a standards body does the same exercise and writes down the recurring patterns.
The categories, walked
I will group the ten into four themes, because that maps better to how you actually attack than a flat numbered list does. For each, the plain meaning, where it lives on the loop, and a concrete example you have already met this week.
Theme 1: The agent is told to do the wrong thing
Agent instruction manipulation. The headline category, and the one everything else orbits. An attacker gets instructions into the context window through content the agent reads, and the agent follows them. This is indirect prompt injection under a formal name. On the loop it lives at ingest, stage 5. It is condition B feeding the whole chain in the trifecta.
You have already seen the canonical case: the Supabase class incident, where an attacker embedded a malicious instruction inside a support ticket message and the agent acting through MCP followed it. If you tag one thing from this list, tag this, because it is the entry point for most of the others.
Tool and capability misuse. Once the agent is taking instructions from the wrong place, it uses its legitimate tools for the attacker’s ends. The tool is not vulnerable in the classic sense. It is being used exactly as designed, for a purpose the operator never intended. This is the select and execute stages, 3 and 4. It is condition A being reached and condition C being fired.
The GitHub MCP case fits here: a booby trapped public issue drove the agent into private repos and back out through a pull request, using tools that all worked perfectly.
Theme 2: The agent was given too much
Excessive agency and permissions. The agent can do far more than the task requires. Broad scoped tokens, write access where read would do, admin capabilities left enabled. This is the precondition that turns a successful injection from embarrassing into catastrophic. It is the confused deputy problem from Day 2, where the agent’s effective permissions are the union of everything its token can reach, regardless of who asked.
This category is where the defender’s cheapest wins live, and therefore where your reports have the most impact. An injection that can only read public data is a curiosity. The same injection against an over permissioned agent is a breach.
Identity and privilege issues. Who is the agent, really, when it acts? Most deployments collapse many users onto one service identity. That breaks every downstream audit and authorization decision. On the trifecta this amplifies condition A, because the valuable thing the agent can reach is now everything any user could reach, not just the current one.
Theme 3: The agent remembers and reasons on poisoned inputs
Memory and context poisoning. Agents that persist memory across sessions can be seeded with malicious content once and triggered later. The injection and the payoff are separated in time, which makes it stealthy and hard to trace. On the loop this is the assemble stage, 1, because poisoned memory is loaded into context before the user even speaks. We spend Day 20 on this.
Knowledge base and RAG poisoning. Same idea, different store. If the agent retrieves from a vector database or document set that an attacker can write to, the attacker plants content that gets pulled into context as trusted reference material. Also assemble stage. Also condition B, but a sneaky version, because the untrusted content arrives dressed as the organization’s own knowledge.
Theme 4: The system around the agent fails
Supply chain and dependency risk. The agent, its framework, its tools, and its MCP servers all come from somewhere, and any of them can be compromised before the agent even runs. You have two vivid examples already: postmark-mcp, which shipped fifteen clean versions before adding a single line of exfiltration code, the first confirmed malicious MCP server in the wild, and the LiteLLM backdoor that sat on PyPI for three hours and reached nearly 47,000 downloads while acting as the model gateway for CrewAI, DSPy, Microsoft GraphRAG and others.
Insecure tool and server implementation. The MCP servers themselves are ordinary software with ordinary bugs, and the scanning data says the bugs are common: command injection in 43 percent of tested servers, path traversal prone file operations in 82 percent of 2,614 implementations, SSRF in 36.7 percent of over 7,000 servers, and a remote code execution flaw rated 9.6 in core MCP infrastructure, CVE-2025-6514. This is the classic appsec you already know, now sitting under an agent that will happily feed it attacker chosen arguments.
Insufficient monitoring and traceability. When something goes wrong, can anyone tell what the agent did and why? Most deployments cannot reconstruct the chain, because the interesting actions happened inside a long autonomous run that no human watched. This is the decide stage compounding across iterations, and it is why the defenses that work are architectural, since you cannot rely on catching the event after the fact.
Cascading multi agent failures. When agents call other agents, a compromise or a bad output propagates. One poisoned agent becomes many. This is the newest and least mapped category, and it is where a lot of the research over the next year will land as multi agent systems ship.
The one page map
Here is the whole thing collapsed so you can pin it next to your trifecta checklist.
| Theme | Category (concept) | Loop stage | Trifecta tie |
|---|
| Wrong instruction | Instruction manipulation | Ingest | B, entry |
| Wrong instruction | Tool and capability misuse | Select, Execute | A reached, C fired |
| Too much power | Excessive agency and permissions | Execute | A amplified |
| Too much power | Identity and privilege issues | Execute | A amplified |
| Poisoned reasoning | Memory and context poisoning | Assemble | B, delayed |
| Poisoned reasoning | Knowledge base and RAG poisoning | Assemble | B, disguised |
| System failure | Supply chain and dependency risk | Assemble | pre trifecta |
| System failure | Insecure tool and server implementation | Execute | A, classic bugs |
| System failure | Insufficient monitoring and traceability | Decide | detection gap |
| System failure | Cascading multi agent failures | whole loop | propagation |
Notice what the map shows. Every category lands on a loop stage you already understand, and most tie to a trifecta condition you already check. The OWASP list is not new material. It is names for the structure you have been finding since Day 1.
How to actually use this
Three practical uses, in order of how often you will reach for them.
In reports. When you write up a finding, lead with the concrete chain, then attach the category name so the reader can slot it into their existing risk register. Defenders triage by framework. A finding tagged with a recognized category gets prioritized. An untagged one gets questioned. Always confirm the current category code on the OWASP site first, given the naming is still moving.
In coverage. When you test, walk the ten categories as a completeness check after you have run the trifecta checklist. The checklist finds the obvious chain. The category walk catches the ones you did not think to look for, especially memory poisoning and supply chain, which the trifecta alone does not surface.
In conversation. When you talk to a client or a team, these names are the shared language. Saying excessive agency lands where saying the token is too broad does not, because the former is in their framework and the latter sounds like your opinion.
Homework for Day 5
Take the two filled trifecta checklists from Day 4.
- For each attack chain you wrote, attach the OWASP category name that best fits the entry point.
- Then attach a category to the target and to the exit. Most chains touch three categories, not one.
- Look at the categories you did not use. For each unused one, ask whether your target actually lacks that surface or whether you simply did not look. Memory poisoning and RAG poisoning are the usual blind spots.
- Pull up the current OWASP agentic Top 10 from the official site and check your category names against the live version, since the labels move.
You now have chains, checklists, and standard names for all of it. Week one is almost done.
Day 6 is the capstone of the theory week: mapping the complete attack surface of one real, named agent deployment end to end, so week two can start breaking things with a full target in view.
