AI Agent Audit Trails: Logs, Receipts and Verification

15 minute read · Reviewed 11 August 2026 · Security expert review required before publication

An AI agent audit trail is a durable record that connects an agent's verified identity and delegated authority to the exact request, policy decision, execution attempt and observed outcome. Operational logs remain necessary for debugging and monitoring. Signed action receipts add stable semantics, integrity protection and portable verification. A defensible audit trail uses both and states clearly what each record can prove.

This guide is for platform, security and audit engineering teams that need to reconstruct consequential agent actions without relying on a model transcript or one mutable database. It provides a comparison model, a conceptual receipt schema, an offline verification procedure and failure fixtures that can be turned into acceptance tests.

What belongs in an AI agent audit trail?

The trail should answer these questions without asking the model to explain itself after the event:

Which agent acted, and which organization was accountable?
Which delegated authority and policy version were evaluated?
What exact request was allowed, denied or sent for approval?
Which protected system received the action?
What did that system report at the time?
Did later settlement, fulfillment, reversal or reconciliation change the outcome?
Can a verifier detect altered or missing evidence?

A chat transcript may show how the agent described its intent. It does not establish the request that reached the payment provider, the mandate that was active or the policy code that ran. A row such as agent_action=success is even weaker because it collapses several states into one label.

Logs, traces, receipts and outcome records

These records serve different operators and retention needs.

Record	Primary job	Typical strengths	Important limit
Application log	diagnose service behavior	searchable, detailed, easy to aggregate	schema and retention can change; administrators may alter it
Distributed trace	follow work across services	request correlation, timing and dependency path	usually records observation, not delegated authority
Action receipt	preserve a protected decision and action	stable schema, request digest, policy and signature	signer attestation does not prove every input fact was true
Outcome record	reconcile later external state	settlement, delivery, reversal or dispute linkage	depends on source quality and reconciliation rules

OpenTelemetry's log data model provides fields such as Timestamp, ObservedTimestamp, TraceId, SpanId, severity and structured attributes. Those fields make logs portable and correlatable. The OpenTelemetry Logs Data Model does not turn every log into transaction evidence. That stronger role requires explicit authority, request and verification semantics.

Receipts do not replace logs. An investigator may use a receipt to identify the transaction, policy and external reference, then use traces and logs to find a timeout or retry. Conversely, a trace ID inside the receipt can connect protected evidence to operational detail without copying sensitive payloads into the portable record.

Define evidence claims before defining fields

Start by listing which claims a verifier needs and which system can support each one.

Claim	Evidence source	Verification
Agent key signed the request	signed transaction envelope	signature, audience, time and key lifecycle checks
Agent had delegated authority	mandate and decision record	issuer trust, revocation and constraint evaluation
Policy allowed the request	policy bundle and decision	policy digest plus deterministic replay
Provider accepted a submission	provider response or query	provider reference and reconciliation
Funds settled	payment system of record	settlement query or signed provider event
Goods arrived	carrier and receiving records	source validation and corroboration

A signature establishes integrity, signer attribution under the verified key and the issuer's attestation. It does not prove that a physical delivery occurred, that a provider response was truthful or that no enforcement bypass existed. Store assurance labels such as unilateral, counterparty_signed or corroborated only when their verification rules are defined.

A request-bound action receipt

The receipt should bind the protected transaction rather than a human summary written after it.

type ActionReceipt = {
  version: 1;
  receiptId: string;
  transactionId: string;
  issuer: {
    organizationId: string;
    agentId?: string;
    verificationMethod: string;
  };
  authority: {
    passportDigest: string;
    mandateDigest: string;
    policyDigest: string;
    approvalDigest?: string;
  };
  request: {
    action: string;
    resource: string;
    destination: string;
    canonicalDigest: string;
    idempotencyKey: string;
  };
  decision: {
    result: 'allow' | 'deny' | 'approval_required';
    reasonCodes: string[];
    decidedAt: string;
  };
  execution?: {
    status:
      | 'not_attempted'
      | 'submitted'
      | 'accepted'
      | 'rejected'
      | 'uncertain';
    externalReference?: string;
    observedAt: string;
  };
  evidenceRefs: Array<{
    type: string;
    digest: string;
    uri?: string;
  }>;
  assurance: 'unilateral' | 'counterparty_signed' | 'corroborated';
  proof: {
    createdAt: string;
    signature: string;
  };
};

