OWASP Top 10 for Agentic Applications: what it asks you to record, and who should sign it

In December 2025 the OWASP GenAI Security Project's Agentic Security Initiative published the Top 10 for Agentic Applications. Most write-ups walk through the ten risks, and this one does too, briefly. It then reads the prevention sections for a narrower question: what the list asks you to record about your agents, and what properties it expects those records to have. The answer is more demanding than "keep logs", and the most useful sentence on the subject comes in the last entry.

The ten risks in one pass

The entries are numbered ASI01 to ASI10. Condensed from the document's own descriptions:

• ASI01 Agent Goal Hijack. An attacker redirects the agent's objectives or decision pathways, because agents "cannot reliably distinguish instructions from related content." The mechanics are in our piece on indirect prompt injection.
• ASI02 Tool Misuse and Exploitation. Legitimate tools used harmfully through injection, misalignment, unsafe delegation or ambiguous instructions.
• ASI03 Identity and Privilege Abuse. Escalation through delegation chains, role inheritance and cached credentials.
• ASI04 Agentic Supply Chain Vulnerabilities. Third-party models, tools, plug-ins, MCP and A2A components or registries that are malicious or tampered with.
• ASI05 Unexpected Code Execution. Code the agent generates, turned into remote code execution or local misuse.
• ASI06 Memory & Context Poisoning. Persistent corruption of stored memory, summaries, embeddings and retrieval stores.
• ASI07 Insecure Inter-Agent Communication. Weak authentication, integrity or authorisation between agents that coordinate.
• ASI08 Cascading Failures. A single fault propagating across agents into system-wide harm.
• ASI09 Human-Agent Trust Exploitation. An agent exploiting a person's trust so that they approve something they should not.
• ASI10 Rogue Agents. Agents that deviate from their intended function or authorised scope, where each action "may individually appear legitimate".

The introductory letter frames all ten with a principle it calls Least-Agency: avoid autonomy you do not need, because "deploying agentic behavior where it is not needed expands the attack surface without adding value." In the same passage it says that "strong observability becomes non-negotiable". This piece picks up from that word, observability.

How the logging requirement escalates

Read the prevention sections in order and the logging advice does not stay at one level. It tightens.

• ASI01: on an unexpected goal shift, "surface the deviation for review, and record it for audit." A record, of unspecified quality.
• ASI02: "Maintain immutable logs of all tool invocations and parameter changes." Now the record must not change.
• ASI08: "Record all inter-agent messages, policy decisions, and execution outcomes in tamper-evident, time-stamped logs bound to cryptographic agent identities." Now any change must be detectable, and each entry is tied to a key.
• ASI09: "Keep tamper-proof records of user queries and agent actions for audit and forensics."
• ASI10: "Maintain comprehensive, immutable and signed audit logs of all agent actions, tool calls, and inter-agent communication".

ASI08 gives the reason. It files the requirement under "logging and non-repudiation" and points back to threat T8, Repudiation and Untraceability, in OWASP's Agentic AI Threats and Mitigations guide, which it summarises as "the ability to trace, attribute, and audit cascading behaviors through resilient logging and non-repudiation mechanisms that prevent silent propagation."

Non-repudiation is the word doing the work. A log supports it when the party that produced an entry cannot credibly deny producing it later, and nobody else can pass an entry off as theirs. An ordinary application log has neither property. Anyone with write access to the store, including a compromised process, can change it without leaving a trace. We set out the fields an agent log needs in the audit trail piece. OWASP's list is concerned with whether anyone other than the author can believe those fields.

Why "immutable" is not enough

The list says less about who writes the record, and ASI09 shows why that matters. Among its examples is "Explainability Fabrications: The agent fabricates plausible audit rationales to justify a risky configuration change." The same entry describes an agent that "acts as an untraceable 'bad influence,' manipulating the human into performing the final, audited action, making the agent's role in the compromise invisible to forensics."

