An agent audit trail should answer a practical question: why did this exact action happen in this exact customer environment? Saving only a chat transcript leaves gaps. A concise structured record can connect the evidence the agent used, the proposal the reviewer saw, the approval authority and the result the implementation actually produced.
Record decisions as separate events
Assign a stable change ID. Record input retrieval time, tenant, source identifiers and relevant evidence hashes. Save the recommendation and its stated uncertainty separately from the proposed machine-readable diff. Include the model or workflow version if needed to reproduce the reasoning environment, without claiming that rerunning a model will produce identical prose.
Record approval identity, scope, expiry and the exact proposal hash. Then record execution attempts, backend responses, before and after observations, verification results and any rollback decision. Denied actions matter: an attempted wrong-tenant operation can reveal a defect even when no write occurred.
Bind the chain without overstating hashes
A proposed approval record can bind a digest of a proposal containing tenant, zone, record name, record type, operation, before value, after value and revision. The trusted approval service must establish who approved it; a hash alone cannot authenticate an approver. Do not let report text or the model's own output create an approval event.
OWASP recommends limiting agent authority and independently controlling high-impact operations. The audit design here is an original operational application of that principle, not a prescribed OWASP event schema. OWASP LLM06.
Reconstruct a hypothetical failed outcome
Suppose a record contains five events: input retrieval, proposal, approval, write attempt and verification. The final event reports that an authorized DNS observation matches the intended value but the representative message fails its required alignment check. Record the configuration observation and failed message postcondition separately. Neither the approval nor a successful write response closes the failed outcome. These are assumed events, not generated logs or actual tests.
A hash-linked event design stores the previous event’s digest in each next event. Altering one event while leaving later links unchanged can reveal inconsistency on verification. An actor able to rewrite the entire chain can recompute those links, so the design alone is not immutable evidence. Protect an independent checkpoint or equivalent integrity control, separate access and retain provenance. No hash-chain test or tamper-resistance benchmark is performed here.
Preserve useful evidence without collecting everything
Store the minimum raw material needed to explain the decision. Authentication reports and email samples can contain personal or customer-sensitive information. Keep private keys, tokens and credentials out of logs. Use evidence references rather than duplicating full messages into every event, and apply access and retention controls to both originals and derived summaries.
A reviewer should be able to tell whether an observation came from an authoritative DNS query, a recursive cache, a provider API response or a synthetic test. Label the environment and evidence type. Missing output is an unknown result, not a successful verification.
Make review and recovery possible
Include a correlation ID for retries so a timeout does not look like a second independent change. Before retrying an uncertain write, read current state and reconcile whether the first attempt executed. Record the reconciliation decision. Protect the audit path from the same agent that can propose changes, and test what happens if logging is unavailable. For sensitive changes, stopping before execution may be safer than creating an unauditable result.