Learn · The category, defined
Zero-knowledge secure intake, explained.
A zero-knowledge intake form encrypts each contact-form submission in the visitor's browser before it sends, so the provider only ever stores an opaque ciphertext envelope it cannot read. Only your team holds the key — so only your team can open the inquiry. That's the whole idea: a category of form that turns website inquiries into leads nobody can read, not even us.
What is a secure intake form?
A secure intake form is a contact form whose submissions are encrypted in the browser before they send. The plaintext inquiry never crosses the network and never lands in a provider's inbox or database — what travels, and what gets stored, is ciphertext.
That's a sharper bar than most “secure” forms clear. An ordinary contact form is only protected in transit: HTTPS shields it on the wire, then it's decrypted the instant it arrives, so the form provider and your own server both receive readable plaintext — and so does anyone who can reach either of them.
“Zero-knowledge” means the provider has zero knowledge of the actual content. Brun knows your account email and billing status, but the inquiries themselves are sealed with a key we never hold. The block to the right is what a real inquiry looks like as it sits on our servers: no name, no email, no message.
How does Brun keep an inquiry unreadable?
Three steps, five stops. The envelope opens exactly twice — never in between.
Sealed in their browser.
A visitor submits your contact form. Nothing about the form changes for them: same fields, same layout, no Brun branding, no account or app to install. They type their inquiry and hit send.
Their browser encrypts it before it sends. A small script encrypts the submission on the visitor's device using your workspace's public key. What leaves the browser is already ciphertext — the plaintext never travels the network.
Step 2 · On our servers
Screened. Never opened.
Our servers check the envelope's structure and accept it, then store it exactly as it arrived: ciphertext. We never hold the key that opens it, so there is nothing for us to read, sell, train on, or hand over.
We store gibberish.
stored on our serversEncrypted so we can’t read it: every inquiry, lead, and note. Server-readable to run the service: your account and team email addresses, billing status, seat counts, timestamps, and any support messages you send us.
Unlocked on your board.
Only your team can decrypt it. When you open your inbox, the envelope is decrypted in your browser with a key only your team holds. The plaintext exists in exactly one place: the device of the person reading it.
It becomes a lead on your board. The decrypted inquiry — re-encrypted with your workspace key — lands on a simple CRM board as a lead you can note, assign, and move from New to Won.
Nothing on your page can decrypt data. The only public identifier a visitor’s browser ever sees is your intake handle, which can neither read nor decrypt anything on its own.
The setup
Do I have to rebuild my form to use it?
No. Whatever you built your form in stays exactly as it is — the fields, the layout, the design. Connecting it is two edits to markup you already own, not a migration.
- <form action="/your-old-endpoint">
+ <form action="…/public/intake/your-handle">
+ <script src="…/intake.js">Ordinary contact form vs. zero-knowledge intake.
The difference comes down to one question: who can read the inquiry along the way. An ordinary form hands plaintext to the provider and your server; zero-knowledge intake hands ciphertext to everyone but your team.
| Ordinary contact form | Zero-knowledge intake | |
|---|---|---|
| Where it's encrypted | In transit only (TLS), then decrypted on arrival | In the visitor's browser, before it sends |
| Can the form provider read it | Yes — it lands in their plaintext inbox or database | No — they store ciphertext only |
| Can your server read it | Yes — your backend receives plaintext | Only your team's browsers, after decrypt |
| What a provider breach leaks | Readable inquiries | Ciphertext only |
| What a subpoena to the provider returns | Readable inquiries | Ciphertext only |
| Setup | Often a rebuild or a hosted form | Two changes to the form you already have |
Secure intake questions, answered.
What is a zero-knowledge intake form?
A zero-knowledge intake form is a contact form whose submissions are encrypted in the visitor's browser before they send, so the provider only ever stores an opaque ciphertext envelope it cannot decrypt. Only the form owner's team holds the key, so only they can read the inquiry. "Zero-knowledge" means the provider has zero knowledge of the actual content.
How is it different from a normal contact form?
A normal contact form sends the inquiry over an encrypted connection (TLS) but decrypts it the moment it arrives — so the form provider and your own server both receive readable plaintext. A zero-knowledge intake form encrypts the submission in the visitor's browser before it sends, so nobody in the middle, including Brun, ever sees plaintext. The only difference your visitors notice is none: the form looks and behaves the same.
Can Brun read my submissions?
No. Submissions are encrypted in the visitor's browser with your workspace's public key, and Brun never holds the private key that opens them. Our servers verify the envelope's structure and store it as ciphertext — an automated test in our release pipeline checks, on every change, that no plaintext column can exist. Decryption only ever happens in your team's browsers.
Do I have to rebuild my form?
No. You keep the contact form you already have. There are exactly two changes: point the form's action at your private Brun intake URL, and add one intake.js script tag to the page. The fields, layout, and design stay the same, and there's no backend work.
What do my website visitors see?
Nothing changes for them. There's no Brun branding on the form, no redirect to a hosted page, and no API key or tenant ID exposed in the page source. The only public identifier is your intake handle, which can neither read nor decrypt anything.
How does an encrypted inquiry become a lead I can work?
When you open your inbox, the ciphertext envelope is decrypted in your browser, re-encrypted with your workspace key, and posted as a lead on a simple CRM board — where you can note it, assign an owner, and move it from New to Won. It's a CRM nobody can read, not even us.
Keep reading
Go deeper on encrypted intake.
- Why your intake must be encryptedThe risks a readable inquiry quietly carries — breaches, subpoenas, AI training — and how end-to-end encryption closes each one.
- Brun vs. ordinary intake toolsHow zero-knowledge intake stacks up against form widgets and typical CRMs on the one question that matters: who can read your inquiries.
- Why Brun signs no BAAWhere the line sits: Brun is not a HIPAA-compliant service and its Terms prohibit PHI. What browser-side encryption does and doesn’t do.
- Brun overviewThe full picture: secure website intake plus a simple CRM board, for 1–5 person teams.
Inquiries only you can read
Start securing your inquiries.
Brun is zero-knowledge intake for 1–5 person teams: website inquiries encrypted in the visitor's browser, stored as ciphertext we can't read, and worked as leads on a simple board only your team can open. Keep your form, make two changes, and start the same day.