This is an illustrative schema, not the verbatim OATI Receipt schema. The request digest should cover normalized action parameters, resource, counterparty, destination, commercial terms and any context that changes authorization. The policy digest identifies the evaluated artifact. An approval digest binds a human decision to the same canonical request.

Canonicalization must be specified. Two valid JSON serializations can differ in key order, numbers or Unicode representation. RFC 8785 defines the JSON Canonicalization Scheme for repeatable hashing and signing. Publish cross-language fixtures for your selected signature profile.

Avoid raw card data, credentials, private prompts and complete customer records in portable receipts. Use minimal claims, digests and controlled evidence references. Integrity protection does not reduce the damage of disclosing sensitive data.

Separate authorization from execution and outcome

One success field cannot describe a distributed transaction. A policy can allow a request, the gateway can dispatch it and the provider can time out after accepting it. Later, the transaction can settle or reverse.

PROPOSED
  -> DENIED | APPROVAL_REQUIRED | AUTHORIZED
AUTHORIZED
  -> NOT_DISPATCHED | SUBMITTED
SUBMITTED
  -> ACCEPTED | REJECTED | UNCERTAIN
ACCEPTED
  -> SETTLED | FAILED | RETURNED | REVERSED

Record each state transition as an append-only event or a linked signed record. When a provider response is lost, the first receipt should say uncertain. A reconciler can later append a settlement record using the same transaction and external references. Rewriting the original receipt would erase the fact that the system was uncertain at an important moment.

The Universal Commerce Protocol treats an order response as a current-state snapshot and uses events plus retrieval for continuing order state. The UCP Order specification supports the same operational separation: protected transaction evidence and changing commerce state need stable links, not one frozen status label.

Offline verification procedure

An independent verifier should run a deterministic sequence and return partial results rather than a single green check.

type VerificationFinding = {
  check: string;
  result: 'pass' | 'fail' | 'unknown';
  detail: string;
};

type VerificationReport = {
  receiptId: string;
  integrity: 'valid' | 'invalid' | 'unknown';
  findings: VerificationFinding[];
  unresolvedEvidence: string[];
};

The verifier should:

Validate the receipt against its declared schema version.
Resolve the issuer, trust chain and verification key.
Check key validity, rotation and compromise policy at receipt time.
Recreate the canonical signing payload and verify the signature.
Resolve Passport and mandate status, including revocation.
Recompute the retained request digest.
Reevaluate mandate constraints and the recorded policy version.
Verify any exact approval against the same request digest.
Match the idempotency key and external reference to the authoritative record.
Follow corrections, reversals and reconciliation records.

A valid top-level signature with a missing request artifact produces an unknown binding result. It should not silently become a fully verified transaction. Likewise, a valid provider event does not prove the agent had authority unless the verifier can connect it to the earlier decision.

Receipt and log correlation pattern

Use stable identifiers across the receipt, trace and business record while limiting sensitive duplication.

{
  "transaction_id": "txn:buyer:8841",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "receipt_id": "receipt:buyer:01K2",
  "idempotency_key": "payment:buyer:INV-8841:v1",
  "external_reference": "provider:pi_3Q...",
  "request_digest": "sha256:6e4f..."
}

The transaction ID belongs to the enterprise workflow. The trace ID connects telemetry. The idempotency key controls retries. The external reference joins to the provider. The digest binds the exact request. Reusing one identifier for every purpose creates ambiguity when a workflow retries, branches or reconciles.

