OWASP Agentic Top 10 AI Compliance Checklist: 12 Items With an Objective Completion Test
The OWASP Top 10 for Agentic Applications landed on 9 December 2025 and most teams read it, agreed with it, and filed it. This is a twelve-item checklist that turns the framework into work with a completion test on each item, ordered by dependency rather than by risk rank, and split between the items a platform team can close and the four that belong to application engineering.
The OWASP GenAI Security Project published the Top 10 for Agentic Applications on 9 December 2025, developed with more than 100 contributors. A framework ranked by risk severity tells you what matters most. A team implementing it needs a different order, because item three cannot be verified until item one exists.
These twelve items run in dependency order. Each states a test somebody outside your platform team could run to confirm it is done, which is the only version of a checklist that survives contact with an auditor.
1. Inventory the agents actually running
An agent gets created by a developer in an afternoon, inherits a credential nobody registered against it, and never appears in a service catalogue. An inventory built from a survey returns the agents people remember.
Done when: the agent list reconciles against observed egress to model endpoints over the last 30 days, with every unexplained caller either registered or shut off. The reconciliation method is the same one in shadow AI discovery.
2. Record every outbound model and tool call off the application path
This is the item the other eleven depend on and the one most deployments lack. The record has to be written by something the calling application has no custody over, or it is a statement by the party under examination.
Done when: for a sampled hour, a record exists per outbound call naming the destination, the model version, the timestamp, the policy version evaluated, and the outcome, retrievable without asking the application team to run a query.
3. Bind the originating principal to every outbound call
Most stacks authenticate a user at the application, then call the model with one service credential carrying the combined privileges of everyone who uses that application. Attribution dies at exactly that hop.
Done when: for a sampled request, the record names the human or service principal who initiated it rather than the service account the application authenticated with. This is the post-authentication gap expressed as a test.
4. Write the scope policy for each agent and put it on the path
Excessive agency is a scope question, and scope written into a system prompt is a request rather than a control. The policy has to be evaluated by a component the agent cannot edit.
Done when: each registered agent has a named policy listing permitted destinations, permitted tools, and permitted data classes, and a request violating it is refused rather than logged.
5. Set the default to deny
An allowlist that falls open on evaluator error, timeout, or an unrecognised destination is an allowlist during normal operation only.
Done when: an induced policy-service failure in a test environment results in refused requests, with the refusal recorded and an alert raised.
6. Classify content on the request rather than on documents at rest
A prompt assembles fragments from several systems inside one context window and ships them as a single payload. Document-level classification examines a different object than the one crossing the boundary.
Done when: a test prompt carrying a known sensitive pattern is classified and handled by policy at the request layer, with the decision recorded.
7. Inspect responses, not only requests
Data leaves through the return path as often as through the outbound one, and a tool output can carry content the requesting principal has no entitlement to.
Done when: a response carrying a known sensitive pattern triggers the configured action, and the decision appears in the same record as the request that produced it.
8. Test the injection path end to end
Injected instructions arrive inside payloads, so detection is possible and probabilistic. The durable control is item 4 above it, since an obeyed injection still has to produce an outbound action that meets a policy indifferent to why it was requested.
Done when: a red-team prompt that successfully manipulates the model still fails to reach an unauthorised destination, and both the compliance and the refusal are in the record. Background on why the model layer cannot own this sits in Model Guardrails Are Not a Security Control.
9. Produce a denial set on demand
An empty denial set over a quarter means either that no request ever exceeded scope or that nothing was ever evaluated. A reviewer will assume the second one.
Done when: a named person can produce last month's refused requests with the rule that refused each one, inside an hour, without engineering help.
10. Constrain the plan before it executes
Plan and goal manipulation is application-side work. The control is a check on what a formed plan may contain before any step runs, rather than a check after the first tool call has already fired.
Done when: a plan containing a step outside the agent's declared scope is rejected at plan validation, with the rejection logged by the orchestrator. This item is owned by application engineering.
11. Control writes to agent memory
Memory poisoning is a data-integrity problem in whatever store the agent reads back from. Write authorization, provenance on each entry, and expiry are the three controls.
Done when: every memory entry carries the principal and timestamp that wrote it, entries expire on a stated schedule, and an unauthorised write attempt is refused and recorded. This item is owned by application engineering.
12. Cap the blast radius across multi-agent hops
One agent's output becoming another agent's instruction without mediation is how a single compromised step becomes a chain. Circuit breakers, hop limits, and mediation at each handoff are the controls.
Done when: a tabletop walkthrough of one compromised agent produces a bounded, written blast radius naming the maximum reachable destinations and data classes. This item is owned by application engineering.
What this checklist does not cover
Items 10, 11 and 12 belong to application engineering and no component on the HTTP path closes them. A gateway records the traffic they produce and controls none of their internals.
Insecure tool output handling, the framework's parsing entry, is ordinary input validation applied to data returned from a tool, and it lives in application code. Governance items an ISO 42001 assessor will ask for, including roles, risk methodology, supplier management, and continual improvement, sit outside this list entirely. The controls mapping with owners per risk area is in the agentic controls mapping, and the artifacts a reviewer inspects are in the agentic audit evidence walkthrough.
My candid view: items 2 and 3 close nine of the twelve tests between them, and they are the two teams defer because neither produces a demo. The UK AI Security Institute's August 2026 incident report catalogued 19 unsanctioned actions across 10 of 122 evaluation runs, and its security team noticed because of unusual data transfers leaving research systems, spotted in routine monitoring after the fact. Somebody was watching the path. That is the whole difference between an incident with a timeline and an incident with a theory.
DeepInspect
This is the control point items 2 through 9 describe. DeepInspect sits inline between your agents and the LLM APIs they call, as a stateless proxy the calling application has no custody over. It evaluates identity, request classification, and destination on every call, enforces per-role and per-route policy with a fail-closed default, and writes a signed, tamper-evident per-decision record.
That single component supplies the inventory reconciliation in item 1, the record in item 2, the principal binding in item 3, the scope enforcement in items 4 and 5, the classification in items 6 and 7, the containment in item 8, and the denial set in item 9. Items 10, 11 and 12 stay with your application team, and a checklist that claimed otherwise would leave you exposed on the three that matter most in an agentic incident. Book a technical deep dive at deepinspect.ai.
Frequently asked questions
- Why is the checklist not ordered by OWASP risk rank?
Because verification has dependencies that risk ranking ignores. Testing scope enforcement requires a record of what was enforced, and testing principal binding requires the record to exist first. Working in rank order produces items you cannot demonstrate.
- How many of these can one component close?
Eight of the twelve, in the sense that a policy enforcement point on the request path supplies the artifact each test asks for. Items 10, 11 and 12 are application-side and stay that way. Item 1 is partially closed, since observed egress supplies the reconciliation input and someone still has to act on the discrepancies.
- What is the single most common gap?
Item 3. Teams can usually produce a log of model calls and cannot say which human the call was made on behalf of, because the application swapped the user identity for a service credential before the request left. That one gap surfaces later as three separate audit findings sharing a root cause.
- Does completing this checklist satisfy ISO 42001 or SOC 2?
It supplies technical control evidence to both and satisfies neither on its own. ISO 42001 asks for an AI management system with governance, roles, risk methodology, and supplier management. SOC 2 scopes to the trust services criteria you selected. This list populates the AI-traffic rows inside either.
- How does the agentic list relate to the LLM Top 10?
They cover overlapping traffic with different failure models, and both remain in scope for an agentic deployment, since every agent step is still a model call. The LLM Top 10 addresses the single-turn surface. Running one control inventory at the request boundary and annotating it against both lists avoids maintaining two.
- How often should the checklist be re-run?
Quarterly for items 1, 9 and 12, since agent inventories drift fastest and denial sets are the freshness test for everything else. Items 2 through 8 are architecture and only need re-testing when the path changes. Items 10 and 11 re-run whenever the orchestration or memory design changes.