Verifiable AI Agent Audit Trails and Signed Receipts

From operational logs to verifiable evidence

An AI agent audit trail is a chronological record of security-relevant actions and decisions associated with a distinct agent identity. It should help answer who called, how the caller authenticated, what controlled capability was requested, which policy applied, whether the request was allowed, what limit was reserved and when the event occurred.

Ordinary application logs help operators debug incidents, but they are usually mutable and controlled by the same organization whose behavior they describe. A screenshot or CSV export can be edited after the fact. Access controls and append-only storage improve the situation, yet an outside reviewer still needs to trust the service, database and export process.

A signed receipt adds a cryptographic integrity statement to a canonical event. Anyone with the receipt and the published verification key can test whether the signed fields changed after issuance. This does not prove that every event was recorded or that the original decision was wise. It proves a narrower, valuable fact: the holder of the signing key attested to this exact record.

Tamper-evident means alteration can be detected. It does not mean the system is complete, truthful about facts it never observed, or impossible to compromise.

Record the minimum useful event

Good audit design starts with a threat model, not with collecting everything. For a credential gateway, useful fields include a stable receipt ID, agent ID, authentication method, destination provider and model, policy decision, budget reservation, timestamp, request correlation ID and software or key version. These fields explain the control-plane decision without copying customer content.

Provider keys, gateway credentials, prompts and model responses should not appear in the receipt. They increase breach impact, complicate retention and make portable evidence unsafe to share. Even apparently harmless metadata can be sensitive at scale, so document retention, access and redaction rules. A receipt should be useful to verify without becoming a replayable credential.

Distinguish observed facts from claims. The gateway can attest that it authenticated a particular credential and forwarded a request to a destination. It cannot necessarily attest that a named human wrote the prompt, that the agent's internal reasoning matched its stated purpose, or that the provider executed the request exactly as expected unless separate evidence supports those claims.

• Identify the agent and real authentication method.
• Describe the controlled destination and decision.
• Include time, correlation and policy or key version.
• Exclude secrets and customer prompt or response content.
• Use explicit semantics for absent or unknown values.

Canonicalize, hash and sign deterministically

Digital signatures operate on bytes, while structured records can have many equivalent serializations. A verifier needs a canonical representation with fixed field names, ordering, encodings and treatment of missing values. Otherwise the issuer and verifier may calculate different messages from the same apparent JSON object, or an attacker may exploit ambiguous representations.

The issuer serializes the approved fields canonically, hashes or directly signs those bytes with a private key, and attaches the signature plus a key identifier. The verification key is published separately. The verifier reconstructs the canonical bytes, selects the stated public key and checks the signature. Any change to a signed field causes verification to fail.

Protect the signing key more strongly than ordinary application configuration. Restrict which component can invoke it, rotate it with an overlap period, publish key status and preserve retired public keys for historical verification. A receipt needs a key identifier and algorithm so verifiers do not guess. Algorithm agility should not permit weak or unspecified choices.

Use chains and checkpoints for sequence integrity

A signature protects one receipt from alteration, but it does not reveal that a different signed receipt was deleted. Hash chaining links each event to the digest of the previous event in a defined stream. Removing or reordering an interior event breaks the subsequent chain. The stream boundary must be explicit, such as one agent or account, so verification has stable semantics.

Chains alone still allow an operator with the signing key to rewrite a suffix and sign it again. Periodic checkpoints published to a separate system, customer archive or transparency service make later rewriting more detectable. Sequence numbers and monotonic timestamps help diagnose gaps, but distributed systems need clear rules for concurrency and delayed events.

These techniques add operational cost. Choose them when the threat model requires sequence or completeness evidence. For many workflows, a portable signature over each receipt plus independent customer storage provides a useful first step. Do not market individual signatures as proof that no event is missing.

A signed receipt protects record integrity. A chain detects sequence changes. An external checkpoint makes later history rewriting harder to hide.

Verification must work outside the dashboard

Independent verification means the reviewer does not need a privileged session in the issuing product. Provide the signed payload, signature, algorithm, key identifier and a stable route for obtaining the public key. A small open verifier or documented command makes the process reproducible and reduces the chance that only the issuer's UI understands the format.

Test positive and negative cases. An authentic receipt should verify with the matching key. Changing the agent ID, destination, decision or timestamp should fail. The wrong public key, a malformed signature and an unsupported algorithm should fail closed with clear errors. Verification should not make a network request that leaks the receipt unless the user explicitly chooses an online service.

Key rotation needs historical semantics. A public key may be retired for new signatures while remaining valid for receipts issued during its active interval. Publish activation and retirement times, retain old public keys, and distinguish a compromised key from a normally rotated one. Reviewers then know whether a cryptographically valid receipt also falls within the key's trusted period.

Use receipts for accountability, with stated limits

Signed receipts can support incident reconstruction, customer evidence, delegated-agent accountability and dispute resolution. They let a platform demonstrate that a particular agent identity passed or failed a control at a given time, without exposing the upstream credential or prompt content. Customers can archive receipts in their own environment and verify them later.

They do not prove that the signing service was uncompromised, that its clock was perfect, that every request produced a receipt or that an agent's output was correct. Complement receipts with access controls, monitoring, key protection, retention policy, backups and independent checkpoints where needed. State these limitations anywhere the evidence is described.

PassControl emits minimal signed call receipts for its gateway decisions and exposes verification material so the integrity check can happen independently. The receipt identifies the agent and authentication context without retaining provider keys, prompts or model responses. This is control-plane evidence, not a transcript and not a blanket compliance certification.