Per-Action Signed Receipts vs Audit Logs and Third-Party Recordkeepers

A common response to the question of AI agent accountability is: "we already have an audit log" or "we use a designated third-party recordkeeper." Both are real answers, and this page does not dismiss either. It examines what each approach proves, where the structure of each limits what it can prove, and what changes when the signing party is unaffiliated with both the agent's operator and the record subject.

What a managed-cloud batch-signed audit log proves

A managed-cloud batch-signed audit log collects event records and periodically applies a cryptographic signature over a batch. The signature covers the batch as it existed at signing time, which means any record that existed before the batch was cut cannot be altered without breaking the batch signature.

This is real tamper-evidence for the batch boundary. Inside a batch, you know the records were not modified after the batch was signed.

What the structure does not prove:

• Who signed. The signing key is held by the cloud platform that also runs the agents. The party that produced the events and the party that signed the batch are affiliated. A reader who trusts the platform learns what the platform recorded. A reader who is auditing the platform has a record signed by the party under audit.
• Per-action granularity. A batch signature covers many events. Adding, omitting, or reordering individual records inside a batch before it is signed produces a signature that still verifies. A per-action signature, issued before the next action fires, binds one specific action at one specific moment.
• The moment of signing. Batch signatures are cut periodically, not at action time. An event logged at 14:00 may not be signed until 15:00 or later. During that window the record exists unsigned.

There is also a real strength worth naming. Batch-signed logs are cheap to operate at scale and integrate naturally into observability pipelines. For operational debugging and internal alerting they are the right tool.

What a designated third-party recordkeeper proves

The designated-third-party model is a compliance structure in which an organization stores its records with a regulated entity that is legally independent from it. The third party holds the records and provides access to regulators.

The structure proves custody: a legally distinct party holds the records and can produce them on demand without asking the subject's permission. That is a verifiable property, recognized in several financial-records regimes.

What the structure does not prove:

• Whether the records were accurate before transfer. The third party custodies whatever it receives. If the record was altered before it left the originating organization, the third party holds the altered version.
• Whether signing happened before transfer. If records are transmitted to the third party after accumulation, the signing event (if any) may be entirely in the originating organization's control.
• Per-action independence. The designated third-party model is usually applied to records in bulk, not to individual actions as they are performed. The independence claim attaches to custody, not to the signing moment.

The structural distinction: when the signing happens and who holds the key

Per-action signing with an unaffiliated key-holder changes the answer to both questions.

Asqav signs server-side as an operator unaffiliated with the agent's operator. The signing key is in Asqav's custody. The signature is applied to each action individually, at the time of the action, before the next action fires. The recorded party cannot forge or backdate its own receipt.

The wire format is published as an IETF Internet-Draft, draft-marques-asqav-compliance-receipts. The verification key is public at GET /.well-known/jwks.json. A verifier that fetches the key and the receipt can check the signature without contacting Asqav or trusting the agent's operator.

A self-signer or operator-run log is by definition affiliated with the record subject. That affiliation is not a product choice; it is a structural fact. You cannot be both the party whose actions are recorded and the unaffiliated party signing those records. Affiliation is the property that limits what a log proves to someone auditing you.

What the receipt proves

Each Asqav receipt carries fields that are verified in /.well-known/governance.json:

• The action type in namespace:verb format, from the action_type_format vocabulary.
• The receipt_type from the wire_vocabulary.receipt_types set (for example, protectmcp:decision, protectmcp:observation, protectmcp:lifecycle).
• The policy decision from the wire_vocabulary.decisions set: allow, deny, rate_limit, or observation.
• The controls_evaluated map, server-built, whose keys appear only when a control genuinely ran on the sign call. A caller-supplied value is dropped before signing.
• Optional witness_policy anchoring into RFC 3161 or OpenTimestamps when a deployer declares a quorum.
• A server-issued nonce of 24 lowercase hex chars, minted per receipt on the signing call.

The controls_evaluated key is the enforcement attestation. Its keys - emergency_halt, delegation_scope, quorum, mandate, policy, content_scan - are present only when each control genuinely ran. An absent key means the control never ran on that action, not that it passed silently. This is documented in the wire_vocabulary.guards section of /.well-known/governance.json.

The signature algorithm is ML-DSA-65 (NIST FIPS 204). The signed bytes cover the canonical receipt envelope, so every field cited above is part of the signature surface.

How independent verification works

A reader holding a receipt verifies it through the public surface:

1. Fetch the verify key from GET /.well-known/jwks.json.
2. Verify the ML-DSA-65 signature over the canonical receipt bytes.
3. Check the hash-chain link against the previous receipt in the agent's chain.
4. Confirm controls_evaluated keys match the deployer's declared policy set.

No Asqav account is needed for steps 1 through 4. The open-source verifier in the asqav SDK on PyPI and @asqav/sdk on npm performs these checks offline. The verify_without_asqav path is documented at Verify Without Asqav.

The endpoint GET /api/v1/verify/{signature_id} is also unauthenticated, per /.well-known/governance.json, so any holder of a signature_id can probe verification without credentials.

Combining approaches

These are not mutually exclusive. Most deployers run all three.

A managed-cloud audit log stays on for operational visibility: dashboards, alerts, debugging. A designated third-party custodian holds batch exports under a compliance program. Asqav receipts add the per-action, unaffiliated-key layer that the other two cannot provide by structure.

The three approaches cover different parts of the audit surface. The batch log proves what the platform chose to record over an interval. The custodian proves the records were held by an independent party. The per-action receipt proves each individual action was recorded at the time it occurred by a party whose key the agent's operator does not control.

Where to go next

• Third-Party Notary: Asqav's role as the unaffiliated signer and the three deployment patterns.
• Independent Verification: the specific checks a reader runs on a receipt.
• Verify Without Asqav: the offline verification walkthrough.
• Platform Logs vs Independent Evidence: what a platform audit log proves, and what changes when you add an independent evidence layer.
• Key Custody and Disclosure: who holds which keys, and why that is the load-bearing structural fact.
• Multi-Witness Anchoring: the witness_policy quorum and what RFC 3161 / OpenTimestamps anchoring adds.