OWASP Top 10 for Agentic Applications 2026

AI Agents are no longer limited to answering questions but may perform a multitude of tasks, including planning, recalling information, executing, and invoking tools and systems within a given domain, potentially with sensitive credentials and real-world impact. The risks posed by these complex systems prompted the publication of the OWASP Top 10 for Agentic Applications 2026 report on December 9, 2025. The report was developed by over one hundred cybersecurity researchers, practitioners, and technical writers who aimed to document and classify the unique security risks introduced by the new class of AI-based applications. The threats include manipulation of agents to deviate from their intended purpose and rogue agents that operate outside their designated scope of control, among others. This blog discusses the OWASP Top 10 for agentic applications.

What is the OWASP Top 10 for Agentic Applications?

Most discussions about security issues relating to AI focus on models: what they say, what they were trained on, and how to prompt them to say different things. When an agent can act on its own behalf, using its own tools and memories, the focus changes from the content of its statements to the actions it performs. This is why the framework came into existence to specifically address the risks from the emergence of agentic capabilities.

OWASP Top 10 for Agentic Applications: Why We Need It

In 2023, the Open Web Application Security Project (OWASP) recognized a need to address a security gap: traditional application security guidance did not fully account for the emergent risks of the intersection between large language models (LLMs) and existing applications and processes, resulting in the LLM Top 10. However, with few exceptions, the LLM Top 10 largely focuses on the model as a text-generation engine. The Agentic Top 10 builds upon the LLM Top 10 by focusing on the emergent risks of agentic systems, which take on characteristics of an autonomous agent with goals, credentials, tools, and memory that can be combined and chained together to perform complex tasks.

Microsoft's AI Red Team, which contributed to the development of the framework, provides a good summary of the changes: taken together, the list makes one idea clear, multiple times over: failures in these agentic systems are rarely bad outputs, but rather bad outcomes, stemming from an agent's ability to consume untrusted input as instructions, chain together tools, act on behalf of another entity, and persist information across sessions and systems. In other words, autonomy introduces a critical new vector for exploitation, wherein the system under test is performing actions that an average human would not have been able to convince to happen, due to insufficient instruction-guarding, overly permissive delegation, or improper use of tools.

How It Relates to the LLM Top 10 and the MCP Top 10

The Agentic Top 10 is not meant to replace the previous lists but rather supplement them, covering areas that the older ones left out. The Top 10 for LLM Applications covers risks that come from the models themselves, such as prompt injection and training data poisoning. In contrast, the MCP Top 10 covers the connections to external tools at a lower level. The Agentic Top 10 then builds upon the OWASP Top 10 for LLM Applications, as many agentic applications would be LLM applications at their core and have those same risks.

In practice, this means that if one were to use a chatbot or RAG system that did not involve tools and coordination between different agents, the LLM Top 10 would be sufficient in securing it, as the Agentic Top 10 would have nothing to apply to such a system. However, any application that uses a third-party agent system or MCP servers would benefit from both lists being used, with the Agentic Top 10 focusing on the supply chain and communication between agents if any specific framework was used for it, being the main factor in the security of such an application. Not three separate lists with different purposes but rather concentric rings, with the LLM Applications list being the core, tools adding another layer and agents another on top of that, with each list adding security that the previous ones could not provide.

The "Least Agency" Principle (the architecture behind the whole list)

• Core idea: An agent should neither hold more autonomy, permission, or standing for a task than is reasonably required by its work. It is a "security through limited capability" principle, akin to the traditional computer security principle of least privilege, but applied to agentic capabilities. Agents that operate with more autonomy, permission, standing, or scope than is reasonably required for their task create room for error, misuse, and abuse.

• Why it's important: An agent does not need to be hacked or compromised to cause damage. Its goals may be only "accidentally" reallocated, its tool usage or delegation decisions may have negative second- and third-order effects, or it may retain privileges or delegation for too long.

• Practical implementations: Designing systems where the goals an agent is allowed to pursue are narrowly limited, requiring human approval for higher-risk tools and actions
  Limiting delegation lifespans, or capping the amount of autonomy an agent is permitted to exercise.

• Why it's listed here: Each of the other points on this list can be seen as a case of an agent having too much room for autonomy, permission, standing, or scope for the task at hand.

The Top 10 Risks Explained in Detail

