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