When an AI agent writes its own logs, who checks the checker?

The problem nobody's talking about

A developer raised a simple question on social media this week: when an AI agent writes its own logs, the record of what went wrong is created by the thing that went wrong ^[1]. It's a bit like asking a suspect to write the police report.

Most logging works this way. The application writes what it did, and you read the logs later. When it's a static system doing predictable tasks, that's usually fine. When it's an AI agent making decisions, calling tools and updating customer records, the logs are often the only trace of what happened and why.

The trouble comes when you need to trust the record. If the agent misbehaves, or is compromised, or just makes a mistake, the logs it writes might not tell the whole story. They might tell a tidy story that happens to leave out the awkward bits.

Stacking verifiers doesn't help

One response is to add another layer: let a second AI check the first one's logs. The developer's point is that this just moves the problem. Now you have two agents, and if the second one is compromised, or instructed to cover for the first, you're back where you started.

It's turtles all the way down. At some point, something has to be independent of the thing being checked.

What Article 12 asks for

The AI Act requires high-risk AI systems to log events automatically over their lifetime, for traceability and for monitoring after they've been released ^[2]. Article 12 says what to log. It doesn't say how to protect the logs, or who keeps them, or what happens when the system writing the log is also the one under scrutiny.

For systems under Annex III, Article 12 applies from 2 December 2027 ^[2]. For systems under Annex I, it's 2 August 2028 ^[2]. That gives you time to decide how you're going to handle this.

The structural question

Here's the question: if an agent writes a log saying it did X, and later someone asks whether it really did X, what do you show them?

You could show them the log. They might point out that the log was written by the agent, so it's not exactly independent.

You could say the log is immutable. They might ask who controls the system that makes it immutable, and whether that system could be instructed to change its mind.

You could add cryptographic signatures. They might ask who holds the keys, and what happens if those keys are used to sign a rewritten version.

The structural problem is this: as long as the record is kept by the same organisation that runs the agent, and can be rewritten by anyone with the right access, it's a diary, not evidence.

What this means for you

If you're building or running AI agents, here are a few questions worth asking now:

• When your agent acts, who writes the record of what it did? The agent itself, or something independent?
• If the agent writes the log, could it also edit the log, or instruct another system to do so?
• If an agent misbehaves, and you need to show an auditor or a customer exactly what it did, what record would you point to?
• Could you prove that record hasn't been quietly tidied up after the fact?

Sealing the record as it happens

This is where a digital witness fits. The idea is simple: as the agent acts, you seal a fingerprint of each step. The fingerprint goes onto a chain where any later change would show, even one made by you.

Say an agent books a meeting, updates a price or sends an email. At that moment, you take a fingerprint of the instruction, the tool call and the result, and seal it with WitniumChain ^[3]. The agent's record stays with you. The fingerprint is posted to a chain that you don't control and can't rewrite.

Later, if someone questions what the agent did, you show them the record and the sealed fingerprint. They calculate the fingerprint themselves. If it matches, the record hasn't changed since it was sealed. Change one character and it won't match.

It doesn't prove the agent did the right thing. It doesn't authorise the action. It just shows that this is the record that was written at the time, and nobody has edited it since.

How it would work

1. Your agent acts: calls a tool, makes a decision, sends a message.
2. Your system seals a fingerprint of the instruction, the call and the result through the MCP server, the SDK or the REST API.
3. When the action is questioned, anyone you share the record with can check the fingerprint and see that it hasn't changed.

What a witness doesn't do

It doesn't replace logging. It doesn't tell you whether the agent was behaving correctly, or whether its instructions were sound. It doesn't catch the agent in the act.

What it does is separate the record from the agent. The agent can still write what it likes in the log. But once sealed, it can't quietly rewrite that log without the change showing up.

That's useful when the question isn't 'did the agent log this?', but 'is this the log the agent actually wrote?'.

What to watch

Article 12 of the AI Act applies from 2 December 2027 for high-risk systems under Annex III, and from 2 August 2028 for systems under Annex I ^[2]. If you're building agents that will fall under those rules, now is the time to decide how you'll keep a record that holds up when it's questioned.

The developer's point stands: an agent that writes its own logs is writing its own report card. If you want an independent record, you need something that sits outside the agent's control.