When we built the agent's state, every step became one Event: an id, a timestamp, an author, and the
content of what happened. The list of events is a complete, attributed, time-ordered record of a run.
That record is the answer to a question auditors have asked for decades. Who did this, and when?
An agent is an actor with no person behind it
A control framework written for people assumes a person is behind every meaningful action. Someone approved the refund. Someone exported the data. The log ties the action to the human, and the human is accountable.
An agent breaks that assumption in the most literal way. The agent reads, decides, and calls a tool, and no person authorised that specific step. So the question "who did this" needs a new answer, and the event log is where the answer lives: this execution, at this timestamp, by this agent, took this action with these arguments.
Getting that record as a by-product of good structure is genuinely useful. It also invites a dangerous assumption, which is that having a log is the same as having an audit trail.
The log you have versus the log an auditor wants
The two overlap, and the gap between them is the security work.
| An auditor asks | A basic event log answers | The gap |
|---|---|---|
| What action was taken? | Yes, the tool name | Often not the full arguments |
| When, and in what order? | Yes, timestamps | Clock trust, ordering under concurrency |
| By which actor, on whose behalf? | The agent name | Rarely the end user or tenant |
| Can the record be altered after the fact? | Usually silently, yes | No tamper-evidence |
| How long is it kept? | Until the process ends | No retention, no export |
| Who may read it? | Anyone with the object | No access control |
Read the right-hand column, because it is the list of things that turn a debugging aid into evidence.
A log an operator can edit after an incident proves nothing. A log that records search_web but not
the query it ran cannot tell you what the agent actually looked at. A record that vanishes when the
process exits was never a record.
A log tells you what happened. An audit trail proves it, to someone who was not there.
Repudiation is the failure mode
The security name for this gap is repudiation: an action was taken, and afterwards nobody can establish what happened or who was accountable. For an agent, repudiation is the default unless you design against it, because the actor is software and the record is a mutable list in memory.
The stakes rise with what the agent can do. An agent that only reads produces a log that matters for debugging. An agent that moves money, changes records or sends messages produces a log that matters for liability. When something goes wrong with the second kind, the event trail is the difference between "here is exactly what it did and on what basis" and "we think it did something around then".
Turning the log into a trail
None of the controls are novel. They are ordinary logging discipline, applied to a component that produces its own actions.
| Control | What it changes |
|---|---|
| Capture arguments, not just tool names | The record shows what the agent did, not merely that it acted |
| Record the end user and tenant on every event | Ties the action to whose behalf it was taken |
| Persist events outside the process | A record that survives the run, and the crash |
| Make the store append-only or tamper-evident | An edited log stops being evidence, so remove the ability to edit it |
| Set retention and access control | Kept as long as the obligation needs, readable only by those who should |
| Log the refusals and the stops too | "It declined" and "it hit the step limit" are events an investigation needs |
Six moves turn an in-memory event list into a record that stands up after the fact.
The last row is the one people forget. An investigation often turns on what the agent did not do, so a stop, a refusal or a hit step-limit belongs in the trail as much as an action does.
What this touches
For the frameworks, this sits on the MAESTRO Agent Frameworks and Monitoring layers and maps cleanly to T8 Repudiation and Untraceability, which the pack defines as actions that cannot be traced back due to insufficient logging or transparency. In the OWASP Agentic Top 10 the anchors are ASI08 and ASI09.
On the regulatory side, framed as scope rather than a citation: every GCC rulebook carries logging, record-keeping and accountability obligations, written on the assumption that a person stands behind a logged action. An autonomous agent is the case those rules did not quite picture, so the event trail is how you demonstrate the same accountability for a software actor. Which obligations apply depends on your regulator and architecture, and that mapping is an advisory estimate until someone checks it properly.
The part worth keeping
The event log is a real asset, and good agent structure hands it to you at no extra cost. That is worth celebrating rather than dismissing.
The point is only that a log and an audit trail are two different things. One helps you debug on a Tuesday. The other stands up months later, to someone who was not in the room, when it matters most. Closing the gap between them is a design decision you make on the way in, not a report you generate on the way out.