Key takeaways
- The document is published by the OWASP Agentic Security Initiative (ASI), sitting under the broader OWASP Top 10 for LLM Apps & Gen AI project.
- An ordinary LLM application answers a prompt and stops.
- OWASP is explicit that agentic threats are "either new or agentic variations of existing threats," and the document repeatedly names which 2025-edition LLM Top 10 risk each threat extends.
- OWASP's own document names a concrete, real incident as its example of T17 Supply Chain Compromise: the Amazon Q Developer extension for Visual Studio Code.
Agentic AI — AI systems built on large language models that plan their own steps, retain memory across turns, and call tools or other agents to get a task done — carries a documented set of security risks that go beyond a normal chatbot. OWASP's Agentic Security Initiative (ASI) names and structures these in Agentic AI – Threats and Mitigations, a reference document now at version 1.1 (December 2025) that defines 17 named threats (T1–T17), from memory poisoning and tool misuse to insecure agent-to-agent protocols and supply-chain compromise, each with a stated mitigation. This guide walks through that taxonomy, how it relates to the existing OWASP Top 10 for LLM Applications, and a real, independently verified incident that maps directly onto one of its 17 threats.
What is OWASP's Agentic AI Threats and Mitigations framework?
The document is published by the OWASP Agentic Security Initiative (ASI), sitting under the broader OWASP Top 10 for LLM Apps & Gen AI project. Its own introduction states it is "the first in a series of guides from the OWASP Agentic Security Initiative (ASI) to provide a threat-model-based reference of emerging agentic threats and discuss mitigations." It covers five things, per its own table of contents: a reference architecture for single- and multi-agent systems; a reference threat model explaining why agentic systems introduce new risk; a detailed, numbered Threat Model of 17 threats; a decision-path Taxonomy Navigator that routes a system through only the threats relevant to its actual capabilities; and example threat models for four real-world-style scenarios. It deliberately does not re-cover ground already owned by other OWASP guides — general LLM risks stay in the OWASP Top 10 for LLM Applications, and the document repeatedly cross-references that list, MITRE ATLAS, and NIST's adversarial machine-learning taxonomy for threats agentic AI inherits rather than introduces.
What makes an AI agent's risk different from a regular LLM app's?
An ordinary LLM application answers a prompt and stops. An agent, per the document's own framing, is built to "perceive its environment, reason about it, make decisions, and take actions to achieve specific objectives autonomously" — it plans multi-step work, keeps short- or long-term memory between steps or sessions, and invokes tools (APIs, code execution, other agents) to act on the world, not just describe it. Each of those three capabilities — autonomous planning, persistent memory, and tool/agent delegation — is also exactly where OWASP's taxonomy concentrates its 17 threats: planning and reasoning create an attack surface for goal manipulation and deceptive behavior; memory creates an attack surface for poisoning; and tool use and inter-agent delegation create an attack surface for misuse, privilege compromise, insecure protocols and supply-chain compromise that a stateless, non-acting chatbot simply does not have.
The 17 threats: OWASP's Agentic AI Threat Model
OWASP's own Detailed Threat Model table defines all 17, each with a stated mitigation:
| ID | Threat | What it is (OWASP's own wording, condensed) |
|---|---|---|
| T1 | Memory Poisoning | Exploiting short- or long-term agent memory to inject false data and alter future decisions |
| T2 | Tool Misuse | Manipulating an agent into abusing its own authorized tools through deceptive prompts or commands |
| T3 | Privilege Compromise | Exploiting weak permission management or dynamic role inheritance to perform unauthorized actions |
| T4 | Resource Overload | Exhausting an agent's compute, memory or service capacity to degrade or break it |
| T5 | Cascading Hallucination Attacks | False information that an agent reinforces through memory, tools or multi-agent exchange, amplifying across steps |
| T6 | Intent Breaking & Goal Manipulation | Attacking an agent's planning and self-evaluation to redirect its objectives and reasoning |
| T7 | Misaligned & Deceptive Behaviors | An agent executes disallowed actions via deceptive reasoning rather than a single prompt failure |
| T8 | Repudiation & Untraceability | Agent actions that cannot be traced or attributed due to weak logging and transparency |
| T9 | Identity Spoofing & Impersonation / Agent Identity Compromise | Impersonating an agent or user, including theft of a persistent agent identity (e.g. a formal agent ID) |
| T10 | Overwhelming Human in the Loop | Exploiting human oversight dependencies with excessive intervention requests and decision fatigue |
| T11 | Unexpected RCE and Code Attacks | Exploiting AI-generated code execution to inject malicious code or run unauthorized scripts |
| T12 | Agent Communication Poisoning | Manipulating inter-agent communication channels to spread false information or disrupt workflows |
| T13 | Rogue Agents in Multi-Agent Systems | A compromised agent operating outside monitoring boundaries, including spreading "infectious" logic to peers |
| T14 | Human Attacks on Multi-Agent Systems | Exploiting inter-agent delegation and trust relationships to escalate privileges |
| T15 | Human Manipulation | Attackers use the implicit trust a human places in an agent to coerce the human into harmful actions |
| T16 | Insecure Inter-Agent Protocol Abuse | Abusing protocols like MCP or A2A — consent bypass, context hijacking — for unauthorized agent actions |
| T17 | Supply Chain Compromise | A compromised component (model, library, tool, build pipeline) lets an attacker manipulate agent behavior |
OWASP's stated mitigations follow a consistent pattern across all 17: validate and sanitize anything that becomes agent input (memory, tool output, inter-agent messages); scope permissions as narrowly as the task allows and never let them inherit implicitly; log and sign agent actions so they are attributable; and — where feasible — have a second model or human check for drift from the agent's intended goal.
How does this map onto the OWASP Top 10 for LLM Applications?
OWASP is explicit that agentic threats are "either new or agentic variations of existing threats," and the document repeatedly names which 2025-edition LLM Top 10 risk each threat extends. T2 Tool Misuse and T3 Privilege Compromise are framed as agentic expansions of LLM06:2025 Excessive Agency; T1 Memory Poisoning extends LLM04:2025 Data and Model Poisoning into real-time, persistent agent memory, with a secondary tie to LLM08:2025 Vector and Embedding Weaknesses for agents backed by a vector database; T5 Cascading Hallucination Attacks extends LLM09:2025 Misinformation into multi-step and multi-agent propagation; T11 Unexpected RCE and Code Attacks sits beyond LLM01:2025 Prompt Injection and LLM05:2025 Improper Output Handling once an agent can actually execute generated code; and T17 Supply Chain Compromise is a direct, agent-amplified continuation of LLM03:2025 Supply Chain. None of these 17 threats replace the LLM Top 10 — see our OWASP Top 10 for LLM Applications guide — they describe what those same risk classes look like once a system gains memory, autonomy and tool access.
A verified real-world case: the Amazon Q supply-chain compromise
OWASP's own document names a concrete, real incident as its example of T17 Supply Chain Compromise: the Amazon Q Developer extension for Visual Studio Code. In July 2025, a threat actor exploited an improperly scoped GitHub token in Amazon's own CodeBuild configuration to commit malicious code into the extension's open-source repository; that code shipped in the published v1.84.0 release. AWS's own security bulletin (AWS-2025-015) states the injected code "was unsuccessful in executing due to a syntax error," so no customer environment was actually altered; Amazon revoked the compromised credentials, pulled v1.84.0 from distribution, and shipped a fixed v1.85.0. The tracked record, CVE-2025-8217, confirms the same facts independently: NVD describes the flaw as "inert, injected code designed to call the Q Developer CLI" and rates it CVSS v3.1 4.0 (Medium). The reason this counts as agentic-specific, rather than an ordinary dependency-poisoning story: the injected payload was itself an agent prompt, instructing the coding agent to wipe local and cloud resources — a form of attack with no equivalent in a non-agentic tool, because a non-agentic tool has no autonomous executor to receive that instruction.
Where do MCP and A2A fit in?
OWASP's T16, Insecure Inter-Agent Protocol Abuse, is specifically about the two protocols that have emerged to let agents share tools and delegate tasks to each other: the Model Context Protocol (MCP) and Agent2Agent (A2A). The document's own description: "as protocols like MCP ... and A2A ... gain adoption to enable agent collaboration, tool sharing, and delegation of tasks, they introduce a new attack surface rooted in inter-agent communication and coordination," naming consent-flow manipulation and context hijacking via injected server responses as concrete scenarios. We cover MCP's own documented attack classes — confused deputy, token passthrough, SSRF — in detail in our MCP server security guide; OWASP's T16 mitigation adds enforcing strong authentication between agents, sanitizing every protocol-level payload, restricting delegation to tightly scoped functions, logging every inter-agent call, and encrypting the channel to prevent adversary-in-the-middle interception.
How should a firmware or IoT team start applying this?
Agentic capability is moving into embedded products, too — a gateway or NVR that runs an on-device or cloud-connected agent to triage alerts, or a diagnostic assistant that can call vendor APIs on a technician's behalf, inherits this same threat set. OWASP's own Agentic Threat Decision Path is the practical starting point: before applying any of the 17 mitigations, ask which capabilities the device's agent actually has. Does it plan its own multi-step actions? Does it keep memory across sessions? Can it invoke tools, run code, or call another agent or service? Does it authenticate itself or a user? Does a human review its output before it acts? A constrained, single-shot agent with no persistent memory and no tool access has no real exposure to T1 Memory Poisoning or T2 Tool Misuse — the decision path exists precisely so a device team does not have to defend against all 17 threats uniformly, only the ones its own architecture actually creates. SoftWSP's device and firmware assessments can factor an embedded agentic AI feature into the same review as conventional firmware and application risk: see device firmware security.
This guide summarises OWASP Agentic Security Initiative publications (Agentic AI – Threats and Mitigations, version 1.1, December 2025, and the OWASP Top 10 for LLM Applications 2025 edition), AWS's own security bulletin AWS-2025-015, and NVD's CVE-2025-8217 record, as read and checked on 5 November 2026; it does not constitute security advice.
Sources
Frequently asked questions
What is OWASP's Agentic AI Threats and Mitigations document, and who publishes it?
It is a reference document from the OWASP Agentic Security Initiative (ASI), part of the OWASP Top 10 for LLM Apps & Gen AI project. The copy reviewed for this guide is marked "Version 1.1, December 2025" on its own title page. OWASP's own introduction describes it as "the first in a series of guides from the OWASP Agentic Security Initiative (ASI) to provide a threat-model-based reference of emerging agentic threats and discuss mitigations," built around a reference architecture, a 17-item threat taxonomy, a decision-path navigator, mitigation playbooks and four example threat models. It is licensed under Creative Commons CC BY-SA 4.0.
What are the 17 threats in OWASP's agentic AI threat model?
Numbered T1 through T17 in the document's own Detailed Threat Model table: T1 Memory Poisoning, T2 Tool Misuse, T3 Privilege Compromise, T4 Resource Overload, T5 Cascading Hallucination Attacks, T6 Intent Breaking & Goal Manipulation, T7 Misaligned & Deceptive Behaviors, T8 Repudiation & Untraceability, T9 Identity Spoofing & Impersonation / Agent Identity Compromise, T10 Overwhelming Human in the Loop, T11 Unexpected RCE and Code Attacks, T12 Agent Communication Poisoning, T13 Rogue Agents in Multi-Agent Systems, T14 Human Attacks on Multi-Agent Systems, T15 Human Manipulation, T16 Insecure Inter-Agent Protocol Abuse, and T17 Supply Chain Compromise. The full table with descriptions and mitigations is below.
How is "tool misuse" different from "excessive agency" in the OWASP Top 10 for LLM Applications?
OWASP's agentic document treats Tool Misuse (T2) as a more specific, agent-era expansion of LLM06:2025 Excessive Agency from the OWASP Top 10 for LLM Applications and Generative AI (2025 edition). Per the document's own text: "the threat is partially covered by LLM06:2025 Excessive Agency. However, Agentic AI systems introduce unique risks with their dynamic integrations, increased reliance on tools, and enhanced autonomy. Unlike traditional LLM applications which constraint tools integration within a session, agents maintain memory adding to increased autonomy and can delegate execution to other agents." In short: excessive agency is the general LLM-era risk of granting too much unchecked capability; tool misuse is what that risk looks like once an agent has persistent memory, can chain multiple tools across sessions, and can hand off execution to other agents.
What happened in the Amazon Q Developer supply-chain incident, and which agentic threat does it illustrate?
In July 2025, a threat actor used an improperly scoped GitHub token to commit malicious code into the Amazon Q Developer extension for Visual Studio Code's open-source repository; the tampered code shipped in the published v1.84.0 release. Per AWS's own security bulletin (AWS-2025-015), the injected code was "unsuccessful in executing due to a syntax error," so no customer resources were altered; AWS revoked the compromised credentials, pulled v1.84.0, and released a fixed v1.85.0. NVD's own record for the tracked vulnerability, CVE-2025-8217, describes it as "inert, injected code designed to call the Q Developer CLI" with a CVSS v3.1 base score of 4.0 (Medium). OWASP's own document cites this exact incident as its real-world example of T17 Supply Chain Compromise, where "adversaries compromise upstream components such as agent prompts, plugins, or framework updates, allowing malicious logic to spread through trusted software."
Do the Model Context Protocol (MCP) and Agent2Agent (A2A) protocol introduce new agentic AI risks?
Yes — OWASP names this directly as T16, Insecure Inter-Agent Protocol Abuse: "as protocols like MCP (Model Context Protocol) and A2A (Agent-to-Agent) gain adoption to enable agent collaboration, tool sharing, and delegation of tasks, they introduce a new attack surface rooted in inter-agent communication and coordination," including consent-flow manipulation and context hijacking via injected server responses. Our dedicated [MCP server security guide](/guides/mcp-server-security/) covers the protocol's own documented attack classes (confused deputy, token passthrough, SSRF) in depth; OWASP's mitigation for T16 adds enforcing strong inter-agent authentication, sanitizing protocol-level data and context payloads, restricting delegation to tightly scoped functions, and logging every inter-agent call.
What is the single most useful first step for a team adopting agentic AI?
Match the mitigation to where the agent actually has autonomy, rather than applying every one of the 17 mitigations uniformly. OWASP's own Agentic Threat Decision Path walks this in order: first ask whether the agent independently plans its own steps (threats rooted in reasoning: intent breaking, deceptive behavior); then whether it keeps memory across turns or sessions (memory poisoning, cascading hallucinations); then whether it executes tools, code or external calls (tool misuse, privilege compromise, resource overload, RCE, protocol abuse, supply chain); then whether it relies on authentication (identity spoofing); then whether it depends on human oversight (overwhelmed human-in-the-loop, human manipulation). A system with no persistent memory and no tool access, for example, has no meaningful exposure to T1 Memory Poisoning or T2 Tool Misuse at all — the decision path is designed to stop teams from treating a 17-item checklist as a flat, one-size-fits-all audit.
In this cluster
Questions about this page?