Ahead · 2026-10-19 · 5 min read
Audit logs for AI agents: who asked it to do what, and when
When an AI agent acts on someone's instruction, you need a record of what it did and who told it to. WorkOS shows how, using Claude's Compliance API as the model.
The agent did it, but who asked?
An AI agent books a hotel, changes an order or raises a support ticket. A week later someone questions it. The agent followed an instruction, but whose?
It's like handing your card to a friend and asking them to pay for lunch. If the charge turns up as something else, you need to know what your friend actually bought, and that you're the one who told them to spend it. The receipt is the record, and it needs to show both people.
That's the audit log question for AI agents, and WorkOS has written a guide to it [1]. They use Claude's Compliance API as the model, because it logs not just what the agent did but who delegated the action, which tools were called and what the results were. It's a good example of what enterprise AI logs need to contain, and it's worth reading if you're building anything that lets an agent act.
What to log
WorkOS breaks the log down into a few parts [1]:
- The agent: which system, model and version acted.
- The delegating user: who instructed the agent, either directly or through another system. The user might be a person or another agent, and the log needs to say which.
- The tool calls: which tools the agent used, with parameters and results. If it sent an email, the log records the recipient, the subject and whether it succeeded.
- Metadata: IP address, session ID, timestamps and the organisation the user belongs to.
The point is traceability. When something goes wrong, or when an auditor asks, you need to show not just that the agent acted but that it was told to, by whom and with what outcome.
Why it matters now
AI agents are moving from demos to production, and the things they do have consequences. They place orders, send messages, change records and make bookings. Some of those actions cost money. Some affect other people. All of them will be questioned at some point.
Article 12 of the AI Act, which applies to high-risk AI systems from 2 December 2027 for Annex III and from 2 August 2028 for Annex I, requires automatic logging over the system's lifetime [2]. It doesn't say how to protect the logs, but it does say they must exist. For AI agents, that means logging the instruction, the action and the result, in a way that lets you trace one back to the other.
WorkOS isn't writing about compliance specifically. They're writing about how to build audit logs that work, and the AI Act is one reason those logs are no longer optional.
The delegation chain
The trickiest part is the chain. Say a person tells an agent to do something, and that agent calls another agent. Who's responsible? The first person, the first agent or the second?
The answer, according to WorkOS, is that you log the whole chain [1]. Each log entry records the actor (the agent that acted), the acting on behalf of user (the person or system that told it to) and, if there's a chain, the original delegator. That way, an auditor or a supervisor can follow it back to the start.
It's the digital equivalent of a note that says "I asked Alice to ask Bob to send the invoice". If the invoice is wrong, everyone knows where to look.
The log is only as good as its protection
WorkOS describes what to log. They don't say much about how to keep it trustworthy, and that's the next question. A log its operator can quietly edit is a diary, not evidence. Access controls and monitoring are the foundation, but they don't answer the question that comes up in a dispute: how do you show that the log you're presenting is the one that was written at the time?
How a digital witness fits here
Here, the thing to seal is each agent action as it happens: the user reference, the agent identifier, the tool call, the parameters, the result and the timestamp. Sealing takes a fingerprint of the record, not the record itself, so the log stays in your systems. WitniumChain writes the fingerprint to a chain where a later change would show, and gives you back a witness ID.
When someone questions what the agent did, or an auditor asks to see the logs, you calculate the fingerprint of the record again and compare it with the sealed one. If they match, the record is exactly what was written at that time. Change a single character and it won't match. Anyone you share the record with can check it the same way, without having to ask you or trust you.
The witness doesn't authorise the action or make it correct. It doesn't show that the log is complete, that the agent should have done what it did or that the delegating user had the right to instruct it. What it does is let you show, in a way that holds up when questioned, that the record of what the agent did hasn't been rewritten since the moment it acted.
You can seal records through the REST API, the SDK or the MCP server. The log entries stay with you. The first 2,000 witnesses a month are free. Read the docs or get access now.
How it would work
- Your agent acts and writes a log entry.
- Your system sends a fingerprint of that entry to WitniumChain and gets a witness ID back.
- Later, when the record is questioned, you calculate the fingerprint again, compare it with the sealed one and share both the record and the proof with whoever needs to check it.
What this means for you
If you're building AI agents, or if your organisation is starting to use them, here are a few questions worth asking now:
- Do your agent logs record who instructed the agent, or just what it did?
- Can you trace an action back through a chain of delegations?
- If an agent changes a customer record, can you show which agent, on whose instruction and when?
- Could you prove that a log entry hasn't been edited, even by someone with administrator rights?
WorkOS's guide is a good starting point for the first three. For the fourth, you need something outside your own systems: a witness that records what was written, without anyone having to trust you to keep it unchanged.
What to watch
For high-risk AI systems under Annex III, the logging requirements in Article 12 apply from 2 December 2027 [2]. For Annex I systems, the date is 2 August 2028 [3]. If your agent makes decisions about people, assesses creditworthiness or does anything else in Annex III, that's the deadline for having logs that meet the rule.
The rule says what to log. Whether those logs will hold up when questioned is a separate matter, and one to decide sooner rather than later.
Sources
- [1]Audit logs for AI agents: Lessons from Claude's Compliance API, WorkOS, 2024
- [2]Article 12, AI Act, European Commission AI Act Service Desk, 2024
- [3]Timeline for implementation of the EU AI Act, European Commission AI Act Service Desk, 2024