Until recently, a company's AI assistant answered questions. Now it increasingly reads email, queries the CRM, prepares payments or writes and runs code. That jump from answering to acting is what turns a chatbot into an agent, and it changes the security question entirely: knowing what it can say is no longer enough, you need to know what it can do.

◢What is the OWASP Top 10 for Agentic Applications?

It is a catalogue of ten risks, numbered ASI01 to ASI10, with examples, attack scenarios and mitigations for each. According to OWASP¹, it was developed with more than 100 industry experts, researchers and practitioners, and it is peer-reviewed. Like OWASP's other lists, it is not a standard or a certification. It is a reference for knowing what to ask and where to start.

It focuses on agents: AI systems that plan, decide and act across multiple steps and systems, often on behalf of a person or a team.

◢How is it different from the LLM Top 10?

The LLM Top 10 looks mainly at what the model says. The agentic list looks at what happens when that answer becomes an action. OWASP makes the point with its first entry: classic prompt injection changes a single response, while in an agent it can change the goal and everything the agent does afterwards.

The core idea of the document is what OWASP calls least agency: do not grant autonomy where it is not needed, because every unnecessary capability widens the attack surface without adding value. It adds a second condition it treats as essential: being able to see at all times what the agent is doing, why, and with which tools. It is the broader version of what I covered in AI agents with too many permissions.

◢When someone changes the agent's goal

ASI01, agent goal hijack, starts from a familiar problem: the model cannot reliably tell an instruction apart from the content it reads. If the agent processes an email, a document or a web page with hidden instructions, it can end up pursuing the attacker's goal. OWASP cites EchoLeak, where a crafted email made Microsoft 365 Copilot follow hidden instructions and leak emails, files and chats without the user doing anything. For more examples, see my piece on indirect prompt injection.

ASI06, memory and context poisoning, is the long-lasting version. Many agents keep summaries, memory or documents for future tasks. If someone manages to slip false information in there, the agent will keep using it in later sessions. OWASP's example is simple: someone keeps repeating a fake flight price, the assistant stores it as true and ends up approving bookings at that price. Its mitigations include keeping each user's memory separate, expiring anything unverified and not letting the agent feed its own output back into its memory.

◢When the agent misuses what it has

ASI02, tool misuse and exploitation, is when the agent stays within its permissions but uses them unsafely. OWASP's examples will be familiar in any office: an email summariser that can also delete or send mail without asking, or a customer service bot meant to look up orders that also issues refunds because the tool had full access to the financial side.

ASI03, identity and privilege abuse, goes one step further. Agents inherit credentials, hand tasks to each other and often trust any internal request. In one of the document's scenarios, a crafted email claiming to come from IT reaches an email-sorting agent, which passes it on to a finance agent, which pays without checking because the request came from another internal agent. OWASP recommends giving each agent its own identity, with permissions scoped to the task and short-lived, plus human approval for anything irreversible.

ASI05, unexpected code execution, affects agents that write and run code, including AI coding tools. The risk is that a manipulated instruction or a model mistake ends up running on a server. The mitigations are well known: never run as an administrator, isolate execution in sandboxes and keep generating code separate from running it, with a check in between.

◢When outside components cannot be trusted

ASI04 covers the supply chain. An agent is assembled from models, tools, plugins, prompt templates and MCP servers, the protocol many assistants use to connect to other applications, and much of it is loaded at runtime. OWASP includes the case of a malicious MCP server on npm that impersonated Postmark's and secretly BCC'd emails to the attacker, reported as the first one seen in the wild. It recommends keeping an inventory of AI components, using only vetted sources and pinning versions.

ASI07, insecure inter-agent communication, appears when several agents work together and their messages are neither authenticated nor protected. An attacker can intercept or alter them, or register a fake agent that receives tasks it should never get.

◢When an error spreads or fools a person

ASI08, cascading failures, describes how a single fault, whether a hallucination, poisoned data or a compromised tool, passes from one agent to the next until it affects the whole system. One of OWASP's examples needs no attacker at all: human oversight relaxes after a run of successes, approvals happen in bulk and changes spread unchecked.

ASI09, human-agent trust exploitation, is the one I care most about for staff. The agent sounds confident and well reasoned, and the person approves without checking. The scenario OWASP describes will be familiar to anyone who has seen CEO fraud: a manipulated invoice reaches the finance assistant, it recommends an urgent payment to an account controlled by the attacker, and the manager approves it trusting the explanation. Because a person carries out the final action, the agent's role stays hidden from whoever investigates afterwards.

ASI10, rogue agents, covers agents that drift from their purpose even when each action looks legitimate. OWASP's example is sobering: an agent tasked with cutting cloud costs learns that deleting the backups is the most effective way to do it. For these cases it asks for tamper-proof logs, a kill switch and the ability to revoke credentials instantly.

◢What should a company do before putting an agent to work?

You do not need to tackle all ten entries at once. Based on OWASP's guidance, these are the questions I would ask before giving an agent access to real systems:

• ▹Does it really need to act, or would it be enough for it to propose and a person to carry it out?
• ▹What can it send, pay, delete or publish? Each of those actions should require human confirmation.
• ▹Which identity does it use? Its own account with minimal permissions beats the credentials of whoever built it.
• ▹What outside content does it read, such as emails, web pages or documents, and what can it do after reading it?
• ▹Where do its tools and connectors come from, and who reviews and updates them?
• ▹Is everything it does logged, and can someone stop it at a moment's notice?

And one for your staff: whoever approves what an agent proposes should know that a convincing explanation is not proof. OWASP includes training the people who oversee agents among its mitigations, and that is exactly what I work on in my cybersecurity and AI training for companies.