OWASP LLM vs agentic AI risks differ in system scope and consequence. The Top 10 for LLM Applications covers model exchanges, data, dependencies, and permissions. The agentic list carries that thinking into systems that hold memory, take delegated access, and run multi-step work. Security architects need enforcement at the tool call, not just the prompt. Aurascape governs that execution path inline and records what each governed action did.

Last updated: September 2026.

What Changes When a Model Becomes an Agent

The OWASP Top 10 for LLM Applications already reaches past model output. It names prompt injection as LLM01 and includes Sensitive Information Disclosure, Supply Chain Vulnerabilities, Data and Model Poisoning, Improper Output Handling, Excessive Agency, Vector and Embedding Weaknesses, Misinformation, and Unbounded Consumption among the top risks for applications built on large language models (LLMs) (OWASP, 2025). Some of those categories concern what a model produces. Others concern what the application depends on, what it ingests, and what it may do. That second set is the ground the agentic list builds on.

An OWASP-affiliated project published a Top 10 for Agentic Applications that complements the LLM Applications list rather than replacing it. It extends the same risk thinking to systems that keep context across sessions, act with delegated access, and run multi-step plans without a person reviewing each step. Coverage of the release names agent-specific categories including agent goal hijack, identity and privilege abuse, unexpected code execution, insecure inter-agent communication, tool misuse and exploitation, agentic supply chain vulnerabilities, and memory and context poisoning (Security Boulevard, 2025).

Agentic AI risk covers failures that grow when a system keeps context, holds delegated permissions, and acts across multiple steps. Some of those failures already appear in the application taxonomy. Supply chain weaknesses and excessive agency are named in both. What changes is the object of analysis. A poisoned memory shapes a decision before any tool runs. A manipulated message between two agents spreads before a person sees output. The risk is no longer only what a model says. It is what a persistent, acting system reaches.

That progression runs in three phases: human-to-AI usage today, human-to-agent delegation, and emerging agent-to-agent execution. Aurascape secures the human-to-AI phase in production and is built for the move to delegated and autonomous execution. That move is exactly what made a second taxonomy necessary.

OWASP LLM vs Agentic AI Risks: How the Two Lists Compare

The two lists ask different questions about the same stack. The comparison below lines up scope, representative risks, and what each taxonomy expects a reviewer to check.

One control plan should cover model exchanges, stored context, delegated permissions, and downstream actions. An unaddressed prompt injection becomes the entry point for a tool-misuse chain the moment a model can act on what it reads. That seam between the two lists is where design attention belongs.

Which Capabilities Expand the Risk Surface?

Four capabilities drive the expansion: tools, memory, delegated permissions, and multi-step autonomy. Each one turns a category from the application list into a live operational risk.

Tools. A tool call is the unit of action an agent takes. Attach tools and an output stops being text. It becomes an API request, a file write, a database read, or a shell command. Prompt injection changes character at that moment. Instructions hidden in a retrieved web page, a shared document, or a tool result no longer only mislead a reader. They steer the next call. The agentic categories carry injection forward as goal hijack and tool misuse, because the same payload now reaches a system holding live credentials.

Memory. Memory stretches the exposure across time. A hostile instruction written into agent state, a vector store, or a shared context file keeps acting after the session that planted it closes. Controls built around a single request and response never see it, because the content arrived earlier and now looks like the agent’s own history. Sensitive information exposure follows a related path, so control design has to separate five surfaces: prompts, model responses, retrieved context, writes into memory, and tool results. A system prompt or a private document can surface in a later response, or in a later tool parameter no user asked for.

Delegated permissions. Delegation changes the entitlement question. An agent holding tokens for a customer relationship management (CRM) system, a ticketing queue, and a data warehouse carries the union of a person’s access with none of a person’s hesitation. Permission review only works against a known population, and most programs start behind on that count. Cloud Security Alliance research found 82% of organizations have unknown AI agents operating in their environment (Cloud Security Alliance, 2026).

Multi-step autonomy. Autonomy chains reasonable steps into an outcome nobody approved. An agent reads sensitive records through one server and writes them out through another. Both actions look normal alone. Together they are exposure. Multi-agent setups add cascading failure: a manipulated agent passes a poisoned instruction to a second agent, and without message provenance the receiving agent cannot tell that instruction from a legitimate one. Containment then depends on trust boundaries between agents and on stopping the next action rather than the last message. Supply chain risk sits underneath all of it and reaches past any single protocol, since models, training data, plugins, libraries, and third-party tool integrations each carry weaknesses that only surface once an agent starts calling them. The tool ecosystem is also growing faster than most review cycles. Censys found more than 12,520 internet-accessible Model Context Protocol (MCP) services, mostly unauthenticated, since the protocol does not require authentication by default (Censys, 2026). MCP is one common tool-execution pattern, not the whole agent access-control problem. Agents also reach systems through direct APIs, browser automation, and generated code that runs locally.

