File 004 · Trust, Verifiable
Trust you can check. Claims we can keep.
Certificates say someone checked. Architecture means there's nothing to find. We're building both — and this page tells you exactly which is which, today.
Last updated: August 2026 · Written by humans, checked against the code.
§ 01 · Architectural Guarantees
Enforced by math, not policy.
Most privacy promises are policies — a document says the company won’t look. Ours are properties — the system is built so looking isn’t possible. Each claim below links to the mechanism that enforces it:
| Guarantee | Mechanism | Documented |
|---|---|---|
| Zero-knowledge key custody | Client-side envelope: every stored key is wrapped under keys that exist only on your devices | blueprint → |
| No server master key | The KEK never reaches us; working keys are RAM-only, session-scoped, evicted on logout/restart | blueprint → |
| No recovery backdoor | By design — no master key exists to be stolen, subpoenaed, or abused | blueprint → |
| End-to-end sealed mail between users | ML-KEM-1024 (FIPS 203) + AES-256-GCM hybrid, subject line included; decapsulation on-device only | blueprint → |
| Memory-hard key derivation | Argon2id (RFC 9106) — offline guessing priced in RAM, not luck | blueprint → |
| Hardware-backed unlock | WebAuthn passkeys with PRF — per-device, phishing-proof, nothing typed | blueprint → |
| Encrypted in transit | TLS 1.3 with certificate pinning on native clients | blueprint → |
§ 02 · Data Handling
The complete inventory.
Everything our systems touch falls into exactly three buckets. This list is exhaustive on purpose:
Stored at rest · opaque
- Wrapped data-encryption key (ciphertext)
- Per-device wrapped KEKs (ciphertext)
- KDF salts & parameters (public by design)
- Sealed provider tokens (ciphertext)
- Wrapped ML-KEM private keys (ciphertext)
- Public keys (that’s what they’re for)
- Account identity: your email address & billing state
Never stored · anywhere
- Your passphrase, in any form
- The KEK, or any key that opens the store
- Plaintext provider tokens
- Unwrapped private keys
- Message plaintext of sealed mail
- Ad profiles, tracking data, browsing behavior
Transient · RAM, session-scoped
- Your working session key (web sessions — RAM, while signed in)
- Live provider token (web sessions only; native apps keep theirs in the device keystore and call your provider directly)
- Content-free operational logs (short retention)
§ 03 · Audits & Certifications
Status: planned. Stated plainly.
What’s verified today — and what isn’t yet
The primitives are standardized and publicly scrutinized: ML-KEM is NIST FIPS 203, AES-256-GCM and Argon2id (RFC 9106) are the industry’s reference choices. The design is public on the blueprint page, threat model and residuals included.
An independent implementation audit is planned and budgeted — results will be published here, unredacted, when complete. SOC 2 and ISO 27001 are on the roadmap as the team grows. Nothing is published yet, and we won’t pretend otherwise. A company that fakes its audit page is telling you exactly how it will handle your data.
§ 04 · Regulation
GDPR & DPDP posture.
Our compliance strategy is data minimization by architecture — the best answer to a data-protection request is having almost nothing to protect. Under the EU GDPR and India’s DPDP Act 2023:
- Lawful basis & purpose: we process your account identity and mailbox access solely to provide the service you signed up for. There is no secondary use — no profiling, no ads, no resale.
- Your rights: access, correction, portability, and erasure are honored via account settings or a mail to support@adamanture.com. Deleting your account deletes your rows — and the ciphertext was useless anyway.
- Data minimization: see the inventory above — we cannot leak, sell, or be compelled to produce what we never had.
- Formal paperwork: the privacy policy is live; DPAs for Workspace, Microsoft 365, Zoho and self-hosted team customers are being formalized during beta — email contact@adamanture.com if you need one now.
§ 05 · Legal Requests
If we’re subpoenaed.
We comply with valid legal process — and here is precisely what that yields: your account email address, billing state, and ciphertext we cannot open. There is no master key to compel. We cannot be forced to use a capability we deliberately don’t have.
The honest boundary: mail you exchange with people not on Unlike Mail is ordinary email held by your provider, subject to your provider’s legal process — not ours. Sealing requires both ends. We say this here because a trust page that skips it isn’t one.
§ 06 · Disclosure
Found a vulnerability?
Report it to contact@adamanture.com — security findings are paid through our bounty program, and we don’t play the “not a bug” game with real reports. Please give us a reasonable window to fix before public disclosure; we’ll credit you (or not — your call) when we publish the fix.
Subprocessors
- Your mail provider (Google, Microsoft or Zoho) — under the OAuth consent you grant and can revoke at any time. A mailbox connected over IMAP from the desktop app has no such link: that credential and connection never reach us.
- Hosting infrastructure — runs our servers; sees only the same ciphertext we do.
- Payment processor — handles billing when you subscribe; never touches mail data.