OWASP Agentic Top 10 mapped to required controls
The OWASP Agentic Top 10 names the threats. This piece maps each one to the controls that close it, the lifecycle gate where each control must be in place, and the evidence required to verify it — so your AI Committee has a working checklist, not just a threat list.
The OWASP Agentic Security Initiative published its Top 10 for agentic AI systems in early 2025. It is the most useful public reference for the specific threat class that traditional AppSec tools miss: agents that plan, delegate, call tools, retrieve from memory, and act in the world with varying degrees of autonomy.
The problem with a Top 10 list is that it names threats without telling you what to do about them. Security teams reading it know that A2 (Prompt Injection) is a problem. They do not know which controls close it, which controls must be in place before a pilot, and what evidence they need to show an auditor that the control is actually working.
This piece fills that gap. For each of the ten entries, we map the required controls, assign a lifecycle gate (before pilot / before production / ongoing), and specify the evidence required to verify the control. The full table is below. The sections before it explain the framework we used to build it.
Why the Agentic Top 10 is different from the LLM Top 10
The OWASP LLM Top 10 covers risks in LLM-backed applications: prompt injection, insecure output handling, training data poisoning, model denial of service, and so on. These are real and important. But they assume a relatively simple architecture: a user sends a prompt, the model responds, the application does something with the response.
Agentic systems break this assumption. An agent does not just respond — it plans, selects tools, calls them, receives results, updates its internal state, and continues. It may delegate to sub-agents. It may retrieve from a memory store that persists across sessions. It may call external APIs with real-world effects. The attack surface is not a single prompt-response pair; it is a graph of decisions, tool calls, and state transitions.
Agentic attack surface — where each OWASP A-number lives
Each layer is an independent attack surface. Controls must be applied at the layer where the threat originates, not only at the output.
The diagram above shows the five layers of the agentic attack surface. Each layer is independent: a control at the output layer does not protect against a memory poisoning attack at the memory layer. This is why the Agentic Top 10 requires a different control set from the LLM Top 10, and why controls must be applied at the layer where the threat originates.
The three lifecycle gates
We assign each control to one of three gates. The gate determines when the control must be in place — not when it should be planned, but when it must be verified.
- Before pilot — must be in place before the system is used by any real user, even in a restricted scope. These are the controls without which the pilot itself is unsafe.
- Before production — must be in place before the system serves its full intended user population. These controls are acceptable to defer during a tightly scoped pilot but not beyond it.
- Ongoing — must remain in place for as long as the system operates. These are operational controls: monitoring, auditing, rotation, periodic review.
Evidence is not the same as implementation
Every control in the table below has an evidence field. This is not optional. A control that is “implemented” without evidence is a claim. A control with evidence is a verifiable fact.
Evidence takes different forms depending on the control type:
- Architecture review — a documented review of the system design showing the control is present.
- Test result — an automated or manual test that demonstrates the control works under adversarial conditions.
- Log sample — a representative sample of log output showing the required fields are populated.
- Policy document — a written policy that governs the control, with a named owner and review date.
- Audit report — a periodic review showing the control was checked and found effective.
When a control's evidence is missing, the control is in the “missing evidence” state in Drel's evidence ledger. It does not count toward the disposition until the evidence is attached and verified.
Which threats require the most controls
Before the full table, a quick orientation: not all threats are equally expensive to close. A2 (Prompt Injection) requires the most controls because it can be exploited at every layer of the agentic stack. A8 (Repudiation) and A10 (Scope Creep) require fewer controls but are the most commonly skipped — they feel like operational hygiene rather than security, which is exactly why they end up in incident reports.
Required controls per threat — minimum viable control set
A2 (Prompt Injection) requires the most controls because it can be exploited at every layer. A8 and A10 require fewer controls but are the most commonly skipped.
The full control map
The table below covers all ten entries. Each row is one control. Controls are grouped by threat. The gate column uses colour coding: amber for before-pilot, red for before-production, grey for ongoing.
This is a minimum viable control set — the floor, not the ceiling. Systems with higher criticality, broader user populations, or access to sensitive data will require additional controls beyond what is listed here.
| ID | Threat | Required control | Gate | Evidence required |
|---|---|---|---|---|
| A1 | Memory Poisoning Attacker injects malicious content into the agent's memory store, causing persistent misbehaviour across sessions. | Memory write access restricted to trusted sources only | Before pilot | Access control policy + code review |
| Memory contents validated against schema before read-back | Before pilot | Schema validation test suite | ||
| Memory store isolated per user/session (no cross-session bleed) | Before pilot | Isolation test: session A cannot read session B | ||
| Memory contents logged with source attribution | Before production | Log sample showing source field populated | ||
| Periodic memory audit for anomalous content | Ongoing | Audit schedule + last-run report | ||
| A2 | Prompt Injection Malicious instructions embedded in user input, retrieved documents, or tool responses hijack the agent's goal. | System prompt and user input separated at the model gateway (not concatenated as one string) | Before pilot | Architecture review showing gateway separation |
| Retrieved documents treated as untrusted data, not as instructions | Before pilot | Prompt template review confirming data/instruction boundary | ||
| Tool responses validated before being passed back to the planner | Before pilot | Validation schema + test cases with adversarial tool responses | ||
| Output monitoring for instruction-following anomalies | Before production | Monitoring rule definitions + alert test | ||
| Red-team exercise covering indirect injection via retrieved docs | Before production | Red-team report with findings and mitigations | ||
| Ongoing adversarial prompt testing in staging | Ongoing | Test schedule + last-run results | ||
| A3 | Tool Misuse Agent invokes tools outside their intended scope, with unintended parameters, or in unintended sequences. | Tool manifest defines allowed parameter ranges and types; agent cannot call outside manifest | Before pilot | Tool manifest + enforcement test |
| Destructive or irreversible tool calls require explicit human approval | Before pilot | Approval boundary implementation + test | ||
| Tool call log captures full invocation (tool id, parameters, caller, timestamp) | Before pilot | Log sample with all fields populated | ||
| Tool call rate limits per session to prevent runaway loops | Before production | Rate limit config + test showing enforcement | ||
| Periodic review of tool call logs for out-of-scope invocations | Ongoing | Review schedule + last-run findings | ||
| A4 | Privilege Escalation Agent acquires permissions beyond its initial grant, either through tool chaining, delegation, or model-level reasoning. | Agent identity has a fixed, minimal permission set; no runtime permission expansion | Before pilot | IAM policy review showing least-privilege grant |
| Delegation chains are bounded: agent cannot grant permissions it does not hold | Before pilot | Delegation policy + test showing escalation blocked | ||
| Permission changes require out-of-band approval (not agent-initiated) | Before production | Change management process + test | ||
| Permission grants reviewed quarterly | Ongoing | Review schedule + last-run report | ||
| A5 | Data Exfiltration via Agent Agent retrieves sensitive data and leaks it through tool calls, generated output, or external API calls. | RAG retrieval scoped to data classes the user is authorised to access | Before pilot | Authorisation test: user A cannot retrieve user B's data |
| Output filtered for PII and confidential data patterns before delivery | Before pilot | Output filter test with synthetic PII | ||
| External API calls (email, webhook, HTTP) require explicit allowlist | Before pilot | Allowlist config + test showing unlisted calls blocked | ||
| Data access log captures what was retrieved, by whom, when | Before production | Log sample with retrieval events | ||
| Anomaly detection on retrieval volume per session | Ongoing | Alert rule + test trigger | ||
| A6 | Goal Manipulation Attacker or malicious content causes the agent to pursue a goal different from the one the operator intended. | Agent goal is stated in the system prompt and cannot be overridden by user input | Before pilot | Prompt template review + adversarial test |
| Goal-critical decisions (scope changes, new objectives) require human confirmation | Before pilot | Confirmation boundary implementation + test | ||
| Agent output reviewed for goal drift in pilot phase | Before pilot | Review process + sample outputs | ||
| Automated goal-drift detection in production | Ongoing | Detection rule + test trigger | ||
| A7 | Unsafe Tool Execution Agent executes tools that have irreversible real-world effects (send email, write to DB, call external API) without adequate safeguards. | Irreversible actions classified in tool manifest with explicit flag | Before pilot | Tool manifest showing irreversible flag on applicable tools |
| Irreversible actions require human approval before execution | Before pilot | Approval flow implementation + test | ||
| Dry-run mode available for all irreversible tools; used in testing | Before pilot | Dry-run test results | ||
| Rollback procedure documented for each irreversible tool | Before production | Rollback runbook | ||
| Execution log for all irreversible actions, retained for 90 days minimum | Ongoing | Log retention policy + sample | ||
| A8 | Repudiation Actions taken by the agent cannot be attributed to a specific user, session, or instruction, making audit and incident response impossible. | Every agent action carries a trace ID linking it to the originating user session | Before pilot | Trace ID present in log sample |
| Audit log is append-only and tamper-evident | Before production | Log integrity mechanism + test | ||
| Audit log retained for minimum 12 months | Ongoing | Retention policy + log age verification | ||
| A9 | Identity Spoofing Agent acts on behalf of a user or system it has not authenticated, or can be made to impersonate another identity. | Agent authenticates to all downstream services with its own identity, not the user's delegated token | Before pilot | Auth flow review showing agent identity used |
| User identity verified before agent acts on user-specific data | Before pilot | Auth test: unauthenticated request returns 401 | ||
| Agent identity credentials rotated on a defined schedule | Ongoing | Rotation schedule + last rotation date | ||
| Anomaly detection on identity usage patterns | Ongoing | Alert rule + test trigger | ||
| A10 | Scope Creep Agent's operational scope expands over time — new tools, new data sources, new user groups — without a corresponding re-review. | Scope is defined in the disposition memo and any expansion triggers re-review | Before pilot | Disposition memo with scope definition and re-review trigger |
| Change management process requires security review for scope changes | Before production | Change process documentation | ||
| Quarterly scope audit comparing current state to approved scope | Ongoing | Audit schedule + last-run report |
When a threat is not applicable
Not every threat applies to every agentic system. A stateless RAG pipeline with no tool calls has no exposure to A3 (Tool Misuse) or A7 (Unsafe Tool Execution). A read-only agent with no write access has limited exposure to A5 (Data Exfiltration via Agent).
The correct response to a non-applicable threat is not to skip it silently — it is to mark it as not applicable with a stated reason. “A3 not applicable: this system has no tool calls; it retrieves from a single read-only vector store and returns a response.” That sentence is evidence. It tells the auditor that the team considered the threat and made a reasoned determination, not that they forgot to look.
A not-applicable determination with a stated reason is evidence. A missing row is a gap.
From control map to disposition
The control map is an input to the disposition, not the disposition itself. Once you have gone through the table and identified which controls are in place, which are planned, and which are missing, you have the raw material for the required-controls section of the AI Risk Disposition memo.
Controls in the before-pilot column that are not yet in place become conditions on the disposition: the pilot cannot start until they are verified. Controls in the before-production column that are not yet in place become conditions on the production release. Controls in the ongoing column that are not yet in place become evidence gaps with a closure plan.
If you are not familiar with the structure of a disposition memo, the previous piece in this series — What an AI Risk Disposition actually contains — walks through it section by section.
Run this control map on your own system
Drel applies the OWASP Agentic Top 10 control map — and six other frameworks — to your assessed system automatically. The output is a structured disposition memo with required controls, evidence gaps, and re-assessment triggers.
Blog
Get new posts in your inbox
AI security review, OWASP Agentic Top 10, ISO 42001 evidence, and what AI Committees actually need. No cadence promises — we publish when there's something worth reading.
A note on scope: Drel reviews assessed systems against documented architecture, configuration and intent. It does not ingest live telemetry from production environments. Dispositions reflect the assessed system at the time of review and the re-assessment triggers that govern when the disposition must be revisited.