Agent audit logging: why platform logs miss the decision you need to prove

What platform logs actually record

When an AI agent decides to send an email, update a customer record or place an order, your cloud platform's audit log will tell you the agent endpoint was called, by whom and at what time. What it won't tell you is which tools the agent used, what reasoning it followed or which function returned the information that led to the action.

That matters, because the interesting question in a dispute is not 'was the agent called?' but 'what did it do, and why?'. Think of it as the difference between your phone bill showing you rang someone and a recording of what you said. One proves contact, the other proves content.

Platform audit logs are built for security monitoring and access control, not for proving the chain of thought in an AI agent. They show the perimeter, not the inside. If six months later a customer says the agent cancelled their subscription without being asked, and your only record is a line saying 'agent invoked at 14:32', you have a problem.

What Article 12 asks for

Under the AI Act, high-risk AI systems must technically allow for the automatic recording of events over their lifetime ^[1]. For systems under Annex III, that applies from 2 December 2027 ^[2]. The rule doesn't say 'platform logs', it says the logs need to support traceability.

Article 19 and Article 26.6 add that providers and deployers must keep the automatically generated logs they control for at least six months, unless another rule asks for more ^[3]. The logs are meant to help with oversight, incident response and answering questions from the people affected by decisions.

Article 86 gives those people a right to an explanation when a high-risk AI system under Annex III makes a decision with legal or similarly significant effects on them ^[4]. A log that says 'agent called' is not an explanation.

Why OpenTelemetry solves the gap

OpenTelemetry is an open standard for collecting traces, metrics and logs from distributed systems. A trace is a record of what happened during a single request: which functions were called, in what order, how long they took and what they returned ^[5].

When an AI agent acts, an OpenTelemetry trace captures the full sequence: the user's instruction, the agent's plan, each tool it called, the responses it got and the final output. That gives you a structured record of the decision chain, in a format machines can read and humans can follow.

Most agent frameworks already support OpenTelemetry, so instrumenting your agents is a matter of adding a few lines to send the traces somewhere you control. The harder part is keeping those traces in a way that holds up when questioned.

WORM storage and tamper evidence

WORM stands for write once, read many: storage where nothing can be changed or deleted after it is written. That matters for logs, because a log you can quietly edit is a diary, not evidence. If you are the one keeping the log, saying 'trust me, I didn't change it' is not convincing.

Tamper-evident storage goes one step further. Each trace gets a fingerprint when it is written, and that fingerprint is sealed in a way that any later change would show. If you alter a single character in the trace, the fingerprint no longer matches, even if you are the administrator.

Article 12.2(d) of the delegated regulation under DORA requires financial firms to protect log systems and log information against tampering, deletion and unauthorised access ^[6]. The same logic applies to AI agent logs under the AI Act: if the logs can be rewritten, they lose the trust they are meant to provide.

How a digital witness fits here

This is where sealing each trace as it is written makes the difference.

Your agent framework sends each OpenTelemetry trace to your WORM storage, and at the same moment a fingerprint of that trace is sent to WitniumChain. The content never leaves your systems, only the fingerprint does. WitniumChain seals the fingerprint on a chain where any later change would show, and gives you a witness ID back.

Six months later, when someone questions what the agent did, you fetch the trace from your storage and calculate its fingerprint again. If it matches the sealed one, the trace is exactly what was written that day. Change even one field in the JSON and it won't match, so nobody can quietly rewrite the decision after the fact.

Who can check it? The person affected by the decision, an auditor, a supervisor or, if it comes to that, a court. The check takes seconds and doesn't depend on trusting whoever kept the log.

What it doesn't do: it doesn't show that the agent's decision was correct, fair or lawful, or that your logging is complete. It shows that this particular trace hasn't been tampered with since the moment it was sealed. That is one piece of the puzzle, but an important one.

You can seal traces through the REST API, the SDK or the MCP server. The first 2,000 witnesses a month are free. Read the full documentation at witniumchain.com/docs.

How it would work

1. Agent framework writes OpenTelemetry trace to WORM storage
2. Fingerprint of trace is sealed via WitniumChain, witness ID returned
3. When questioned, fetch trace, recalculate fingerprint and compare with sealed one

What this means for you

If you run AI agents that make decisions about people, ask your team these questions this week:

• Are we capturing OpenTelemetry traces for our agent invocations?
• Where are those traces stored, and can anyone with admin rights edit them?
• If a customer or auditor asked what our agent did on a specific day six months ago, could we show them the full tool chain?
• Are we keeping traces for at least six months, as Article 19 and 26.6 require?

Platform audit logs are a good start for security monitoring. For proving what your AI agent decided, and why, you need your own instrumented traces in tamper-evident storage.

What to watch

High-risk requirements under Annex III of the AI Act apply from 2 December 2027. If your agents make decisions about creditworthiness, employment, education, law enforcement, migration or access to essential services, they fall under that definition and the logging duty in Article 12 applies ^[7].

For AI agents used in financial services, DORA's logging requirements are already in force as of 17 January 2025 ^[6].

The six-month retention rule is a floor, not a ceiling. Sector rules or national law may ask you to keep logs longer, and if someone files a complaint or starts a case, you will need the logs for as long as the matter is open.