What a useful AI audit trail must record

An AI audit trail is a record of what an AI system did, what it attempted to do, and who authorised actions that needed a person's approval. For an AI agent that can send messages, update records or spend money, the trail should preserve the exact action, its payload, the approval decision and the information the approver saw. A timestamp and a line saying "approved" are not enough.

The test is simple. Suppose an agent changes a supplier's bank details and a payment goes to the wrong account. Can you reconstruct which details the agent proposed, which details a person approved, and which details were actually submitted? Can you tell if anything changed between those steps? If the answer depends on asking the agent what happened, the audit trail has already failed its most useful test.

Record the action, not the agent's account of it

An agent might report, "Updated the supplier record successfully." That sentence belongs in a work summary. It does not tell an operations lead which record changed, which fields were touched or whether the destination system accepted the update.

A useful trail records events at the point where they happen. A request to an integration is one event. The integration's response is another. If the agent retries after a timeout, that retry belongs in the record too. Otherwise, a reviewer might see one successful update without discovering that the same instruction was submitted twice.

Each event needs enough context to identify the delegation, the agent acting under it, the tool used, the target and the outcome. A timestamp helps put events in order, but timestamps alone do not establish causation. The record should connect a proposed action to its approval, execution attempt and final response through identifiers that survive retries.

There is also a difference between asking a tool to do something and knowing that it happened. An API response can confirm acceptance without confirming completion. A queued email may still fail to send. The trail should keep those states separate instead of turning every accepted request into a claimed result.

Keep the payload that was actually approved

Consider an outreach agent preparing a message to a prospective partner. A log entry saying "Email approved at 14:06" identifies a decision but leaves the most interesting evidence missing. What was the recipient address? What did the subject line say? Did the body include a proposed commercial commitment?

The approval needs to be tied to a specific version of the proposed action. For an email, that means the recipient, subject, body and relevant attachments. For a payment, it means the destination, currency, amount and payment reference. For a record update, it means the record identifier and the values being changed.

That does not mean putting every secret into an unrestricted logging database. Access tokens, passwords and unrelated personal information should not be copied into a trail for convenience. Sensitive payloads can require restricted access, selective masking and separate retention rules. The point is to preserve enough authenticated evidence for an authorised reviewer to establish what was submitted, without creating another place for credentials to leak.

One useful design is to bind the approval to a fixed payload version or cryptographic digest. If the agent edits the message after approval, the new version no longer matches the approved one. It must go back for a decision. Approval should never be treated as permission to send whatever the agent happens to produce next.

The approver's view belongs in the evidence

An approval record has two sides: the decision a person made and the information available when that person made it. Keeping only the decision loses half the story.

Imagine that an approval card describes an action as "Update customer account," while the underlying request changes the billing email and deletes an existing payment instruction. The reviewer may click approve without understanding the full effect. Months later, a log with the person's name beside "approved" would make the decision look better informed than it was.

For actions with external consequences, the trail should preserve the approval presentation or a reliable representation of its contents. Which fields were visible? Which were hidden behind an expandable detail? Was there a warning, an estimated cost or an expiry deadline? What exact version did the person accept?

In Delagents, actions with effects outside the workspace wait in an approvals inbox. Each card shows the exact action, the cost so far and a deadline, and a person can approve, change or reject it. The audit question follows directly from that design: the recorded decision should remain connected to the action that the card presented, including any changes made before approval.

Identity needs equal care. A useful record distinguishes the agent that proposed an action, the person who authorised it and the account or integration that executed it. A generic "admin approved" entry is weak evidence if several people share the role. It may tell you that permission existed somewhere, but not who exercised it.

An editable log cannot settle a dispute

Suppose a manager questions why an agent sent a document to an external recipient. The person responsible for the system opens the activity log, finds the event and changes the recipient address before exporting the record. The export now tells a tidy story. Nothing in the file reveals that the story was edited.

This is why editability matters. An ordinary activity list can help people supervise work, but if past events can be silently rewritten, it cannot independently support an investigation. The ability to correct a display error should not include the ability to alter the historical evidence underneath.

An append-only log takes a different approach. New entries can be added, including corrections, but existing entries cannot simply be replaced through the normal application path. If an event was misclassified, a correction should point to the original and explain the change. Both remain visible.

Append-only storage is a necessary design choice, not a complete guarantee. A system administrator with unrestricted control over the underlying storage might still be able to tamper with it. Teams with stronger evidence requirements should examine write permissions, access to exported records, storage protections and whether alterations can be detected independently. Hash chaining, signed records or independently controlled storage may help, provided their keys and administration are protected too.

There is a practical privacy question here. Records may need to be retained for an investigation and later removed under a retention policy. That policy should define who can authorise deletion, how deletion is recorded and what must remain as evidence of the decision. "Append-only" should never be used as an excuse to retain sensitive material indefinitely.

Record policy changes beside the work

An agent's action can be technically valid and still raise a serious question: why was the agent permitted to do it?

Picture an agent that normally reads a shared inbox. On Tuesday, somebody widens its integration scope so it can modify contact records. On Wednesday, it overwrites a phone number. An audit trail containing only Wednesday's tool call misses the change that made the action possible.

Policy history should show the previous permission, the new permission, who requested the change, who approved it and when it took effect. Where the system uses a rule version, the action record should identify which version governed the decision. A later policy change should not rewrite the apparent rules of an earlier event.

The security model at Delagents includes an append-only activity log for tool calls, approvals and policy changes. This matters because a reviewer may need to reconstruct both the action and the authority behind it. A hard budget cap on each delegation also gives a spending boundary that can be checked against the work performed.

The same principle applies when something is blocked. A rejected request or a denied permission change is useful evidence, particularly if the agent tries again through another tool. Recording only successful actions removes the events that may best explain how the system behaved under pressure.

Test the trail before handing over sensitive work

You do not need to begin with a payment or a live customer record. Use a controlled test in which an agent drafts an email to a test recipient, requests approval, receives a change to the recipient address and then completes the approved action. Keep the original proposal and the revised one.

Have someone who did not watch the test reconstruct what happened using only the audit evidence. Give them a few specific questions:

1. What exact recipient and message did the agent propose first?
2. Who changed the recipient, what did the approval card show afterward, and who approved the final version?
3. Which payload was submitted to the sending tool, and what response did the tool return?
4. If the agent retried or a permission changed, can the reviewer see that event in the correct order?
5. Can someone with routine workspace access alter an earlier event without leaving evidence?

Ask the reviewer to locate the records rather than accept a reconstructed narrative generated by the same agent. If the trail shows the final email but cannot recover the original proposal, note the gap. If the approval event has no connection to the executed payload, note that separately. These are different problems and require different fixes.

Before moving to a live delegation, repeat the test with a rejection and a failed tool call. Check what happens when an approval expires without a decision. An audit trail that looks complete on the happy path may reveal very little about work that was interrupted.

Put this reconstruction exercise on the checklist for your next agent pilot. Assign one person to approve the test action and another to inspect the evidence afterward. Do not give the agent permission to send externally or change live records until the second person can match the request, the approval and the actual execution without relying on the agent's own explanation.