Out-of-process Signing
Asqav is the unaffiliated third-party notary for AI tool call receipts. The signer runs in a trust boundary the agent does not own, holds the keys the agent never touches, and emits receipts an external auditor can verify offline against the public verify key. This page documents the out-of-process deployment topology: the signer ships as a container image the customer runs on its own infrastructure, with keys held in a customer-controlled KMS or HSM.
The unaffiliated-third-party position has a regulatory shape:
- SEC 17a-4(f) gives broker-dealers two ways to execute the required undertakings (2022 amendments, Release No. 34-96034): a designated third party unaffiliated with the broker-dealer, or an internal designated executive officer. Asqav fits the unaffiliated-third-party route, which co-located keys inside the audited workload cannot.
- NYDFS 23 NYCRR 500.06 calls for audit trail systems designed to reconstruct material financial transactions sufficient to support normal operations and obligations of the covered entity.
- DORA Articles 28 to 30 have financial entities evidence ICT third-party risk management and retain attestable evidence of those controls.
The signer running outside the agent process is what gives the resulting receipts verifiable evidentiary weight against these provisions. Asqav does not make legal admissibility claims; whether a receipt meets a given evidentiary standard is for the customer and its legal counsel to determine.
The threat the boundary closes
Threat model
An attacker who compromises the agent process, through prompt injection that achieves code execution, a poisoned tool dependency, or a memory-safety bug in a model runtime, gains arbitrary code execution inside the agent. With in-process signing, that attacker can:
- read the signing key out of process memory
- mint forged receipts that look indistinguishable from genuine ones
- backdate or alter the hash chain to hide their actions
With out-of-process signing, the attacker has process-level access to the agent but no read access to the signer's keys. The signer accepts request payloads, validates them, and returns signed envelopes. The signer never returns the private key. A compromised agent can request signatures on attacker-chosen payloads, but it cannot retroactively rewrite the chain, and the signer's local audit log captures every request the agent made.
Why this matters for compliance
Regulators and assessors expect the key custody question to have a clean answer, and that expectation comes from how the reviews run rather than from any clause naming a hardware security module. Take four of them:
- a HIPAA risk analysis under 45 CFR 164.308(a)(1)(ii)(A), an assessment of risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information, which puts the workload handling PHI inside its scope
- a NYDFS 23 NYCRR 500.06 review of audit trail systems designed to reconstruct material financial transactions, where an audit trail is worth what the key that signed it is worth
- a SOC 2 Type II engagement over the entity's own key management control
- a DORA Article 28 ICT third-party-risk review.
Every one of those reviewers lands on the same question: where does the signing key live, and who can read it. Keys held in a hardware security module or a separate trust boundary keep that answer short, and the out-of-process signer is the architecture behind that answer.
What a compromised agent can still do
A precise threat model names the residual, not only the win. With Asqav, the agent process holds an API key and nothing else. The signing key and the receipt ledger live outside the agent, and on the hosted deployment they also live outside the agent operator's infrastructure.
What an attacker holding that API key cannot do:
- Read the signing key. It stays server-side, or in a customer KMS where the secret never enters Asqav's database.
- Rewrite or delete an issued receipt. Receipts persist under per-agent and per-organization hash chains, and the agent-facing API exposes no call that removes one. The single erasure call, a GDPR Article 17 payload erasure, nulls the stored payload alone; the digest and the signature stay valid, and the erasure writes its own audit entry.
- Backdate a record. Signing time is stamped server-side and anchored to external timestamp authorities.
What that attacker can still do:
- Request signatures over content it chose. This residual holds for any signer that sits outside the agent, whatever its shape: a signature proves who recorded what and when, not that the reporting process told the truth. Asqav narrows the residual instead of hiding it. Each receipt can declare its capture path (see Capture topology), so a verifier can tell a self-reported receipt from one captured by a network proxy or an eBPF probe at a boundary the agent does not control. Output binding through
result_digest, counterparty acknowledgments, and a WebAuthn user co-signature each tie a receipt to evidence the agent cannot produce alone. - Stay silent. A receipt that was never requested leaves no trace by itself. Deployments that also capture at a boundary record traffic the agent never reported, and passive telemetry observations give an auditor a second record set to compare the signed receipts against.
The deployment topology
The signer ships as a single container image. Both deployment shapes (Asqav-hosted SaaS, customer-deployed self-hosted) use the same image and emit the same wire format.
The agent never holds the signing key. The signer holds the key in a LOCAL, AWS KMS, or GCP KMS backend, with BYO HSM available for FIPS 140-3 deployments. The signer talks to Asqav SaaS over a single outbound HTTPS hop to deposit signed digests and RFC 3161 timestamps. Raw prompts, raw model outputs, and private keys never leave the customer trust boundary. The signing time is anchored to Bitcoin through OpenTimestamps, the only required call outside the customer network.
Responsibilities split into two domains. The customer-controlled zone holds every component operated at runtime: the signer process, the signing key material, and the receipt store and payloads. The vendor-supplied artifacts are the fixed pieces the customer imports and inspects: the container image, the verifier libraries, the receipt format spec, and the default anchor URLs. Asqav does not operate any of the vendor-supplied artifacts on the customer's behalf.
Full operational detail is on the Self-hosted Signer page. An air-gapped install with zero outbound HTTP is also documented for the strictest deployments.
Two topologies from one SDK
The Python SDK reaches the signer through one environment variable. Pointing it at https://api.asqav.com/api/v1 uses the Asqav-hosted notary signer. Pointing it at a local socket or a private signer URL uses a customer-deployed notary signer.
Asqav-hosted notary signer
import asqav
asqav.init(api_key="sk_live_...")
agent = asqav.Agent.create("invoice-bot")
receipt = agent.sign(
"filesystem:write",
{"path": "/exports/q1-invoices.csv", "bytes": 18324},
)Customer-deployed notary signer
import os
import asqav
os.environ["ASQAV_API_URL"] = "https://signer.internal.example.com/api/v1"
asqav.init(api_key="sk_live_...")
agent = asqav.Agent.create("invoice-bot")
receipt = agent.sign(
"filesystem:write",
{"path": "/exports/q1-invoices.csv", "bytes": 18324},
)The SDK call is identical. The trust boundary changes: in the second example, the signer runs on customer-controlled infrastructure, the signing key never leaves that infrastructure, and a compromised agent cannot forge past receipts.
Who deploys this topology
Customers in regulated industries (finance, healthcare, defense, government) typically deploy the customer-hosted notary signer:
- a US broker-dealer that needs SEC 17a-4(f)(3)(v) unaffiliated-third-party evidence and a SOC 2 Type II control over the signing key
- a covered entity under HIPAA where the agent is processing PHI inside the workload and an assessor expects to see who controls the signing keys
- a DORA-regulated EU financial entity where Article 28 ICT third-party-risk concentration on a hosted signer is itself an audit finding
- a NYDFS 23 NYCRR 500.06 covered entity whose audit-trail control must survive a workload compromise
- a defense contractor where the agent runs inside a CMMC enclave and the signer must run inside the same enclave
Customers iterating on a new AI feature, or self-serve teams without a hard regulatory boundary, typically use the Asqav-hosted notary signer until they need the customer-deployed topology.