The OWASP Agentic Top 10, Part 1: Five Risks That Live Below the Model

In early 2026, OWASP published the first version of its Top 10 for Agentic Applications, a companion to its widely adopted LLM Top 10 designed specifically for the risks introduced when AI models are given tools, memory, and the ability to act autonomously. It is the first serious attempt by a major security standards body to categorize what makes AI agents different from traditional software, and what it surfaces is worth attention from anyone running agents in production.

We broke the list into two parts. This is Part 1, covering ASI01 through ASI05. Part 2 covers ASI06 through ASI10.

The first thing that stands out when you read through the framework: most of the risks do not live inside the model. They live in the space between the model’s output and the systems it touches. That distinction matters because the tools most organizations deploy for AI security today, model-level guardrails, input/output filters, prompt shields, are positioned at the wrong layer to catch them.

ASI01: Agent Goal Hijack

OWASP describes Agent Goal Hijack as what happens when an attacker manipulates the inputs or context that reach an agent, causing it to pursue an objective other than the one it was given. The most common delivery mechanism is prompt injection: malicious instructions embedded in content the agent retrieves and processes as part of its normal operation.

The word “retrieval” is the key. Goal hijacking typically arrives not through a user prompt but through a tool response. A document the agent fetches from a knowledge base. A calendar event. A web page pulled during a research task. The model interprets the content, and if that content contains embedded instructions, the model may follow them.

OWASP’s 2025 research found that prompt injection into agentic pipelines was one of the most prevalent attack techniques observed across active AI deployments. The model processes the retrieved content faithfully; it has no way to distinguish data from instruction when the boundary between them is not enforced at the tool level.

Model-level defenses cannot reliably stop this. By the time the model sees the injected content, it has already been retrieved and formatted by a tool. The attack surface is in the execution layer, in what gets fetched and how it reaches the model.

ASI02: Rogue Agent Behavior

OWASP’s Rogue Agent category covers situations where an AI agent behaves in ways that deviate from its intended task, not because of an adversarial input but because of insufficient constraints on what it can do and how persistent its state can be.

The risk is not that a well-configured agent spontaneously misbehaves. It is that agents accumulate memory and state across sessions, and the mechanisms for constraining that persistence are often absent or underdefined. An agent with write access to a shared knowledge base, given a task in one session, can leave artifacts that influence another agent’s behavior in a subsequent session.

OWASP flags the specific concern of multi-agent systems where one agent’s outputs become another agent’s inputs, creating amplification paths for behavioral drift. Each hop in a chain without validation is a point where a deviation can compound.

This is an execution-layer problem in the same way that a misconfigured database trigger is not a query problem. The model made a reasonable decision given its input. The failure is in what the system permitted the model to do with that decision after the fact.

ASI03: Tool Misuse

ASI03 is, in OWASP’s framing, the risk that tools themselves become the harm vector. An agent authorized to call a set of tools may invoke them in sequences, combinations, or contexts that produce outcomes the system designers never intended, and the individual tool calls may each appear legitimate in isolation.

OWASP’s description points to the core issue: current tool authorization models are coarse. An agent is either allowed to call a tool or it is not. There is no standard mechanism for saying “this agent may call the send-email tool, but not to external addresses, and not more than three times per session, and not with attachments over a certain size.”

The attack does not require a malicious model. It requires a model reasoning about how to accomplish a goal using available tools, and arriving at a path that is technically permitted but semantically wrong. The enforcement gap is in the runtime, not the model’s intent.

We wrote about how tool call visibility is the piece missing from most observability stacks in our first post in this series. ASI03 is the precise risk that gap enables.

ASI04: Insecure Runtime Supply Chain

The model is not the only software that runs when an agent executes a task. There is a surrounding system: tool definitions, MCP server implementations, plugins, SDKs, retrieval pipelines. ASI04 addresses the security posture of that surrounding system.

A 2025 analysis of the Model Context Protocol ecosystem found multiple MCP server implementations with vulnerabilities that could allow tool poisoning, where a malicious or compromised server causes an agent to behave in ways not authorized by the user or operator. Tool definitions themselves can be manipulated: changing a tool’s description can alter how the model reasons about when and how to use it, without touching the model at all.

OWASP notes that most organizations applying AI agents to real workflows have no formal process for auditing third-party tool integrations. The implicit assumption is that if the model is trusted and the prompt is controlled, the output will be safe. ASI04 identifies that assumption as the missing piece: the runtime supply chain is an attack surface with its own integrity requirements, independent of the model.

ASI05: Privilege Misuse and Abuse

ASI05 is the most direct connection to credential security, and the risk most organizations are least prepared for. OWASP defines it as the failure mode where an agent’s permissions exceed what its assigned tasks require, and that excess becomes available to misuse.

In practice, this is nearly universal. Agents are credentialed at setup with whatever access seems plausible for the range of tasks they might perform. The credentials are static. They are not scoped to individual task types. They are not rotated between sessions. And when the agent executes, nobody tracks which credentials were used for which tool calls.

The consequence is not hypothetical. OWASP’s guidance explicitly references the need for per-task minimal privilege, session-scoped credentials, and audit trails at the execution layer. The same principles that apply to human IAM apply to agents: the blast radius of any single compromised session should be bounded by what that session was actually authorized to do.

Most organizations cannot currently produce an audit trail of which credentials an agent used in a given session. They could not answer, after the fact, whether a specific token was used outside its intended scope. That gap is what ASI05 is describing.

What ASI01 through ASI05 have in common

The pattern is consistent across all five. Each risk describes something that happens at the boundary between model output and real-world action: in the tools that are called, the credentials that authenticate those calls, the state that persists after a session ends, or the pipeline that routes data to and from the model.

Model-level security tools sit at a different boundary. They evaluate inputs before they reach the model, or outputs before they leave it. That is useful for a specific class of risk. But none of the five risks above are caught at the input-output boundary, because none of them originate there.

The practical consequence is that an organization can deploy a comprehensive model-level security stack, pass an AI red team evaluation, and still be exposed to every risk in ASI01 through ASI05, because those risks require visibility into what happens after the model decides what to do.

Part 2 covers ASI06 through ASI10: Memory and Context Manipulation, Cascading Hallucination, Uncontrolled Resource Consumption, Inadequate Consent and Transparency, and Repudiation and Non-Attribution. The pattern holds there too.

If you’re working through what execution-layer visibility looks like in practice, reach out to us at hello@omnodex.com.

---

Sources

• OWASP, “Top 10 for Agentic Applications 2026”, OWASP GenAI Security Project, 2026.
• Huang et al., “MCP Security Notification: Tool Poisoning Attacks”, arXiv preprint, April 2025.
• Anthropic, “Model Context Protocol: Specification and Ecosystem Overview”, 2025.
• OWASP, “LLM and Generative AI Security Center of Excellence Guide”, OWASP GenAI Security Project, 2025.