Audit Trails for AI Agents: Complete, Tamper-Proof Logging

An audit trail for AI agents is the complete, tamper-proof logging of all decisions, tool calls, data accesses, memory operations and human approvals of an agent. It makes autonomous behavior forensically traceable, satisfies regulatory logging obligations, and provides evidence in the event of damage about who or what triggered an action. Unlike classic application logging, it must make the agent-specific decision path reconstructable.

• What is logged: prompt, model version/configuration hash, tool-call sequence with arguments, retrieval queries and document IDs, output with rationale, human overrides, memory events, cost and latency.
• How it is protected: WORM storage (Write-Once-Read-Many) and cryptographic signing for tamper detection; offloading to the SIEM beyond the reach of the agent.
• Why it is necessary: EU AI Act logging obligations, GDPR accountability and forensics following incidents that escalate faster than classic incident response can contain them.

Why agents need their own audit trail

Classic LLM applications merely respond: prompt in, completion out. Agentic systems, by contrast, plan, reason, select tools, write to memory and act with minimal step-by-step human approval. It is precisely these properties (autonomy, tool usage and persistent state) that create a decision path which conventional request/response logs do not capture.

In the OWASP model for agentic applications (ASI01–ASI10, published on December 9, 2025), traceability is no longer a top-10 risk in its own right, but is embedded: the former draft topic "Repudiation & Untraceability" today sits within ASI03 (Identity & Privilege Abuse) plus overarching logging requirements. The audit trail is thus a cross-cutting control that makes several risk classes investigable in the first place.

Three examples from OWASP research demonstrate the need:

• ASI06: Memory & Context Poisoning: a single successful injection attack can permanently poison persistent memory; a central detection signal is that the agent "remembers" instructions for which no provenance record exists. Without origin-based logs, this proof is impossible.
• ASI08: Cascading Failures: according to Galileo AI research (December 2025), in simulations a single compromised agent poisoned 87% of downstream decisions within 4 hours, faster than classic incident response can contain it. Only a complete inter-agent log makes the propagation reconstructable.
• ASI10: Rogue Agents: in the threat-to-control overview, "audit" is, alongside continuous behavioral baselines and a kill switch, one of the core controls for detecting persistent misalignment over time.

What must be logged

OWASP research (Section 7.6, Audit logging) defines the minimum forensic scope per agent action, that is, for every individual action rather than per session:

The decisive factor is provenance metadata: every memory entry should record source, timestamp, ingestion path and confidence. In the OWASP logic, memory writes are security-relevant events. Data enters persistent memory only via an explicit, audited write operation, never implicitly.

Tamper-proofing: WORM and cryptographic signing

An audit trail is only as credible as its immutability. If a compromised agent, or an attacker holding its privileges (ASI03: "the attacker inherits the agent's permissions"), can subsequently alter the logs, the forensic evidential value is lost. The patterns cited in the research:

• WORM storage (Write-Once-Read-Many): immutable logs that can no longer be modified after being written.
• Cryptographic signing: each log entry is signed, so that tampering becomes detectable (tamper detection).
• SIEM integration: logs are routed out centrally and held beyond the reach of the agent and its tool permissions.

In the classic STRIDE threat logic, this addresses the Repudiation category, which is retained in Microsoft's STRIDE-for-AI adaptation. In addition: where code executions are logged, configuration-file writes outside regular change management and sub-process spawns also belong in the trail (detection signals from ASI05).

Why it is necessary: logging obligation, accountability, forensics

The regulatory driver is threefold. Firstly, the EU AI Act requires automatic recording of events over the lifetime for high-risk AI systems (record-keeping, Art. 12), flanked by Art. 14 (human oversight) and the post-market monitoring obligation from Art. 72. Under the Digital Omnibus (Regulation (EU) 2026/1744), Art. 12 and Art. 14 apply only from December 2, 2027, for Annex III systems and from August 2, 2028, for Annex I systems. OWASP research additionally maps the agentic risks to Art. 15 (robustness, cybersecurity) and notes that deployers must read OWASP-style threat catalogs in addition to Art. 15, because the harmonized standards as of May 2026 do not yet close many gaps.

Secondly, GDPR accountability (Art. 5(2), Art. 24) requires evidence of appropriate technical and organizational measures, including security of processing under Art. 32. The research links several risks directly to the GDPR. It maps ASI03 to Art. 32(1)(b) (confidentiality and integrity of systems) and to the instruction principle of Art. 32(4). That provision covers natural persons acting under the authority of the controller or processor. Applied to the agent, it means the agent may act only within the controller's instructions, but it is not itself a processor. The research links ASI06 to Art. 5(1)(d) (accuracy) and Art. 17 (right to erasure). Memory-deletion processes must therefore be aligned with Art. 17, and that alignment in turn must be documented.

Thirdly, the audit trail provides the forensics. In the manufacturing procurement cascade incident (2025), a procurement agent was gradually persuaded over three weeks that its authorization limit was 500,000 USD; the attacker subsequently placed 5 million USD in fraudulent orders across 10 transactions. Only a complete trail of memory writes, tool calls and human-override events makes it possible to reconstruct such a "boiling-frog" sequence retrospectively and to examine the human approval chain.

For regulated sectors in Austria and Germany, EU overlays apply: NIS2 (access control and asset management, Art. 21(2)(i)) as well as DORA with ICT incident management and reporting (Art. 17–23) for financial service providers. In the ISO/IEC 42001 framework, the audit trail is anchored in Control A.6.2.8 (Logging), supplemented by A.6.2.6 (Operation and Monitoring).

Retention by sector

For high-risk AI systems, the EU AI Act sets a floor: providers (Art. 19(1)) and deployers (Art. 26(6)) must keep the automatically generated logs under their control for at least six months, unless applicable Union or national law provides otherwise. Sectoral periods come on top:

This article does not constitute legal advice. The specific periods, applicable article numbers and sectoral obligations must be clarified on a case-by-case basis with your legal and compliance function.

Practical example: audit record of a tool action

This is what a single signed entry, stored in WORM storage, might look like in pseudocode: each field corresponds to the OWASP minimum standard.

```
audit_event {
event_id: "a1f9-…" // unique, part of the signature
agent_id: "procurement-agent-07" // ASI03: Non-Human Identity
timestamp: 2026-06-09T08:14:22Z
model: { version, config_hash }
prompt: { user, system, injected_context }
retrieval: [ { query, doc_ids[] } ]
tool_call: { name: "create_purchase_order",
args: { amount: 5_000_000, vendor: "…" } }
rationale: "Order aligns with stored authorization limit"
memory_read: [ { key: "auth_limit", provenance: NULL } ] // <- alarm
human_override: { approver: "none", action: "auto-approved" } // <- alarm
cost: { tokens, usd }
signature: "sig:…" // cryptographic tamper detection
}
```

Two fields here are the forensic gold nuggets: the memory read with provenance: NULL shows that the authorization value has no verifiable origin (ASI06 signal), and the missing human override on a 5-million transaction evidences a circumvented approval gate (ASI09). Without these fields, the incident could not have been investigated.

For agencies and B2B decision-makers

Anyone bringing agents into production processes shifts liability and the burden of proof: in the event of a dispute or audit, what counts is what was verifiably logged. Marketing agencies that build agent workflows for clients should treat audit trails as an architectural requirement from the outset, not as logging bolted on afterwards. Blck Alpaca, based in Vienna, supports DACH companies in designing agentic systems with forensically robust, OWASP- and ISO 42001-compliant audit trails, from provenance metadata through WORM storage to SIEM integration. This keeps autonomy traceable and audit-proof.