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.

Encryption at rest is the default level. It is not the same as a key that cannot be exported, and Enterprise agents can instead sign in an Asqav-managed cloud KMS. Key protection levels states plainly what each level protects against.

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: over a hundred vectors across seven receipt formats, each with its expected verdict pinned, including forged signatures and tampered payloads that must fail.

The signature on a compliance-mode receipt you exported checks on your own machine against the key set saved with it, with no Asqav account and no call to Asqav, today and in ten years. That covers the signature check only. The full verdict also needs a confirmed timestamp anchor, and receipts signed without compliance mode cannot be checked this way. Export before your plan's retention window ends, because records past it are deleted. 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 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 submitted for anchoring through OpenTimestamps onto Bitcoin; that witness stays pending until its Bitcoin upgrade lands, so a receipt may carry an anchor_pending state that a later anchoring pass clears. On the Enterprise plan, an external RFC 3161 timestamp authority unaffiliated with Asqav additionally timestamps the receipt digest synchronously, so the time claim does not rest on our clock.

Encryption and security practices

• TLS on every public connection: the API and the website are served over HTTPS.
• 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. Production administration goes through the hosting control panel rather than tenant API keys. We do not currently claim MFA enforcement on administrative access.
• Branch protection on the source repositories: changes land through pull requests that cannot merge until their required CI checks report green on the platform repository and the two required checks on the SDK, and the rules apply to administrators as well as to everyone else. Neither repository requires an approving review, because each currently has one maintainer account. Dependency vulnerability scanning (Trivy and pip-audit) runs in CI. See change controls for the enforced list.

Data residency and hosting

The Asqav API and database run on Hetzner in Falkenstein, Germany. Customer receipt data is stored in the EU. Cloudflare provides DNS for asqav.com and sits in front of the API as a reverse proxy that terminates TLS and filters attacks, so API requests pass through its network in transit. 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 second database copy is kept in a daily set held off the server; the newest copy restores cleanly, row counts and constraints checked in the 2026-10-17 drill. See the Privacy Policy for retention windows.

Subprocessors

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

Deletion and retention

Request deletion of your account data by emailing info@asqav.com; we delete it within 30 days. Signature records carry plan and compliance retention floors, and legal holds or regulatory mandates can require longer retention - the canonical windows are in section 4 of the Privacy Policy, with the regime-by-regime table on the data handling page. Deleted data persists in backups until those backups expire; it is not selectively wiped from snapshots or dumps. Digests anchored to public timestamping infrastructure (Bitcoin via OpenTimestamps, RFC 3161 authorities) cannot be withdrawn once anchored; what is anchored is a digest over the receipt's signed bytes, not your action context.

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. Our detection sources, severity ladder, and containment and recovery steps are documented in the incident response runbook.

The public status page shows the sign-verify canary and /health readings from the same feed. It also lists recorded incidents and the support response targets the API publishes.

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 September 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.

SSO provisioning. SAML 2.0 with just-in-time user provisioning on first assertion; cross-organization assertions are refused. SCIM is not supported today. See the SSO documentation.

Deployment

Asqav runs in its EU cloud: nothing to run, and hash-only by default so payloads stay on your side.

Questions

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