OWASP Top 10 for Agentic Applications: What Changed From the LLM Top 10 and What to Do About It

Your coding agent sends emails, modifies production databases, and spawns sub-agents to handle tasks you never explicitly approved. This is not a chatbot anymore but an autonomous system with its own class of security risks, and the framework you used to secure single-model applications does not cover it.

Why the LLM Top 10 Isn’t Enough Anymore

The OWASP LLM Top 10 was designed for single-model, query-response applications where security risks live at the input and output boundary. The OWASP Top 10 for Agentic Applications (ASI01–ASI10) was designed for systems that take autonomous actions, use tools, and communicate with other agents. Security risks span goal manipulation, tool misuse, inter-agent trust, and persistent memory across extended task trajectories. It is a different threat model entirely. All ten ASI risks map to one or more entries in the LLM Top 10, but in every case the agentic execution scope makes the original risk much worse.

As Trent AI is an OWASP partner startup, we work closely with the OWASP community on agentic security frameworks. The full OWASP Top 10 for Agentic Applications is the canonical source for everything in this article.

The LLM Top 10 vs. Agentic Top 10: The Full Comparison

If you already know the OWASP LLM Top 10, the question is not “what are the new risks?” The question is: what changed, and why does it matter for agentic AI security? The comparison table below maps every LLM Top 10 entry to its ASI equivalent and shows exactly where the risk got worse.

Every ASI risk traces back to at least one LLM Top 10 entry. ASI04 is the cleanest one-to-one with LLM03, while ASI09 compounds four predecessors (LLM01, LLM05, LLM06, LLM09) into a single attack surface. ASI07 (Insecure Inter-Agent Communication), ASI08 (Cascading Failures), ASI09 (Human-Agent Trust Exploitation) are the entries where the lineage is loosest. They require multi-agent architecture, error-propagation paths, or weaponized human-in-the-loop dynamics that single-model deployments rarely produce. For a broader context on why autonomous action changes the threat model, see the guide to agentic AI security.

The Risks That Require Architectural Solutions

Three ASI risks require architectural solutions that input/output guardrail layers alone cannot address: ASI07, ASI08, and ASI09. You need changes at the orchestration, communication, and approval layers of your agent system.

ASI07 Insecure Inter-Agent Communication

ASI07 has LLM Top 10 ancestors (LLM02 Sensitive Information Disclosure, LLM06 Excessive Agency), but it only becomes a distinct risk class once you operate a multi-agent system. It covers vulnerabilities in the communication channels between AI agents: message forgery, replay attacks, and the propagation of goal hijacks across an agent network. An attacker who injects a single forged message into a multi-agent system can redirect the entire task trajectory of every downstream agent that processes it.

You need authentication at the inter-agent layer, not just output filtering. The three concrete mitigations are cryptographic identity per agent instance, signed inter-agent messages, and message schema validation. Runtime guardrails are necessary but not sufficient here: you need authenticated inter-agent channels.

ASI08 Cascading Failures

ASI08 compounds LLM01 (Prompt Injection), LLM04 (Data & Model Poisoning), and LLM06 (Excessive Agency) into a system-behavior failure mode. One failing agent triggers error-correction in others; those recovery attempts cause additional failures; the system amplifies rather than dampens the initial problem. If you’ve ever implemented circuit breakers in a microservices architecture, ASI08 is the agentic equivalent of cascading service failures.

In practice, you implement circuit breakers at the orchestration layer, design all agent actions for idempotency, bound error-correction so recovery attempts can’t trigger more failures, and limit blast radius by isolating agents into failure domains.

ASI09 Human-Agent Trust Exploitation

ASI09 compounds four LLM Top 10 entries (LLM01, LLM05, LLM06, LLM09) into active exploitation of the human approval loop. Where LLM09 describes a passive risk (humans over relying on AI output), ASI09 describes attackers weaponizing that trust relationship to cause humans to authorize specific harmful actions. Two concrete attack patterns illustrate the difference. Alert fatigue exploitation floods the human with legitimate approval requests until they auto-approve without reviewing. The phantom agent attack impersonates a legitimate agent interface to harvest approvals for unauthorized actions.

Your defenses need to operate outside the agent’s own output channel. Use a separate visual confirmation channel for high-impact approvals, monitor approval requests for anomalies, enforce time-delayed approvals for high-risk actions, and require mandatory attribution in all action requests so that every approval states which agent, which task, and which action.

Deep Dive: The Seven Evolved Risks

ASI01 Agent Goal Hijack