Here is the breakdown of the ten categories of the Agentic Security Initiative (ASI) below, which describe particular ways in which an autonomous system may fail to maintain its autonomy, each of which is characterized by a particular class of causes and solutions. Taken together, these categories define the life cycle of an autonomous agent: its objectives, tools, identity, memory, communication with other agents, and response to failures in its operations.

ASI01: Agent Goal Hijacking (content injection)

This risk surface occurs when an attacker is able to modify an agent's instructions by injecting new content into content the agent trusts, thus modifying the agent's objectives.

Mitigation

Structurally separate untrusted content from trusted instructions, and require confirmation or reconfirmation of the latter; treat any content retrieved from untrusted sources as untrusted, with any processing of it done in a manner that prevents it from taking control over the agent.

ASI02: Tool Misuse and Exploitation

This risk surface stems from an agent being able to perform an authorized but unsafe action using a tool, either as a result of an attacker's input or due to the agent's own incorrect reasoning.

Mitigation

Have a limited set of credentials to deploy or build components with, and require human confirmation when commits affecting agent-facing instructions or tools occur; restrict potentially destructive tools' access to fresh credentials that are only issued for specific tasks and not general use.

ASI03: Identity and Privilege Abuse

This risk surface stems from agents often acting on behalf of a user or under a privileged identity; an attacker can abuse this by causing the agent to perform unauthorized actions they would not be able to otherwise.

Mitigation

Issue short-lived, narrow-use credentials whenever possible; limit the scope of any session or tool interaction to a particular repository or resource; treat privilege escalation similarly to any other form of potential misuse.

ASI04: Agentic Supply Chain

An agent interacting with other agents or tools exposes all of the components it uses to potential attack and misuse; each of these components then becomes a risk surface for compromising the agent.

Mitigation

Use narrower tokens when accessing different resources, especially when distinguishing between internal and external agents; isolate sessions that access publicly available information from the rest; treat servers or other computers used to run agents as additional potential risk surfaces, akin to relying on third-party code.

ASI05: Unexpected Code Execution (RCE)

This risk surface stems from an agent being able to directly or indirectly read or write code, which provides an attacker with opportunities to execute arbitrary code on a system executing the agent.

Mitigation

Have code execution, including code generation or execution by tools, happen in a restricted environment whenever possible; require explicit approval for code execution on production or file system/network access; make sure that an agent cannot chain code generation, interpretation, or execution steps with reading user-provided content.

ASI06: Memory Poisoning

This risk surface occurs from agents that remember information about past interactions, either through long-running sessions or persistent storage, and from this information being modified by an attacker to contain malicious or misleading data.

Mitigation

Treat modification of persistent memory as a potentially privileged action; do not allow an entity, including the agent itself, to modify such data unless it has been explicitly authorized to do so; periodically verify the integrity of data in persistent memory.

ASI07: Insecure Inter-Agent Communication

As agents start to form larger systems, the communication between them becomes a critical but frequently insecure risk surface; an attacker can compromise this communication to modify or inspect agent data or instructions in transit.

Mitigation

Treat messages sent from one agent to another as untrusted inputs; do not automatically accept or believe any data or instructions received from another agent; perform additional monitoring and analysis on inter-agent communication compared to regular user input.

ASI08: Cascading Failures

This risk surface stems from agents performing unsafe or incorrect actions due to an earlier agent providing them with the wrong context, expectations, or data; unlike regular errors, these errors are often not obvious and fail to be noticed until significant damage has been done.

Mitigation

Add checkpointing or additional validation steps between major stages of an agent-assisted or multi-agent system; prevent minor failures from being escalated to full-scale failures by ensuring that later agents are not operating on incorrect or unsafe information without noticing.

ASI09: Human-Agent Trust Exploitation

This risk surface stems from how humans interact with agents; an attacker can threaten or bribe humans to get them to approve requests or provide information the agent would not be able to do on its own.

Mitigation

Make the capability of an agent clear at all times; encourage users to question an agent's suggestions if they have any doubts; require humans to provide their own verification rather than rely solely on the agent's capabilities.

ASI10: Rogue Agents

This risk surface stems from agents behaving in ways that differ dangerously from their intended use case or instructions, either due to incorrect reasoning or an attacker compromising them directly.

Mitigation

Segregate production and development environments at the infrastructure level if possible; do not allow the agent itself to decide what constitutes a production environment; ensure that particularly critical actions always require additional explicit approval beyond simply following the agent's instructions; store logs, data, and other information separately from the agent if possible, to ensure that they are not modified by a rogue agent.

