Security.
The strongest security posture is to never touch the thing you are protecting.
What Apostillum never touches
Four things never reach our servers, under any circumstance, by anyone:
- Plaintext AI conversations
- Master encryption keys
- Shamir key shares
- Decryption ability of any kind
When you seal a record, the encryption runs entirely on your machine. Your device encrypts the plaintext with a master key you generated locally and splits that key into Shamir secret shares on your device. Only the resulting ciphertext and its SHA-256 fingerprint leave your machine. Apostillum then fans that fingerprint out to three independent witnesses — Hedera, Bitcoin (via OpenTimestamps), and an RFC 3161 timestamp authority — and writes the encrypted blob to AWS S3 Object Lock WORM storage. Apostillum never sees plaintext at any step. There is no server-side ingestion path for plaintext because no such path exists in the codebase.
The three-witness timestamp
Every sealed record's SHA-256 fingerprint is anchored, independently, to three independent timestamping authorities — two public blockchains plus an RFC 3161 timestamp authority:
- Hedera Hashgraph — via the Hedera Consensus Service
- Bitcoin — via OpenTimestamps calendar servers
- RFC 3161 Timestamp Authority — via FreeTSA
All three networks receive the same fingerprint. Any buyer can verify any of the three independently, using public block explorers and standard verification tooling, without trusting Apostillum at all. The verification portal queries the first witness (Hedera); cross-checking against Bitcoin and the RFC 3161 authority requires only the sealed record's fingerprint, which you already hold.
A timestamp without the content's fingerprint is meaningless. All three witness networks are given the same fingerprint so that tampering or substitution would require simultaneous compromise of three independent public infrastructures.
Keys stay on your machine
Your master encryption key is generated locally, during apostillum setup, and never transmitted. The same is true of every key used to sign or seal a record. Shamir secret sharing uses a 3-of-5 threshold: all five shares are generated on your device, and the distribution is entirely your decision — you may keep all five yourself, hand them to counsel, escrow them with a custodian, or split them across jurisdictions. Apostillum holds zero shares. Not as a matter of policy, as a matter of the code never having access.
Apostillum has no mechanism to read a sealed record, decrypt it, delete it from the blockchain, or remove it from WORM storage. These are not policies. They are architectural facts.
What lives on our servers
The honest enumeration of everything Apostillum stores on your behalf:
| Data | Location | Purpose |
|---|---|---|
| Email address | Supabase | Account identity |
| Hashed password | Supabase (managed) | Authentication |
| Stripe customer ID | Supabase | Billing reference |
| Tier and subscription status | Supabase | Feature gating |
| Signup IP address | Supabase | Fraud review |
| Optional profile fields (first name, last name, organization, job title, phone) | Supabase | User-provided, opt-in |
| Charter seat metadata (seat number, listing consent fields, listing identity) | Supabase | Public Charter register |
| Device fingerprints | Supabase | Per-device authentication |
None of this data is your work product. The work product — the AI conversations themselves — lives on your device, on the AI provider's servers, and inside the encrypted WORM blob that Apostillum cannot open. Stripe holds the payment instrument. Apostillum holds what it needs to know which account paid for which tier, and nothing more. The frame for this page is not that we handle your sensitive data carefully. It is that we never have it.
Retention
Sealed records on WORM storage: twenty-year minimum, per the Charter commitment. User-profile metadata: kept while the account is active, deleted within six months of account closure. Blockchain anchors are immutable by definition — they are public ledger entries outside Apostillum's control. Verifying a sealed record after account closure requires only its fingerprint, which you retain on your own device; your ability to prove the record is independent of whether your account still exists.
Reporting a vulnerability
Email security@apostillum.com. The alias is routed to the founder's primary inbox with alerting enabled.
- Acknowledgment target: within 24 hours
- Resolution target: within 14 days
We aim to tighten these further as the team grows.
A machine-readable disclosure policy is published at /.well-known/security.txt per RFC 9116.
Account security
- Multi-factor authentication via TOTP, supported through Supabase — enabled for accounts before general availability.
- Password rules: twelve-character minimum and a common-password blocklist. No arbitrary symbol or number rules that push users toward weaker passwords.
- JWT signature verification on every authenticated request.
- Per-device session tokens on the desktop application, each individually revocable from the account page.
- Account closure requires type-to-confirm with the account email, and is irreversible.
Formal audits
The most useful security audit we could commission would only confirm what is true by construction: there is no customer content on Apostillum servers to protect. Formal audit engagements — SOC 2 Type II and ISO 27001 — will be initiated before general availability. Not as a gap they would close, but as a procurement document for buyers whose compliance teams require one.
Subprocessors
The full list of third-party infrastructure Apostillum relies on:
- Supabase · Postgres and authentication
- Render · application hosting
- Stripe · payment processing
- Amazon Web Services · S3 Object Lock WORM storage
- Hedera Hashgraph · blockchain witness
- OpenTimestamps · Bitcoin witness
- FreeTSA.org · RFC 3161 timestamp authority
None of these subprocessors has access to unencrypted customer records. Stripe holds payment instruments. Supabase holds account metadata as enumerated above. All three witness networks hold only a fingerprint.
The principle
Apostillum is the first infrastructure in this category designed around the principle that the operator should not be trusted — not because the operator is untrustworthy, but because trust is a weaker guarantee than impossibility. Every control on this page is a consequence of that principle.