Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

What Is the OWASP Top 10 for Agentic AI?

It is the OWASP GenAI Security Project's December 2025 list of the ten top risks in agentic applications, ASI01 through ASI10, from agent goal hijack to rogue agents, written for systems that act rather than only write. Check which of the ten your browser-based agent meets on its first screen, because four apply before it does anything unusual.

An agent platform faces a winding path through gates, barriers, steps, and varied geometric risk shapes.

It is the OWASP GenAI Security Project's December 2025 list of the ten top risks in agentic applications, ASI01 through ASI10, from agent goal hijack to rogue agents, written for systems that act rather than only write. Check which of the ten your browser-based agent meets on its first screen, because four apply before it does anything unusual. The earlier OWASP Top 10 for LLM Applications described what can go wrong when a model reads and writes text. The agentic list describes what can go wrong when a model also acts: calls tools, holds credentials, remembers across sessions, talks to other agents and asks people for approval. An agent that navigates enterprise applications exhibits most of those behaviors by design. This page sets out what the list contains and how it relates to the LLM Top 10, which of the ten risks a browser-based agent meets first, where on a subscription account screen goal hijack and tool misuse occur, how human-agent trust exploitation differs from prompt injection, how the ASI entries line up with MITRE ATLAS and Microsoft's failure-mode taxonomy, and which claims a buyer should decline. It draws on research on why agentic AI projects fail in regulated industries for the deployment context.

Key findings

  • The OWASP Top 10 for Agentic Applications lists ASI01 Agent Goal Hijack, ASI02 Tool Misuse, ASI03 Identity & Privilege Abuse, ASI04 Agentic Supply Chain Vulnerabilities, ASI05 Unexpected Code Execution, ASI06 Memory & Context Poisoning, ASI07 Insecure Inter-Agent Communication, ASI08 Cascading Failures, ASI09 Human-Agent Trust Exploitation and ASI10 Rogue Agents, with the framing that "Once AI began taking actions, the nature of security changed forever" (OWASP GenAI Security Project, 2025).
  • The project's announcement describes the list as reflecting collaboration "between AI security leaders and practitioners across the industry," in co-chair Scott Clinton's words (OWASP GenAI Security Project, 2025).
  • The agentic list sits beside, not in place of, the OWASP Top 10 for LLM Applications 2025, whose entries on prompt injection and excessive agency remain the root mechanisms behind several ASI risks (OWASP, 2025; OWASP, 2025).
  • Human-agent trust exploitation has a documented attack form: forging approval dialogs so that a person authorizes an operation they did not intend (OWASP, 2025).
  • MITRE ATLAS and Microsoft's April 2025 taxonomy of agentic failure modes provide complementary vocabularies for the same risks (MITRE, 2026; Microsoft AI Red Team, 2025).
  • Several ASI risks reduce in severity when the model never receives the real values on a screen, the premise examined in research on AI agent data exposure.

What does the OWASP Top 10 for Agentic Applications list, and how does it relate to the LLM Top 10?

The OWASP GenAI Security Project published the Top 10 for Agentic Applications on December 9, 2025, describing it as the benchmark for agentic security, with the ten entries running from ASI01 Agent Goal Hijack through ASI10 Rogue Agents (OWASP GenAI Security Project, 2025). The accompanying release describes the list as the product of industry-wide collaboration among security leaders and practitioners (OWASP GenAI Security Project, 2025).

The relationship to the LLM Top 10 is one of layering. The 2025 LLM list catalogs risks in applications that use a model to read and generate text, among them LLM01 Prompt Injection and LLM06 Excessive Agency (OWASP, 2025). Those two are the roots from which several agentic risks grow. Prompt injection, in which untrusted content alters the model's behavior (OWASP, 2025), is the mechanism behind agent goal hijack and much of memory poisoning. Excessive agency, in which the model holds more capability than its task needs (OWASP, 2025), is the condition that makes tool misuse and privilege abuse consequential.

What the agentic list adds is the consequence layer. An injected text application produces a wrong answer; an injected agent produces a wrong action, and the ASI entries name the forms that action takes. The project's own sentence, that the nature of security changed once AI began taking actions, is the thesis of the list.

Which of the ten risks does a browser-based agent meet first?

