Remote Attestation

Remote attestation lets you cryptographically confirm that a Model Vault Encrypted deployment is a genuine trusted execution environment (TEE) running the exact code you expect, before you send any data. It turns “trust us” into “verify it yourself.”

For background on TEEs, see the Confidential Computing Primer.

The flow below describes Model Vault Encrypted’s Intel TDX deployment with Intel Trust Authority as the attestation service. Other confidential-VM platforms (for example, AMD SEV-SNP) provide the same guarantees through equivalent mechanisms, with platform-specific evidence formats and verifiers.

What attestation proves

When a TEE starts, the hardware measures what is loaded into it and produces signed evidence (often called a quote), rooted in keys embedded in the chip. An attestation service then appraises this evidence and issues a signed attestation result that clients can verify. Model Vault Encrypted uses composite attestation that covers both the CPU and the GPU, together answering three questions:

Is this genuine TEE hardware? The evidence is rooted in keys embedded by the hardware manufacturers (Intel for the TDX CPU, NVIDIA for the GPU), so it cannot be forged by software pretending to be a secure environment.
Is it configured securely? The evidence confirms the security-critical configuration: that the Intel TDX VM is not debuggable, that the GPU booted with debug disabled, and that confidential-computing mode is active.
Is it running the expected code? The evidence contains cryptographic measurements (in effect, a fingerprint) of the firmware, kernel, inference workload, and container policy that were loaded, plus the GPU’s firmware and driver measurements. If anything differs, the fingerprint differs.

The Passport model with Intel Trust Authority

Model Vault Encrypted uses the Passport attestation model. Each trusted environment obtains a signed attestation token (its “passport”) from Intel Trust Authority (ITA), an external attestation service operated by Intel. Clients verify that passport rather than re-evaluating raw hardware evidence themselves.

End-to-end encryption between the client and the deployment uses Oblivious HTTP (OHTTP), so the load balancer and network only ever see ciphertext. The OHTTP keys are generated inside the confidential VMs and are never shared with Cohere.

End-to-end attestation and request flow

Secure environment starts

The deployment starts inside a confidential-computing environment with protected CPU execution and a GPU running in confidential-computing mode. During startup, the platform measures the firmware, kernel, runtime configuration, workload, and GPU state. Those measurements become the evidence that is later checked against an approved policy. The evidence is rooted in hardware keys built into the CPU and GPU, so the host or application software cannot forge different measurements and make them look valid.

ITA attestation (per VM)

The deployment generates an OHTTP key pair inside the trusted environment and binds the public key to the attestation evidence. Intel Trust Authority validates the CPU and GPU evidence against the hardware vendors’ roots of trust and checks the measured values against the registered policy. If the evidence matches, ITA returns a signed attestation token. The token is refreshed periodically.

Fleet-level trust

For deployments with multiple replicas, only environments that pass the same attestation policy are trusted to serve encrypted traffic. OHTTP keys remain inside attested environments and are never available to Cohere or the host infrastructure. This lets the service scale while preserving the same client-side verification and end-to-end encryption guarantees.

Client key discovery

The client-side Cohere OHTTP proxy fetches the deployment’s OHTTP public key and attestation token. It verifies that the token was signed by ITA, that the measurements match the approved policy, and that the OHTTP key is cryptographically bound to the attested environment. Only after those checks pass does the client trust the key.

Encrypted request serving

The client encrypts the request with OHTTP using the attested public key and sends it through the load balancer. The payload stays encrypted end to end; intermediate infrastructure can route the request but cannot decrypt it. The request is decrypted only inside an attested environment, inference runs there, and the response is encrypted before it leaves. The client-side Cohere OHTTP proxy decrypts the response. The load balancer never sees plaintext at any point.

How Intel Trust Authority verifies

ITA issues each attestation token as a JSON Web Token (JWT) signed with PS384. Your client verifies that token’s signature against ITA’s published public keys (JWKS), so it can confirm the result without trusting Cohere or the host. A non-empty set of matched policies is the single most important signal: it means the hardware was genuine and the measured software matched the approved values. If the policy did not match, no token is issued and the connection is refused.

Verifying the verifier

Intel also offers a Faithful Verification service: you can submit an attestation token to Intel and receive cryptographic proof (SGX quotes) that every ITA microservice that issued it was running unmodified code inside genuine Intel SGX enclaves. This protects you even against a compromised or rogue attestation operator.

Binding the connection to the environment

Attestation also protects against a host that tries to sit in the middle of the connection and impersonate the environment:

At startup, the confidential VM generates an OHTTP encryption key pair. The private key stays inside the TEE’s protected memory, and the public key is bound into the attestation evidence (carried in the report’s data field).
The client encrypts requests to the attested public key, so only a genuine, attested TEE can decrypt them.

Because the public key is covered by the signed attestation, the client knows the key really belongs to the attested environment and not to the host or load balancer. For scaled deployments, this trust model extends across the serving fleet without exposing plaintext to intermediate infrastructure.

Matching measurements to expected code

A fingerprint is only meaningful if you know what it is supposed to be. The ITA policy encodes the expected measurements for a given software version, produced by a reproducible build of the vault image and registered before deployment, so a passing attestation means your vault is running exactly that approved stack. The token also reports supporting detail you can inspect, such as the TDX measurement registers (MRTD, RTMR0 to RTMR3), the GPU firmware and driver measurement results, the TEE’s security-version and patch level, and the policy that was evaluated. See Verifying Your Deployment for what each field means.

What you are actually trusting

Attestation proves which code is running, but that code still has to be trustworthy: whatever runs inside the TEE can see your plaintext, so it is part of the trusted computing base. Cohere authors that code, but its trustworthiness does not rest on Cohere’s word. Two properties let you verify it for yourself:

The code is open source and built reproducibly. Cohere authors the vault image, the container policy, and the workload, but they are open and reproducibly built, so you (or an independent party) can rebuild the artifacts and confirm that the measurements in the attestation policy correspond to inspectable source, not to a black box.
An independent party enforces the check. The expected measurements are registered with Intel Trust Authority, which appraises the evidence and issues the token. Cohere supplies the policy, but it cannot forge a passing result, and you can verify the verifier itself with Intel’s Faithful Verification service.

In other words, you do not trust Cohere’s word that the right code is running; you trust hardware roots, an independent verifier, and source you can inspect.

When attestation runs

Per session: the client verifies attestation before exchanging any data, and refuses the connection if the evidence is invalid or the measurements do not match.
Short-lived and refreshed: attestation tokens are valid for only a few minutes and are refreshed periodically, so the result reflects the environment’s current state rather than a one-time check at deploy time.
In the Model Vault app: an encrypted vault carries a verification badge that reflects its current attestation status, so you can see it at a glance alongside your other vaults.
Available through the API: verification is not limited to the Model Vault app. Every inference response includes an attestation certificate that your client can check programmatically, confirming proof of the policy, CPU, GPU, and software before you trust a response.