Cryptographic proof of secure execution

"Secure" is a claim. We ship the evidence with it. With remote attestation, your side can verify, before any data leaves your hands:

What hardware is running the workload: a genuine AMD SEV-SNP, Intel TDX or NVIDIA confidential-computing device, verified against the vendor's signing keys
What code is running: a cryptographic measurement of the exact software image, compared with the release you approved
That the connection ends inside it: the encryption key of your session is bound into the hardware-signed report, so no proxy, load balancer or operator can sit in the middle

If any check fails, the client refuses to send data.

How it works

Measured launch. When the confidential VM or enclave starts, the CPU records a hash (the launch measurement) of the firmware, kernel and application image, which nothing running later can change.
Hardware-signed report. On request, the CPU produces an attestation report containing that measurement and a field for our data. The report is signed with a key that chains to the silicon vendor's root (for AMD: VCEK → ASK → ARK).
Key binding. The workload puts a hash of its TLS or session public key (plus your fresh nonce) into the report, which proves the key lives inside that measured environment.
Verification on your side. Your client or verifier checks the signature chain, compares the measurement with a pinned value, and checks the key binding and nonce. Only then does it proceed.
Attestation-gated secrets. Database keys, model weights and API credentials are released by a key broker only to workloads that pass attestation. An operator who copies the disk gets ciphertext.

Pinned, not trust-on-first-use

Many confidential-computing SDKs accept "the latest release" from the vendor's repository. That quietly moves the trust back to whoever controls the repository. We pin the measurement of the exact release you approved:

Builds are reproducible: anyone can rebuild the image from source and get the same measurement.
Releases are signed, and their provenance is published to a transparency log.
When we ship an update, you get the new measurement, the diff and the provenance before your verifiers accept it.

Per-response receipts

For AI and API workloads, we can also sign each response inside the enclave. Every answer then carries a receipt that ties it to the attested code that produced it. That's useful when you need to prove, later, which model and code produced a given output.

What we've done ourselves

We don't sell attestation we haven't checked. We have independently verified the attestation chains of three commercial confidential-AI providers from the outside (AMD SEV-SNP and Intel TDX), using our own tooling and no vendor code. We also built client-side attestation and encrypted request sealing into our own agent runtime. Those findings, including where the providers' guarantees end, shape how we design your deployment.

What attestation does not prove

Attestation proves what is running and where. It doesn't prove the code is bug-free, which is why every build also gets an audit, tests and a small TCB (see Reducing your TCB). It also relies on the silicon vendors' roots of trust and firmware being sound. That residual trust is documented in every deployment.