OWASP Agentic Top 10: the ten risks, and the four to check first

The short version

• The OWASP Top 10 for Agentic Applications for 2026 names ten security risks for AI agents, numbered ASI01 to ASI10.
• The list is a consensus framework from expert review, so it names risks without measuring how often they occur.
• Agent risk comes from what the agent can do, so credentials and tool scope matter more than prompt wording.
• Identity, tool scope, goal hijack and human approval set how much damage one bad instruction can do.
• An agent that can only read and draft faces far less of the list than one that acts on its own.

What are the ten risks in the OWASP Agentic Top 10?

The ten risks are agent goal hijack, tool misuse and exploitation, identity and privilege abuse, agentic supply chain vulnerabilities, unexpected code execution, memory and context poisoning, insecure inter-agent communication, cascading failures, human-agent trust exploitation and rogue agents. OWASP numbers them ASI01 to ASI10.

The OWASP GenAI Security Project published the list on 9 December 2025 as the OWASP Top 10 for Agentic Applications for 2026. It came from expert collaboration and global peer review. That matters for how you read it. It is a consensus framework, not a survey, so it tells you what experienced people think can go wrong. It does not tell you how often any of it happens.

The common thread is autonomy. A chatbot that gives a bad answer wastes someone's time. An agent that acts on a bad instruction can send the email, change the record or move the money. Every item on the list is a version of that gap between what the agent was asked to do and what it is able to do.

What does each OWASP agentic risk mean?

How does the agentic list differ from the OWASP LLM Top 10?

The LLM Top 10 covers applications built on a language model. The agentic list covers systems where that model plans, holds credentials, remembers and acts. The first asks what a model might say. The second asks what a model might do.

Some ideas overlap, but the consequence changes. Prompt injection on the LLM list becomes goal hijack on the agentic one. An injected instruction in a plain chatbot produces a strange reply. The same instruction in an agent with email and file access produces an action, and that action is logged under a valid account.

So the two lists stack. If your system only answers questions, the LLM list is the right starting point. If it can take actions, use both. The agent inherits every weakness of the model underneath it, then gives those weaknesses a way to reach your systems.

Which OWASP agentic risks should you check first when buying an agent?

Check identity and privilege abuse, tool misuse, goal hijack and human-agent trust exploitation first. Together they set the blast radius, meaning how much damage one bad instruction can do. This order is our judgement, not OWASP's.

Identity comes first because it caps everything else. A hijacked agent can only do what its credentials allow. If it runs under a broad service account, every other failure inherits that reach. If it holds a short-lived credential scoped to one task, a successful attack stays small.

Tool misuse is next because tools are where a fooled agent does its damage. A tool that can send any message to anyone is a different risk from one that can only reply to the current thread. Narrow tools are cheap to build and leave a hijacked agent with little to work with.

Goal hijack is third because there is no reliable way yet to stop a model following instructions hidden in what it reads. Agents read email, tickets, web pages and PDFs, and any of those can carry instructions. Assume some will get through, and design so they cannot achieve much.

Human approval is fourth because it is the control most teams lean on, and it wears out. A person who has approved a long run of sensible actions will approve the next one without reading it. Approval works when it is rare and when the reviewer sees the raw action, not the agent's description of it.

What should you ask an agent vendor about these risks?

• •Whose credentials does the agent run under, and what is the widest thing those credentials allow?
• •Which tools can it call, and which of them change data or send anything outside the company?
• •What happens when a document tells the agent to ignore its instructions, and can we watch that test?
• •Which actions need a human, and what does the approver see on screen?
• •What is written to memory, who can read it, and how do we remove an entry?
• •How do we stop the agent mid-task, and how long does that take?
• •Can you produce a log of every tool call for a given task, including the ones that failed?

What does the survey evidence say about these risks?

It points to weak visibility and loose identity controls, but the evidence is thin and vendors paid for most of it. Read these figures as signals, not measurements.

A Cloud Security Alliance survey from January 2026, with 418 responses, reported that 82% of enterprises have unknown AI agents in their environments. A second CSA survey from the same month, with 228 responses, found that more than two-thirds of organisations cannot clearly distinguish AI agent actions from human ones. Those findings sit close to identity abuse and rogue agents. If you cannot list your agents or attribute their actions, you cannot contain them.

Incident figures are harder to read. An IRONSCALES report, with fieldwork by Censuswide among 501 US IT and cybersecurity professionals at companies with 1,000 to 10,000 employees, said 77% of organisations had an agentic AI-related security incident in the past year, and 57% reported a confirmed case. A self-reported incident is whatever the respondent counted as one.

All three surveys are self-reported. Token Security financed the first and co-developed its questionnaire. Aembit did the same for the second. IRONSCALES commissioned the third. All three are vendors with a commercial interest in the result. That does not make the numbers false, but they should not be the reason you buy anything.

Does the OWASP agentic list apply to small businesses?

Yes, but only the parts your agent can reach. The risks follow capability, not company size. A small firm whose agent can issue refunds has the same mechanism exposed as a large one, with fewer people to notice when it goes wrong.

The evidence on smaller firms is weaker. The IRONSCALES sample covers companies with 1,000 to 10,000 employees. Gravitee's published survey of 900 senior technology leaders covers organisations with 250 or more employees across the UK and US. Neither includes firms under 50 staff. We have no reliable figure for agent incidents at small firms, so we will not offer one.

General AI use gives only rough context. The UK Cyber security breaches survey puts businesses using, adopting or considering AI at 31%, and the US Census Bureau reports that firms with at least 20 employees are the biggest AI users. Both measure AI in general, not agents, so neither tells you how many small firms run one.

When is working through the whole list not worth it?

When the agent has no way to act. An assistant that reads approved content and drafts text for a person to check does not need a programme built around ten risks. A short review of goal hijack and data exposure covers most of what can go wrong.

Several items drop out on structure alone. A single agent has no inter-agent messages to secure. An agent with no way to run code has no sandbox to build. Cascading failures need something to cascade through. Do not spend a sprint on controls for parts your system does not have.

That is not an excuse to skip the basics. Even a read-only agent can be hijacked by a document it reads, and it can leak what it can see. Scope also drifts. The day someone adds a send button, the agent is a different system and the review starts again.

Can a vendor claim to be OWASP compliant for agents?

Not in any way that settles the question. The list is a framework of risks, not a scheme with an auditor, so 'OWASP compliant' tells you little on its own. Ask what was tested.

A useful answer names the risks in scope, the risks ruled out and why, the tests that were run and what failed. Failures are a good sign. An agent that has never failed a test has probably not been tested hard.

The same applies to a build you commission. Ask for the test set, not the summary. You should be able to rerun it after every change to the agent's tools, prompts or model.