Security

How Asqav holds keys

Every agent registered with Asqav gets its own ML-DSA key pair (NIST FIPS 204). Keys are generated server-side from the operating-system CSPRNG, and key generation refuses to run if the entropy pool is not yet seeded. Signing happens server-side under Asqav custody: the agent's operator never holds the signing key, so the recorded party cannot forge or backdate its own record.

Secret keys are encrypted at rest with AES-256-GCM, and every key access is written to an access log. Public verify keys are published at /.well-known/jwks.json, so anyone holding a receipt resolves the signing key themselves instead of asking us which key signed.

Asqav cannot rewrite history quietly either. Each receipt links to its predecessor through a per-agent SHA-256 hash chain and anchors into external witnesses, so removing or altering a past receipt is detectable by anyone holding the chain.

Your evidence outlives us

The question behind "you are a small vendor" is what happens to seven years of evidence if we disappear. Our answer is structural, not contractual.

Receipts conform to an open specification submitted to the IETF, the Internet-Draft draft-marques-asqav-compliance-receipts. The standalone offline verifier is Apache-2.0 licensed and ships inside the asqav package on PyPI; the rest of the public asqav-sdk repository is source-available under the Elastic License 2.0. The conformance vectors are also Apache-2.0 and live in the same repository: 44 vectors across five receipt formats, each with its expected verdict pinned, including forged signatures and tampered payloads that must fail.

A receipt you hold verifies on your own machine, with no Asqav account and no call to Asqav, today and in ten years. A security reviewer can confirm this in about ten minutes: verify a receipt without Asqav.

Architecture and data flow

By default, the cloud does not receive your action payloads. The SDK's default mode against the Asqav cloud is hash-only: it canonicalizes the action context locally (RFC 8785), hashes it with SHA-256, and sends only the resulting digest plus a small whitelisted metadata bag. Asqav signs and stores the digest; the payload stays on your infrastructure. Full-payload mode is the default for self-hosted deployments and is available on cloud for organizations that explicitly opt in.

That digest is unsalted unless you pass a 32-byte salt of your own to the SDK, which switches it to HMAC-SHA-256. We do not issue the salt and never receive it. An unsalted digest over a predictable action can be guessed by anyone holding it, so treat it as personal data when the action relates to an identifiable person. How the hash is computed has the detail and the caveats.

What Asqav stores: the signature record (digest or payload, depending on your mode), the signature, timestamps, the hash-chain link, and anchor evidence.

Anchoring is layered. Each receipt joins its agent's SHA-256 hash chain. Each receipt is also anchored through OpenTimestamps onto Bitcoin. On the Enterprise plan, an external RFC 3161 timestamp authority unaffiliated with Asqav additionally timestamps the receipt digest, so the time claim does not rest on our clock.

Encryption and security practices

• TLS for every connection in transit.
• Agent signing keys encrypted at rest with AES-256-GCM, with key access logging.
• Production secrets fail closed at startup: a deploy missing a security secret stops instead of running with the protection silently absent.
• Passwords hashed with Argon2id using OWASP-recommended parameters, with breached-password screening through the HaveIBeenPwned range API (k-anonymity: only the first five characters of a hash leave the server).
• API keys carry scoped permissions, and tenant data access is organization-scoped at the query layer.
• Branch protection on the source repositories: changes land through pull requests with required CI checks, and dependency vulnerability scanning (Trivy and pip-audit) runs in CI.

Data residency and hosting

The Asqav API and database run on Hetzner in Falkenstein, Germany. Customer receipt data stays in the EU. Cloudflare provides DNS, TLS, and CDN in front of asqav.com. The static website at www.asqav.com is served by Vercel and carries no customer API data. The database accepts connections only from inside the server's private network. The server is backed up daily through Hetzner's automated snapshot service, held on separate backup infrastructure. A database-level dump is also taken daily as a faster-restore copy; that copy is stored on the same server today, not at a separate off-site location. See the Privacy Policy for retention windows.

Subprocessors

Current as of June 2026. We update this table when the list changes.

Incident notification

If a personal-data breach affecting your account data occurs, we notify affected customers without undue delay.

For breaches where Asqav acts as your data processor (receipt data you route through the platform), we notify you within 72 hours of becoming aware, as set out in the Data Processing Agreement. The 72-hour processor notification and the vulnerability disclosure window below are separate clocks covering different obligations.

Vulnerability disclosure

Email info@asqav.com with the subject line Security report: <short description>, a description of the issue and its impact, and the smallest reproduction you can produce. We acknowledge reports within 2 business days and aim to provide a fix or mitigation timeline within 10 business days. Please give us a reasonable window before any public disclosure.

In scope: the asqav PyPI package, the @asqav/sdk npm package, the *.asqav.com cloud service, and the published Docker images. Issues in third-party services we depend on should go upstream.

Compliance status

Status as of June 2026.

GDPR. Data handling is documented on the data handling page and in the privacy policy. The standard Data Processing Agreement is published at /dpa; contact info@asqav.com to execute a signed counterpart. Hosting is EU-based, as described above.

The security vulnerability disclosure window (2 business days to acknowledge, 10 business days to provide a mitigation timeline) is a different clock from the DPA's 72-hour personal-data breach notification; they address separate obligations.

SOC 2. A SOC 2 Type II audit is on our roadmap; no audit is underway today. The controls we run now are the ones documented on this page. We answer security questionnaires within 5 business days.

Deployment options

Cloud (default). EU-hosted, nothing to run, hash-only by default so payloads stay on your side.

Self-hosted signer (Enterprise). Run the signing path inside your own network with Docker Compose, so keys and payloads stay within your boundary. See the self-hosted signer docs.

Questions

Send security questionnaires and architecture questions to info@asqav.com. We respond within 5 business days.