Encryption at rest is a solved problem. Encryption in flight, between systems that were never designed to trust each other, with proof afterwards that nothing was altered — that is the problem KryptAPI exists to solve. This page is the mechanism, in full.
A KryptAPI envelope is a single JSON object with five parts. Hover or focus any layer — in the diagram or the list — to separate the stack and see the field it maps to on the wire.
{
"v": 1,
"env": "env_9f42a1c7b3d4c1a7",
"hdr": {
"hop": 2,
"kid": "key_agent_5f1c",
"alg": "ECDH-ES+A256GCM",
"iv": "9pQm1xTf0Ad2"
},
"epk": { "kty": "EC", "crv": "P-256", "x": "b2c80f55…13ae", "y": "7d19aa0e…c412" },
"aad": "hop=2;route=rt_2d55;ts=1786553527;retain=7y",
"ct": "k9RtQ2b…",
"att": [
{ "peer": "agent-runtime.client", "sig": "1e77…c39a", "ok": true },
{ "peer": "ops-dashboard.client", "sig": "7c02…e441", "ok": true }
]
}
// note what is absent: no content key, no recipient private material,
// no plaintext metadata beyond what routing strictly requires.Sealing once at the origin and relaying that same ciphertext everywhere would make one stolen key a catastrophe. KryptAPI instead performs a fresh key agreement per hop, between exactly the two peers on that hop, bound to that hop's route ID and timestamp.
Each peer holds a long-lived identity key-pair used only for attestation signatures — never for content encryption. For the transfer itself, the sender generates an ephemeral key-pair, performs ECDH against the recipient's published public key, and runs the shared secret through HKDF-SHA256 with the hop's AAD as the info parameter.
Because the AAD is bound into the key derivation, the derived key only works for that exact hop, route and time window. Replaying a captured envelope onto a different hop produces a key that decrypts nothing.
Select an edge to open its hop transcript. Each hop negotiates its own suite and derives its own key.
Scroll through a rotation ceremony: a key splits into a 2-of-3 quorum across custody nodes you control, rotates on schedule, and recombines with the event committed to your audit chain.
Key material is generated inside your boundary and split into a 2-of-3 quorum: your infrastructure, your HSM, and an offline escrow you control. KryptAPI receives public key material and a fingerprint. That is the entire extent of our custody.
On the scheduled cadence — or on demand via POST /v1/keys/:id/rotate — each share re-derives. The retiring pair enters a read-only grace period so in-flight envelopes still open; new envelopes bind to the new key from the first millisecond.
The rotation writes one audit entry carrying the quorum record, the retiring and incoming fingerprints, and the attestations of every participating custodian. It is metered as an attestation event, priced like infrastructure, and printed on your statement.
The right column does not resolve on hover, on click, or on a support ticket. It does not resolve because the data does not exist on our side of the boundary.
| Field | What the relay carries | What the relay can read |
|---|---|---|
| Envelope ID | env_9f42a1c7…c1a7 | env_9f42a1c7…c1a7 |
| Route ID & hop index | rt_2d55 · hop 2 | rt_2d55 · hop 2 |
| Ciphertext length | 41,208 bytes | 41,208 bytes |
| Key fingerprints | 8f2a…d901 → 5f1c…a740 | 8f2a…d901 → 5f1c…a740 |
| Timestamps | sealed 14:32:07 · opened 14:32:09 | sealed 14:32:07 · opened 14:32:09 |
| Payload content | ciphertext | |
| Content key | never transmitted | |
| Recipient private key | never transmitted | |
| Filename / subject / body | inside ciphertext | |
| End-user identity | inside ciphertext |
Ciphertext is held only until the destination collects it, then dropped on receipt-of-open. Undelivered envelopes expire on the route's TTL — default 72 hours, configurable down to 60 seconds.
A lawful demand produces routing metadata, quantities, and fingerprints. It cannot produce content, because we cannot produce content. We publish the shape of what we would hand over.
Relay operators can restart nodes and read queue depths. There is no console, flag, or break-glass procedure that renders a payload. The capability was never built.
TLS proves you are talking to a server. Attestation proves you are talking to that service, running that policy, holding that key — and proves it in both directions, on every hop, every time.
A service attests with its Ed25519 identity key and a policy digest covering which routes it may open and which it may originate.
An LLM agent additionally attests its agent ID, weights digest, and prompt-policy ID. Change the policy and the attestation changes with it.
A failed attestation emits attestation.failed in amber, refuses the envelope, and bills nothing. There is no permissive mode.
The envelope is identical in all three. Only the question of who runs the relay changes.
KryptAPI operates the relay. You publish public keys, we route ciphertext. Fastest path to production — most integrations are live inside a day, and there is nothing for you to patch.
custody: yours · relay: ours · median setup: hours
envelope opened →Cloud relay, but key operations execute inside your hardware security module via PKCS#11. Rotation ceremonies require a quorum of your custodians. Common where a regulator wants key operations attributable to named humans.
custody: your HSM · relay: ours · quorum: 2-of-3
envelope opened →You run the relay binary in your own VPC or on-premises. KryptAPI supplies the software, the peer directory format, and the audit verifier. Metering is reported from your relay's signed usage receipts.
custody: yours · relay: yours · air-gap: supported
envelope opened →Architecture reviews are done by the engineers who maintain the relay. There is no sales-engineering layer to get past.