Verifying Your Deployment

This page covers how you verify a Model Vault Encrypted deployment in practice. For the underlying mechanism, see Remote Attestation.

The verification that actually protects your data is automatic and client-side: the Cohere OHTTP proxy checks attestation on every connection, binds it to the key it encrypts to, and refuses to connect if anything is wrong. Separately, the Model Vault app displays a vault’s attestation details for at-a-glance status and audit. That display is informational; it is the client-side check, not the app view, that gates your traffic.

Automatic verification (the Cohere OHTTP proxy)

You do not have to do anything manually for verification to occur. The client-side Cohere OHTTP proxy, whether run as a standalone proxy or used as a Python package, runs the full check on every session and refuses the connection if anything is wrong:

1. It fetches the deployment’s OHTTP public key together with its attestation evidence (on AMD SEV-SNP, using the background check model) or its attestation token (on Intel TDX, using the passport model).
2. It confirms the result is authentic. On AMD SEV-SNP, it appraises the raw evidence directly, checking the SEV-SNP report against AMD’s certificate chain and the GPU evidence through NVIDIA’s Remote Attestation Service (NRAS). On Intel TDX, it verifies the token’s signature against Intel Trust Authority’s published public keys (JWKS), confirming Intel genuinely issued it and it was not tampered with.
3. It confirms the attestation policy matched, meaning the hardware was genuine and the measured software matched the approved values.
4. It confirms the OHTTP public key is cryptographically bound to the attested TEE, so it is encrypting only to the genuine environment.
5. It confirms the result is fresh: the evidence answers the proxy’s own nonce (background check), or the token is still within its short validity window (passport).

Only if all of these pass does the proxy encrypt and send your request.

In the background check model, freshness comes from the proxy’s own challenge: each time the proxy fetches the OHTTP key, it sends a new nonce, and the evidence must contain it, so a recording of an earlier attestation cannot pass.

In the passport model the proxy does not run its own nonce challenge against the deployment. Freshness is instead guaranteed by the token’s short lifetime: Intel Trust Authority issues a token only after a nonce exchange with the VM that produced the evidence, so a valid, unexpired token attests that the underlying evidence was fresh when ITA appraised it. Tokens are valid for only a few minutes and are refreshed periodically, so the result reflects the environment’s current state.

Inspecting attestation in the Model Vault app

Each confidential-computing model carries a green shield in the Model Vault app. Click it to open the attestation details, where the result is broken down into hardware, firmware, software, and policy checks:

The single most important field is the policy result: if the attested evidence matched an approved policy, the overall verdict is secure. The sections below explain what each group of fields tells you; where the AMD SEV-SNP and Intel TDX paths differ, both are listed.

Token Metadata (Intel TDX)

On Intel TDX, the Token Metadata section describes fields of the token issued by Intel Trust Authority.

CPU confidentiality

These fields describe the confidential VM the workload runs inside.

AMD SEV-SNP (Azure)

The virtual TPM’s PCRs are listed under Software and firmware integrity below.

Intel TDX

The measurement registers record what was loaded, in stages:

• MRTD: the initial measurement of the confidential VM, taken by the hardware as the TD is built (the virtual firmware that launches it).
• RTMR0: virtual firmware (OVMF/TDVF) and its configuration.
• RTMR1 / RTMR2: the kernel, initrd, boot parameters, and OS components measured during boot.
• RTMR3: runtime, workload-specific measurements (for example, the inference stack and configuration).

GPU security

These fields prove the GPU is genuine hardware running verified firmware. The GPU evidence is checked by NVIDIA’s Remote Attestation Service (NRAS) on both paths and folded into the composite token.

Software and firmware integrity

Attestation verifies the integrity of the whole stack, not just the GPU. The evidence and the attestation policy together confirm both the CPU/VM side and the GPU side.

CPU and virtual machine (AMD SEV-SNP on Azure):

• The Azure paravisor firmware that hosts the VM’s virtual TPM, captured in the SEV-SNP launch measurement.
• The boot chain, kernel, initrd, and boot configuration, captured in the virtual TPM’s PCRs.
• The read-only root filesystem (dm-verity) and the enforced Kata container policy, so only the approved image, containers, and processes can run.

On AMD SEV-SNP, this section of the app lists the virtual TPM’s PCRs, which record what was loaded, in stages. The attestation policy pins each of them to approved values:

• PCR4: the boot chain, meaning the unified kernel image (UKI) and the kernel it carries.
• PCR5: the GPT partition table.
• PCR8: the deployment’s initdata, which carries the enforced Kata agent policy and the guest configuration.
• PCR9: the kernel command line and initrd. The command line carries the dm-verity root hash, so this also pins the root filesystem.
• PCR11: every section of the UKI, which identifies the OS image.

CPU and virtual machine (Intel TDX):

• The virtual firmware (OVMF/TDVF) and the TDX module that launched the confidential VM, captured in MRTD and RTMR0.
• The kernel, initrd, and boot configuration, captured in the runtime measurement registers.
• The read-only root filesystem (dm-verity) and the enforced Kata container policy, so only the approved image, containers, and processes can run.

GPU (checked by NRAS):

• The attestation report was parsed, its certificate chain validated, and its signature cryptographically verified.
• The driver and VBIOS Reference Integrity Manifests (RIMs) were validated and their signatures verified.
• All GPU firmware measurements match their reference values.

Together these confirm that the firmware, operating system, inference workload, and GPU are all the approved, measured stack, not just that the underlying hardware is genuine.

Policy compliance

On AMD SEV-SNP, each policy hash is the SHA-256 digest of the policy file, prefixed with sha256:. To confirm that the deployment was appraised against the published policy and nothing else, compare the CPU hash with the digest of trustee_policy_cpu.rego, and the GPU hash with the digest of trustee_policy_gpu.rego, in the Integritee release named by the policy version. The release’s signed predicate.json also records these digests under trustee_policies. A mismatch means the policy differs from the one Cohere published.

Deeper audit (advanced)

For security teams who want to go further:

• Policy provenance (AMD SEV-SNP): every policy release in Cohere’s public Integritee repository is Sigstore-signed and recorded in the public Rekor transparency log, and lists the measurements of each approved workload. You can verify a release with standard Sigstore tooling and compare its values against your own measurements of the guest OS image and guest configuration data (initdata).
• Faithful Verification report (Intel TDX): submit your attestation token to Intel to obtain cryptographic proof that every ITA microservice involved in issuing it ran unmodified code inside genuine Intel SGX enclaves. This protects you even against a compromised or rogue attestation operator.
• Raw measurements and collateral: the result exposes the full CPU measurements (the SEV-SNP launch measurement and virtual TPM PCRs, or the TDX measurement registers), security-version numbers, and verification collateral so you can independently compare them against expected values.

Troubleshooting verification failures

If the proxy refuses to connect, it is by design: verification failed and no data was sent. Common causes:

• Invalid evidence or token signature: the SEV-SNP evidence did not chain to AMD’s roots of trust, or the token was not genuinely signed by Intel Trust Authority. Do not send data.
• Policy did not match: the measured firmware, kernel, workload, or GPU firmware differs from the approved stack, so the appraisal failed.
• Key not bound to the TEE: the OHTTP public key was not cryptographically tied to the attested environment, which can indicate an attempted interception.
• Expired or replayed attestation material: the evidence did not answer the proxy’s nonce, or the token is past its short validity window.

In all cases the safe behavior is the one that happens automatically: the proxy refuses to connect. If a vault consistently fails verification, check its status in the Model Vault app and contact Cohere support.

Related pages

• Remote Attestation
• Security Model
• Calling an Encrypted Vault over the API