AI Agent Security Risks: OWASP's 17 Threat Categories

The security risks of an AI agent are not the security risks of a chatbot, and the list below is the published taxonomy of them we work from: OWASP's Agentic AI Threats and Mitigations v1.1, seventeen categories numbered T1 to T17. It is a separate document from the OWASP Top 10 for LLMs because the attack surface is different, and the difference is that an agent takes actions in the real world. Seventeen is the count in that edition, read in April 2026. It is not a ranking, and nothing on this page counts how often any of them happens.

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 published Agentic AI Threats and Mitigations v1.1 in response. Every T-number below is that edition, read in April 2026. OWASP revises the document, so check the current one before you carry a number from here into your own threat model.

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.

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

Tool and privilege abuse

Resource and availability

Identity and trust

Multi-agent and system risks

Supply chain and accountability

---

Which threats matter most for your deployment?

If you're running agents with production infrastructure access, these are the six we would start with. That is our reading of the list and not an order OWASP publishes:

T2 (Tool Misuse) is the one our own deny list is aimed at. An agent with legitimate access to a database can execute a legitimate query that was never supposed to run at scale. A layer between the agent and the tool reads that query before the runtime acts on it, which is the only point where a decision about it is still possible.

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. Our scanner reads the user message for instruction-like payloads and records what it finds. It is observe-only: a hit is logged, never blocked.

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 audit trail outside its reach, you are 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. Binding a key to one agent is what closes that here; an unbound key leaves the agent header self-asserted.

T11 (RCE) is the tail-risk scenario. An agent with code execution access should never be able to run arbitrary code. Our layer is a deny list, so it denies the patterns it knows and lets through what it does not recognise.

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. What exists here is requests per minute, per tenant and per agent, counted in each proxy instance's own memory.

What to do about it: the mitigation layer

That enforcement layer sits outside the agent process, intercepts each 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:

• Tool-call interception:reading the agent's requests before they execute
• AI agent proxy:the network component that sits between agent and LLM API
• AI agent policy enforcement:the decision engine that evaluates actions against defined rules

Detection after the fact is not the same control as a decision before the call.

---

OWASP wrote a separate document because the chatbot threat model does not cover tool access. If you are building governance controls, the decision has to sit before execution rather than after it.