Best practices to secure AI systems from emerging agentic AI risks

Awareness of the ten risk categories is a necessary but insufficient foundation for securing agentic systems. The key complementary insight is that there are three fundamentally different stages for securing such systems: those that occur before deployment (preventing designers from introducing weaknesses), during testing (preventing attackers from finding exploitable bugs), and after launch (preventing operators from suffering direct consequences)

Threat Modeling Before Deployment

• Enumerate comprehensive action sets: beyond APIs, catalog every tool, plugin, and MCP server the agent can access, and define catastrophic outcomes for each being invoked incorrectly.

• Explicitly identify trust boundary crossings: every place where untrusted content (emails, documents, web content, tools) enters the system or is processed by the agent.

• Model privilege chains: record what credentials, tokens, or permissions the agent possesses at all times, how they're acquired, and whether any provide greater access than needed for its tasks.

• Assume both adversarial attacks and logical failures: when designing defenses, think through how the system itself might fail catastrophically versus how an attacker might influence it to do so.

• Size risks by potential impact, not just probability: low-probability vectors that could delete production data should receive special attention versus high-probability but low-impact risks

Red-Team Scoping During Testing

• Test multi-step attack chains: some malicious requests may require combining innocuous actions that the model would not refuse individually.

• Include indirect injection vectors: when the agent accesses or ingests content (search results, documents, issues), test using compromised third-party content as inputs.

• Probe tools and privilege boundaries: try to get the agent to exploit its own privileges in ways it should not be able to, testing supply chain and credential access risks.

• Test memory persistence: if the agent is compromised across sessions, check if it can persist malicious instructions that will later be executed by the same instance.

• Red-team the human operators: Validate whether operators trust false information from the agent about its own status or capabilities.

Runtime Monitoring Design in Production

• Log separately from the agent: maintain independent audit trails the agent cannot delete or control, rather than relying on its self-reporting.

• Require privileged action reviews: for any potentially destructive or high-privilege operation, have a separate human or system approval that the agent cannot bypass.

• Detect anomalous behaviors: look for actions inconsistent with stated intent or patterns, even when individual steps appear benign.

• Circuit-break ongoing attacks: build in automatic "kill switches" to stop cascading failures or attacks that have already caused damage.

• Monitor and rotate credentials: since agentic systems often use third-party tools, actively watch that these are used as intended at runtime rather than abused.

AI Agent Security Frameworks Worth Knowing

OWASP is not the only organization mapping this area; several other frameworks target the same space from different angles, offering complementary approaches to the challenge. Knowing what they are allows you to use them together with more benefit.

MAESTRO (Cloud Security Alliance) – A Threat Modeling Framework

MAESTRO (Multi-Agent Environment Security Threats, Risk, and Outcomes) is a threat modeling framework created and published by the Cloud Security Alliance in February 2025, meant to target the unique risks introduced by agentic systems. Where the OWASP Top Ten lists out common risks, MAESTRO provides an organized way to discover risks particular to a business's implementation of agentic systems. It classifies these according to seven tiers - foundation models, data operations, agent frameworks, deployment and infrastructure, evaluation, observability, and the agent ecosystem - and potential interactions or risks between them, with specific attack surfaces and techniques highlighted. It explicitly builds upon prior methodologies such as STRIDE, PASTA, and LINDDUN, targeting the areas they lacked in terms of generative AI security, and is therefore compatible with OWASP in general, providing a different but overlapping set of tools. In practical terms, while the Top 10 is a list of risks to spot and address, MAESTRO and particularly OWASP's own tools are useful to actually design around them.

MITRE ATLAS

A continuously updated, real-world repository of adversarial techniques and tactics against AI systems, meant to parallel ATT&CK for conventional cybersecurity frameworks. Unlike OWASP or MAESTRO, which are prescriptive or partially prescriptive (listing out techniques to use or avoid), ATLAS is descriptive, listing out known techniques that attackers have used or may attempt in the future. This makes it particularly valuable for informing red teaming or validation exercises, as well as understanding what attacks your threat modeling actually needs to cover.

NIST AI RMF (Generative AI Profile)

