# Cohere Model Vault Confidential Computing: Beta, API and Security Limits Encrypted Vaults add hardware-backed protection to managed inference, but the client you use determines where that protection begins. By Paras Madan | 2026-10-22 Cohere announced Confidential Computing on Model Vault in public beta on October 22. It runs inference on NVIDIA H100 GPUs in Microsoft Azure, adding protection while data is being processed. The practical change is that customers can verify the computing environment before releasing a sensitive request to it. A dedicated model endpoint already separates one customer's infrastructure from another's. This release addresses a different question: who can read the data inside the infrastructure operating that endpoint? ## What changes in an Encrypted Vault Model Vault is Cohere's managed, single-tenant inference service. The [new confidential-computing option](https://cohere.com/blog/introducing-confidential-computing-on-cohere-model-vault) adds a protected execution environment across the CPU and GPU, plus encryption that carries the application payload into that environment. Ordinary transport encryption protects a request while it travels between systems. Once a server receives it, the application needs access to its contents. With confidential computing, plaintext processing happens inside a hardware-protected boundary intended to keep outside infrastructure and its operators from reading protected memory. The model still processes plaintext inside that boundary. This is not computation directly on encrypted values, and it should not be confused with homomorphic encryption. ## The API stays familiar, but the connection changes The important integration detail is in Cohere's [Encrypted Vault API documentation](https://docs.cohere.com/docs/model-vault/encrypted/api-usage). Request and response formats remain familiar, but applications must use a client-side OHTTP proxy or the Python `conseel` transport wrapper. Calling the vault directly does not provide the documented client-side flow. OHTTP, or Oblivious HTTP, encrypts the application payload for the destination that is allowed to decrypt it. Before sending, the client verifies signed evidence about the hardware and software, checks it against an approved policy, and verifies that the encryption key belongs to that environment. A failed check stops the request. **The verification belongs before the data leaves your environment.** Cohere also documents a hosted proxy for demonstrations, disabled by default. That route changes the trust model because Cohere operates the proxy. It should not be treated as equivalent to running verification and encryption on the customer's side. For an engineering team, this adds a component to own even though the inference servers remain managed. Proxy versions, approved measurements and failed-attestation handling become part of the deployment process. ## Beta availability, models and pricing The announcement calls this a public beta. The [pricing documentation](https://docs.cohere.com/docs/model-vault/encrypted/pricing) is more specific about commercial access: the beta is free for design partners, with interested teams directed to contact Cohere. General-availability pricing has not been published there. This is not a promise of free confidential inference for every API account. The [supported-model list](https://docs.cohere.com/docs/model-vault/encrypted/supported-models) includes Embed, Rerank, Parse, the Compass bundle, North Mini Code, Cohere Transcribe and customized Cohere models. Availability can differ from Standard Vaults, so teams should confirm the exact model rather than assume every Cohere model is included. H100 on Azure is the announced beta infrastructure. Blackwell support, including B200, is future work rather than something to plan an immediate deployment around. ## What confidential computing does not solve Cohere's [architecture explanation](https://cohere.com/blog/inside-cohere-model-vault-building-verifiable-confidential-ai-inference) draws useful limits around the claim. Some side-channel and physical attacks remain outside its protection boundary. Operators may still interrupt a workload even when they cannot read its protected memory. Request timing, message size, traffic volume and routing information can remain observable. In this architecture, the API credential and model identifier sit outside the OHTTP-protected application payload too. Application security also remains the customer's problem. A model can still follow a malicious instruction, an application can still expose data through an overly permissive tool, and the wrong person can still receive a response. Encrypting the inference path does not repair those decisions. Nor does it determine where data is processed. Residency requirements and contractual reviews need their own checks. ## Where this becomes useful Consider an internal document-search product. A security team might accept the model's quality but reject the number of infrastructure components that could see proprietary material during inference. Encrypted Vaults offer a way to narrow that exposure without asking the product team to operate the entire serving stack itself. The remaining work is to decide which measured environment deserves approval and how that approval changes when software is updated. Attestation makes that decision enforceable; it does not make the decision for the customer. That is the useful shift here. A managed inference purchase can now include a technical test for the environment receiving the data, rather than relying entirely on a supplier's description of it. I'm Paras. I work at the intersection of AI, engineering and distribution. I help teams turn complex enterprise AI products and technical launches into clear stories that developers and decision-makers can understand. [Book a 30-minute call](https://cal.com/paras-madan/30min).