How Do These Categories Show Up in Disclosed Findings?

Taxonomies earn their keep when they map to disclosed findings. EchoLeak, tracked as CVE-2025-32711, was a zero-click indirect prompt injection in Microsoft 365 Copilot (NVD, 2025). It shows a top LLM application risk firing with no user action, which is the same condition that makes the agentic categories necessary. If injection needs no click, autonomy needs no accomplice.

Aura Labs, Aurascape’s threat research team, documented SilentBridge, a class of zero-click indirect prompt injection flaws in the Manus agent, with three variants distinguished by untrusted-content source and each rated CVSS v3.1 9.8. The research demonstrated impacts in testing including email data theft, secret leakage, remote code execution, and cross-tenant access, with mitigations deployed after responsible disclosure (Aura Labs, 2026). One finding like this spans goal hijack, tool misuse, unexpected code execution, and privilege abuse in a single chain. That is why the agentic categories work better as a sequence than a checklist.

Supply chain risk fires without any model behavior at all. Aura Labs also reported CVE-2025-66454, a hardcoded default JWT signing secret shipped in the Arcade MCP Server Framework and left enabled in production. Anyone who knew the public value could mint valid tokens, reach internal routes, and enumerate or invoke available tools. Arcade patched it in three days. No model was manipulated. One misconfigured component in the tool layer produced unexpected access on its own, which is the agentic supply chain category in practice.

Each finding landed on a consequential control point: a tool invocation, a protected route, or an accepted token. The table below states the control requirement for each recurring agentic category and how Aurascape meets it.

Where Should Enforcement Sit Once Agents Can Act?

Agent interactions run on two channels. The intelligence channel connects the agent to the model. The tool-execution channel connects the agent to the servers and systems it acts on. Aurascape secures the intelligence channel with the AI Proxy and the tool-execution channel with the Zero-Bypass MCP Gateway, so policy can match stated intent against attempted action inside a governed session (Aurascape, 2026). The enforcement point is the call itself. The context is the decoded conversation around it. The outcome is a decision taken before the action reaches the target system.

Inside that governed architecture, the Gateway marks every call it approves, and the AI Proxy checks the intelligence channel for that mark. An agent’s tool use surfaces in the model conversation, so a call that skipped the Gateway is caught there and blocked before the model acts on it. Unsanctioned execution does not complete inside the governed path. That pairing matters because a routed gateway only controls the calls that reach it. An agent routes through a conventional MCP gateway only if it is configured to do so, a user can change that by editing one line, and the call is never inspected after that.

Tool-level sanctioning does the rest of the work. Tools are approved individually, with tags such as read-only or write so one rule governs a whole class of tools. Access rules decide who may use which tools, bound to users and groups. Protection rules inspect what moves through them with 600+ real-time data classifiers applied direction-aware to requests and results, so a secret is caught whether it leaves in a parameter or arrives in a tool result. Tool definitions are pinned at sanction, a server-side change requires explicit admin re-fetch and review, and tool descriptions are inspected for hidden instructions and unsafe auto-approve settings. High-risk write and execute calls are held for human confirmation or blocked. Aurascape applies runtime policy to discovered agents and their governed tool calls using agent, user, tool, and session context. For MCP, the Gateway operationalizes OAuth 2.1 so each call carries the privileges of the person behind it, with tokens held in memory only, scoped per user per server, and set to expire. Actions run across the canonical set: allow, coach, notify, redact, redirect, block, capture, and require tenant. Security tunes outcomes instead of choosing between allowing everything and breaking the workflow.

None of that works against an inventory nobody has. Aurascape’s endpoint agent uses process and filesystem analysis to discover and monitor AI running locally, detecting an agent launch and its configuration, including MCP server connections, before that agent takes its first action. The MCP Server Catalog enrolls servers automatically the first time an agent uses one, complete with their tool inventories, and flags tool activity that bypassed the Gateway. For agents a team builds, the posture inverts: the agent reaches only approved servers and tools, and the Gateway logs every call it makes.

How Do You Turn Both Lists Into Controls, Owners, and Evidence?

Architects ship controls, owners, and evidence, not taxonomies. The sequence below runs the lifecycle from build through operation to retirement, and it applies to both OWASP lists at once.

1. Discover the AI apps, accounts, and agents already in use, including local agents on laptops and MCP servers reached on first use.
2. Classify each agent by what it can reach, not by what it was designed to do, and record whether it runs under an enterprise tenant or a personal account.
3. Test before release, covering prompt injection, jailbreak, code injection, and misinformation scenarios, plus code path and CVE detection on generated code.
4. Gate deployment on a named application owner, an approved tool list, and a recorded set of delegated permissions.
5. Sanction tools individually and tag them by effect, separating read from write and execute.
6. Scope permissions so each tool call carries the privileges of the person behind it and nothing more.
7. Inspect both directions at the call boundary: parameters going out, results coming back, files and code included.
8. Review component changes on a cycle, covering model versions, libraries, plugins, and any tool definition a server has altered since approval.
9. Set the response range across all eight policy actions so the common case is coaching or redaction, not a blocked project.
10. Capture an interaction record for each governed agent action: user, application, server, tool, parameters, detected data categories, and the decision.
11. Retire cleanly, revoking tools, disabling agents, and removing server enrollments that no workflow still needs.

