What is the OWASP Top 10 for Agentic Applications?
By Identra · Updated
The OWASP Top 10 for Agentic Applications is OWASP's list of the top security risks in AI agents that pursue goals, call tools and take actions. It covers threats such as goal hijacking, tool misuse, privilege abuse, memory poisoning and rogue agents.
What are the ten risks in the OWASP Agentic Top 10?
OWASP's GenAI Security Project publishes the list. The OWASP overview has the full text. The short version:
- Agent goal hijacking. Something the agent reads changes what it is trying to do.
- Tool misuse and exploitation.
- Identity and privilege abuse. The agent acts with more authority than the task needs, or borrows someone else's.
- Agentic supply chain vulnerabilities, such as a compromised MCP server or plugin.
- Unexpected code execution.
- Memory and context poisoning. Bad content gets saved and shapes later runs.
- Insecure inter-agent communication.
- Cascading failures, where one fault spreads across connected agents and systems.
- Human-agent trust exploitation. A convincing summary gets a reviewer to approve something they should not.
- Rogue agents.
How is it different from the OWASP LLM Top 10?
The OWASP LLM Top 10 is about applications built on a model. What goes in, what comes out. The agentic list starts once the model can do things. A chatbot that leaks its system prompt is a bad day. An agent with a Jira token, a shell and write access to the vendor table can turn the same bad input into a payment.
If your agent calls tools, review it against both lists. The table below is a way to frame the questions. It is not an official mapping between categories.
Untrusted content
- LLM application view
- Can input change the model's output?
- Agentic application view
- Can it redirect the task or trigger a tool call?
Permissions
- LLM application view
- What data does the app expose?
- Agentic application view
- What can each tool call or delegated task actually do?
Blast radius
- LLM application view
- Can bad output hurt a user?
- Agentic application view
- Can a stored memory or a chained agent spread the damage?
What does goal hijacking look like in practice?
Say a finance team runs a procurement agent. It reads the accounts payable inbox, matches invoices and drafts payment requests. An attacker emails a fake vendor notice with instructions to update the bank details and mark the change as verified. That is indirect prompt injection. The instruction rides in on material the agent was always going to read.
Now suppose the same service account can edit vendor records and approve payments. The email becomes a wire to the wrong account. If the agent also saves the new details as a trusted fact, next month's run reuses them without ever seeing the email again.
The fix is boring. The agent can propose a bank change. A separate process confirms it by calling the vendor on a number already on file. Payment approval sits with a person who sees the old and new account numbers side by side.
Which controls cover most of the list?
Across agentic AI security, least privilege does the most work. Check authorization in the service the tool calls, because the model's explanation of why it needs access counts for nothing. OWASP's AI Agent Security Cheat Sheet goes deeper on tools, memory and approvals.
- Give every agent a named owner. Write down its tools, credentials, data stores and memory.
- Allow only the tools the task needs. Validate arguments like file paths, SQL statements and outbound URLs.
- Keep retrieved content apart from instructions. Track where each memory entry came from so you can delete it.
- Authorize each request between agents. A trusted sender does not make every request safe.
- Tie human approval to the exact target and values. If the values change, ask again.
- Vet MCP servers and plugins before an agent can use them, and again when they update.
How do you test an agent against it?
Drop the fake vendor email into a test inbox. Then check the vendor table and the payment queue. An agent that says it declined has proved nothing.
AI red teaming should also go after tool responses, saved memories and the approval screen itself. Keep the logs of what was attempted and what actually happened. They will contain business data, so lock them down.
Then pull the AI agent kill switch for real. Does stopping the run also drop queued jobs and revoke the agent's tokens?
How Identra thinks about it
Identra discovers AI agents across Microsoft 365 Copilot and Foundry, Google Workspace and Anthropic, and shows who owns each one. On managed macOS and Windows devices it inventories MCP servers, skills and plugins. Agent tool calls on those devices are checked against policy, and destructive shell commands can be denied when policy is set to block. Every agent run is recorded with the user, device and outcome. When an analyst revokes a risky OAuth grant, the result is recorded too.
Go deeper: AI security, built on identity
Frequently asked questions
Is the OWASP Agentic Top 10 a compliance standard?
No. It is risk guidance. Mapping your controls to it does not certify anything or prove an agent is secure.
Does it apply to a single agent?
Yes. Goal hijacking, tool misuse, privilege abuse and memory poisoning all hit a lone agent. Inter-agent risks only come in once agents pass work to each other.
Can prompt filtering handle all ten?
No. A filter cannot decide whether a tool call is authorized, shrink a token's scope or clean a poisoned memory store.
Does human approval make an agent safe?
Only if the reviewer sees the real action and the evidence behind it. An approval based on the agent's own summary is easy to game.
Where should a team start?
With agents that can change production, move money or expose sensitive data. List position matters less than what an attacker can actually reach.