How do you audit what an AI agent did?

The problem with autonomous systems

When a human opens a support ticket and transfers money, you log who did what and when. When an AI agent does it, the question gets harder. The agent made calls to three different tools, consulted a knowledge base, got approval from a human for one step but not the others, and acted on an instruction that came in two hours earlier. Which part of that do you log, and how do you tie it all together?

Think of it like a parcel. When a courier delivers it, you sign for it and get a receipt with a time and a name. When an autonomous drone delivers it, the receipt needs to show not just that the parcel arrived, but which route the drone took, which obstacles it avoided, and whether anyone gave it permission to land on your roof. The action is the same, but proving what happened takes more detail.

Vercel's technical guide addresses this ^[1]. It sets out practical patterns for logging agent actions in a way that allows reconstruction: which user or system initiated the chain, which tools the agent called, what each tool returned, and who approved what. The guide is built for developers working with AI agents that interact with APIs, databases and users, and it treats the audit trail as part of the architecture, not an afterthought.

What the guide recommends

The core idea is to capture each layer of an agent's activity as a distinct, traceable event. That means logging the instruction that started the chain, each tool call the agent made in response, the result of each call, and any human approval in between ^[1].

For example, say a customer asks an agent to reschedule a delivery. The agent checks the delivery schedule, proposes a new slot, waits for the customer to confirm, then updates the booking system. A complete audit trail records the customer's original message, the agent's call to the schedule API, the proposed slot, the customer's approval, and the final booking update, each with a timestamp and a reference to the user or system that triggered it.

The guide also covers error handling. When an agent fails partway through a chain, the log should show where it stopped and what it tried to do next ^[1]. That matters for debugging, but also for explaining to a customer or a supervisor why something didn't happen.

Why it matters under the AI Act

Article 12 of the AI Act requires high-risk AI systems to technically allow for the automatic recording of events over their lifetime ^[2]. It doesn't say how to protect those logs, but it does say what to capture: enough to understand what the system did and why.

AI agents that make decisions about people—hiring, credit, access to services—are likely to be high risk ^[3]. For systems in Annex III, the logging requirement applies from 2 December 2027 ^[2]. That gives organisations about a year to decide how their agents will log, what they will log, and who will be able to check it later.

The question isn't just whether the agent followed the rules. It's whether you can show, six months later, what the agent actually did when a customer disputes the outcome. A log its operator can edit is easy to challenge. A log nobody can check is worse.

What this means for you

If you're building or running AI agents, the technical challenge is linking events in a way that makes sense to someone who wasn't there. Vercel's guide gives one way to do that. The legal challenge is knowing that the logs will be questioned, possibly in front of a supervisor or a court.

Here are three questions to ask now:

1. Does your agent log the instruction, the tool calls, the approvals and the results, or just some of them?
2. When an agent acts on a user's behalf, can you show which user, and when they gave permission?
3. If an agent's decision is challenged a year from now, could you reconstruct what it did and why?

Article 26 of the AI Act also requires users of high-risk systems to inform people affected by decisions ^[4]. That includes telling them, on request, the reasoning behind an automated decision. If the agent didn't log enough to explain itself, that becomes hard to do.

How a digital witness fits here

This is a strong fit for a digital witness. The thing to seal is each step the agent takes: the instruction it received, each tool call it made, the result of each call, and any approval along the way. Sealing takes a fingerprint, not the data, so the log itself never leaves your systems.

Seal each event when it happens. If an agent updates a booking, seal the record of that update the moment it's written. If it waits for approval, seal the approval event when the user confirms.

Anyone you share the log with—an auditor, a supervisor, the person affected—can later check that it's the same log that was sealed on the day. Change a single character in the record and the fingerprint won't match.

What it doesn't do: it doesn't authorise the agent's actions, and it doesn't show that the decision was right. It shows that the record of what the agent did, and when, hasn't changed since it was sealed. That's narrower than compliance, but it's the part compliance audits tend to ask for.

You can start with WitniumChain: send a fingerprint of each log entry through the REST API, the SDK or the MCP server, and get a witness ID back. The first 2,000 witnesses a month are free. Read the docs to see how it works with your logging stack.

How it would work

1. Your agent writes each instruction, tool call, approval and result to its log.
2. Your system sends a fingerprint of each entry to WitniumChain as it's written, and stores the witness ID with the entry.
3. When someone questions what the agent did, you share the log and the witness IDs, and they check that the fingerprints still match.

What to watch

The AI Act's logging requirement for high-risk systems in Annex III applies from 2 December 2027 ^[2]. If your agents make decisions about employment, credit, access to essential services, law enforcement or migration, you have until then to decide what they log and how you keep it checkable.

Standards for AI logging and traceability are still being written. The European Commission's AI Office has published preliminary guidance, but detailed technical standards under Article 41 are expected in 2026 and 2027. Those standards will set out what 'automatic recording of events' means in practice, and they are likely to say more about reconstruction and auditability than the regulation itself does.

Vercel's guide isn't the only approach, but it's one of the first public, technical attempts to say how logging for AI agents should actually work. Worth reading if you build them, or if you have to explain to a board why the agents you run need better logs.