Asqav as Third-Party Notary
Asqav operates the unaffiliated third-party signer for AI agent action receipts. The signing service is operationally and legally independent from the customer's AI infrastructure, which is the precondition several record-retention regulations write into law. Commercial terms for production engagement are not pre-published in this docs cluster. Contact info@asqav.com for the SLA, the data-processing addendum, and the inbound-regulator response window.
A receipt that the agent vendor signs over its own actions is self-attestation. Several regulators have already concluded that self-attestation does not satisfy the audit-trail requirement, and they say so in regulation text. Asqav exists to fulfil the unaffiliated-party half of that requirement, so that the signed evidence carries weight with the regulator who reads it.
Standard and notary are two distinct things
Asqav plays two roles, and they are easy to conflate. The standard is the open receipt format. The notary is the independent party that signs. Keeping them apart is what makes a receipt count as evidence.
The standard is the open receipt format: the IETF draft plus the conformance vocabulary that defines what a valid receipt looks like and how to verify one. Anyone can implement it and any conformant verifier can check a receipt against it.
The notary is the unaffiliated party that actually signs, anchors, and stands behind each receipt: Asqav, the independent signer that SEC 17a-4(f)(3)(v) requires sit outside the regulated entity, a separation the examiners and auditors applying NYDFS 23 NYCRR 500.06 and DORA Articles 28 to 30 look for in practice.
The two roles depend on each other. The standard makes the notary's output verifiable by anyone, with no need to trust Asqav. The notary makes the standard load-bearing, because an open format with no unaffiliated signer behind it is still self-attestation. Asqav authors the standard and operates the notary.
What "unaffiliated" means in practice
Asqav is incorporated as a separate legal entity from every customer it serves. The signing keys live in custody Asqav controls. The signer container runs on infrastructure that is not under the customer's operational control on the signing path. The customer cannot retroactively modify or suppress a signed receipt that Asqav has issued.
This separation is the structural property the regulators ask for. It is also the structural property an inbound auditor checks before treating the receipt log as evidence rather than as the agent vendor's own narrative.
Why self-attestation does not satisfy the audit-trail rule
The audit-trail rules cited across this docs cluster have a shared shape. A regulated entity must keep a tamper-evident record of certain actions. The record must be verifiable by someone who is not the regulated entity. The someone-else clause is load-bearing. If the entity signs its own receipts, the evidence and the actor are the same party, and the record stops being independent.
Asqav slots into the unaffiliated-party slot. The customer keeps full control of the agent runtime, the policy engine, the data pipeline, and the model choice. Asqav owns the narrow surface where the receipt is produced, signed, and made available to an inbound auditor.
Three deployment patterns
Customers pick the deployment pattern that matches their assurance level and data-residency posture. All three patterns preserve the unaffiliated-party property.
BYO HSM customer-isolated
The customer provisions a dedicated HSM partition that Asqav operates under a key-custody agreement. The HSM lives in the customer's compliance perimeter, but the signing-key material is held in a partition the customer cannot directly access without breaking the custody agreement. Recommended for regulated financial entities and any deployment where the HSM audit trail is itself an inbound deliverable.
Multi-tenant SaaS
The default cloud deployment on api.asqav.com. The signing keys are held in Asqav's KMS and the signer runs in Asqav-controlled containers. Each tenant's receipt stream is logically isolated and signed under a tenant-bound key. The unaffiliated-party property holds because Asqav is the legal counterparty, not a contractor of the customer.
On-prem self-host with attested boot
For air-gapped or sovereign-cloud environments. The signer runs on customer hardware, but Asqav publishes the signer image with a reproducible build attestation and the boot chain is attested to a known measurement. The customer cannot modify the signer in production without breaking the attestation. See Out-of-process signing for the deployment topology and key-custody model.
How the receipt becomes inbound-auditor evidence
Each signed receipt carries:
- the principal and the action
- the request digest and the result digest
- the time of signing
- the policy decision that gated the action
- the cryptographic signature over the whole envelope.
The verify key is published at GET /.well-known/jwks.json. The wire format is published in draft-marques-asqav-compliance-receipts on the IETF Datatracker.
An inbound auditor fetches the verify key, fetches the receipt set, and verifies the signatures offline. The auditor does not have to trust either Asqav or the customer to trust the chain, because the wire format is published and the verify key is public.
Regulation-by-regulation walkthrough
- SEC 17a-4(f)(3)(v) designated third party: how Asqav fulfils the designated-third-party slot for broker-dealer electronic records.
- DORA Articles 28-30: how Asqav slots into the EU financial-entity third-party ICT register.
- NYDFS 23 NYCRR 500.06: how Asqav reinforces Class A entity audit-trail compliance under the New York DFS cybersecurity rule.
Where the standard lives
The standard - the wire format and verification procedure - is published on the IETF Datatracker as draft-marques-asqav-compliance-receipts. The reference verifier is the open-source asqav SDK on PyPI and @asqav/sdk on npm. The offline evidence pack the notary produces is built by asqav audit-pack export and verifies against the same public key. See agent receipts for what one of those signed receipts contains and how a holder verifies it, and receipt verification for the verifier API surface.