Everything clients send you, sealed on arrival
If people trust you with something, they send it to you first. A prospective client attaches three years of tax returns to an email. A patient fills in an intake form on their phone in a waiting room. Somebody leaves a voicemail with an account number in it because that was the fastest way to tell you. None of those people thought about where it would land.
Where it lands is usually a shared mailbox that four people have access to, a form plugin that stores submissions in plain text on a server you have never seen, and a voicemail transcription service that keeps a copy. Each of those is a place your clients' information is readable by someone who is not you. Most firms discover this during an incident, an audit, or a client questionnaire that asks a question nobody can honestly answer.
Secure Client Intake seals every one of those channels at the point of arrival. The form encrypts in the visitor's browser before it is submitted. The email attachment is sealed at the transfer boundary, before the mailbox ever holds it. The call recording is sealed on capture. Your staff open submissions inside your own system, where they were always meant to be read — and everywhere in between holds nothing but ciphertext.
We learned this the expensive way, on our own product
Send someone a link and you are trusting the mailbox, the phone, and everyone who ever gets into either. Send them a sealed envelope and you are trusting one key — theirs.
What broke
We shipped tokenised magic-link authentication for an operations platform. It was correct, it was standards-clean, and it worked exactly as designed — until one shared mailbox was compromised. Every "secure link" sitting in that inbox became an open door, and the audit trail cheerfully recorded each entry as legitimate. The cryptography never failed. The assumption did.
What we learned
A link delegates trust to whatever channel carries it. If the channel is a mailbox, a webhook, a phone system, or an agent runtime, then that channel is now part of your security boundary whether you audited it or not. The only durable fix is to stop shipping references to content and start shipping content that is already sealed to a specific recipient key.
What we built
KryptAPI seals content into an envelope at the moment it leaves one service and opens it only inside the next. Each hop authenticates the peer before the envelope moves, the relay carries ciphertext it cannot read, and every movement commits a hash to a chain you can export and verify yourself. A compromised mailbox now yields exactly one thing: ciphertext.
Hover or focus the diagram to replay the re-forge. It is the whole company in one 400ms transition.
Email, forms, and phone calls — sealed one channel at a time
Most firms start with whichever channel currently makes them most uncomfortable, and add the others once they see how little changes for the people using them.
Email and attachments
Clients will keep emailing you documents, whatever your policy says, because email is what they have. So we stop treating the mailbox as a safe place to put things. Incoming messages and their attachments are sealed the moment they cross the transfer boundary, before your mail provider stores anything readable, and the sealed version is what lands in your intake system.
If that mailbox is later compromised — a reused password, a stale session, an ex-employee's device — what the intruder finds is ciphertext and routing metadata. Not tax returns.
Ingress sealed at the transfer boundary; the mailbox is never trusted.
What your staff sees
Nothing new to learn. The message appears in your case system, your CRM, or your dispatch board exactly where it appears today, opened in place. The only visible difference is a small custody line showing when it was sealed and who opened it — which is the line your compliance officer will eventually ask for.
Web forms
Your intake form is the one place where you are asking for sensitive information in writing. We replace the plumbing behind it, not the form your visitors see: the fields are encrypted in the visitor's own browser, before the submit button does anything. Your website host, your form vendor, and the network in between never hold a readable submission, because one never reaches them.
The form still looks like your form. It still validates, still sends a confirmation, still works on a phone with two bars of signal.
Sealed in the visitor's browser before submit — the edge sees ciphertext.
What your staff sees
A submission queue inside your own dashboard, opened with your organisation's key when a staff member views it. Nobody has to log into the form vendor's admin panel to read a client's answers, which also quietly removes an entire category of "who has access to that account?" from your next security review.
Phone calls and voicemail
Calls are the channel nobody remembers to secure, and the one most likely to contain a card number, a diagnosis, or an address said out loud. Recordings and transcripts are sealed on capture, as two separate envelopes travelling the same route, so a transcript can be opened for triage without the audio ever being unsealed.
Retention becomes a decision you make deliberately, rather than a default you inherited from a telephony vendor.
Transcript and recording sealed as separate envelopes on one route.
What your staff sees
The transcript in the ticket, the recording one click behind it, both opened inside your system. Dispatchers and intake coordinators carry on working the way they always have; the difference is that the call no longer exists in readable form on somebody else's infrastructure.
Three channels in, one dashboard out
The same route inspector we use for full multi-hop delivery, filtered down to the three intake edges. Click any edge to read the handshake that happens before a submission is allowed to move.
Select an edge in the map to open its hop transcript.
Each channel proves its own identity differently — a domain key, a browser-held form key, a trunk certificate — and each derives its own content key.
Edges are keyboard-focusable. Tab to a hop and press Enter to inspect it. The full multi-hop version, including agent and archive legs, lives on Sealed Delivery.
The engagement, in four lines
- Encrypted web forms, sealed in the visitor's browser before they even hit submit
- Sealed email and attachment ingress — the mailbox is never trusted with plaintext
- Phone-call transcripts and recordings sealed on capture
- Your staff open submissions only inside your own dashboard, never in transit