Every business moves things it would not want read on the way. A signed contract going from your inbox into your case system. A payment instruction going from finance into the bank portal. A patient record going from a scanner into a chart. A job photo going from a phone in a parking lot into dispatch.
Today, almost all of that travels readable. It sits in a mailbox, in a form vendor's database, in a file-sharing link that works for anyone who has it, on a server belonging to a company you have never audited. Nothing has to be broken into for it to leak — someone only has to already be somewhere they should not be, and everything they find is legible. When it goes wrong, the second problem arrives immediately after the first: you cannot say precisely what was exposed, or prove what was not.
Sealed Delivery changes what is actually in transit. Content is locked into an envelope the instant it leaves one system and can only be opened inside the next one, by a key we do not hold and cannot produce. What travels in between is unreadable — to us, to your vendors, to whoever eventually gets into the mailbox. And every movement leaves a receipt, so the question "what moved, when, and who opened it" has an answer you can hand to somebody else.
Nothing about how your business runs has to change. We sit between the systems you already have, and we handle the part in the middle — the part where information is usually readable by anyone who happens to be holding it.
From wherever the information already lives: an email, a form on your website, your own dashboard, a phone system, an AI assistant. You keep working exactly the way you work today.
The content is locked into an envelope only the recipient's key can open, and we carry it blind. We can see that something moved, how big it was, and when. We cannot see what it said.
It opens inside the receiving system, where it was always meant to be read — and the delivery is written to a permanent record with the time, the recipient, and a receipt you can produce later.
For your engineers: click any hop to see exactly what happens on it.
Click any edge in the map to inspect that hop: the mutual attestation exchange, the negotiated cipher suite, the envelope header with its per-hop key ID, and the audit entry the hop emits. Every hop is genuinely different, because every origin proves itself differently.
Select an edge in the map to open its hop transcript.
Each hop negotiates its own suite, proves its own identity, and derives its own key. Nothing is reused across hops — a compromised hop key opens exactly one hop.
Edges are keyboard-focusable. Tab to a hop and press Enter to inspect it.
The console below is not a mock-up. It generates two real ECDH P-256 key-pairs, derives a shared AES-256-GCM key, encrypts what you type, hashes the ciphertext with SHA-256, and decrypts it on the other side — entirely inside this tab, with no network calls. The middle column shows every field the relay would actually hold.
this is everything we can see
{}Nothing you type leaves this page. There is no endpoint behind this widget — that is the point of showing you the primitives instead of a video.
Open an envelope to read it. It stays open — a desk of read correspondence is exactly the mental model we want you to leave with.
Each hop derives its own content key from a fresh ECDH exchange between exactly the two peers on that hop. Keys are never reused across hops and never derived from a long-lived secret, so compromising one hop's key yields one hop's payload and nothing else.
envelope opened →Private keys are generated in your infrastructure, your HSM, or an offline escrow quorum. KryptAPI publishes and verifies public key material and nothing else. There is no "recovery" path where we can read your traffic, because there is no material on our side to recover it with.
envelope opened →The relay stores routing metadata, ciphertext length, timestamps, and key fingerprints. It never stores plaintext, content keys, or decrypted metadata. Ciphertext is held only as long as the destination needs to collect it, then dropped on receipt-of-open.
envelope opened →Before an envelope moves, both peers prove themselves: a challenge/response signed with Ed25519 over a nonce bound to the route ID and timestamp. Agents attest their model identity and prompt policy the same way a service attests its TLS identity. An unattested peer receives nothing.
envelope opened →KryptAPI sits between the systems you already operate. Anything that can make an HTTPS call can seal, relay, and open — which in practice means everything on this row.
Billing is metered against the movements themselves, at rates fixed in your agreement and printed verbatim on every statement. There are no seats to count, no platform fee, and no tier that stops fitting the month your volume changes.
We don't do surprise math.