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 behaviour 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 9 December 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 behavioural 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 — not per session, but per individual action:

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 — persistent memory only via an explicit, audited write operation, not 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. OWASP research additionally maps the agentic risks to Art. 15 (robustness, cybersecurity) and notes that deployers must read OWASP-style threat catalogues in addition to Art. 15, because the harmonised standards as of May 2026 do not yet close many gaps.

Secondly, the GDPR accountability obligation requires evidence of effective technical and organisational measures (Art. 32 TOMs). The research links several risks directly: ASI03 with Art. 32(1)(b) and Art. 32(4) (processing on instructions — the agent is the "instructed processor"), ASI06 with Art. 5(1)(d) accuracy and Art. 17 erasure obligation. Memory-deletion processes must be aligned with Art. 17 (right to erasure) — which 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 authorisation 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 DACH sectors, sectoral overlays are added: 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

Retention periods are sectoral, not generic. OWASP research cites:

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: "—", 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 authorisation 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.