# CoreWeave Zero Trust AI Framework: Controls, Availability and Limits

CoreWeave is connecting key custody, support access and confidential computing, but the framework's components are at different stages of availability.

By Paras Madan | 2026-10-21


CoreWeave announced its Zero Trust AI Framework on October 21, 2026, bringing encryption keys, provider access and runtime protection into one security model for AI infrastructure. The important qualification is availability: this is a framework spanning existing controls and planned capabilities, not six newly released, generally available products.

For an enterprise team, the useful question is which parts of a specific workload are protected today. A framework name cannot answer that on its own.

## What the framework covers

CoreWeave's [technical announcement](https://www.coreweave.com/blog/coreweave-zero-trust-ai-framework-your-model-your-data-your-trust) groups the design into six areas:

| Area | Intended control |
| --- | --- |
| Key access | Keep encryption-key authority with the customer |
| Node access | Require authorization for provider support access |
| Infrastructure | Verify the execution environment through attestation |
| Data in use | Protect code and data during execution |
| Model data | Do not use customer data to improve CoreWeave's own models |
| Network transport | Encrypt traffic across the CoreWeave backbone |

These controls address different points in a workload's lifecycle. Keeping a storage key outside the provider is different from protecting memory while a model runs. Restricting a support engineer's access is different again from verifying the machine's state.

**The controls need to be evaluated together, but none should stand in for the others.** A procurement checklist that records only whether a service is encrypted misses most of that distinction.

## What is available and what is planned

CoreWeave's [security page](https://coreweave.com/security) says customer-provided-key encryption is available for AI Object Storage. It separately lists Remote Key Encryption, or RKE, for limited availability in Q4 2026. Those should not be treated as interchangeable availability claims.

RKE was already described in the company's [September 22 announcement](https://www.coreweave.com/blog/bringing-enterprise-identity-and-key-control-to-ai-on-coreweave). Its proposed approach keeps key management with the customer's existing system rather than importing keys into a provider-side key store. The October framework therefore adds a broader organizing model around a previously announced capability.

The [October 21 release](https://investors.coreweave.com/news/news-details/2026/CoreWeave-Launches-the-CoreWeave-Zero-Trust-AI-Framework-Keeping-Customers-in-Control-of-Access-to-Their-Models-Data-and-Runtime-Environments/default.aspx) also describes plans for NVIDIA's third-generation confidential computing across CPUs, GPUs and NVLink, including HGX Rubin NVL8. CoreWeave expects that hardware in Q4 2026 and plans to begin with selected bare-metal environments before expanding to other deployment models, including Kubernetes workloads.

The same release describes Support Access Management as customer authorization for a defined operational need, with access ending when that activity ends. It also identifies MACsec encryption for backbone traffic. An enterprise still needs to confirm the supported environment and contractual scope for the workload it intends to deploy.

## Why attestation and key custody need to connect

Attestation provides evidence about an execution environment. A key-management system can use that evidence when deciding whether to release access to protected material. The important implementation question is what happens when the evidence is missing, stale or does not match the expected configuration.

Consider a hypothetical inference deployment using private model weights. Storage encryption protects the saved artifact, but the application eventually needs usable weights to perform inference. The security review must follow that transition rather than stop at the storage boundary.

Ask which component requests access, which identity authorizes it, what environmental evidence is checked, and what is recorded for later review. Also ask how revocation affects running workloads, not only future requests. Those answers matter more than a general claim that the provider cannot read customer data.

## What enterprise teams should verify

A focused evaluation should map every control to an actual service configuration and availability status. Include the supported key manager, deployment type, hardware, support workflow and failure behavior.

Performance and operations belong in the same review. Check the effect of unavailable key infrastructure, maintenance events and recovery procedures. A strong control that nobody has tested during an incident can create uncertainty precisely when the team needs predictable behavior.

CoreWeave's announcement is useful because it brings several parts of the trust boundary into one discussion. The next step is evidence at workload level: which controls are enabled, what they prevent, and how the customer can verify that they continue to work.

I'm Paras. I work at the intersection of AI, engineering and distribution.

I help teams explain complex enterprise AI products clearly to technical buyers and decision-makers, without losing the engineering detail.

[Book a 30-minute call](https://cal.com/paras-madan/30min).