Data Handling
Last updated: 11 June 2026
Summary
The Asqav cloud runs in hash-only mode by default. Your code computes a SHA-256 hash of each action locally and sends us the hash plus a small metadata bag. We sign the hash with ML-DSA and store the signature record. We never receive the prompts, tool arguments, or model outputs themselves.
That hash is unsalted by default. An unsalted hash of a predictable action can be guessed by anyone holding the hash, so read How the hash is computed before you decide what belongs in an action context.
If you self-host, nothing leaves your infrastructure unless you turn on cloud telemetry.
What we receive on cloud
- A SHA-256 hash of the canonical action context.
- A whitelisted metadata bag: agent_id, org_id, session_id, action_type, timestamp, model_name, tool_name. Other keys are dropped.
- Account data: email, hashed credentials, usage metrics.
How the hash is computed
The SDK canonicalizes the action context, hashes it with SHA-256, and sends the digest. No salt is applied unless you supply one, so two identical actions produce the same digest and a third party who holds the digest can test candidate values against it until one matches. For an action drawn from a small set of possibilities, such as an email address from a company directory, that search is cheap.
The SDK accepts an optional 32-byte salt through the org_salt parameter on asqav.init(). When you set it, the digest becomes HMAC-SHA-256 keyed by your salt, which defeats that guessing attack. Two things to know before you rely on it:
- You generate and store the salt. We do not issue one, we never receive it, and we cannot recover it for you. If you lose it, nobody can recompute those digests again.
- The wire format labels every digest
sha256, so a third party who follows our published fingerprint spec will recompute a plain SHA-256 and report a mismatch on a salted receipt. The signature still verifies; the digest comparison is what breaks.
We are working toward making a salted digest the default and giving the wire format a way to say which construction was used. Both have to change together, because a digest labelled sha256 that is really an HMAC breaks the independent verification we ask people to rely on. We are not putting a date on it here.
Treat a digest as personal data when the action it covers relates to an identifiable person. The European Data Protection Board takes the position that a hash of personal data stays personal data, and that unsalted or unkeyed hashes are not on their own a sufficient confidentiality measure (Guidelines 02/2025 on blockchain technologies, version 2.0, adopted 07 July 2026, paragraph 52).
What we do not store
- Raw prompts.
- Tool arguments.
- Model outputs.
- Any field you do not put into the metadata whitelist.
Full-payload mode is available on cloud only as an opt-in under a signed agreement. The default is hash-only.
Self-hosted
You operate the signer. You choose what to log, what to retain, and where signatures are stored. Asqav has no access. In this mode you remain both controller and operator.
What we do with signatures
- Sign the canonical document with ML-DSA (FIPS 204).
- Link each signature to the previous one in a chained record.
- Optionally attach an RFC 3161 timestamp.
- Optionally anchor each receipt's hash leaf to Bitcoin via OpenTimestamps (per-receipt single leaf, not a Merkle root).
Retention
Signature records are retained while your account is active. Account closure and data deletion requests are handled via info@asqav.com; see the Privacy Policy for retention details and backup windows.
When an organisation signs any receipt in compliance mode or declares a regime via the compliance_regimes array, the longest applicable retention floor governs:
| Regime | Floor | Source |
|---|---|---|
Compliance mode (any receipt signed with compliance_mode, no regime declared) | 184 days | baseline floor for all of the organisation's signature records and activity logs |
| EU AI Act (Articles 12 + 26) | 184 days | "at least six months" |
| Colorado AI Act SB 24-205 | 184 days | parity with EU AI Act when high-risk |
| CIRCIA | 731 days (2 years) | covered cyber incident records |
| SEC 17 CFR 240.17a-4(b) | 1096 days (3 years) | broker-dealer subset |
| DORA Article 17 | 1827 days (5 years) | ICT incident retention |
| NYDFS 23 NYCRR Part 500 | 1827 days (5 years) | 500.6(b) audit-trail retention |
| HIPAA Security Rule | 2192 days (6 years) | 164.316(b)(2) policy/procedure retention |
| SEC 17 CFR 240.17a-4(a) | 2192 days (6 years) | broker-dealer primary |
| Texas TRAIGA HB 149 | 2192 days (6 years) | longer of HIPAA 6yr or Texas-required |
| NIST AI RMF | voluntary | no retention floor change |
Multiple regimes apply additively. The longest floor wins. The full list of bindings, with file:line evidence, lives at /docs/compliance.
Subject rights
Access, rectification, erasure, and portability requests go to info@asqav.com. For erasure of audit records we delete the linked metadata. The hash stays, because it is the anchor the signature covers. We treat that hash as personal data when it relates to an identifiable person, and we do not claim it is beyond recovery: an unsalted digest over a predictable action can be guessed. Setting a salt you hold, and destroying it, is what makes a digest unrecoverable. See How the hash is computed.
Hosting and transfers
Customer data is hosted exclusively in the EU (Hetzner, Falkenstein, Germany). Where data flows to a sub-processor outside the EEA, we rely on the Standard Contractual Clauses referenced in our DPA.
Sub-processors and DPA
The canonical sub-processor list is published at /security. The standard Data Processing Agreement is at /dpa. Contact info@asqav.com to execute a signed counterpart.
Compliance posture
Asqav is designed around GDPR Article 25 data minimization. Hash-only by default in cloud is how we implement it. We support your processor obligations under Article 28. We do not hold SOC 2 or ISO 27001 certifications and do not claim either.
Compliance Receipts emitted by Asqav follow the IETF Internet-Draft draft-marques-asqav-compliance-receipts, an Independent Submission profiling draft-farley-acta-signed-receipts for EU AI Act Articles 12 + 26, DORA Article 17, NYDFS 23 NYCRR Part 500, NIST AI RMF, Colorado AI Act SB 24-205, Texas TRAIGA HB 149, CIRCIA, HIPAA Security Rule, and SEC 17a-4. Per-regime mapping at /docs/compliance.