Retention and access policy should be field aware. Keep enough signed material to verify historical decisions after ordinary key rotation, while storing sensitive payloads in a controlled evidence service with narrower access and a documented deletion schedule. Record who retrieved an evidence package and for which case. If legal hold, privacy deletion and audit retention requirements conflict, route the case to the accountable records owner instead of letting the receipt service improvise. A digest can show that a retained artifact matches the original reference. It cannot restore content that was deleted or prove what inaccessible content once said.

Failure and recovery cases

Failure	Detection	Recovery
Receipt body changes after signing	signature failure	quarantine record and retrieve trusted copy
Valid receipt references another request	digest mismatch	retain both artifacts and flag substitution
Mandate was revoked before execution	lifecycle check failure	classify authorization evidence as invalid
Policy source changed after the event	stored digest differs	retrieve versioned policy artifact
Provider timed out after submission	no authoritative terminal response	keep state uncertain and reconcile by stable key
Signing key rotates	current key differs	resolve historical key and validity interval
Signing key is later compromised	compromise policy applies	classify receipts by trusted time boundary
Evidence URI disappears	retrieval fails	use retained digest to detect replacement; report content missing
Two records claim conflicting outcomes	linked state conflict	preserve both and query authoritative system
Counterparty disputes unilateral evidence	assurance check	avoid mutual-proof claim and seek counterparty evidence

Key compromise deserves an explicit rule. Rotation is routine and should preserve historical verification. Compromise may require rejecting records after a known time or downgrading assurance when the compromise window is uncertain. That rule belongs in the verification policy, not in an incident-specific spreadsheet.

A reproducible audit-trail fixture

Build one complete fixture package and use it in release tests:

fixture/
  passport.json
  mandate.json
  request.json
  policy.bundle
  approval.json
  receipt.json
  provider-response.json
  reconciliation.json
  expected-verification-report.json

Run these mutations independently:

change one request amount after approval;
revoke the mandate one second before execution;
reorder and reserialize JSON before verification;
remove the provider response;
rotate the receipt key;
duplicate the submission with the same idempotency key;
present a valid receipt under the wrong transaction;
add a conflicting reconciliation result.

The expected report should identify the failed check and preserve all checks that still pass. This is more useful than a test that expects only true or false, because production investigations usually contain incomplete evidence rather than perfectly invalid packages.

What current payment protocols contribute

AP2 defines Checkout and Payment Mandates with corresponding receipts. It requires role-specific validation to occur in deterministic code and links receipts to the mandates used for a transaction. Its dispute section describes how the mandate and receipt pairs can be verified, while leaving operational retention and retrieval outside the current specification. The AP2 specification is useful because it exposes both the protocol object and the operational gap.

That gap is where enterprise audit design lives. A schema cannot choose retention periods, preserve historical keys, reconcile a payment reversal, enforce tenant access or package evidence for an auditor. Teams need those services even when every participant agrees on the wire format.

Current Intelliger and OATI boundary

OATI's public developer preview implements Receipt schemas, builders, RFC 8785/JCS canonicalization, Ed25519 and ES256 profiles, verification, examples, middleware and shared conformance fixtures. The deployed control-plane vertical slice emits an issuance Receipt for a credential ceremony. That issuance record is separate from a later protected business transaction.

Durable bilateral evidence, retention, audit-package export and dispute workflows remain incomplete. Independent cryptographic and protocol review is also open. A sandbox transaction demonstrates the developer contract, while a complete two-enterprise production dispute exercise remains a release gate. The target Intelliger Outcome Ledger and cross-merchant outcome verification are blueprint components, not deployed services.

Security review note: an expert must review retention, access control, cryptographic lifecycle, assurance labels, privacy and dispute procedures for the deployment. This article was reviewed against OATI's documented developer-preview status on 11 August 2026. It does not certify a particular evidence system.

Put the audit model into use

The broader AI agent authorization guide explains how authority is bound before execution. Compare the engineering tradeoffs in action receipts versus application logs and follow the complete flow in an auditable MCP transaction. The OATI Receipt documentation and public verifier provide the relevant developer path.

To adapt the fixture package and structured verification report to your stack, open the public OATI repository.