Security asks for an agent audit trail, and the demonstration shows a timeline of messages and tool calls. It looks complete until someone asks whether the customer record changed, who approved that exact change, and whether the agent used another connection outside the timeline.

Define the audit question before accepting the export. A useful review follows a business action from request through authority, attempted execution, destination result, and any correction.

The MCP portable execution discussion raises the gap between individual call logs and a connected workflow history. For procurement, that gap becomes a test: can a reviewer reconstruct a selected action without the agent’s own narrative?

Choose the unit under review#

Start with a concrete action such as changing a customer’s renewal date. A whole conversation is too broad and one HTTP request too narrow: the unit covers the decision and effect the business cares about, across however many calls it took.

Write down each claim to prove:

The requester was entitled to ask.
The approver had authority.
The approved proposal matched the attempted action.
The destination accepted or rejected the change.
A later correction links to the original event.

A model explanation does not prove why a system acted; authority and destination state need their own records. Likewise, a successful tool response shows a request was accepted, not that an asynchronous job finished.

Review question	Evidence to request
Who initiated the task?	Authenticated requester and delegation information
What was authorized?	Exact proposal, approver, scope, and decision time
What was attempted?	Destination, operation, and stable action identifier
What happened?	Destination response or later state verification
What changed afterward?	Linked correction, retry, or reversal
What lies outside this view?	Other credentials, tools, and execution paths

Reconstruct a difficult example#

Take an account change that times out. The agent reports failure, but the destination already saved the new date, and a retry then sees a conflict. If the audit package holds only the first tool response, a reviewer concludes nothing happened. If it holds only the final account state, they cannot explain the duplicate attempt.

A reviewer reconstructs one timeout from the audit package alone.

Ask the seller or operator to reconstruct that sequence with synthetic data: the timeout, the destination-state check, the retry decision, and the final outcome. A missing response is a fact to investigate and gives no basis to infer success or failure.

Then inspect a denied action. Show that the denial links to a specific proposal and that the prohibited action did not execute through the tested path. One missing log entry says nothing about every other external path.

Check coverage and retention separately#

One system captures the right events and retains them for too little time. Another retains years of logs that lack the fields needed for attribution. Review both dimensions, and confirm who can export the data and whether an investigator keeps access after the original employee leaves.

GitHub’s enterprise audit documentation describes its own audit surface, one source in a larger workflow that does not hold the full agent decision chain.

Minimize sensitive payloads according to the review purpose. Sometimes identifiers and a controlled source reference suffice; sometimes a versioned copy shows what the approver saw. Let the investigation set the evidence design, not cheap storage.

State the limit of the claim#

An audit package demonstrates attribution and reconstruction for a defined path. It does not show that every action was appropriate, that all credentials were covered, or that the organization satisfies a particular legal obligation; the responsible teams evaluate those separately.

Deixic’s evidence and activity guide shows operators how to inspect decisions and results. The audit-row essay covers an individual action record. Procurement covers export and retention arrangements for the actual purchase.

End with a written scope: the workflow, systems, action types, identities, period, and excluded paths, plus one successful reconstruction and one failure or denial example.