OWASP Agentic Top 10: secure AI agents before launch

The OWASP Agentic Top 10 is OWASP's list of the biggest security risks for AI agents: systems that plan, call tools, keep memory and act on their own across several steps. If your app has moved from a chatbot that answers questions to an agent that sends email, edits records or runs code, this is the list to check before launch.

The full title is the OWASP Top 10 for Agentic Applications for 2026, published in December 2025. This guide explains the ten entries in plain words and turns them into checks you can run.

What the OWASP Agentic Top 10 covers

OWASP describes the list as peer reviewed and built with more than 100 experts, researchers and practitioners. Each entry has a description, common weak spots, example attacks and fixes.

It sits next to the OWASP LLM Top 10, not in place of it. The LLM list covers the model as one part of your app. The newest edition, covered in our OWASP LLM Top 10 2026 guide, says that once the model becomes an actor with tools and memory, you should read the two together.

The authors' main point is that agents amplify existing weaknesses. A prompt injection in a chatbot gives a bad answer. The same injection in an agent can send messages, move data or delete records.

The ten risks in plain words

• ASI01 Agent Goal Hijack. Hidden instructions in a page, document, email or tool result change what the agent is trying to do. OWASP notes that agents cannot reliably tell instructions apart from the content they read.
• ASI02 Tool Misuse and Exploitation. The agent uses a tool it is allowed to use, but in a harmful way: deleting data, calling a costly API over and over, or sending information out.
• ASI03 Identity and Privilege Abuse. The agent runs on borrowed keys, tokens or user sessions, so nobody can tell what it did on whose behalf, and its access can be stretched.
• ASI04 Agentic Supply Chain. Tools, plug-ins, models and other agents loaded from third parties, often at run time, may be tampered with.
• ASI05 Unexpected Code Execution. The agent writes and runs code or shell commands that were never reviewed.
• ASI06 Memory and Context Poisoning. Someone plants bad data in the agent's memory, summaries or search index, and it shapes later decisions.
• ASI07 Insecure Inter-Agent Communication. Messages between agents can be faked or changed because nobody checks who sent them.
• ASI08 Cascading Failures. One wrong step spreads from agent to agent and grows into a much bigger failure.
• ASI09 Human-Agent Trust Exploitation. People approve what a confident agent suggests without checking it.
• ASI10 Rogue Agents. An agent drifts outside its job and keeps acting there.

Start with Least-Agency

Before any single check, OWASP gives one idea it calls Least-Agency: do not give an agent autonomy it does not need. Its authors write that adding agent behavior where it is not needed widens the attack surface without adding value.

In practice, ask three questions for each thing the agent can do. Does it need to do this at all? Does it need to do it without a person confirming? Does it need to keep doing it after the task ends? Every "no" removes a risk from the list before you test anything. Our guide to excessive agency shows how to cut tool permissions back.

Checks for what steers the agent

These cover ASI01, ASI06, ASI09 and ASI10.

• Treat everything the agent reads as untrusted: uploads, web pages, emails, calendar invites and tool results. Plant a test instruction in each one and see whether the agent follows it.
• Write some test data into memory as one user, then check whether another user's session can see it. OWASP's fix is to keep each user's memory separate.
• Log the agent's goal and tool calls, and alert when they change mid-task.
• Show people what the agent is about to do, not just its reasons, so they are approving an action and not a story.
• Make sure you can stop an agent and cancel its access quickly. OWASP names kill switches and credential revocation as the response to a rogue agent.

Checks for what the agent can do

These cover ASI02, ASI03 and ASI05.

• Give each tool the smallest permission it needs. OWASP's own examples: read-only database queries, and no send or delete rights for an email summarizer.
• Require a person to confirm deleting, transferring or publishing, with a preview of exactly what will change.
• Give the agent its own identity and short-lived, task-scoped credentials rather than a long-lived admin key or a copy of a user's session.
• Run any code the agent writes in a sandbox with no route to production data, and block outbound traffic except to approved addresses.
• Put a spending or call limit on each tool.

Checks for what the agent connects to

These cover ASI04, ASI07 and ASI08.

• List every tool server, plug-in, model and outside agent the system can load, where each comes from, and who can change it. Our guide to LLM supply chain security has a review you can reuse.
• Check that messages between agents are authenticated, so one agent cannot pretend to be another.
• Break one step on purpose, such as a tool returning garbage, and watch whether the next agents stop or carry on.

Worked example: an inbox agent before launch

Say your agent reads a shared support inbox, looks up the customer, drafts a reply and can issue a store credit.

1. Least-Agency first. Does it need to send replies, or only draft them? Make it draft only. Store credits need a person to approve, with the amount and customer shown.
2. Goal hijack. Send the inbox an email with a hidden line asking the agent to issue a credit to a different account. The agent should flag it, not act on it.
3. Tool misuse. Confirm the customer lookup is read-only and returns only the customer named in the email.
4. Identity. Check the agent uses its own key with access to the inbox and the lookup, and nothing else.
5. Memory. If it keeps notes between emails, plant a note from one customer's thread and check another thread cannot see it.
6. Cascade and trust. Make the lookup fail. The agent should say it could not find the customer, not guess. Check that the approval screen shows the action itself, not just the agent's summary.

Six checks, one afternoon, and each maps to an OWASP entry you can name in your report.

Frequently asked questions

Is the Agentic Top 10 the same as the LLM Top 10?

No. The LLM Top 10 covers the model as part of an app; the Agentic Top 10 covers systems that plan and act with tools, memory and other agents. OWASP says to use both when your model acts on its own.

Does a simple chatbot need the Agentic Top 10?

Mostly not. If it only answers questions and calls no tools, start with the LLM Top 10 and our prompt injection testing guide.

What is the single most useful fix?

Give the agent less: fewer tools, narrower permissions, and a person approving anything that deletes, pays or publishes. That shrinks what every other entry can do.

Get started

Planning where agents fit in your team? whitehatstoic's AI adoption advice helps you find where AI helps, roll it out safely and measure the result, with a use-case review, a tool and pilot plan, and a safe-use policy.

Already built the agent? Our cybersecurity and AI safety testing covers AI systems and their APIs, with a written report, fixes and a retest after fixes. Book a meeting with whitehatstoic: tell us the product, the deadline and your biggest worry, and we reply with a plan and a price.