The agent audit trail: what to record and what auditors will ask

Every agent platform produces logs. Far fewer produce an audit trail. The difference is who the record is for. A log helps an engineer see what a process did. An audit trail lets someone who was not in the room, weeks later, establish who asked for a piece of work, who allowed each consequential step, what actually ran and what came of it. When agents act on behalf of a team, the second kind of record is the one you will be asked for.

Five kinds of event, one record

An agent run produces many events, but an audit needs five kinds, and it needs them linked to each other.

• The request. The instruction as it was given, by whom, under which work order, with the scope and bounds that applied. Paraphrased goals drift over time; keep the original wording.
• The decision. For every action that paused: who decided, when, and on exactly what. The approver saw a specific call, so the record should hold that call word for word, not a summary of it.
• The tool run. Which tool was called, with which inputs, under which credential reference, and what it returned, errors included. Record the reference to a credential, never the secret itself.
• The outcome. What changed outside the agent: the message sent, the file written, the record updated, the deliverable produced, together with the sources that support it.
• The refusal. Every time something did not happen: a person rejected a step, a policy blocked a call, a bound was reached, a dependency was unavailable. Teams forget to keep these more than any other event, and auditors find them the most telling.

Why the record has to be continuous

Most teams already hold pieces of this. The approval lives in a chat thread, the tool call in a job runner, the outcome in the target system's own history. Each piece is accurate. Together they still fail, because the link between them is a guess made by matching timestamps.

The link is the point. An auditor does not only want to know that someone approved an email and that an email was sent. They want to know that the email sent is the email that was approved, that it went out once, and that it went out after the decision rather than before it. That chain only holds if the request, the decision, the run and the outcome sit on one record in the order they happened. If you have to join three systems to answer the question, you are reconstructing, not reading.

Sampled and reconstructed logs are not audit

Two shortcuts look like audit and are not.

Sampling. Keeping one run in ten, or only the runs that errored, is a reasonable way to watch performance. It is useless for audit, because audit questions are about specific events. “Did the agent ever export this folder?” cannot be answered from a sample. Neither can “show me every rejection from last quarter.”

Reconstruction. Some systems rebuild a history after the fact: from the agent's own summary of what it did, from the current state of the target system, or from a trace assembled when somebody asks. A summary written by the agent is a claim about its work, not evidence of it. Current state shows where things ended up, not who moved them there. A trail earns trust because each entry was written when the event happened and was never edited afterwards.

A related trap is the demo view. A screen that shows illustrative entries so the page does not look empty teaches people to trust a view that may reflect nothing at all. An audit page should show real entries or an honest empty state, and nothing in between.

Questions an auditor will ask

Test your trail against the questions it will actually face. For any piece of agent work, you should be able to answer these by reading, not by investigating:

1. Who started this work, with what goal, and inside which scope?
2. Which steps paused for a decision, who decided each one, and what exactly were they shown?
3. Was the call that ran identical to the call that was approved?
4. Which tools ran, with which credentials, and what did they return?
5. What did the agent produce, and which sources support it?
6. What was rejected, blocked or refused, and did the work find another way through?
7. Was the work stopped or resumed, and by whom?
8. How much did it spend, and against which spend ceiling?

Question six is the one weak trails fail. If a rejection shows up only as an absence of activity, you cannot prove the agent did not route around it.

How GoCux keeps the record

In GoCux each piece of work runs as a work order, and its steps are written to that order's record as they occur, so the result, its sources and the decisions taken along the way stay together. When an action pauses, the held call is quoted exactly, and the decision and its outcome are sealed as receipts at the moment they happen. Rejections are recorded too, and a rejection never releases the work. Requests, decisions, tool runs and outcomes read as a single trail inside the workspace, and there is no sample mode on the audit page. Resuming work after the stop control has been used is a deliberate act with a name attached. The governance page shows how these pieces fit together.

Check your own trail

• Pick one completed run and answer the eight questions above using only the record. Note every answer that needed another system.
• Find a rejected step and confirm the rejection is an entry, not a gap.
• Compare an approved call with the executed one. They should match exactly.
• Confirm that credentials appear as references, not values.
• Check that entries cannot be edited once written, and that nothing on the audit view is illustrative.
• Make sure the trail covers every kind of action that pauses; the seven action classes are a good starting list.

For the pause itself, read why agents should ask before acting. For why a refusal deserves its own entry, see a refusal is a result. And for who should be making the decisions the trail records, see who may approve agent work.