Take those two together. In the first, the agent writes a false entry into the audit trail. In the second, the audit trail is accurate: it records the human's action and misses the agent's part in it. Neither is fixed by immutability. Making a fabricated rationale immutable only preserves the fabrication. What helps is a record the agent did not write. It should describe what actually ran and what it produced, and be written at a boundary the agent cannot reach. That is the same objection to agent-written transcripts we raised in the SOC 2 piece, and here OWASP makes it for us.

The key belongs outside the agent

ASI10 contains the sentence that says how to get there. After recommending signed behavioural manifests and per-run ephemeral credentials, it adds:

All signing and attestation mechanisms assume hardened cryptographic key management (e.g., HSM/KMS-backed keys, least-privilege access, rotation and revocation). Keys must never be directly available to agents; instead, orchestrators should mediate signing operations so that a compromised agent cannot simply exfiltrate or misuse long-lived keys.

This constraint is what gives "signed logs" any value. If the agent process can reach the signing key, a hijacked agent (ASI01) or a rogue one (ASI10) can sign whatever it likes, and the signature proves only that the key was used. The signer has to sit on the far side of a boundary the agent cannot cross. In practice that means the orchestrator or host, with the key in a separate process, a keystore or an HSM.

ASI04 applies the same logic to what the agent runs. Its advice is to "Sign and attest manifests, prompts, and tool definitions", to "verify provenance before install or activation" and to "auto-reject unsigned or unverified." ASI01 goes further and suggests evaluating an "intent capsule", which it calls "an emerging pattern to bind the declared goal, constraints, and context to each execution cycle in a signed envelope". The direction is the same across the list: bind what was meant to run, what did run and what came out, then sign it with a key the agent cannot use.

Where a signed execution receipt fits

That is the problem a Traceseal execution receipt is built for, so here is the mapping, limits included. The receipt specification defines a signed JSON document in three parts. The execution section holds hashes of the signed skill manifest, the sandbox configuration, the inputs and the outputs, plus the exit code, the timing, and a hash of the matching entry in the operator's hash-chained audit log. The provenance section holds the publisher's key, per-file content hashes and a transparency log reference. The attestation is an ed25519 signature by the operator over both.

• ASI02 and ASI05: the input, output and sandbox profile hashes record what a call received, what it returned and what configuration it ran under.
• ASI04: the manifest hash and publisher fingerprint tie the execution to one signed artefact. The transparency log reference lets a third party check that the manifest was published rather than swapped in.
• ASI08 and ASI10: the operator signature gives each entry the non-repudiation property the list asks for. In our runner the operator key never enters the sandbox, which is the arrangement ASI10 describes. A third party can check the signature with one command and nothing but the receipt file.

Three limits, stated plainly. First, the specification says outright that a receipt "does NOT prove the operator is honest"; it is "an attestation, not a proof of execution". A receipt moves trust from the agent to the operator. That is the point, but the trust has moved rather than disappeared. Publishing to a witnessed transparency log narrows what the operator can rewrite afterwards. Second, receipts detect nothing. A hijacked goal (ASI01) or a manipulated human (ASI09) still produces well-formed receipts. What they give you is a reliable account of what happened when you reconstruct it afterwards. Third, a receipt covers only what passes through the receipting boundary. An agent with a second route to a tool that bypasses it leaves no receipt for that route, as our sandbox write-up discusses.

What the list leaves open

The document is guidance, not a standard. It does not define a log format, say which component should hold the keys beyond "orchestrators", or explain how a third party should check a log that someone else kept. It uses "immutable", "tamper-evident" and "tamper-proof" in different entries without separating them, although they are different properties. The first prevents change. The second makes change detectable. The third is something no software log fully achieves. A team that cites the list in a security review will have to decide which one it means.

The useful reading of the list is not that agentic systems need more logging, since they already produce plenty. It is that the record has to be one the agent could not have written differently, signed with a key the agent could not reach. Every other prevention section assumes that record exists when something goes wrong.