AASI01 compounds LLM01 (Prompt Injection) and LLM06 (Excessive Agency). The primary attack vector is indirect injection: malicious instructions embedded in content the agent reads from its environment (web pages, documents, API responses) rather than content the user directly submits.

Implement goal integrity monitoring at the orchestration layer to detect when an agent’s behavior diverges from its assigned objective. Treat all environment content as untrusted, not just direct user input. For high-impact irreversible actions, require explicit human confirmation before the agent proceeds.

ASI02 Tool Misuse & Exploitation

ASI02 describes attacks that exploit an agent’s tool-calling capabilities: not by compromising the tools themselves, but by manipulating the agent into using legitimate tools in malicious sequences. LLM06 flagged over-permissioned agents as the condition. ASI02 describes what happens when attackers exploit it. Individually-permitted tool calls that together achieve a malicious outcome are tool chaining attacks. MCP tool definition injection, where an attacker embeds malicious instructions in the schema description an agent reads when discovering available tools, is the ASI02 vector specific to MCP environments.

Scope your tool allowlists per task type (not global), run tool call sequence analysis to detect chaining anomalies, and keep tool schemas minimal: describe exactly what the tool does, nothing more.

ASI03 Identity and Privilege Abuse

ASI03 covers attacks that exploit agent identity: either by impersonating one agent to another, or by exploiting trust relationships to escalate privileges across agent boundaries. Single-agent over-privilege (LLM06) combined with prompt-driven identity manipulation (LLM01) and sensitive information disclosure (LLM02) evolves into cross-agent impersonation and the confused deputy problem, where an orchestrator causes a sub-agent to act with capabilities the orchestrator was not authorized to delegate.

Start with cryptographic agent identity per instance (not per agent type). OAuth/OIDC alone is not enough: you need task-scoped tokens that expire at task completion. Log all identity assertions; so, your audit trail captures exactly which agent claimed which identity at which point in the task.

ASI04 Agentic Supply Chain Vulnerabilities

ASI04 is the agentic evolution of LLM03 Supply Chain, addressing the shift from static software dependencies to runtime supply chain, where the tools, servers, and registries an agent connects to can change during execution. LLM03 risks are evaluated at build time. ASI04 risks are live during task execution: an agent can download and use a compromised MCP server that didn’t exist when you deployed. ASI04 is also the first OWASP framework entry to explicitly name a specific protocol (MCP).

Your first line of defense is MCP server allowlisting so that agents connect only to pre-approved registries. Pin tool definition versions so you don’t auto-update tool schemas. Extend your SBOM to include dynamic runtime dependencies. MCP deserves its own treatment: see the dedicated section below for attack surface analysis and implementation guidance.

ASI05 Unexpected Code Execution

ASI05 covers code execution risks in agents where code execution is often the intended primary function. The risk is not mishandling output but unsafe execution of intentionally-generated code. LLM01 (Prompt Injection) plus LLM05 (Improper Output Handling) treated code execution as a downstream risk when AI-generated output was passed to other systems. ASI05 inverts this: in coding agents and agents with computer use capabilities, code generation and execution is the designed behavior. The risk is what the execution can access.

Before executing, distinguish reversible from irreversible actions and gate irreversible ones on explicit human confirmation. Use purpose-built sandboxed execution environments (gVisor, Firecracker) rather than general-purpose container isolation. Apply time-bound execution windows and restrict your agent to only the file system access, network egress, and process permissions the current task requires.

ASI06 Memory & Context Poisoning

Your agent’s memory stores are an attack surface. ASI06 addresses the planting of false facts, instructions, or context in persistent stores that activate across future tasks. Where LLM04 (Data & Model Poisoning) and LLM08 (Vector & Embedding Weaknesses) address training-time and embedding-store risks, ASI06 Memory and Context Poisoning a runtime risk. An attacker can plant a false fact in an agent’s episodic memory today and activate it weeks later when the agent retrieves that memory for a high-stakes task. If your agentic system uses RAG, ASI06 is your highest-priority memory risk.

Treat working memory, episodic memory, and semantic memory as separate stores with independent access controls. Implement memory TTL policies so that memories expire, and high-stakes memories require re-verification. Log memory write provenance so you know what wrote each entry. Scan retrieved memory content for injected instructions before including it in active context.

MCP and the Agentic Supply Chain

