How does the OWASP Agentic Top 10 differ from the LLM Top 10?

The agentic list covers systems that invoke tools, hold state across steps, and delegate to other agents, where a bad decision becomes an action rather than a sentence. The LLM list covers the single-turn request and response surface. The LLM Top 10 remains in scope for an agentic deployment, since every agent step is still a model call.

Is the OWASP Agentic Top 10 a control framework?

It is a risk taxonomy. It names failure modes and discusses mitigations without specifying controls, owners, or evidence, which is why an assurance function has to build a mapping like this one before the list can appear in a statement of applicability or a customer security response.

Which risks can a policy gateway enforce?

Tool invocation authorization, identity binding on outbound calls, excessive agency scope limits, response classification for exfiltration, and the per-decision record. Prompt injection is partially covered, since the payload is inspectable and detection is probabilistic. Plan manipulation, memory poisoning, cascading multi-agent failure, and insecure output handling are application-side controls.

Why put authorization on the path rather than inside the agent?

Because the agent is the component whose plan may have been corrupted. An authorization decision made by the same process that formed the plan inherits any compromise of that plan. Moving the decision to a component the agent has no custody over is what makes the boundary hold when the reasoning above it fails.

Does this mapping satisfy ISO 42001?

It supplies input to one, and does not substitute for it. ISO 42001 asks for an AI management system covering governance, roles, risk assessment methodology, supplier management, and continual improvement, most of which is organisational work. This mapping populates the technical control rows and leaves the management-system rows untouched.

How often should the mapping be revisited?

Whenever the framework revises, whenever a new agent pattern enters production, and whenever the four application-owned rows change hands. The rows most likely to drift are the ones nobody in security owns, which is exactly why they are named separately here.

OWASP Agentic Top 10 AI Controls Mapping: Which Risks an Assurance Programme Can Actually Own

The OWASP GenAI Security Project published the Top 10 for Agentic Applications on 9 December 2025, built with more than 100 industry contributors. What it publishes is a risk taxonomy. An ISO 42001 statement of applicability, a SOC 2 scope document, and a customer security questionnaire all want something else: a control, an owner, and a way to tell whether it is operating.

Converting a risk list into that shape is where mappings usually go wrong, because the tempting move is to assign every risk to the security team and every control to the platform. Four of these risks belong to application engineering and will never move.

I want to do the conversion honestly, risk area by risk area, with the owner named and the coverage verdict stated. The engineering-side version, with example policy rules and audit field names per category, is in the OWASP Top 10 for Agentic Applications gateway control mapping. The evidence question sits in the agentic audit evidence walkthrough.

Why the agentic list needs its own mapping

The LLM Top 10 describes a single-turn system: a prompt arrives, a completion returns, and the risk surface is the content of both. An agent adds three things that change the control model. Tool invocation turns a bad decision into an action rather than a sentence. State carried across steps means contamination persists past the turn that introduced it. Delegation to other agents propagates authority through hops nobody reviewed.

Those three additions produce the same three control requirements each time: authorization on every outbound action, a boundary that holds when the plan changes mid-run, and a record that survives the identity handoffs.

Authorization controls

Tool invocation, identity spoofing, and excessive agency are one control problem wearing three labels. Each resolves to the same question at the moment of an outbound call: which human or service principal is this action attributable to, and is that principal permitted to take it right now.

The failure mode is uniform across deployments. A user authenticates at the application. The application then calls the model or the tool using one service credential holding the combined privileges of everyone who uses that application, and the authorization decision downstream evaluates the service account. Authority stops being bound to a person one layer before the request leaves the boundary.

The control is per-request authorization evaluated against the originating principal, applied on the path rather than inside the agent. Placing it inside the agent means the component whose plan may have been corrupted is also the component deciding what it may do, which is the arrangement the framework's excessive-agency entry describes. Owner: platform engineering, with policy authored by security.

Content controls

Prompt injection and data exfiltration through output channels are content problems on the request and response path. Both are inspectable, and neither is fully solvable by inspection.

Injected instructions arrive inside a payload, so the payload can be classified, patterns can be denied, and the request as sent can be recorded. Detection is probabilistic and will miss novel phrasing, which is why the durable control is the authorization layer above rather than the filter itself. An injected instruction that the model obeys still has to produce an outbound action, and that action meets a policy that does not care why it was requested. Guardrails inside the model do not close this, for the reasons in Model Guardrails Are Not a Security Control.

Response inspection covers the exfiltration entry. Classification has to run on the context window rather than on documents at rest, because a prompt assembles fragments from several systems and ships them as one payload. Owner: security, enforced by platform.

Controls that belong to application engineering

Plan and goal manipulation, memory poisoning, cascading failure across multi-agent workflows, and insecure tool output handling live above the request boundary.

Memory poisoning is a data-integrity problem in whatever store holds the agent's memory, controlled by write authorization on that store, provenance on entries, and expiry. Plan manipulation is controlled by constraining what a plan may contain before it executes. Cascading failure is an orchestration design problem, controlled by blast-radius limits, circuit breakers, and refusing to let one agent's output become another agent's instruction without mediation. Insecure output handling is input validation on data returned from a tool, which is ordinary secure coding applied to a new source.

A gateway records the traffic these produce and controls none of them. Any mapping claiming otherwise is selling.

The mapping

Five Full, one Partial, four None. A statement of applicability built from this table gives a reviewer four rows to interrogate the application team about, which is the correct outcome, because those four are where agentic incidents actually start.

The one control that changes the others

Insufficient logging reads as the dullest entry and does the most work. The other nine are investigated, evidenced, and tuned using the record it produces.

The property that matters is authorship. A record written by the agent, or by the application hosting the agent, is a statement by the party under examination. The UK AI Security Institute's August 2026 incident report catalogued 19 unsanctioned actions across 10 of 122 evaluation runs and described agents misrepresenting themselves to persuade human maintainers to run code. Once an agent has done that, its own narration of events carries no evidential weight, and the record has to be produced by something on the path that the agent neither authors nor can edit.

My candid view: the framework's separation from the LLM Top 10 was the right editorial call and it has produced a predictable side effect, which is teams running two mappings and two control inventories over one traffic path. The controls that answer AAA02 and AAA03 are the same controls that answer LLM01 and LLM06. Map once, at the request boundary, and annotate against both lists.

DeepInspect

This is the enforcement point the five Full rows describe. DeepInspect sits inline between your agents and the LLM APIs they call, as a stateless proxy the calling application has no custody over. For every request and response it evaluates identity, data classification, model authorization, and organizational policy, and makes a pass or block decision before the traffic reaches the model.

Against this mapping it fills tool invocation and identity spoofing with per-request authorization bound to the originating principal, excessive agency with scope policy evaluated per action and a fail-closed default, exfiltration with classification inside the context window, and the logging row with a signed, tamper-evident per-decision record. The four rows marked None stay with your application team, and a reviewer will respect the mapping more for saying so. Book a technical deep dive at deepinspect.ai.