When the AI agent can edit the evidence

The problem WorkOS spotted

WorkOS published a short post ^[1] on a design question many will face: what happens when an AI agent can edit the records of what it did?

The company builds authentication and directory tools for developers. One of those tools is AuditLogAPI, which generates structured audit logs. WorkOS added a feature that lets agents act on a user's behalf, and then ran into a clear tension.

An agent needs working data it can manage. It might keep a transcript of what it said and did during a session, and it ought to be able to delete that transcript when the session ends, to comply with data minimisation under the GDPR ^[2]. At the same time, the audit log—the record of what the agent actually did, under whose delegation, and when—must stay unchanged. If the agent can edit the audit log, the log is no longer evidence.

Two kinds of records

WorkOS draws a line between two kinds of records:

• The agent's trace: a working record of what the agent is doing in real time, often a chat transcript or a list of tool calls. The agent can delete this when a session ends or a user asks for it to be removed.
• The audit log: a structured, immutable record of the agent's actions. It captures the agent's identity as an actor type, the scope it was granted, the delegating user, and what it did. The agent cannot edit this.

The point is that the audit log records events, not conversations. It doesn't need the full transcript, just a structured entry per action: who (or what) did it, what was done, when, and on whose instruction.

Why it matters

AI agents are already booking meeting rooms, placing orders and changing records in live systems. They do it because someone delegated that authority, often through a natural-language instruction. The harder question comes months later, when something is questioned.

Say a customer claims an agent changed an order without being asked. Or say a supervisor wants to know which version of an agent made a particular decision, and under what scope. The audit log is what answers those questions, but only if it's clear that the agent—or anyone else—couldn't have rewritten it in the meantime.

Article 12 of the AI Act ^[3] requires high-risk AI systems to technically allow for the automatic recording of events over their lifetime, for traceability. For Annex III systems, that applies from 2 December 2027 ^[4]. The article says what to log; it doesn't say how to protect the logs. A log the agent can quietly edit is easier to challenge on the day someone asks what actually happened.

The Product Liability Directive ^[5] is another reason to care. Software placed on the market after 9 December 2026 falls under strict product liability, and under certain conditions courts can order relevant evidence to be handed over. If your agent acted, you'll want a record of what it did that can't be dismissed as tampered.

How a digital witness fits here

Sealing the audit log as it's written gives you a record you can show hasn't changed, even if the agent—or anyone with administrator rights—could in principle have edited it.

What you seal is each structured audit event as it's written: the actor (the agent), the actor type, the scope it was granted, the delegating user, the action and the timestamp. The seal takes a fingerprint of that entry, not the content itself, so the entry never leaves your systems. The fingerprint is recorded on WitniumChain ^[6], and you get a witness ID back.

When an event is questioned, anyone you share the record with can calculate the fingerprint again. If it matches the sealed one, the entry hasn't changed since the moment it was written. Change a single character and the fingerprints won't match.

You can do it through the REST API, the SDK or the MCP server ^[7], and the first 2,000 witnesses a month are free.

What a digital witness doesn't do is show that the agent's action was right, that it was authorised, or that the audit log is complete. It shows one thing: that the entry you're looking at now is the one written at the time.

How it would work

1. Your system writes a structured audit event (agent ID, action, delegating user, timestamp) to the log.
2. At the same time, it sends a fingerprint of that event to WitniumChain and gets a witness ID back.
3. Months later, when the event is questioned, you calculate the fingerprint again and compare it with the sealed one. A match means nothing has changed.

What this means for you

If you're building with AI agents, here are three questions worth asking this week:

• Does your agent have the ability to edit the audit log of what it did?
• Are you separating working data (transcripts the agent can delete) from evidence (structured audit events that stay unchanged)?
• If a supervisor or a customer questioned an agent's action six months from now, could you show a record that nobody—including the agent—could have quietly rewritten?

The WorkOS post is short and technical, and it's worth reading if you're designing systems where agents act. The design they chose—two separate records, one mutable and one not—is a pattern others will likely follow.