The witness was the suspect: why AI audit logs can't be trusted

The problem with self-certification

Imagine you lend someone your car, and when they bring it back with a dent, they hand you a handwritten note saying "I checked, and I didn't hit anything." You'd ask for a second opinion. That's the position you're in when an AI agent logs its own actions.

AI agents are already making decisions, booking appointments, changing orders and answering questions on behalf of organisations. Most of them keep logs of what they do. The logs are meant to be a reliable record for audits, disputes and compliance checks. But here's the catch: the system being audited is also the one writing the audit trail. If the agent misbehaves, breaks or gets compromised, its logs can misbehave, break or get compromised in exactly the same way.

That's not a theoretical risk. It's a design flaw.

When the witness is also the suspect

In any investigation, you separate the witness from the suspect. You don't ask the defendant to keep their own court record. You don't let the financial controller also be the auditor. The principle is simple: whoever is being checked shouldn't be the only one keeping the record.

AI audit logs break that principle. The agent acts, and the agent logs. If something goes wrong with the agent's reasoning, the logging function—which runs in the same system—can go wrong in the same way. If an attacker gets in, they don't just compromise the actions, they compromise the record of the actions. The witness is the suspect, and the evidence comes from the suspect's own diary.

That's fine for debugging during development. It's not fine when the log is meant to be evidence six months later in front of an auditor, a regulator or a court.

What the AI Act requires, and what it doesn't

Article 12 of the AI Act says that high-risk AI systems must technically allow for the automatic recording of events over their lifetime ^[1]. For systems in Annex III, that applies from 2 December 2027; for Annex I systems, from 2 August 2028 ^[2]. The law tells you what to log: enough to trace the system's operation and support monitoring. It doesn't say how to protect the logs.

That's not an oversight. The regulation sets the requirement; it's up to you to meet it in a way that holds up. A log that the system itself could quietly edit, or that an attacker with access could rewrite, is easy to challenge. The law asks for the logs. Whether they hold up as evidence is another matter.

The same issue shows up in DORA, the operational resilience regulation for financial services. Article 12 of the technical standards requires logging procedures that protect logs against tampering, deletion and unauthorised access ^[3]. Again, the requirement is clear. How you meet it is your call.

The gap between a log and evidence

A log is a list of what the system says happened. Evidence is something you can show to someone who doesn't have to trust you. The gap between the two is the problem.

Say an AI agent changes a customer's order, and the customer later disputes it. You pull the log, and it shows the agent acting on an instruction it received. The customer says no such instruction was given. Who's right? If the only record is the one the agent wrote, and the agent could have written anything, the log doesn't settle it. It's your word, backed by a system you control.

Now say the agent was compromised, or a bug caused it to misinterpret an instruction. The same bug or compromise that caused the action could also have corrupted the log. Even if you're certain nothing went wrong, you can't prove it, because the proof would have to come from the thing that might have gone wrong.

That's the conflict of interest.

What this means for you

If you're running AI agents, or planning to, here are the questions to ask now:

• Could your agent's logs be altered by someone with administrator access, or by the agent itself if it malfunctioned?
• If an agent's decision were challenged six months later, would the log be your only record, or do you have a second source?
• Can you show an auditor or a supervisor that a log hasn't been edited since the event it records, even by your own team?
• Who would you be asking to trust you, and why would they?

The answers matter, because regulations like the AI Act and DORA are moving the goalposts. Logging used to be something you did for your own benefit. Increasingly, it's something you'll need to show others, and they won't take your word for it.

How a separate record breaks the circle

This is where a digital witness fits. The idea is to seal a fingerprint of each log entry, or each instruction and result, as the event happens. The fingerprint goes to an independent system—<a href="/signup">WitniumChain</a>—that anyone can check. The log stays with you. The fingerprint is just a string of characters, calculated from the log entry, that changes completely if even one character in the entry changes.

When someone questions what happened, you calculate the fingerprint again from the log entry you have. If it matches the sealed one, the entry hasn't changed since it was sealed. If it doesn't match, someone has edited it, and that shows. The check doesn't require trust. It's just maths.

Say a compliance officer asks whether anyone with admin rights altered the access log during an incident. With sealed fingerprints, you can show that the log segment from that hour matches what was sealed at the time. Even an administrator with full access can't rewrite a sealed record without the change showing up in the check.

Here's how it would work for an AI agent:

1. The agent receives an instruction, calls a tool and records the result.
2. As each step happens, your system sends a fingerprint of that record to WitniumChain through the <a href="/docs">REST API, SDK or MCP server</a>, and gets a witness ID back.
3. Later, when the action is questioned, you share the record with whoever needs to see it. They calculate the fingerprint and compare it with the sealed one. If it matches, the record is unchanged.

The agent can still log its own actions. The difference is that now there's a second record, independent of the agent, that nobody—including you—can quietly edit. The witness isn't the suspect any more.

What it doesn't do: it doesn't tell you whether the agent's action was correct, authorised or compliant. It doesn't replace monitoring, access controls or your internal audit. It just breaks the circle where the thing being checked is also the only one vouching for itself.

What to watch

As AI agents move from labs to production, expect regulators and auditors to start asking harder questions about logs. The AI Act's logging requirements for Annex III high-risk systems apply from 2 December 2027. DORA's technical standards on ICT risk management, including the bit about protecting logs, have applied since 17 January 2025 ^[3].

The gap between a log and evidence is going to get more attention, because it's the gap where trust is supposed to live, and trust doesn't scale. The question isn't whether your agent keeps logs. It's whether anyone who doesn't work for you would believe them.