> This page is for version v2 API (default). > For other versions, use one of these documentation indexes: > - v2 API (default): https://docs.cohere.com/v2/llms.txt > - v1 API: https://docs.cohere.com/v1/llms.txt > For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.cohere.com/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.cohere.com/_mcp/server. # Remote Attestation > How remote attestation proves which code runs inside a encrypted vault deployment, on AMD SEV-SNP or on Intel TDX with Intel Trust Authority. 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](../../../docs/model-vault/encrypted/confidential-computing). > **Note** > > Model Vault Encrypted has two attestation paths, depending on the deployment's confidential-VM > platform: **AMD SEV-SNP** deployments use the background check model, with the evidence appraised > directly by the Cohere OHTTP proxy on your side, and **Intel TDX** deployments use the passport > model, with the evidence appraised by Intel Trust Authority. The Cohere OHTTP proxy supports both and > follows whichever path the deployment uses. ## 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 (AMD for an SEV-SNP CPU or Intel for a 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 confidential 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. ## Attestation models In both models, the deployment's evidence is verified before any data is sent; the models differ in where that verification takes place. On AMD SEV-SNP, the Cohere OHTTP proxy verifies the evidence directly in your environment. On Intel TDX, Intel Trust Authority verifies the evidence and issues a signed token, which the proxy then validates. The proxy supports both models and selects the appropriate one automatically; no configuration is required. Both models are defined in the IETF Remote ATtestation procedureS (RATS) architecture. ### Background check model (AMD SEV-SNP) In the **background check model**, the verifier obtains the evidence directly from the deployment and evaluates it, rather than relying on a credential the deployment presents. Here, the verifier is the Cohere OHTTP proxy running in your environment. The proxy sends the deployment a fresh challenge (a nonce), receives the raw evidence in return, and verifies that evidence against the approved policy. For the GPU, it uses **NVIDIA's Remote Attestation Service (NRAS)** to compare the GPU's measurements against NVIDIA's signed reference values, and checks NVIDIA's signature on the verdict before applying the policy to it. ### Passport model (Intel TDX) In the **passport model**, each trusted environment obtains a signed attestation token (its "passport") from **Intel Trust Authority (ITA)**, an external attestation service operated by Intel. The Cohere OHTTP proxy then verifies that passport. End-to-end encryption between the Cohere OHTTP proxy 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. ### Attestation (per VM) An OHTTP key pair is generated and rotated inside the trusted environment, and the public key is bound to the attestation evidence. In the background check model, the deployment produces fresh evidence for each challenge from the proxy and returns it with the public key, and the proxy verifies the evidence before using the key. In the passport model, the deployment produces fresh evidence for ITA's challenge, and ITA verifies it and issues a signed attestation token, which is refreshed periodically. In both cases, the verifier validates the CPU and GPU evidence against the hardware vendors' roots of trust and checks the measured values against the approved policy. ### 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 together with its attestation evidence (background check) or token (passport). On AMD SEV-SNP, it appraises the evidence directly and confirms the evidence answers its own challenge; on Intel TDX, it verifies that the token was signed by ITA. In both cases, it checks 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 proxy trust the key. ### Encrypted request serving The proxy 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 the attestation material is verified ### AMD SEV-SNP: appraisal in the Cohere OHTTP proxy The Cohere OHTTP proxy checks that the CPU evidence is authentic against AMD's certificate chain, and the GPU evidence through NRAS, then evaluates the approved policy over the resulting claims. Because the appraisal runs on your machine, the only external verifier you rely on is NVIDIA, for the GPU. The proxy also fetches policy releases from Integritee on GitHub, but installs one only after verifying its Sigstore signature, so GitHub is an availability dependency rather than a trust dependency. The result is recorded as a token signed by a key that exists only inside the running proxy, so it is a record of the proxy's own appraisal rather than a credential issued by a third party. If the policy does not match, the appraisal fails and the connection is refused. ### Intel TDX: token from Intel Trust Authority ITA issues each attestation token as a **JSON Web Token (JWT) signed with PS384**. The Cohere OHTTP proxy 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 Cohere OHTTP proxy 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 proxy 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 attestation policy encodes the expected measurements for a given software version, produced by a build of the vault image. The policies are published as signed releases in Cohere's public [Integritee](https://github.com/cohere-ai/integritee) repository, so a passing attestation means your vault is running exactly that approved stack. * **AMD SEV-SNP (appraised by the Cohere OHTTP proxy)**: the proxy downloads the policies and installs a release only after verifying its Sigstore signature, which ties it to Integritee's release workflow and the public Rekor transparency log. * **Intel TDX (appraised by Intel Trust Authority)**: the policy is registered with Intel Trust Authority, and the attestation token contains the name and hash of the policy that was evaluated. The result also reports supporting detail you can inspect, such as the CPU measurements (the SEV-SNP launch measurement and virtual TPM PCRs, or the TDX measurement registers MRTD and 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](../../../docs/model-vault/encrypted/verifying-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. * **Checks are enforced independently of Cohere.** On AMD SEV-SNP, the Cohere OHTTP proxy running in your environment appraises the evidence against a policy whose every release is signed and publicly logged. On Intel TDX, Intel Trust Authority appraises the evidence against a policy registered with it and published in the same signed releases, 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 Cohere OHTTP proxy verifies attestation before exchanging any data, and **refuses the connection** if the evidence is invalid or the measurements do not match. * **Fresh and refreshed**: in the background check model, the proxy challenges the deployment with a new nonce each time it fetches the OHTTP key; in the passport model, tokens are valid for only a few minutes and are refreshed periodically. Either way, 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 application can check programmatically, confirming proof of the policy, CPU, GPU, and software before you trust a response. ## Related pages * [Verifying Your Deployment](../../../docs/model-vault/encrypted/verifying-deployment) * [Security Model](../../../docs/model-vault/encrypted/security-model) * [Confidential Computing Primer](../../../docs/model-vault/encrypted/confidential-computing)