OWASP April 11, 2026 · 8 min read

OWASP's 17 Agentic AI Threats — What They Mean for Your Security Team

J

Jay Cabello

Founder, Intercis · Security engineer

OWASP published the Agentic AI Threats taxonomy (T1–T17) because the chatbot threat model doesn't apply to agents with tool access. This isn't a rehash of the OWASP Top 10 for LLMs. It's a separate document addressing a fundamentally different attack surface: agents that can take actions in the real world.

Why a separate taxonomy?

Chatbots receive input and produce text. Agents receive input, reason, and execute tool calls — API calls, file writes, shell commands. The risk model is different because agents have agency. OWASP recognized this gap and published Agentic AI Threats and Mitigations v1.1.

When a chatbot generates a false claim, the damage is contained to whatever the user does with that text. When an agent with filesystem access reasons that it should delete "stale artefacts," the damage happens at the moment the tool call executes. There's no user approval step in between. The agent is operating on your infrastructure in real time.

That's why the threat model is separate. And why a security team protecting production agents can't rely on the same controls that protect a customer-facing chatbot.

The 17 threats, grouped by category

Agent manipulation threats

T1: Memory Poisoning — An attacker modifies the agent's memory store, causing it to operate with false context and make decisions based on lies.
T5: Cascading Hallucination — The agent generates a false belief, uses it to make a decision, and that decision cascades into further hallucinations and actions based on the original lie.
T6: Intent Breaking (Prompt Injection) — An attacker embeds instructions in tool outputs or external data that override the agent's original goal.
T7: Misaligned & Deceptive Behaviors — The agent's objectives drift from what the operator intended, or the agent actively deceives to achieve its goals.

Tool and privilege abuse

T2: Tool Misuse — The agent uses a tool in a way that was technically allowed but operationally harmful (e.g., delete queries that were never meant to run).
T3: Privilege Compromise — The agent's credentials or API keys are exposed or compromised, allowing an attacker to impersonate the agent.
T11: Unexpected RCE & Code Attacks — The agent executes code or shell commands that an attacker embedded, or the agent generates code that contains vulnerabilities when executed.

Resource and availability

T4: Resource Overload — The agent makes excessive API calls, consumes unbounded compute, or drives up infrastructure costs through uncontrolled tool usage.
T10: Overwhelming HITL (Human-in-the-Loop) — The agent generates so many escalations or requests for human approval that the review process breaks down.

Identity and trust

T9: Identity Spoofing & Impersonation — The agent or an attacker impersonates a legitimate user or service, causing downstream systems to trust malicious actions.
T15: Human Manipulation — The agent or an attacker uses social engineering or persuasion to convince a human to approve a harmful action.

Multi-agent and system risks

T12: Communication Poisoning — An attacker corrupts or intercepts messages between multiple agents, causing them to make decisions based on false information.
T13: Rogue Agents — An unauthorized or compromised agent begins operating in a system where it shouldn't have access or authority.
T14: Human Attacks on Multi-Agent Systems — A human operator of one agent attacks or manipulates another agent in a multi-agent deployment.
T16: Protocol Abuse — The agent exploits weaknesses in the protocols or standards it uses to communicate with other systems.

Supply chain and accountability

T8: Repudiation & Untraceability — The agent's actions cannot be reliably traced back to a specific decision or audit log, making accountability and forensics impossible.
T17: Supply Chain Compromise — A dependency, framework, or service the agent relies on is compromised, and the agent inherits the vulnerability.

Which threats matter most for your deployment?

If you're running agents with production infrastructure access, six threats are highest priority:

T2 (Tool Misuse) is the threat that actually happens. An agent with legitimate access to a database can execute a legitimate query that was never supposed to run at scale. A governance layer between the agent and the tool can see the query, understand its scope, and block it before execution.

T6 (Intent Breaking) matters because prompt injection is real. If your agent reads data from external sources — files, APIs, user input — an attacker can embed instructions in that data. A proxy between the agent and the LLM API can detect and block instruction-like payloads in tool outputs before they influence the agent's reasoning.

T8 (Repudiation) is the auditor's question. If something goes wrong, can you prove what the agent did, when it did it, and what policy it was evaluated against? Without an immutable audit trail, you're relying on logs the agent process controls — which may be modified or deleted.

T9 (Identity Spoofing) matters in systems where the agent acts on behalf of a user or service. If the agent can assume a false identity, it can trigger actions that are authorized for that identity but not for the agent. A governance layer enforces identity context and scope.

T11 (RCE) is the tail-risk scenario. An agent with code execution access should never be able to run arbitrary code. A policy engine can whitelist specific code patterns or execution contexts, denying anything outside that scope.

T4 (Resource Overload) is often overlooked until you see the bill. An agent making thousands of API calls without rate limits can consume compute resources or cost you money in minutes. Governance means setting hard limits on tool usage per agent, per time window, per request.

What to do about it: the mitigation layer

OWASP provides six mitigation playbooks for the T1–T17 taxonomy. The key takeaway: you need an enforcement layer between your agent and the tools it calls. Input filtering alone doesn't cover tool misuse. Output filtering alone doesn't prevent privilege escalation. You need all six pillars working together.

That enforcement layer sits outside the agent process, intercepts every tool call before execution, evaluates it against a security policy, and makes a pre-execution decision to allow or deny. Internal glossary terms to understand this architecture:

If you're only monitoring and alerting after actions execute, you're not mitigating these threats. You're detecting them. There's a real difference, and your compliance team knows it.

The core question: Can a security team at your organization write, review, and enforce policies that govern what an agent is allowed to do before that agent runs? If not, the agent isn't governed — it's just monitored.

OWASP's Agentic AI Threats taxonomy is the security industry's way of saying: the threat model for an agent is not the same as the threat model for a chatbot. If you're building governance controls, you need to defend against agent-specific threats. And you need enforcement at the pre-execution layer, not the post-execution layer.

Ready to govern your agents?

Intercis provides pre-execution enforcement for agentic AI threats. We sit between your agent and the LLM API, intercept every tool call, evaluate it against your policies, and make the decision before anything executes.

Apply for early access
All posts