Agent auditability is the ability to reconstruct an agent's actions and examine the evidence behind them. A transcript captures what was said. An audit trail also needs to explain which identity acted, what it was allowed to do, which tool ran, which source informed the answer and what changed.
Record decisions at the service boundary
Give a run and its tool calls stable identifiers. Record the caller, the applicable authorization decision, tool version, timestamps, outcome and references to relevant artifacts. Keep model and prompt versions available alongside the execution record. A tool's own service should record the operation it actually executed, rather than trusting a model's description of it.
Avoid treating every payload as something to retain forever. Define which fields can be logged, which require redaction, who can inspect records and how long they remain available. An audit system that leaks customer data creates a new incident surface.
Illustrative audit event:
run_id / tool_call_id / actor_reference
operation / tool_version / authorization_decision
started_at / finished_at / outcome / artifact_references
These fields are a starting point, not a compliance standard. The record must fit the operations and questions the organization needs to investigate.
Distinguish observation from justification
A trace may show that a tool ran. It does not automatically show that the user had permission, that the returned data supported the conclusion or that deployment was justified. Attach the evidence relevant to each decision. For a release, that may include the evaluated configuration, test results, approval and deployed identity.
My preprint From Traceability to Justifiability examines this distinction in public delivery records. Its findings have a defined sample and observation date. The paper and repository allow readers to inspect the method instead of accepting a general claim that all agent pipelines behave the same way.
Check whether the trail answers an incident question
Take a failed or disputed action and try to reconstruct it without asking the original agent. Can another reviewer identify the actual tool arguments, relevant permission decision and outcome? Can they distinguish an attempted operation from a committed change? Can they identify missing evidence instead of receiving a fabricated explanation?
Test interrupted runs, denied operations, retries and partial failures. Check that sensitive data remains protected when someone reads the audit trail.
Evidence to request when choosing an engineer
Ask for an example incident reconstruction and the records that support it. Look for clear boundaries between what the system observed, what the engineer inferred and what remains unknown. The MetaMCP and evaluation-harness cases below show implementation work; the research source explains the accountability questions behind it.