Learn · For recruiters & executive search
Candidate intake software for recruiters that keeps an off-market search off the record.
Brun is candidate intake software for recruiters and executive search firms. Your existing recruiting intake form encrypts each candidate submission in the browser before it sends, so the vendor only ever stores an opaque ciphertext envelope it cannot read. Only your team holds the key — so only your team can open the inquiry.
A passive candidate’s name and comp figure stop being something a breach or a nosy colleague could stumble on, and start being a lead only your recruiters can open. Keep your website, keep your ATS, and manage every lead on a simple board built for confidential executive search.
What is a secure candidate intake form?
A secure candidate intake form encrypts each submission on the candidate's own device, before the network ever sees it. Name, current employer, comp expectations — those details leave the browser only as ciphertext, so no form vendor's inbox and no third-party database ever holds a readable copy.
For a search firm, that means a passive candidate’s name and comp figure never sit anywhere in the clear: not logged in a vendor’s ticketing queue, not sitting in a database an ATS migration could expose. That guarantee is spelled out in full on the zero-knowledge intake page. Scroll to step 2 below to see exactly what a candidate inquiry looks like once it lands on our servers.
Why ordinary recruiting intake exposes the searches you can't afford to leak.
Inbound candidate and client inquiries land in plaintext — in inboxes, form-tool databases, and generic ATS/CRM vendors that can technically read everything — so a single breach or rogue insider can expose off-market candidates, comp figures, and confidential mandates, the very leaks that get an executive fired and a search firm sued. These are the records a discreet search cannot survive losing:
- Names and current employers of off-market / passive candidates who have not gone public with a job search.
- Current compensation, bonus structure, equity, and salary expectations disclosed during intake.
- Confidential client mandates such as replacing a sitting executive who has not yet been told.
- Candidate references, work history, and reasons-for-leaving shared in confidence.
- Off-the-record interest from senior leaders who would be fired or blacklisted if their search leaked.
Under GDPR and CCPA/CPRA, a recruiter is the party legally responsible for how candidate personal data is stored and who can see it — on top of the contractual and reputational duty of confidentiality owed to clients running a discreet search. Candidate comp data and off-market identities are exactly the records that trigger breach-notification duties and destroy client trust if leaked from a form submission or an over-permissioned inbox.
The form and ATS vendor can read every word
Whoever hosts your form — the form widget, the email-to-inbox relay, the ATS/CRM database behind it — receives the candidate inquiry in plaintext. Their staff, their integrations, and anyone who breaches them get the same readable copy of an off-market name and a comp figure.
A shared inbox spreads it across your firm
When the submission reaches your backend, it's plaintext there as well — in logs, in a database, in the shared inbox it triggers. Every place it's copied is another surface a breach, a subpoena, or the wrong colleague can read a senior candidate's numbers.
How does Brun keep a candidate inquiry unreadable?
A passive candidate's name is worth protecting the moment they type it, so Brun encrypts the inquiry in their browser and never holds the key. From the moment it leaves their screen to the moment it lands as a lead on your board, it never exists in a form anyone but a recruiter on your team can read.
Sealed in their browser.
Nothing about the form changes for them: same fields, same branding, no Brun logo, no account or app to install. A passive candidate or a hiring client types their inquiry and hits send.
The moment they hit submit, a script on their device encrypts the fields with your firm's public key, which is built to seal information in and never let anyone read it back out. Names, current employers, and comp figures leave the browser already as ciphertext.
Screened. Never opened.
We validate the envelope's structure, accept it, and file it away as ciphertext — that's as far as our servers go. We're never handed the key that opens it, so a breach of our servers or a subpoena served on us turns up nothing but an unreadable off-market name and comp figure — never a leak.
We store gibberish.
stored on our serversThis is what leaves our servers unreadable: every candidate inquiry, every lead, every note. Account housekeeping stays visible so we can run the service — your team’s email, billing status, and support messages, nothing about a candidate.
Unlocked on your board.
When a recruiter on your team opens the inbox, their own browser performs the decryption — the key never leaves your firm. The candidate's details become readable on that recruiter's screen and nowhere else.
The decrypted inquiry — re-encrypted with your workspace key — lands on a simple board as a lead you can triage, assign to a consultant, and move from New to Won as the placement lands. Hand the cleaned record off to your ATS when you are ready.
Your careers page exposes no API key and no tenant ID — just a public intake handle, and that handle can’t read or decrypt anything. Full mechanics →
Ordinary recruiting intake form vs. Brun zero-knowledge intake.
Read down this table and one question repeats: does a plaintext copy of the candidate's inquiry exist anywhere outside an authorized recruiter's browser? With an ordinary form, yes — in the vendor's database and your shared inbox. With Brun, no.
| Ordinary recruiting intake form | Brun zero-knowledge intake | |
|---|---|---|
| Where it's encrypted | In transit only (TLS), then decrypted on arrival | In the candidate's browser, before it sends |
| Can the form/ATS vendor read it | Yes — off-market names and comp land in their readable database | No — they store ciphertext only |
| What a vendor breach exposes | Off-market candidates, comp figures, confidential mandates | Ciphertext only — nothing readable |
| What a subpoena to the vendor returns | Readable candidate and client records | Ciphertext only |
| What a GDPR/CCPA audit finds on the vendor's servers | Plaintext personal data, broad breach-notification exposure | Unreadable ciphertext, minimized exposure |
| Who on staff can stumble on a senior candidate's numbers | Anyone with inbox or CRM access | Only an authorized recruiter who decrypts the lead |
| Setup | Often a new form, a hosted page, or an ATS migration | Two changes to the intake form you already have |
Do I have to rebuild my form or migrate my ATS?
No. You keep the candidate intake form you already have. Change one attribute: your candidate intake form's action becomes /public/intake/{public_handle}. Candidate fields, layout, branding, and your ATS downstream all carry on untouched. One script tag, dropped onto that same page, handles the browser-side encryption for every candidate submission. Nothing else is required — no backend build, no hosted page, no swapping your ATS.
- <form action="/your-old-endpoint">
+ <form action="…/public/intake/your-handle">
+ <script src="…/intake.js">Candidate intake questions, answered.
What is candidate intake software for recruiters?
It is the tool that captures inbound candidate and client inquiries from your website and turns them into a workable pipeline. Brun is intake-first: you keep your existing recruiting intake form exactly as it is, and Brun encrypts every submission in the candidate's browser before it sends. Each inquiry lands as a lead on a simple board your team can work — without you swapping your site or your ATS.
How does Brun keep off-market candidate inquiries confidential?
Every field a candidate types — their name, current employer, comp, and reason for a discreet move — is encrypted in their browser before it ever leaves their device. Brun stores only ciphertext it cannot read. Only your team holds the keys to decrypt the inquiry, so even Brun, a hosting provider, or an intercepted request sees nothing usable. That is how an off-market search stays off-market.
Do I have to replace my website or my ATS to use this?
No. Brun is designed to sit behind the intake form you already have. You keep your current website, branding, and application form, and you keep your ATS or CRM for downstream work. Brun's job is the confidential first mile: encrypting the submission in the browser and dropping the decrypted lead onto a board for your recruiters to triage and route.
Does Brun support my GDPR and CCPA obligations for candidate data?
Brun is built to support your obligations, not to certify your compliance for you. Because submissions are encrypted in the candidate's browser and Brun only ever holds ciphertext it cannot read, the plaintext personal data never sits on a vendor server in readable form — which shrinks your breach-notification exposure and supports data-minimization and need-to-know access principles. You remain the party responsible for your own GDPR/CCPA compliance — the data controller, in GDPR terms; Brun is engineered so it cannot become an unwanted reader of the candidate content you route through it.
What happens to confidential comp and salary-expectation data submitted through the form?
Compensation, equity, and salary expectations are encrypted alongside the rest of the inquiry the moment the candidate hits submit. They travel as ciphertext and are only decrypted by an authorized member of your team viewing the lead. They are never logged in plaintext, never readable by Brun, and never sitting exposed in a shared inbox where the wrong colleague could stumble on a senior candidate's numbers.
How is Brun different from a recruiting CRM like Bullhorn, Recruit CRM, or Recruiterflow?
Those are full ATS/CRM platforms that hold candidate data in readable form on their servers. Brun is narrower and more private by design: it secures the intake moment — keep-your-own-form, encrypted-in-the-browser, nobody-but-you-can-read-it — and gives you a simple lead board to triage from. Plan options and pricing are shown when you pick a plan at signup, and every plan carries the same encryption; you can still hand decrypted leads off to your existing CRM.
Go deeper on confidential intake.
- What zero-knowledge secure intake isThe category, defined: how an inquiry is encrypted in the browser before it sends and stored as ciphertext nobody but you can read.
- Why your candidate intake must be encryptedThe risks a readable candidate inquiry quietly carries — breaches, subpoenas, AI training — and how end-to-end encryption closes each one.
- Secure intake and complianceSensitive inquiries under confidentiality duties and data-protection rules — what the encryption does and doesn't cover.
- Brun overviewZoom out: sealed candidate intake wired to a lead board, scoped for small recruiting and search teams.
- Intake by industrySee how zero-knowledge intake reads for your specific practice — law, therapy, real estate, financial advice, and more.
Not legal advice
This page describes Brun's architecture and how it relates to candidate-data protection; it is general information, not legal advice. Your obligations under applicable data-protection law (e.g. GDPR/CCPA) depend on your specific firm and candidates — confirm your compliance posture with qualified counsel.
Searches only you can read
Start protecting your candidate intake.
Brun is zero-knowledge candidate intake for 1–5 person recruiting and executive search teams: candidate inquiries sealed in the browser, unreadable to us, worked as leads only your recruiters can open. Keep your form, keep your ATS — two edits and you're taking sealed submissions today.