OWASP Agentic Top 10 AI Audit Evidence: The Artifacts That Prove a Control Ran
OWASP released the Top 10 for Agentic Applications on 9 December 2025, built with more than 100 contributors. A framework tells an assurance function what to look for and stops short of telling it what a passing answer looks like on paper. This walks the evidence an auditor or a customer security review can actually inspect for each risk category, separates the categories that produce inspectable artifacts from the ones that do not, and names where the record has to come from.
OWASP GenAI published the Top 10 for Agentic Applications on 9 December 2025, developed with more than 100 industry contributors and scoped separately from the LLM Top 10 because the failure modes differ once a model can call tools and carry state across steps.
A risk framework names what can go wrong. An assurance function then has to answer a narrower question: when a customer's security review asks how you know your control for AAA02 worked last quarter, what document do you hand them.
I want to walk that question category by category. The engineering version of this mapping, with policy rules and audit field names, sits in the OWASP Top 10 for Agentic Applications gateway control mapping. This piece is for the person who has to evidence it rather than build it.
The evidence test
Three properties separate an artifact an auditor accepts from a screenshot that ends the conversation badly.
The artifact has to be produced automatically as a byproduct of the control running, rather than assembled afterwards by someone reconstructing what probably happened. Coverage has to extend to the denied path as well as the permitted one, because a log showing only successful requests proves nothing about enforcement. Authorship has to sit with something other than the component under examination, which is the self-attestation problem arriving in an agentic setting.
An agent's own account of its actions fails the third test outright. When the UK AI Security Institute catalogued 19 unsanctioned agent actions across 10 of 122 evaluation runs in its August 2026 incident report, the finding that mattered for assurance work was that agents misrepresented themselves to persuade humans. A component that can misrepresent itself cannot be the author of the record about what it did.
Categories that produce inspectable evidence
Tool invocation and authorization. The artifact is a per-call record naming the requesting principal, the tool or destination reached, the policy version evaluated, and the allow or deny outcome. An auditor samples a week, picks calls, and asks which identity authorized each. A deployment where every outbound call carries one shared service credential answers with the service account name, which is a finding rather than an answer. That gap is the post-authentication gap restated as an evidence problem.
Excessive agency. The evidence is the denial set. A sample of requests the policy refused, with the rule that refused them and the timestamp, demonstrates that a boundary exists and was tested by real traffic. An empty denial set over a quarter means either that nothing ever exceeded scope or that nothing was ever evaluated, and an auditor will assume the second.
Data exfiltration through outputs. The artifact is a classification decision recorded per request and per response, showing what category the content fell into and what the policy did with it. Prompt content assembles fragments from several sources inside one context window, so a document-level classification report from a data-governance tool covers a different object than the one that left the boundary.
Insufficient logging. This category audits itself. The evidence is the record set the other categories draw on, tested for completeness across a named window and for whether the calling application had write access to it.
Categories that do not
Four categories in the framework describe failures inside the model or inside the agent's reasoning, and no artifact produced on the request path establishes that they did not occur.
Plan and goal manipulation, memory poisoning, and cascading failure across multi-agent workflows resolve to what the agent decided and why, which lives in application state and model behaviour. A request record proves what was sent and what came back. It does not prove that the plan the agent formed was the plan a designer intended. Prompt injection sits half in and half out: the injected instruction travels inside a request and is therefore recordable, and whether the model complied with it is a model-behaviour question that the record shows only through the resulting call.
Insecure tool output handling is application code. A gateway sees the output crossing the boundary and has no visibility into how the calling code parsed it.
Saying so in an assurance document is worth more than a coverage table with ten green rows. Every security reviewer worth the meeting will pick the weakest claim and pull it.
The evidence table
What an auditor asks for in practice
The requests I have seen land in three shapes. Give me every model endpoint called in June and reconcile it against your approved provider list. Pick five denied requests and show me the rule that denied them. Show me one request from initiation to response with the identity attached at every hop.
That third request is the one that separates deployments. Answering it needs a record that survives the hop where the application swaps a user identity for a service credential, and most stacks lose the principal exactly there.
My candid view: the framework's most useful entry for an assurance programme is the logging one, and it reads as the least interesting because it names an absence rather than an attack. Nine of the ten categories are investigated using the artifacts the tenth is supposed to produce. Teams that treat it as housekeeping and work the exciting entries first end up unable to evidence any of them.
DeepInspect
This is the record layer the four fully-covered rows depend on. DeepInspect sits inline between your agents and the model 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.
For an agentic deployment, that record answers the three questions above with the same artifact: the destination reconciliation, the denial set with the rule that fired, and the principal bound to each outbound call rather than lost at the service-credential boundary. The plan, the memory store, and the orchestration trace stay with your application. Book a technical deep dive at deepinspect.ai.
Frequently asked questions
- What is the OWASP Top 10 for Agentic Applications?
A risk framework published by the OWASP GenAI Security Project on 9 December 2025, developed with more than 100 contributors, covering the security risks specific to autonomous and agentic AI systems. It sits alongside rather than inside the OWASP LLM Top 10, because an agent that invokes tools and carries state across steps fails in ways a single-turn completion does not.
- Does the framework require any particular evidence?
It describes risks and mitigations without specifying an evidence format, which is normal for OWASP material and is why assurance teams end up building the mapping themselves. The evidence expectation usually arrives from a customer security questionnaire, an ISO 42001 or SOC 2 audit, or a regulator, and the framework then supplies the vocabulary for the answer.
- Why can an agent's own logs not serve as audit evidence?
Because the component under examination authored them. The three standard failure modes are selective logging of the successful path, modification by whatever process failed, and loss when the process dies before the write commits. The UK AI Security Institute's August 2026 incident report added a sharper reason for agents specifically: it observed agents misrepresenting themselves to humans, which puts any self-narrated record in the same category as an unaudited statement.
- Which categories can architecture on the request path evidence?
Tool invocation control, excessive agency, identity binding on outbound calls, data classification on requests and responses, and logging completeness. Plan manipulation, memory poisoning, cascading multi-agent failure, and insecure output handling produce their evidence inside the application and the orchestration layer.
- How does this differ from a controls mapping?
A controls mapping states which control addresses which risk. An evidence walkthrough states what a third party can inspect to confirm the control ran, which is a stricter question and the one that decides audits. A control with no artifact is a claim.
- What is the fastest way to test our current position?
Pick one agent, pick one day, and try to produce every outbound model call it made with the originating human principal attached to each. Teams that can do this in an afternoon are in reasonable shape. Teams that need a week and a data engineer have discovered their finding before an auditor did.