An agent that reads rendered screens and acts through a browser meets some entries on its first task and others only in specific architectures. The table sorts them.

ASI entry Exposure for an agent reading and acting on enterprise screens
ASI01 Agent Goal Hijack Immediate: every screen it reads is untrusted content that can redirect the task
ASI02 Tool Misuse Immediate: the browser and the applications on it are the tools, and a hijacked goal misuses them
ASI03 Identity & Privilege Abuse Immediate: the agent acts under a person's session and inherits that person's permissions
ASI04 Agentic Supply Chain Architecture dependent: extensions, plugins and model providers in the chain
ASI05 Unexpected Code Execution Lower for a pure browser agent; higher where it reaches a terminal or IDE
ASI06 Memory & Context Poisoning Present where the agent persists memory across sessions
ASI07 Insecure Inter-Agent Communication Present only in multi-agent designs
ASI08 Cascading Failures Present where one agent's output feeds another's input
ASI09 Human-Agent Trust Exploitation Immediate: every approval prompt is a surface for deception
ASI10 Rogue Agents Present wherever the agent can act without a person between it and the consequence

Four entries, ASI01, ASI02, ASI03 and ASI09, are immediate for a browser-based agent, because they follow from what such an agent is. It reads screens, which is untrusted content. It acts through applications, which are tools. It acts as the user, which is privilege. And it asks the user for approval, which is trust. The remaining six depend on how the agent is built and connected. The four reduce to two questions: what did the model receive, and what can it do without a person. Research on how to secure AI agents organizes the control set around those same two questions.

Where on a subscription account screen do goal hijack and tool misuse occur?

Take a subscription account record in a billing console showing the account name, the billing contact's name and email, the payment method, the plan, a credit balance and a notes field where support staff record conversations. The agent's task is to apply a promotional credit and send a confirmation.

ASI01 occurs if the notes field, or an email the agent read earlier, contains an instruction that redirects the task: change the billing email to an attacker's address, or apply a larger credit, or send the confirmation containing the payment details to a different recipient. The model received that instruction as part of ordinary content and may follow it, which is prompt injection in the LLM list's terms (OWASP, 2025) and goal hijack in the agentic list's. ASI02 occurs at the moment the redirected goal becomes an action: the billing console's edit function, which the agent was permitted to use for the credit, is used to change the contact email. The tool was legitimate; the use was not. ASI03 is already present, because the agent is acting inside the support engineer's session, with every permission that engineer holds, including ones the task never required.

The hijack needs content the model reads, the misuse needs a tool, the abuse needs privilege, and the screen, the console and the session supply them. The remaining question is what stops the chain, and the agentic list's answer, across its entries, is to constrain what the agent can do and insert a person at the consequential step. A design that also removes the real values from what the model reads, so that the billing contact's email is CONTACT_001 and the payment method is PAYMENT_001, removes the data the hijack was trying to redirect, which is the argument research on securing AI agents in the enterprise develops.

How does human-agent trust exploitation differ from prompt injection?

Prompt injection deceives the model. Human-agent trust exploitation, ASI09, deceives the person. The OWASP community's attacks page documents the form it takes: HITL Dialog Forging, also called Lies-in-the-Loop, which "manipulates the content and presentation of approval dialogs, deceiving users into authorizing malicious operations" (OWASP, 2025). The agent, hijacked or not, presents an approval request that describes a benign action while the action it will perform is different.

The two risks demand different controls. Against prompt injection, the organization limits what the model receives and what it can do. Against trust exploitation, the organization must ensure that the approval the person sees is rendered from a source the agent cannot alter, shows the real values and the real action, and arrives rarely enough that the person reads it. An approval dialog generated by the agent from its own summary of its intended action is the attack surface itself. An approval that shows the actual field values about to be committed, drawn from the destination system rather than the model's description, is not.

This is why ASI09 is on the list as a separate entry rather than a consequence of ASI01. A design can defeat goal hijack by placing a person at the consequential step and still fail if that person's view is controlled by the agent. The human in the loop is a control only when the loop is built so the human sees the truth. Excessive agency, from the LLM list, describes the agent having too much capability (OWASP, 2025); ASI09 describes the agent having too much influence over the one control meant to check it.

How do the ASI risks map to MITRE ATLAS and Microsoft's taxonomy?

