An AI agent that signs its own audit trail holds the signing key in its own process memory. That arrangement is convenient, and it has a hole in it. An attacker who compromises the agent, through a prompt injection that reaches code execution, a poisoned tool dependency, or a memory-safety bug in a model runtime, gets arbitrary code execution inside the agent. With in-process signing, that attacker can read the signing key out of memory, mint forged receipts that look indistinguishable from genuine ones, and backdate or alter the hash chain to hide what they did.
Out-of-process signing closes that hole by moving the signer into a separate trust boundary. The agent keeps an API key and nothing else. The signing key lives in a process the agent cannot read, ideally in a customer-controlled KMS or HSM the agent operator never touches. A compromised agent can still request signatures, but it cannot extract the key, and the signer's own audit log records every request.
The threat the boundary closes
Name the adversary before the feature. An attacker with process-level access to an in-process-signing agent has three moves available.
Read the signing key out of process memory. Once the key is exfiltrated, the attacker signs anything they like, anywhere, with no further help from the agent.
Mint forged receipts that look genuine. With the key, the attacker produces signatures the verifier accepts. The audit trail now contains records of actions the agent never performed.
Backdate or alter the hash chain. Remove a receipt that incriminates the attacker, recompute the chain, and a stored-versus-stored check passes if the verifier trusts stored columns.
Out-of-process signing removes the first move, which removes the second, because without the key the attacker cannot forge. The third move is handled separately, by the rule that verification re-derives every hash from the canonical bytes instead of comparing two stored values.
What a compromised agent can still do
A precise threat model names the residual, not only the win. The agent holds an API key. An attacker holding that API key can request signatures on content they chose. That 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, 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.
The other residual is silence. A receipt that was never requested leaves no trace by itself. Deployments that capture at a boundary record traffic the agent never reported, which gives an auditor a second record set to compare the signed receipts against.
The architecture
The signer ships as a single container image. Both deployment shapes, Asqav-hosted SaaS and customer-deployed self-hosted, use the same image and emit the same wire format.
The agent process imports the Asqav SDK and talks to the signer over a Unix domain socket or mTLS. The signer holds the ML-DSA-65 keys, validates each request, signs, and appends to the hash chain. 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 in the self-hosted shape.
The Python SDK reaches the signer through one environment variable. Point it at https://api.asqav.com/api/v1 and you use the Asqav-hosted notary signer. Point it at a local socket or a private signer URL and you use a customer-deployed signer. The SDK call is identical in both cases. The trust boundary changes.
Why the boundary has regulatory weight
Regulators and assessors expect the key custody question to have a clean answer.
SEC 17a-4(f) gives broker-dealers two ways to execute the required electronic-records undertakings: 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 sufficient to reconstruct material financial transactions. DORA Articles 28 to 30 have financial entities evidence ICT third-party risk management. HIPAA covered entities that handle PHI in the workload have to show an assessor who controls the signing keys.
In each case the architectural question is the same. Does the signing key live inside the workload that uses it, or in a separate trust boundary? The out-of-process signer is the answer assessors expect.
Who deploys this topology
Customers in regulated industries typically deploy the customer-hosted signer. A US broker-dealer that needs SEC 17a-4(f)(3)(v) unaffiliated-third-party evidence. A covered entity under HIPAA where the agent processes PHI inside the workload. A DORA-regulated EU financial entity where Article 28 ICT third-party-risk concentration on a hosted signer is itself an audit finding. A defense contractor where the agent runs inside a CMMC enclave and the signer must run inside the same enclave.
Teams 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.
The operational detail for the self-hosted shape, including the air-gapped install with zero outbound HTTP, is on the out-of-process signing page.