A compliance-focused framework that instead targets the four NIST-mandated functions (govern, map, measure, manage) and serves as a reference guide for discussions with stakeholders. Where the other frameworks discussed are primarily used by technical teams to assess or build a system's security, NIST AI RMF is useful when the conversation turns to leadership, auditors, or regulators. It's the standard to reference when technical security is not the primary concern, and several of the other frameworks explicitly mention NIST AI RMF equivalencies when discussing their own entries.

Together, they tell a story: OWASP Top 10 defines what the security concerns of agentic systems are, while MAESTRO enumerates where in one's architecture to look for them - and Akto ATLAS provides the techniques to actually test for them. NIST AI RMF, meanwhile, is used when discussing one's approach to security with stakeholders, and particularly when those stakeholders are not technical themselves.

How Akto Protects AI Agent Systems Against All 10 ASI Risks

Testing tells you what the holes are; protection closes them before an attacker can exploit them. Akto's runtime layer covers the ASI category to the enforcement point, since most AI security products were designed to test models in isolation, flagging unsafe text output for human review, while Akto was built to protect AI autonomy, securing systems that reason, choose, access, and execute.

ASI01 (Goal Hijack) and ASI02 (Tool Misuse) - blocked before execution

Akto's guardrails are built directly into the tool invocation call, analyzing the tool name, arguments, and context before granting access to the tool, blocking potentially unsafe arguments or access to restricted resources before any execution has occurred. This is a direct enforcement point against an agent whose goal has been subverted through injection, since even if the injected instruction gets past initial security layers, the tool misuse it attempts to perform will still be blocked by Akto's runtime protection.

ASI03 (Identity and Privilege Abuse) and ASI04 (Supply Chain) - governed at the endpoint

Instead of granting broad access privileges to a generic identity, Akto's runtime security restricts access based on the specific tool being called, treating each invocation as an access control event and mapping agents to the specific credentials and permissions being used to invoke each tool, analyzing which agents, MCP connectors, and APIs are being used to perform each action and what data sources or credentials each agent has access to. Additionally, by analyzing the tool execution environment for installed skills across all agents and endpoints, Akto's SkillGuard product enables organizations to maintain a centralized inventory of all skills installed across all agents in their environment, blocking unapproved skills from running while providing centralized audit logging of which skills are installed on which agents, by which teams, with which permissions, and when. On the supply chain level, this provides visibility and control over skills, while on the agent level, it prevents privilege abuse by restricting tools to only those that have been explicitly approved for use.

ASI05 (Unexpected Code Execution) and data leakage post-tool-call

The enforcement doesn't end when the tool finishes executing; tool results are inspected before being returned to the calling agent, preventing data leakage in the results from MCP servers, such as credentials or PII that may have been accidentally or maliciously included in the output.

ASI06 (Memory and Context Poisoning) - caught via drift detection

Since poisoned memory doesn't announce itself, Akto's runtime layer looks for anomalous behavior, such as unexpected access patterns, rather than specific malicious content, by analyzing behavioral drift from standard patterns, similar to how content scanning alone is insufficient for detecting malicious skills. The same principle applies to memory scanning - while static analysis of memory content may be able to detect known malicious patterns, it will miss attacks that employ novel techniques or disguises, while behavioral analysis will detect anomalous patterns that could indicate memory poisoning.

ASI07 (Insecure Inter-Agent Communication) and ASI08 (Cascading Failures) - monitored across executions, not individual calls

Agentic AI workloads are inherently distributed and involve multiple interacting agents; while standard AI security tools focus on protecting individual model interactions, Akto Argus is designed to monitor and protect entire distributed agentic AI workflows, detecting and responding to inter-agent communication threats, such as insecure data exchange or cascading failures that affect multiple agents, at the level of entire end-to-end workflows rather than individual model calls.

ASI09 (Human-Agent Trust Exploitation) - full auditability of all decisions

All of Akto's decisions to block or restrict an agent action are logged with human-readable context, providing full transparency into what, when, and why an action was blocked, enabling human auditors to review and verify potentially unsafe agent behavior, such as when an agent attempts to convince a human user to bypass security controls, by checking against Akto's logs of its own decisions.

ASI10 (Rogue Agents) - real-time blocking of agent actions

The guardrails are designed to actively block unsafe agent actions in real-time rather than simply flagging them for human review, interrupting the agent's execution before it can cause harm, while still allowing the agent to continue operating normally if no security policies are violated. This is a crucial distinction for rogue agent scenarios, such as the Replit AI jailbreak, where the agent attempts to convince the user to manually bypass security controls, as simply notifying the user is insufficient protection if the user is tricked into granting the agent unrestricted access.