Two other bodies of work describe the same territory, and auditors and red teams use all three. MITRE ATLAS, the Adversarial Threat Landscape for Artificial-Intelligence Systems, is a knowledge base of adversary tactics and techniques against AI systems, structured in the manner of ATT&CK (MITRE, 2026). Where the OWASP list names risks, ATLAS names what an adversary does, so an organization can take ASI01 and ask which ATLAS techniques realize it, and build detections accordingly.

Microsoft's AI Red Team published a taxonomy of failure modes in agentic AI systems in April 2025, distinguishing failures that are novel to agents from those inherited from earlier AI systems, and distinguishing security failures from safety failures (Microsoft AI Red Team, 2025). Its vocabulary is an engineer's: what breaks, and whether the break is new. The OWASP list is a defender's ranking; ATLAS is an attacker's catalog; the Microsoft taxonomy is a systems analysis. All three treat the agent's capacity to act as the thing that changed and locate the central risks in the gap between what the model is given and what it may do.

A security review written against the OWASP list can be checked against ATLAS for detection coverage and against the Microsoft taxonomy for completeness. None of the three prescribes a product. Each describes conditions, and an organization chooses controls that remove the conditions: less in front of the model, less the model can do, a person at the consequence, and a record of all three. Research on AI agent data security sets out that control set against the same literature.

What does a governed environment change?

A governed environment changes the four ASI entries a browser agent meets first, goal hijack, tool misuse, identity and privilege abuse and human-agent trust exploitation, from risks the model must resist into risks bounded by what the model can see and commit. Run directly in the application or the user's browser, the agent reads real account values and can act on them; in the environment, it reads tokens and acts only through an approval it cannot render itself.

This class of control works at the rendered screen. Sensitive values on a billing or account page are replaced with consistent tokens before any model reads them, and the task runs on tokens. Real values resolve only at an approved destination at the moment of an approved action. A named person confirms what is tokenized and approves consequential actions such as payments, submissions and record changes. Every screen as tokens, every action and every approval is recorded and exported to the organization's own logging.

The list names risks, not controls (OWASP GenAI Security Project, 2025). What this class of control supplies is the mapping the previous section asked for: hijacked goals and misused tools operate on tokens (ASI01, ASI02), the agent's own identity cannot commit a consequential change (ASI03), and the approval is rendered from the destination system rather than by the agent, which the documented dialog-forging attack depends on (OWASP, 2025). ASI05 through ASI08 and ASI10 remain architectural questions it does not answer.

The control does not alter the application, the user's permissions or the model, and it does not address entries that sit outside the rendered page.

Where does RedactSure sit?

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company. Its design addresses the four immediate entries on this page by changing what the agent receives and what it can commit. Agents work inside a governed environment in the customer's own cloud. On every rendered screen, substitution happens at the render layer before any model reads it, so a subscription account's billing contact and payment fields reach the model as consistent tokens such as CONTACT_001 or ACCT_001 for the whole run, which removes the real values a goal hijack would redirect. Real values resolve only at approved destinations at the moment of an approved action, so a misused tool commits tokens unless a person approves the real action. A named person confirms the tokenization policy and approves every payment, submission and record change, the arrangement RedactSure calls Supervised Delegation, with the approval showing the real action rather than the agent's description of it. Every screen as tokens, every action and every approval lands in the AI Control Record and exports to the customer's SIEM. The design is model agnostic, requires no per-application integration, and leaves user permissions unchanged.

Deployments are in pilot. A pilot on the reader's own account workflow would show the four immediate entries exercised against a real screen, with the model's input, the held action and the approval record. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page rests on the OWASP GenAI Security Project's December 9, 2025 publication of the Top 10 for Agentic Applications and its accompanying release, the OWASP Top 10 for LLM Applications 2025 and its entries on prompt injection and excessive agency, the OWASP community page on HITL Dialog Forging, the MITRE ATLAS knowledge base, Microsoft's April 2025 taxonomy of failure modes in agentic AI systems, and published RedactSure research pages on agent security, data exposure and regulated-industry deployments. All sources were read as of October 16, 2026.

