The OWASP Agentic Top 10, scored against a policy engine

The OWASP GenAI Security Project published its Top 10 for Agentic Applications on 9 December 2025, developed with hundreds of contributors and reviewed by national cybersecurity agencies, standards bodies, and enterprises. It exists because autonomous systems break assumptions that both traditional appsec and the earlier LLM top 10 were built on. Once software started taking actions on its own authority, the shape of the problem changed.

What follows is a scorecard, not a summary. For each entry: what it is, and what a policy engine evaluating every tool call, spawn, delegation, plan, and budget event actually does about it. Three verdicts are used — Enforced means the mechanism directly prevents the risk class, Partial means it bounds the damage without preventing the cause, and Out of scope means it does not address the entry at all.

Six of ten land on "partial." That is the honest number, and a vendor claiming ten out of ten is telling you they haven't read their own threat model.

The scorecard

ASI01 — Agent Goal Hijack

Partial Attackers alter an agent's objectives through content it cannot reliably distinguish from legitimate instruction. OWASP puts this first for good reason: it is the entry point for most of the rest.

A policy engine cannot prevent the hijack. That is a model property, and nothing sitting below the model changes it. What it changes is the consequence: the hijacked agent's plan is evaluated whole before step one runs, and every tool call it subsequently attempts is checked against the session's scopes. The goal is captured; the actions are not. That distinction is the entire argument for this layer, and it is a genuinely partial answer — an agent hijacked into doing something it was already permitted to do proceeds untouched.

ASI02 — Tool Misuse

Enforced Agents employing legitimate tools unsafely — destructive parameters, unexpected tool chains, ambiguous prompts producing damaging calls. This is the entry a policy decision point was designed for.

The tool_call event carries the tool name and its arguments, and both are available to the policy. That argument-level view is what separates this from a permission list: an agent may be allowed to call issue_refund and still be denied issue_refund(amount=50000). The shipped security.rego hard-denies sensitive file extensions, system paths, and path traversal, and those denials carry a SECURITY_CRITICAL tier that cannot be escalated to a human for override.

ASI03 — Identity & Privilege Abuse

Enforced Agents inherit user or system identities, often carrying high-privilege credentials, session tokens, and delegated access — and then act with more authority than the task required.

Three mechanisms cover this. Sessions carry explicit scopes rather than ambient credentials. The credential broker issues short-lived, task-scoped credentials instead of handing the agent a long-lived key. And agent_lifecycle.rego enforces that a child agent's requested capabilities are a strict subset of the parent's, so privilege cannot be manufactured one delegation hop at a time.

The qualifier that belongs on this verdict: it holds within the agent boundary. A policy engine does not issue your IAM identities, replace your service mesh, or stop a human from putting a production admin token in an environment variable.

ASI04 — Agentic Supply Chain Vulnerabilities

Partial Compromised tools, plugins, or MCP servers fetched at runtime altering agent behaviour or exposing data. This is the entry most likely to be overclaimed, so it's worth being blunt.

Allowlisting which tools an agent may call genuinely reduces the reach of a compromised server: if a poisoned MCP server exposes forty-seven tools and your policy permits three, the other forty-four are unreachable regardless of what their descriptions say. That is real, and it is meaningfully better than trusting a server wholesale.

But it detects nothing. In February 2026 a trojanized Oura Ring MCP server was submitted to a legitimate registry, functionally identical to the real one, carrying an infostealer. An allowlist naming that tool passes it through unchanged. Signing, pinning, provenance, and registry hygiene live upstream of any runtime gate, and no amount of policy enforcement substitutes for them.

ASI05 — Unexpected Code Execution

Enforced Agents generating or running code unsafely — shell commands, scripts, evaluated expressions without validation.

security.rego hard-denies unsandboxed code execution, and agent_plan.rego blocks any plan containing execute_shell, run_command, drop_database, or delete_all — evaluated before the plan's first step runs, so a safe-looking prefix never gets to execute.

The boundary worth stating: this governs code execution that goes through the gate. A tool that shells out internally presents as one permitted tool call, and what happens inside it is invisible. The gate is at the tool boundary, not inside your tool implementations.

ASI06 — Memory & Context Poisoning

