Key Takeaways
- OWASP’s Agentic Top 10 covers goal hijacking, tool misuse, identity abuse, supply chain risks, memory poisoning, and rogue agents.
- Agent autonomy expands risk because one manipulated input can trigger actions across tools, systems, and other agents.
- Identity controls such as scoped credentials and per-action authorization reduce privilege abuse.
- Containment measures including sandboxing, guardrails, and circuit breakers limit blast radius.
- Runtime monitoring helps detect downstream behavior when preventive controls fail and supports faster response.
AI agents now book meetings, query databases, move data between systems, and in some deployments, approve payments. They do this with real credentials, often on nothing more than a general instruction to “handle it.” That’s agentic AI in practice, and it’s why security teams are treating it as its own risk category instead of an extension of chatbot security.
The OWASP GenAI Security[1] Project has spent the past year building the reference material for that risk category through its Agentic Security Initiative (ASI). This piece walks through what the OWASP Top 10 for Agentic Applications actually says, why agentic systems open attack paths that older AI security models miss, and which mitigations are worth prioritizing first.
Quick answer: OWASP’s Agentic Security Initiative has published a Top 10 list of agentic AI risks (ASI01 through ASI10), covering goal hijacking, tool misuse, identity abuse, supply chain compromise, memory poisoning, insecure agent-to-agent communication, cascading failures, human trust exploitation, and rogue agents.
The mitigations center on two things: scoping agent identity and permissions tightly, and containing how far one bad decision can travel before a human notices.travel before a human notices.
Why Agent Autonomy Changes the Threat Model
The original OWASP Top 10 for LLM Applications was built around one risk: a model produces a bad response to a bad prompt. Agentic systems break that assumption. An agent plans across several steps, keeps memory between sessions, calls tools with delegated access, and in a growing number of deployments, coordinates with other agents to get a task done. One manipulated input can now set off a chain of actions instead of a single flawed answer.
OWASP’s own framing gets at this directly: agents “plan, decide, and act across multiple steps and systems, often on behalf of users and teams,” which is a fundamentally different exposure than a model that just generates text. A compromised agent doesn’t leak a sentence of bad output. It transfers funds, deletes records, or hands elevated access to whoever tricked it, sometimes all three, and often before anyone notices.
Adoption is outrunning the governance meant to contain it. According to the Gartner CIO and Technology Executive Survey[2], only 17% of organizations have deployed AI agents so far, but more than 60% plan to within two years, which Gartner calls the most aggressive adoption curve among all the emerging technologies it tracks in that survey. That’s the gap ASI exists to close.
Inside the OWASP Agentic Security Initiative
ASI sits inside the broader OWASP GenAI Security Project, the group behind the widely used LLM Top 10. Its output includes a foundational threat taxonomy (17 threat types, cited as T1 through T17), a governance report on the state of agentic AI security, and the document most teams reach for first: the OWASP Top 10 for Agentic Applications[3] with input from more than 100 practitioners, researchers, and vendor security teams.
The Top 10 isn’t a replacement for the deeper taxonomy. Think of it as the fast-access version: ten entries, each with a description, common vulnerability patterns, documented attack examples, and mitigation steps a team can act on this quarter.
- Generates High-Confidence Alerts
- Disrupts Autonomous and AI-Assisted Attacks
- Extends Detection Across Hybrid Environments
The OWASP Top 10 for Agentic Applications
| ID | Risk | The Short Version |
|---|---|---|
| ASI01 | Agent Goal Hijack | An attacker changes what the agent is trying to do, usually through hidden instructions in a document, email, or web page. |
| ASI02 | Tool Misuse & Exploitation | The agent uses a tool it's allowed to use, just not the way anyone intended, like deleting records instead of only reading them. |
| ASI03 | Identity & Privilege Abuse | Delegated permissions, cached credentials, or agent-to-agent trust get exploited to reach access the agent shouldn't have. |
| ASI04 | Agentic Supply Chain Vulnerabilities | A tool, plug-in, MCP server, or third-party agent loaded at runtime turns out to be malicious or tampered with. |
| ASI05 | Unexpected Code Execution | Prompt injection or unsafe code generation causes arbitrary code to run on a host or inside a container. |
| ASI06 | Memory & Context Poisoning | Stored context or long-term memory gets seeded with false information that quietly shapes later decisions. |
| ASI07 | Insecure Inter-Agent Communication | Messages between agents get intercepted, spoofed, or replayed because there's no real authentication between them. |
| ASI08 | Cascading Failures | One bad decision, hallucinated or injected, spreads across connected agents before a human catches it. |
| ASI09 | Human-Agent Trust Exploitation | People over-trust confident-sounding agent output and approve something they'd never sign off on otherwise. |
| ASI10 | Rogue Agents | An agent drifts outside its intended scope, whether that started with a compromise or emerged on its own. |
Two patterns cut across the whole list. Credential handling shows up in ASI03, ASI05, and ASI10. Containing what one bad decision can reach shows up in ASI01, ASI02, ASI07, and ASI08. Get those two areas under control and the rest of the list gets a lot less intimidating.
What Are the 10 OWASP Agentic AI Threats?
Here’s what each one looks like in practice, along with the real incidents behind it and the mitigation OWASP recommends.
ASI01: Agent Goal Hijack
Agents run on natural language, and OWASP is blunt about the weakness that creates: an agent “cannot reliably distinguish legitimate instructions from attacker-controlled content.” A single hidden line in a document or an inbound email is often enough.
The clearest example is EchoLeak (CVE-2025-32711), a zero-click vulnerability that Aim Security’s research team[4] disclosed in Microsoft 365 Copilot. According to Aim Security’s own announcement, the flaw let an attacker exfiltrate sensitive Microsoft 365 data with nothing more than a single email sent to someone in the target organization, no click, no download, no user action of any kind. Microsoft patched it server-side, and there’s no evidence it was exploited in the wild before the fix. Still, it’s the case OWASP itself cites as the reference example for ASI01.
The fix starts with treating every piece of natural-language input, including retrieved documents and inbound email, as untrusted by default, and requiring a human check before an agent’s plan or goal changes mid-task.
ASI02: Tool Misuse and Exploitation
This one plays out inside an agent’s authorized boundaries. A support bot meant to look up order history can also issue refunds, simply because the token behind it carries more access than the task needed. OWASP frames this as the agentic evolution of Excessive Agency from the LLM Top 10.
Nothing exotic fixes it. Scope every tool to the narrowest permission set it can function with, require confirmation before anything destructive runs, and put execution inside a sandbox with an egress allowlist.
ASI03: Identity and Privilege Abuse
Most identity systems were built for people logging into a dashboard, not for software that spins up sessions and inherits access from whatever spawned it. That mismatch is what lets a low-privilege agent relay an instruction to a high-privilege one and have it executed without a second look, the classic confused-deputy problem, now running at machine speed.
Short-lived, task-scoped credentials and per-action authorization close most of this gap. It’s also why OWASP points to platforms like Microsoft Entra and AWS Bedrock Agents, which now treat agents as governed non-human identities with their own audit trail rather than an extension of whoever built them.
ASI04: Agentic Supply Chain Vulnerabilities
Agents load tools, prompt templates, and sometimes other agents dynamically at runtime, which is a different problem than auditing a fixed dependency list once at build time. OWASP’s own incident tracker documents this happening more than once: a poisoned prompt shipped through the Amazon Q Developer extension in July 2025 that risked destructive file-wipe commands, and a malicious MCP server published on npm two months later, in September 2025, that impersonated a legitimate email tool, secretly BCC’ing every message to the attacker.
Signed manifests, pinned tool versions, and an inventory someone actually reviews go a long way here.
ASI05: Unexpected Code Execution
Coding agents generate and run code in real time, so a prompt injection or an unsafe deserialization step can turn plain text into an executed command. OWASP’s own attack-scenario list for this entry describes exactly this happening during a “vibe coding” incident, where an agent generated and ran unreviewed shell commands during an automated self-repair task and deleted production data in the process.
Ban eval() in production paths. Run generated code without root access. Separate the step that writes code from the step that executes it, with a check in between.
ASI06: Memory and Context Poisoning
Agents that remember things across sessions can be talked into remembering the wrong things. OWASP documents cases where an attacker reinforces a false claim across several interactions until the agent treats it as fact, and separately, security researchers have shown prompt injection that permanently corrupts an AI system’s long-term memory store.
Scan every new memory write before it’s committed. Segment memory by user and by task. Let unverified entries expire instead of sitting there indefinitely.
ASI07: Insecure Inter-Agent Communication
As multi-agent setups become normal, the channels agents use to talk to each other (APIs, shared memory, message queues) become an attack surface that perimeter security was never built to watch. Weak authentication between agents opens the door to replay attacks and impersonation of a peer agent.
Mutual authentication, signed messages, and attested agent registries are the baseline here, nothing more exotic is required to close most of it.
ASI08: Cascading Failures
This entry is about spread, not origin. A poisoned input or a hallucinated output can skip past the checks a human would normally catch, then propagate through delegated tasks before anyone notices. OWASP’s example involves a poisoned market-analysis agent inflating risk limits that downstream trading agents then act on automatically, with compliance staying blind because everything looks “within parameters.”
Sandboxed trust boundaries and circuit breakers between planning and execution are what stop one failure from becoming ten.
ASI09: Human-Agent Trust Exploitation
Agents sound confident. That confidence is the vulnerability. Automation bias makes it easy for a manipulated agent to talk a person into approving a wire transfer or a database change they would never sign off on if they’d worked through it themselves.
This is as much a process problem as a technical one, so the fix leans on process: explicit confirmation steps for high-impact actions, and a plain-language risk summary instead of the agent’s own self-written justification for why an action is safe.
ASI10: Rogue Agents
A rogue agent has drifted outside what it was built to do, whether that started with an outside compromise or emerged from its own reward-seeking behavior over time. OWASP describes this as an amplified insider threat, since agentic systems can cause that kind of damage at a speed no human insider ever could.
Cryptographic identity attestation, signed behavioral manifests that state what an agent is allowed to do, and a kill-switch that actually works are what contain it once it starts.
Real Examples of Agentic AI Security Incidents?
None of this is theoretical. OWASP maintains a running log of real incidents mapped against the Top 10, updated weekly, and it includes EchoLeak, the Amazon Q supply chain compromise, the fake Postmark MCP server, and a handful of remote code execution bugs found in AI coding assistants over the past year.
The OWASP GenAI LLM Top 10[5], took a similar evidence-first approach for the model-level risk list, describing its updated rankings as grounded in “thousands of real-world AI security incidents” rather than expert opinion alone.
The financial stakes are visible outside AI-specific research too. IBM’s report[6] found that shadow AI, meaning unsanctioned AI tools employees adopt without security sign-off, was a factor in 20% of breaches and added roughly $670,000 to the average breach cost. Ninety-seven percent of the affected organizations said they had no proper access controls on the AI tools involved. That’s the exact governance gap the OWASP Agentic Top 10 is trying to close before agent deployments outpace it further.
Where Should Enterprises Start With Agentic AI Security?
You don’t need to fix all ten at once. A sequence that holds up for most enterprise teams:
- Know every agent and its identity. You can't secure what you can't see, and an inventory of agents and their credentials closes a good chunk of ASI03 by itself.
- Minimize permissions and tool access. Scope each agent to only what its specific task requires. This blunts ASI01, ASI02, and ASI05 at the same time.
- Separate trusted instructions from untrusted context. Retrieved documents, emails, and web content should never carry the same authority as a signed system prompt. This is where ASI06 and most of the ASI01 hijack path get addressed.
- Put guardrails around high-impact actions. Require human sign-off, or at minimum a policy check, before anything destructive, irreversible, or financially significant executes.
- Monitor behavior continuously. Every fix above only works if you can see when an agent's behavior stops matching what it was built to do, which is what actually catches ASI08 and ASI10 in practice.
Notice how identity sits at the top of that list, not as an afterthought. It’s the one control that touches the most entries on OWASP’s Top 10, and it’s also where detection technology tends to earn its keep.
How Do You Detect an Agentic AI Attack?
OWASP’s guidance is mostly architectural, and that’s the right place to start: identity controls, policy engines, and sandboxing come before anything else. But OWASP identifies the risk. It doesn’t (and can’t) promise the risk never materializes. A few of these entries, ASI03, ASI08, and ASI10 in particular, ultimately come down to catching attack behavior once it starts, regardless of what triggered it.
That’s the layer we build for. OWASP identifies identity and privilege abuse (ASI03) as a core agentic risk. What typically follows a compromised agent credential or a hijacked delegation chain is an attacker moving through Active Directory itself, running reconnaissance, attempting Kerberoasting, or issuing DCSync-style replication requests to harvest credentials at scale. Our Active Directory Intercept™ module is built to spot exactly that kind of activity, not the AI agent’s decision-making, but the identity and privilege abuse that shows up in AD once something has already gone wrong.
Our deception technology plays a similar role for ASI08 and ASI10. It places convincing decoys and breadcrumbs directly in the paths a compromised or rogue agent, or the human and malware behind it, would take next. There’s no legitimate reason for anything to touch those decoys, so an interaction is a high-confidence signal rather than noise. Both capabilities plug into Fidelis Elevate®, our XDR platform, giving security teams one place to see when an agent’s downstream behavior, or the credential it’s using, no longer matches what it was authorized to do.
Put simply: OWASP maps where the risk lives. We help catch what happens once someone tries to exploit it.
The Bottom Line
You can’t fully trust an autonomous agent, and OWASP’s Top 10 doesn’t ask you to. What it asks for is control over what an agent can reach and visibility into what it actually does, so that when one of these ten risks slips past your architecture, and eventually one will, you catch it before it becomes a headline.
AI-Accelerated Attacks Demand a New Defense: Detect, Divert, Deceive
- OT, IoT, and SCADA Decoys
- Cyber Terrain Mapping
- Attacker Friction Mechanisms
Frequently Asked Questions
What are the main security concerns related to AI according to OWASP?
OWASP splits this into two related lists. The LLM Top 10 covers model-level risks like prompt injection and sensitive information disclosure. The Agentic Top 10 covers what happens once that model can plan, use tools, and act on its own: goal hijacking, tool misuse, identity abuse, supply chain compromise, and rogue agent behavior among them.
What are the latest updates from OWASP on AI security?
The Top 10 for Agentic Applications 2026 came out December 9, 2025. The GenAI LLM Top 10 2026 followed on August 3, 2026, an edition OWASP describes as grounded in thousands of documented real-world incidents rather than expert opinion alone. OWASP also keeps a weekly-updated log of agentic exploits mapped to the Top 10 categories.
Can OWASP's guidelines help improve AI privacy in my organization?
To a real extent, yes, though privacy isn’t a separate checklist in OWASP’s framework. ASI06 (Memory & Context Poisoning) and ASI03 (Identity & Privilege Abuse) both cover how sensitive data leaks through unsegmented memory and over-broad credentials, and the recommended mitigations, encryption, memory segmentation, scoped access, line up closely with standard data privacy controls most compliance teams already know.
How does OWASP recommend protecting AI systems from cyber threats?
The pattern repeats across every entry: scope credentials tightly, require human approval for anything high-impact or irreversible, treat external input as untrusted by default, sandbox execution, and log continuously so unusual behavior is visible instead of silent. The underlying assumption is that some component will eventually be compromised, so the system should be built to contain that outcome rather than pretend it won’t happen.
How is this different from standard application security testing?
Static tools like SAST and SCA scan code and dependencies before deployment. They don’t see an agent’s live prompts, memory, tool calls, or messages to other agents while it’s running. That’s why the Agentic Top 10 leans so heavily on runtime monitoring and identity controls instead of pre-deployment review alone.
Citations:
