Frequently Asked Questions About Model Vault Encrypted

Create a vault as usual and choose the Encrypted option. Model Vault Encrypted is currently in beta; to join, contact Cohere. See the Quickstart.

Model Vault Encrypted is priced separately from a Standard Vault. See Pricing.

Yes. Hardware-enforced confidentiality, single-tenant isolation, Zero Data Retention, and verifiable attestation map onto common requirements, and the attestation evidence can support audits. It is not legal advice; evaluate the controls against your own obligations. See Compliance.

The cryptographic material needed to decrypt your prompts and responses never leaves the TEE, and with Zero Data Retention nothing is persisted, so there is no plaintext for Cohere to produce. There are no operational, debug, or support paths that bypass the TEE boundary.

Yes. Each attestation token identifies the environment, the policy evaluated, and when verification occurred, giving you a verifiable record. For the strongest assurance, Intel’s Faithful Verification service lets you confirm the attestation service itself ran genuine, unmodified code. See Compliance.

No. Your prompts and responses are decrypted only inside the trusted execution environment (TEE), using keys that are generated inside the environment and never shared with Cohere. The protection is enforced by the hardware and verified through attestation. See the Security Model.

No. The confidential VM keeps CPU memory hardware-encrypted and the NVIDIA GPU runs in confidential-computing mode, so the hypervisor, host operating system, and anyone with privileged access to the machine see only ciphertext. This is the core difference from a conventional cloud deployment.

No, and more fundamentally Cohere cannot. Your prompts and responses are decrypted only inside the TEE and Cohere never has access to them, so there is no plaintext that could be used to train, fine-tune, or improve any model. Zero Data Retention (ZDR) further ensures they are not retained after inference.

Content stays inside the TEE, but a few things are necessarily visible outside it: routing metadata carried in request headers (such as the model name, so the load balancer can route the request), operational metrics derived from infrastructure telemetry (latency, throughput, utilization), and network-level metadata (timing and byte volume). None of these expose the contents of your prompts or responses. See Monitoring.

Cohere (including operators and support), the cloud provider and anyone with hypervisor or host-level access, the Kubernetes control plane, the load balancer and network, and other tenants (your vault is single-tenant). All of them sit outside the trust boundary. See the Security Model.

A compromised or malicious host OS, hypervisor, or orchestration layer; a privileged insider at the cloud provider or at Cohere attempting to read data in use; a network attacker or compromised load balancer on the path; and any attempt to substitute tampered code for the approved inference workload (caught by attestation).

Confidential computing does not eliminate every risk. Residual risks include hardware side-channel attacks (timing, cache, microarchitectural leaks), attacks requiring deep physical access to the hardware, metadata and traffic-pattern observation (request timing, sizes, the model called), and availability (the operator still controls scheduling and can stop or restart the environment). These depend on the correctness of the underlying Intel and NVIDIA hardware.

A Standard Vault gives you a dedicated, single-tenant deployment with data protected in transit and at rest. Model Vault Encrypted adds protection in use (confidential computing across CPU and GPU) plus verifiable remote attestation, so your data is also protected while the model is running, and you can prove it.

TLS protects data in transit and disk encryption protects data at rest, but both leave data in plaintext in memory while it is processed. Confidential computing closes that gap by keeping data encrypted and isolated in use, inside the TEE, where even the infrastructure operator cannot read it. See the Confidential Computing Primer.

The keys that protect your data are generated inside the TEE and never leave its hardware boundary, so Cohere and the cloud provider never have access to them. Memory-encryption keys live in the processor; the OHTTP keys that protect your traffic are generated per environment and shared only with peer environments that pass attestation. See Encryption & Key Management.

Requests are end-to-end encrypted from your client into the TEE with Oblivious HTTP (in transit), processed inside a hardware-based confidential VM and an NVIDIA GPU in confidential-computing mode (in use), and the vault boots from an integrity-protected, read-only image (at rest). Plaintext exists only inside the TEE, only for the duration of the request.

Remote attestation lets you cryptographically confirm that you are talking to a genuine TEE running the exact, approved code, before any data is sent. It turns “trust us” into “verify it yourself,” which is what makes the privacy guarantee verifiable rather than contractual. See Remote Attestation.

That the environment is genuine TEE hardware (rooted in keys from Intel and NVIDIA), that it is configured securely (debug disabled, confidential-computing mode on), and that it is running the expected code (measured firmware, kernel, inference workload, container policy, and GPU firmware). If anything differs, the measurements differ and attestation does not pass.

It is automatic. The client SDK, or proxy, verifies attestation on your behalf and refuses the connection if anything is wrong. Every inference response also includes an attestation certificate your client checks, confirming proof of the policy, CPU, GPU, and software for the environment that served it. You can also inspect the result visually in the Model Vault app. See Verifying Your Deployment.

Both. The client sdk or proxy verifies attestation before sending data, and every inference response includes an attestation certificate you can retain as a verifiable record of the exact environment that served the request. See Compliance.

The client refuses the connection and does not send your request, so your data is never exposed to an unverified environment. Verification failing is the safe outcome by design.

Any change to the vault image, model, or configuration changes its attestation measurements. The updated measurements are registered through the reproducible build pipeline, and attestation continues to gate every request against the approved values, so an unexpected or tampered build fails verification rather than silently serving traffic.

No. The load balancer and network only ever carry Oblivious HTTP (OHTTP) ciphertext and cannot decrypt it. Your client verifies attestation and encrypts only to an OHTTP key that is cryptographically bound to a genuine, attested environment, so a host or proxy cannot route you to untrusted hardware or impersonate the vault: traffic sent to anything that has not passed attestation simply cannot be decrypted.

See Supported Models for the current list, which is expanding over time.

The impact is modest. The GPU’s internal computation and on-package memory bandwidth are unaffected; the main cost is encrypting data as it moves between the CPU and GPU. Newer generations of confidential-computing GPUs reduce this cost further, narrowing the gap with non-confidential execution.

Inference runs inside a hardware-based confidential VM (for example, Intel TDX or AMD SEV-SNP) paired with a confidential-computing-capable NVIDIA GPU. To confirm the options available for your model, capacity, and region, contact Cohere.

Yes, the API is the same. The only difference is that your traffic goes through the Cohere client or proxy, which verifies attestation before any data is sent, then encrypts your requests and decrypts your responses end to end using OHTTP. Your application code stays unchanged. See Using the API with an Encrypted Vault.