Two products, two layers. Akto ATLAS secures the employee AI layer, discovering shadow AI usage across browsers and endpoints and enforcing guardrails on all AI interactions in real-time to prevent data leakage or unauthorized actions before they leave the employee's device, while Akto ARGUS secures the AI agent application layer, protecting both internal and external agentic AI systems by monitoring their production use and enforcing guardrails across all agent interactions, acting as an MCP proxy to control what agents can do, see, or execute. Together, they provide full coverage across all ten ASI categories, from the individual user's device to the enterprise application layer.

Ready to see how your agents measure up against the OWASP Agentic Top 10?

Book a Agentic Security demo with Akto to assess your agentic attack surface, not just some abstract concept.

Final Thoughts on OWASP Top 10 for Agentic Applications

Agentic AI did not invent new vulnerabilities; it invented new consequences. The same prompt that generated a hallucinated sentence can delete a database or expose a private repository if the model at the other end of the prompt now has agency to do so. Every point in the OWASP Top 10 for Agentic Applications relates to this single principle: least agency. An agent should have no more autonomy or trust than what is needed for the task at hand. The framework gives you the language to express this. What you do with that language is what will ultimately keep you safe.

FAQs on OWASP Top 10 for Agentic Applications

1. What is the OWASP Top 10 for Agentic Applications, and when was it published?

It is a worldwide peer-reviewed prioritization of attack surfaces for autonomous and agentic AI systems, created by the combined effort of over a hundred industry experts, released by the OWASP GenAI Security Project on the 9th of December 2025, and organized as ASI01-ASI10 around ten broadly defined risk categories. As of the release date, it has been available for community review and adoption since December 2025.

2. What real-world attack example was ASI01 (Agent Goal Hijack) based on?

EchoLeak (CVE-2025-32711), a zero-click prompt injection vulnerability in Microsoft 365 Copilot discovered in mid-2025 – a single carefully crafted email with a secret instruction embedded in it could convince the Copilot to exfiltrate the contents of the user’s files to a third-party server.

3. What is the difference between static supply chain risk (LLM03) and agentic supply chain risk (ASI04)?

LLM03 refers to supply chain security concerns related to language models, such as training data provenance and potential risks associated with a pretrained model or a fine-tuning checkpoint. In contrast, ASI04 refers to model autonomy and the ability of agentic systems to dynamically incorporate external tools, memories, and chains of reasoning, potentially introducing additional attack surfaces, such as MCP server integrity, skills registry, and tooling authenticity. Unlike traditional models, agentic systems actively include external information and capabilities at runtime, which opens up additional attack vectors.

4. Which of the ASI risks are uniquely agentic and do not apply to regular LLM applications?

Tool misuse is the only concern that is specifically agentic in nature, namely, the opportunity for an attacker to exploit agent autonomy and toolchains to achieve unintended effects – the attack surface of the tool itself is extended via the presence of the agent. Rogue agents and cascading failures stem from the same root cause – the ability of autonomous agents to engage in multi-step reasoning and action across multiple interconnected entities. While these issues can be seen as advanced variations of prompt injection or model poisoning, they are enabled specifically by agents’ autonomy and goals, which makes them agentic analogs of broader LLM concerns. The rest of the risk categories were either already present in the LLM Top 10 or represent extensions of it.

5. What is the AI Vulnerability Scoring System (AIVSS), and how does it relate to this framework?

The AIVSS is a companion document to the OWASP AI Security Top 10 listing, defining a vulnerability scoring system for AI-related security issues. While this framework concentrates on the prioritization and taxonomy of different attack vectors and weaknesses, AIVSS provides a way to assess and compare the impact of individual vulnerabilities using a modified CVSS score. The Agentic AI Risk Score from AIVSS builds upon a traditional CVSS base score by incorporating additional factors related to the autonomy, memory persistence, and multi-agent collaboration surfaces specific to autonomous agents.

6. How should the company apply this list – for threat modeling, testing, or monitoring purposes? Or maybe all three?

It depends on the company’s needs and whether they are developing agentic applications (in which case, they should consider all three options). It can be used for threat modeling to define the potential attack surfaces in their application, design red-team testing scenarios to evaluate the real-world impact of these threats, and establish monitoring and detection capabilities to identify and respond to these attacks in production.