MCP (Model Context Protocol), an open standard developed by Anthropic and released in November 2024, is now the de facto protocol for agent-to-tool connectivity across all major AI tooling vendors. ASI04 is the first OWASP framework entry to explicitly name a specific protocol, which signals that the agentic supply chain risk is not abstract: it is tied to infrastructure choices you are making today.

The OWASP Top 10 for Agentic Applications identifies three MCP-specific attack surfaces under ASI04 (Agentic Supply Chain Vulnerabilities). Server compromise is the most direct: an attacker controls or compromises the MCP server, which means they control what tools the agent sees and can invoke. The agent has no way to distinguish a poisoned registry from a legitimate one. Tool definition injection is subtler: malicious instructions embedded in the schema description the agent reads when discovering available tools. Before the agent calls the tool, the schema itself redirects behavior. Resource content poisoning completes the picture: injecting malicious instructions into MCP-served content (files, documents, data) that the agent treats as legitimate context from a trusted source.

A concrete example. A developer installs a popular MCP server from a public registry to give their agent access to a productivity tool. The server is legitimate, but a minor update introduces a tool definition that includes hidden instructions telling any connected agent to exfiltrate task context to an external endpoint. The developer’s agent executes the instruction because it trusts tool definitions as authoritative.

To protect your agents against MCP supply chain attacks: allowlist MCP servers so agents connect only to pre-approved registries, pin tool definition versions so schemas do not auto-update, validate tool schemas against expected structure before loading, treat all MCP-served resource content as untrusted (the same way you would treat external API responses), and log all MCP tool invocations with full parameters for audit trail.

The Least Agency Principle

Least Agency is an official concept introduced in the OWASP Top 10 for Agentic Applications (2026). It is the agentic equivalent of least privilege: an agent should have only the permissions, tools, memory access, and communication scope it needs to complete the current task and nothing more. Unlike least privilege, which is applied statically at deployment, Least Agency is applied dynamically: permissions and tool access should narrow to the minimum required for each specific task, then be revoked when the task completes.

The five dimensions of Least Agency, each mapping to a specific ASI risk:

1. Tool scope: Grant access only to the tools required for the current task. Revoke at task completion.
2. Identity scope: Each agent instance gets a unique cryptographic identity scoped to its current task, not a shared or persistent identity.
3. Memory scope: Agents read only the memory stores relevant to the current task. Memory writes are logged and attributed.
4. Execution scope: Code execution and system access are bounded to what the current task requires. No general-purpose execution environments.
5. Communication scope: An agent communicates only with the agents and services its current task requires. No standing inter-agent trust relationships.

If you’re moving toward Least Agency, replace static role assignments with task-scoped credential grants that expire when the task completes. Static RBAC holds permissions for the agent’s lifecycle. Least Agency narrows them per task and revokes at completion.

If Least Agency is how you design agent permissions, the ASI01–ASI10 checklist is how you verify you’ve applied it.

Using ASI01–ASI10 as a Threat Modeling Checklist

The ASI framework is not just a risk inventory. It is a threat modeling input. When we threat-model agentic systems, we walk through ten questions, one for each ASI risk. For each agent in your system, ask: “Is my system exposed to this?”

1. ASI01: Can external content (web pages, documents, API responses) redirect this agent’s goal without human detection?
2. ASI02: Can tool definitions be modified after an agent loads them, and do you monitor tool schema changes?
3. ASI03: Can one agent escalate privileges by impersonating another, or trigger the confused deputy problem?
4. ASI04: Are all MCP servers in your registry pinned and signature-verified? Do you maintain a runtime SBOM?
5. ASI05: Is code execution sandbox-isolated with restricted egress and no persistent file system access beyond task scope?
6. ASI06: Is persistent memory protected from untrusted write operations, and do you have memory TTL and provenance logging?
7. ASI07: Are inter-agent messages cryptographically authenticated and integrity-verified at the receiving agent?
8. ASI08: Do you have circuit breakers at agent orchestration boundaries to prevent cascading failure amplification?
9. ASI09: Are agent approval requests anomaly-monitored, clearly attributed, and delivered via a separate confirmation channel?
10. ASI10: Can any agent create persistent triggers, register new capabilities, or persist state across sessions without explicit human authorization?

The ASI checklist is a threat enumeration step within a broader threat modeling process. It tells you what to look for, not how to prioritize or remediate what you find.

If you want this checklist running continuously instead of once a quarter, Trent’s agents scan, judge, mitigate, and re-evaluate your agentic system against ASI01–ASI10 every time the code changes. Join the waitlist or ask for a demo.

Reviewed by Eno Thereska, Co-founder & CEO at Trent AI