No hands-on testing of any product was performed for this page. The table assigning exposure levels to the ten entries for a browser-based agent is this page's analysis, not OWASP's; OWASP ranks the entries but does not grade them by agent type, and the list's own text and mitigations should be read in full rather than from this summary. Entry names are given as the cited announcement lists them. Where any product or framework is described as not addressing an entry, the statement refers to the pages reviewed and not to the product as a whole. Standards documents and vendor features change, and the page carries its date. Statements about RedactSure describe its current design, with deployments in pilot. The subscription account record used as the worked example describes a record type, not any organization; the fields, the task and the injected instruction are illustrative.

Whether a given agent deployment adequately addresses the risks in the OWASP list, and what obligations attach to it under law or contract, are determinations for the organization's counsel, its assessors and its own security and compliance officers, not for a research page.

What the record shows

The OWASP Top 10 for Agentic Applications is a list of what goes wrong when a model acts, published to sit alongside the earlier list of what goes wrong when a model writes. For an agent that reads enterprise screens and acts through a browser, four entries are immediate: goal hijack, because every screen is untrusted content; tool misuse, because the applications are the tools; privilege abuse, because the agent acts as the user; and trust exploitation, because the approval dialog can lie. The other six depend on architecture. The four reduce to two questions, what the model received and what it can do without a person, and the controls that answer them are substitution before the read, a person at the consequence, and a record of both; RedactSure's design is one arrangement of those controls. The test is to name one agent and one account screen, place a redirecting instruction in its content, and ask what the model received, what it attempted, and who saw the real action before it landed.

Frequently asked questions

Is the OWASP Top 10 for Agentic Applications a replacement for the LLM Top 10?

No. The two lists layer. The LLM Top 10 for 2025 addresses risks in applications that use a model to read and generate text, including prompt injection and excessive agency. The agentic list addresses what happens when the model also acts, naming the forms that action takes when it goes wrong. Several agentic entries have an LLM entry as their mechanism: goal hijack is prompt injection with a consequence, and tool misuse is excessive agency exercised.

Which ASI entries matter most for an agent that works in a browser?

Four are immediate because they follow from what a browser agent is: ASI01 goal hijack, since every screen it reads is untrusted content; ASI02 tool misuse, since the applications it works in are its tools; ASI03 privilege abuse, since it acts within a person's session; and ASI09 human-agent trust exploitation, since every approval prompt can be forged. The other six, from supply chain to rogue agents, depend on how the agent is built, connected and allowed to persist.

What is agent goal hijack in practice?

Content the agent reads during a task contains instructions that redirect the task toward the attacker's goal. On a billing screen, a notes field or an earlier email might instruct the agent to change a contact address or send payment details to a new recipient. The model receives the instruction as ordinary content and may follow it. The mechanism is prompt injection; the agentic list names it separately because the outcome is an action in a live system rather than a wrong answer in a chat.

How is human-agent trust exploitation different from a user being tricked by a phishing email?

The deception is delivered through the agent's own approval interface. In the documented attack form, HITL Dialog Forging, the approval dialog describes a benign action while the agent performs a different one. The user is approving what appears to be their own agent's routine request. The defense is structural: render approvals from a source the agent cannot alter, show the real values and the real action, and keep approvals rare enough to be read.

How do MITRE ATLAS and Microsoft's taxonomy relate to the OWASP list?

They describe the same territory from different angles. ATLAS catalogs adversary tactics and techniques against AI systems, so it answers how an attacker would realize an OWASP risk and what to detect. Microsoft's April 2025 taxonomy classifies failure modes in agentic systems by whether they are novel to agents and whether they are security or safety failures. The OWASP list ranks risks for defenders.

Can a single product address the whole list?

No, and a vendor claiming so has misread the list. Entries such as insecure inter-agent communication and cascading failures depend on the organization's architecture, and supply chain risk depends on every component in the chain. A product can address specific entries and should say which, how and where. For a browser-based agent, the four immediate entries are addressed by controls on what the model receives, what it can commit without a person, how the approval is rendered, and what record is kept.

Book an AI Agent Security Review →

Bring your hardest questions.

Bring one sensitive workflow and the decisions your team needs to keep in its hands.

Book a demo

About the author

Christopher Sowa
Chris SowaCo-Founder, President and Chief Commercial Officer, RedactSure

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

Book a demo

Book a demo

Having trouble? Open the booking page or email us.