Partial Compromised memory systems and RAG databases influencing future agent decisions — the MINJA pattern, where a malicious write surfaces turns later as if the agent had reasoned it itself.

Governed memory carries provenance: every entry is permanently tagged with the trust tier and source it came from, so tool-derived text stays marked UNTRUSTED and is never treated as a trusted instruction. The mechanism is covered in detail here.

Partial rather than enforced for two reasons. Sanitization on write is best-effort pattern matching that a determined attacker phrases around — provenance is the durable control, not the scrubbing. And a RAG index poisoned upstream, outside the governed memory path, is simply not something this layer sees.

ASI07 — Insecure Inter-Agent Communication

Partial Multi-agent message exchanges lacking authentication, encryption, or semantic validation.

Of those three, policy enforcement supplies exactly one: semantic validation. The agent.delegate and agent.spawn events gate the handoff itself, checking that what's being passed is within what the parent held. Most agent frameworks treat a handoff as an internal function call with no checkpoint at all, so this is a real gap being closed.

Authentication and encryption between agent processes it does not provide. That is mTLS, a service mesh, or your existing transport security — and if your agents talk over an unauthenticated channel, a semantic check on the payload is not the control you're missing.

ASI08 — Cascading Failures

Partial A small error in one agent propagating across planning, execution, memory, and downstream systems.

Three ceilings bound the propagation: delegation depth is capped, multi-step plans are capped at a step count, and per-session budgets on tokens, calls, and cost halt a runaway loop at the infrastructure layer regardless of what the model wants to do next. A cascade that would have run for an hour stops when the budget does.

Bounding is not detecting. Nothing here notices that an agent's output has become subtly wrong and is being consumed downstream as if correct. Ceilings limit how far a failure travels; they don't tell you it happened. That's observability and evaluation work, on the other side of the line from enforcement.

ASI09 — Human-Agent Trust Exploitation

Out of scope Users over-trusting agent recommendations, letting attackers influence decisions or extract information through the human rather than the machine.

This is the entry where the honest answer is uncomfortable. Policy enforcement addresses none of it — and because routing high-risk actions to a human reviewer is a core part of how this layer works, it increases how much weight ASI09 has to carry. Every action escalated to an approval queue is an action whose safety now depends on a person reading a justification written, directly or indirectly, by a system that may be compromised.

What can be done is narrow but not nothing: give the reviewer the raw event, the actual arguments, the session's history, the policy version that escalated it, and the risk tier — enough context to disagree with the agent's framing. An approval queue that shows a summary and two buttons is a rubber stamp with extra latency. But that is interface design mitigating a human factor, not enforcement, and it should not be scored as coverage.

ASI10 — Rogue Agents

Partial Compromised or misaligned agents acting harmfully while appearing legitimate — persisting, and sometimes impersonating trusted agents. OWASP describes this as the ultimate insider threat: authorized, trusted, misaligned.

Deny-by-default is the structural answer to the "authorized" half. A rogue agent still cannot exceed its session scopes, still cannot grant a child more than it holds, still cannot exceed its budget — and every attempt lands in an immutable audit record with the policy version that decided it. When you do discover a rogue agent, that log is what tells you what it managed to do.

The "misaligned" half is untouched. Detecting behavioural drift — an agent doing permitted things for the wrong reasons — is a monitoring and evaluation problem. Enforcement makes the blast radius finite and the history reconstructable. It does not raise its hand.

What the scorecard says

Three of ten fully addressed is not a weak result for a single layer, and it isn't meant to read as one. The entries in the enforced column — tool misuse, privilege abuse, unexpected code execution — are the ones where damage is immediate and irreversible, and they're where deterministic pre-execution checks fit best.

The pattern in the partial column is consistent enough to be worth naming: enforcement bounds blast radius, it does not detect causes. It stops a cascade from running forever without noticing the error that started it. It stops a compromised MCP server from reaching tools you didn't allow without noticing the server is compromised. Anywhere the risk is "something bad is happening and no one knows," this is the wrong layer, and you want observability, evaluation, and drift detection instead.

And ASI09 is a reminder that a control can shift risk rather than remove it. Moving a decision to a human is a real mitigation for some failures and a new attack surface for others. Both things are true, and a scorecard that only counted the first would be marketing.

Frequently asked questions