OWASP Agentic Top 10: The Audit and Logging Duties in ASI02, ASI08 and ASI10, Mapped onto AER-1

The OWASP Top 10 for Agentic Applications (2026 edition, published by the OWASP GenAI Security Project on 9 December 2025) names the security risks of autonomous agents. Three of its ten risks turn on the same operational question: when an agent misuses a tool, when a failure cascades across agents, or when an agent goes rogue, what record exists afterwards to reconstruct what happened? This page maps the audit and logging expectations in ASI02, ASI08 and ASI10 onto the fields of an AER-1 receipt, the open receipt format defined by IETF Internet-Draft draft-zambo-aer1-26. The mapping is a reading aid. It is not a certification, and a receipt format on its own does not make any deployment secure or compliant with anything.

What the three risks ask the record to do

OWASP states the risks; its prevention guidance for each one reaches for the same instrument, a complete invocation log that still reads true when it is examined later. In ASI02 (Tool Misuse and Exploitation), the guidance asks for logs of all tool invocations, kept so entries cannot be quietly altered after the fact, because misuse of a legitimate tool is visible only in the sequence of calls. In ASI08 (Cascading Failures), the guidance escalates to time-stamped logs bound to agent identities, because a cascade can be untangled only if each step can be attributed and ordered. In ASI10 (Rogue Agents), the guidance asks for comprehensive audit logs covering the agent's actions, because an agent operating outside its mandate has to be provable from a record it does not control. The three asks share one shape: a per-call record, filed when the call runs, that a later reader can check without trusting the agent's own account.

ASI02, Tool Misuse and Exploitation

What the record has to show	Where it sits in an AER-1 receipt
Every tool invocation, not a sample	One receipt per tool call, minted by the endpoint at execution time. A call that leaves no receipt is visible as a gap in the sequence.
Which tool ran, with what input	The receipt's tool field and input record, kept with the call.
What came back	The saved result, kept as exact bytes with its SHA-256 output digest.
Entries that still read true later	Verification is a recompute: re-hash the saved result and compare it with the digest filed at execution. A changed result fails the check, for anyone, with no account.

What a receipt does not do for ASI02: it does not decide whether a call should have run. Policy, permissions and approval gates sit in front of execution. The receipt is the evidence those controls leave behind, and the thing that makes a misuse pattern across many calls visible at all.

ASI08, Cascading Failures

What the record has to show	Where it sits in an AER-1 receipt
Ordering across a chain of calls	Workflow records bind a job's receipts in sequence: each step's digest feeds the chain commitment, and a workflow close files the final entry digest.
Time stamps a reader can rely on	Each receipt is filed with its execution time; external anchors (Section 10 of the draft) can register a digest with an outside service at a stated time.
Attribution per step	The receipt's execution context records the calling context for the step, so a multi-agent chain shows which step came from which caller.
Where the cascade started	Because every step carries its own input and output digests, a reader can walk the chain and find the first step whose output no longer matches the work it was handed.

What a receipt does not do for ASI08: it does not stop a cascade. Circuit breakers, budgets and kill switches do that, in the runtime. The receipt chain is how a team proves afterwards where the failure entered and which downstream steps consumed it, instead of arguing from summaries.

ASI10, Rogue Agents

What the record has to show	Where it sits in an AER-1 receipt
A comprehensive action log	The receipt stream: every call through the endpoint, in order, including calls that were rejected.
A record the agent does not control	Receipts are minted by the serving endpoint, not written by the agent, and each resolves at a stable public URL. An agent cannot file a receipt for work that did not run, and cannot edit the saved result afterwards without failing verification.
"Done" claims that can be tested	A completion claim can cite receipt ids. Anyone can open them, read the saved results, and recompute the digests. A claim with no receipts, or receipts that fail, is visible as exactly that.

What a receipt does not do for ASI10: it does not keep an agent inside its mandate in the first place. It removes the rogue agent's best cover, which is that its own summary is the only record of its work.

Reading this mapping honestly

AER-1 is an individual Internet-Draft at revision -26, not an RFC, and this page claims mapping, not endorsement: OWASP has not reviewed it. A receipt proves the saved result has not changed since it was saved; it does not prove the result was right. Deployments still need the controls OWASP describes around the log: least-privilege tool access, approval gates for destructive actions, monitoring, and a way to stop an agent mid-run. What the receipt changes is the quality of the evidence those controls produce.

Sources

OWASP GenAI Security Project, OWASP Top 10 for Agentic Applications (2026 edition), ASI02 Tool Misuse and Exploitation, ASI08 Cascading Failures, ASI10 Rogue Agents: genai.owasp.org
Internet-Draft draft-zambo-aer1-26, AER-1: AI Agent Execution Receipt: datatracker.ietf.org/doc/draft-zambo-aer1/
The public verifier: zambo.dev/verify. The endpoint: zambo.dev/mcp.