Security · zero-access encryption for blocked leads

We check it. We lock it. We can't read it.

SpamKill checks every submission at the moment it arrives. The ones we block are sealed with your key before they're stored — and from then on, only your passphrase can open them. Decrypted in your browser. Gone after 31 days.

Scope, stated up front

This page covers blocked leads. The check itself reads the submission — a filter can't judge what it can't see. Submissions that pass are delivered to your CRM in the original format, with pipeline stage, UTMs and hidden fields intact, and are not retained by us. What we store is what we blocked.

How a blocked lead is sealed

Locked at the moment we catch it. Opened only by you.

01 · Sealed at block time
Zero-access encryption.
Once we block a submission, it's locked with a key only your passphrase can open.
Sealed with your public key at block time (libsodium X25519 sealed box). One key per domain.
02 · Your key, locked
No escrow, no support override.
The private key is stored only under your passphrase — never in a form we can use.
Private key stored locked under Argon2id(passphrase). Records in DynamoDB; the locked key in RDS.
03 · Decrypted in your browser
Your passphrase never leaves your device.
We never receive it, store it, or see it.
Unlock and decrypt run client-side. The passphrase is never transmitted.
04 · Gone at 31 days
Auto-deleted after 31 days.
No copies, no backups, no archive.
31-day TTL on the records table; deletion typically within 48 hours of expiry. No backups of that table.
Try it yourself

Seal a lead in your browser. Then try to read it back.

Everything below runs on this page, with the same libsodium primitives the vault uses. Nothing you type is sent anywhere: the only request is the one-time load of the cryptography library, and your browser's Network tab will show you that. In production our servers seal with only the public key on file; here your browser plays both parts.

1 · What the visitor typed
A lead we are about to block.
Edit anything. This is the submission as our check saw it.
2 · What sits in our database
The row a database thief would get.
A few fields stay readable so your dashboard works. The lead itself does not.
Seal the lead to see what we would store.
3 · What you see after unlocking
Only with the passphrase, only in a browser.
Unlocking runs Argon2id on your device, then opens the locked key, then the record.
Seal the lead first. Your passphrase appears here.
Demo passphrase from a short word list. Setup in the product draws five words from a list of about 7,700. Start over with a new key
What we can't do

We can't reset it, and that's the point. Not our support team, not our engineers.

If the encryption passphrase is lost, so is the data — like a good backup password. You create it during setup, and we never keep a copy. Write it down or save it in your password manager before you finish: what you keep is the only way back in.

This is not your account login password. Your login password works the way every login password does, and you can reset it yourself at any time. The encryption passphrase is a separate secret that never reaches us — which is exactly why we can reset the one and not the other.

For your security team

The parts worth checking.

Two systems, write-only servers
Your key and your data are kept in two separate systems, and the servers that write your leads can't read them back. A stolen database contains nothing readable.
Records: DynamoDB. Locked key: RDS. Core's IAM role on the records table is write-only.
Built on audited primitives
libsodium, the audited open-source cryptography library, and Argon2id, the winner of the Password Hashing Competition.
X25519 sealed boxes for records; Argon2id for the key wrap.
The passphrase
Five generated words, about 65 bits of entropy — centuries at a billion guesses a second, and Argon2id makes a billion a second impossible.
Generated, not chosen: the entropy claim holds for the generated passphrase only. Subprocessors: see the DPA.
Questions

Questions your security team will ask

Who can see a blocked lead?
Only someone with your passphrase, in a browser. Our engineers can't open one; a stolen database contains nothing readable.
What if we lose the passphrase?
The blocked leads sealed under it are unrecoverable — by you or by us. Protection keeps running; you create a new key and the queue fills again from that point. Keep the passphrase somewhere safe.
What about the submissions you allow?
Delivered to your CRM in the original format — pipeline stage, UTMs and hidden fields intact — and not retained by us. The sealed queue holds what we blocked, nothing else.
Data Processing Addendum → SLA → We publish what we block: Threat Intel → Questions from your security team: [email protected]