Most infrastructure companies start with an idea. This one started with an incident report we had to write about our own work.
In early 2044 we were four engineers building operational software for companies that run on intake: work orders arriving by email, forms filled in on phones at the side of a road, voicemails transcribed at two in the morning, and increasingly, AI agents summarising all of it into a dashboard someone would read over coffee. The plumbing worked. The authentication was tokenised magic links, because that is what everyone shipped, and it was the right call by every standard we were measured against.
Then a shared operations mailbox at one client was compromised. Not dramatically — a reused password, a stale session, the ordinary way it always happens. The attacker did not need to break anything we had built. They simply opened the inbox and found weeks of "secure links", each one a valid, unexpired, correctly signed invitation to a system holding customer records, site photographs, and payment instructions. Every entry was logged. Every entry looked legitimate, because by the rules we had written, every entry was legitimate.
We spent the next fortnight rotating tokens and writing an incident report, and somewhere in the middle of that fortnight the actual lesson arrived. Our cryptography had not failed. Our assumption had. We had assumed that the channel carrying a credential was neutral — a pipe, not a participant. It never was. The moment you send a link, the mailbox holding it becomes part of your security boundary, and you have almost certainly never audited it, because it does not belong to you.
A link is a promise: whoever holds this may enter. A sealed payload is a proof: only this key can open this, and here is the record of it being opened. The difference sounds academic until you are on a call at midnight explaining to a client why a system that did everything right leaked anyway.
So we stopped shipping references and started shipping sealed content. KryptAPI is that decision, generalised: any service, any model, any pipeline can seal, relay and attest through one interface, and the relay in the middle — us — never holds the keys to read what it carries. We built the thing we wished had existed the week before that mailbox was opened.
Hover the diagram to replay the re-forge.
You will find it in the client portal: no magic links, no emailed codes to a mailbox someone else might own. We could have quietly used the convenient thing for our own login. It felt like the one place we had no excuse.
Each of these has cost us a deal at least once. They are listed in the order we would defend them.
Private key material is generated inside your boundary and stays there. We hold public keys and fingerprints. This forecloses a whole category of product we could otherwise sell — server-side search, content-aware routing, "smart" summarisation of what we carry — and we have declined all of it, because every one of those features requires the ability to read your payloads, and once that capability exists it can be compelled, subpoenaed, or misused.
The relay carries ciphertext, routing metadata and quantities. There is no decrypt path, no break-glass procedure, and no support workflow that ends with an engineer reading a customer payload. When a client asks us to recover a lost envelope, the honest answer is that we cannot, and we say so in the first reply rather than the third.
Seals, opens, rotations, attestations, statements and settlements all write to the same hash chain, and every entry commits to the one before it. Your finance record and your security record are the same record. Nobody has to trust our word about what happened; they can verify it with a tool we did not write for them specifically.
AES-GCM, ECDH, Ed25519, SHA-256, HKDF. Nothing on that list would surprise a cryptographer, and that is the point. The interesting work is completeness: binding the AAD into key derivation so replays fail, refusing downgrade instead of negotiating it, making rotation a first-class event rather than a maintenance window, and never leaving a permissive mode switched on for convenience.
Three steps, in this order, with the detail we would give you on the first call rather than in the third meeting.
A short call. What information moves, between which systems, and who is allowed to read it at the other end. You will usually find two or three routes you had forgotten were carrying anything sensitive at all — that part alone is worth the hour.
Days, not months. Your tools stay exactly where they are, your team keeps working the way it works, and we wire the sealing into the gaps between systems. Nothing is decommissioned and nothing has to be learned.
Every movement is locked and logged from the first payload. You get the audit trail immediately — not after a rollout period, and not as a paid add-on later.
We do not publish client names, logos, or quotes. A list of who trusts us is a list of who to attack, and the shape of the integration tells you more than a logo ever would. Open each envelope for the quantities.
The shapes are recognisable even when the names are not, and one of them is probably yours.
A law firm whose client uploads must never sit readable in email. Engagement letters, discovery material and settlement statements arrive from clients all day, and every one of them currently lands in a mailbox that a single reused password could open.
maps to Secure Client Intake →A clinic using AI to summarise charts without exposing patient data. The summaries save hours a week; the part nobody can answer is where the chart text went, who else could read it, and what proof exists either way.
maps to Safe AI Connections →An agency moving campaign assets across forty client dashboards, where the hard requirement is that no client's material can be read by the network's own central tooling — including by the people who built it.
maps to Sealed Delivery →A field-service company sealing phone and email intake into dispatch, with an audit trail that survives an insurance dispute two years later — because somebody will eventually ask exactly when a job record moved and who opened it.
maps to Audit & Compliance Records →Field crews submit job intake by phone and email from sites with poor connectivity. Both channels now seal at the transfer boundary and open inside the dispatch system; the shared operations mailbox was removed from the trust boundary entirely.
Client asset pipelines across forty tenant dashboards, where the hard requirement was that no tenant's material could be readable by the network's own central tooling. Each tenant holds its own key-pair; the shared platform relays and never opens.
AI-agent chart summarisation with sealed model input and output on both legs, plus attested model identity and prompt policy on every call. Archive keys sit in a 2-of-3 offline escrow with a seven-year retention hint in the AAD.
Quantities are rounded and figures are current as of the last statement period. No sector, region, or volume combination described here is specific enough to identify an organisation, and that is deliberate.
Architecture questions are answered by the engineers who maintain the relay, usually within one business day. There is no qualification form, no discovery call before a technical answer, and no sales-engineering layer between you and someone who has read the sealing code.
If you are evaluating us against an internal build, tell us — we will give you an honest read on when building it yourself is the right call. For roughly one integration in five, it is.
Sealed since first payload. We do not run social accounts; if it matters, it belongs in an envelope.