Exceptions need their own discipline, because they are where a control plan quietly stops matching production. Every exception should record five things: the exact scope being allowed, the named owner accountable for it, an expiration date, the compensating control that runs while the exception is open, and the evidence a reviewer will read at renewal. An exception with no expiry is a design decision nobody signed. The mapping below assigns each control area an owner, the evidence it produces, and how an exception to it is handled.

Those controls line up with the frameworks auditors already use. The NIST Generative AI Profile organizes AI risks into suggested actions under the Govern, Map, Measure, and Manage functions of the AI Risk Management Framework (NIST, 2024). Article 12 of the EU AI Act requires automatic recording of events over the lifetime of high-risk systems (EU AI Act, 2024). Interaction records that capture the actor, the tool, the data involved, and the policy decision contribute toward that kind of evidence collection, alongside the wider compliance review a legal or audit team performs. ISO/IEC 42001 supplies the management-system wrapper, requiring defined roles, documented controls, and periodic review of an organization’s AI management system (ISO, 2023). Sector detail changes the data types and the regulators, not the underlying architecture, as the control maps for enterprise AI, financial services, and healthcare and pharmaceutical organizations show.

There is a program argument for doing this early. Gartner predicts over 40% of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value, or inadequate risk controls (Gartner, 2025). Security architects can answer the risk-control factor in that prediction directly, through enforceable policy, pre-release testing, and action-level evidence, well before a project reaches a cancellation review.

Frequently Asked Questions

What is the difference between the OWASP LLM risks and the OWASP agentic AI risks?

System scope and consequence. The OWASP Top 10 for LLM Applications covers model exchanges plus the application around them: data, dependencies, output handling, and permissions. The Top 10 for Agentic Applications extends that thinking to systems that keep context, act with delegated access, and complete multi-step plans, adding categories such as agent goal hijack and insecure inter-agent communication.

Does the OWASP LLM Top 10 still apply once you deploy agents?

Yes, and it applies with more consequence. An agent still takes untrusted input and still generates responses that can disclose data or point to a compromised dependency. What changes is that several of those same failures now have a path into a tool call, so a disclosure or an injected instruction can trigger an action rather than only a misleading answer.

Why does prompt injection get worse in an agentic system?

Because the injection reaches a component with credentials. In a chat application, an injected instruction distorts the response. In an agentic workflow, it can also drive a downstream action, because the agent supplies the permissions. Zero-click cases such as EchoLeak in Microsoft 365 Copilot and SilentBridge in the Manus agent show the trigger can require no user action at all.

What is excessive agency, and how do you control it?

Excessive agency is an agent holding more capability, permission, or autonomy than its task requires. Control it at invocation. Approve tools by effect, apply delegated scope, inspect the call in both directions, and require confirmation or block execution when policy demands it.

How do memory and context poisoning differ from prompt injection?

Timing and persistence. Prompt injection acts on the current turn. Poisoning writes hostile content into memory, a vector store, or shared state so it shapes later sessions, often after the original interaction closes. Controls that inspect one request at a time miss it, which is why conversation-level context and classification on both requests and results matter.

Is governing MCP enough to cover agentic risk?

No. Agents also act through direct APIs, browser automation, and generated code, so the control objective is the execution path rather than a single protocol. Governing MCP well closes a large and fast-growing share of that path, particularly given how many MCP services are reachable without authentication.

What audit evidence do agentic risks require?

Evidence at the level of the action. For each agent interaction: which user delegated the work, which account or tenant was in effect, which server and tool were invoked, which parameters and data categories were involved, what came back, and what policy decision was taken. Aurascape creates interaction records for audit and effectiveness, governed by role-based access control (RBAC) for privacy.

Aurascape maps both OWASP taxonomies to working controls across AI interactions and governed tool execution: discovery of the AI apps, accounts, and agents in use, inline classification of the data moving through each governed call, a Gateway that marks approved calls and stops unmarked ones, and interaction records for the actions that run. If your agent program is moving from pilot to production, the fastest way to see the difference is to watch a tool call get stopped before it runs.

See how Aurascape governs agent tool execution inline →

GARTNER® is a registered trademark and service mark of Gartner, Inc. and/or its affiliates and is used herein with permission. All rights reserved. Gartner does not endorse any vendor, product or service depicted in its research publications and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact.