CoreWeave Says It Cannot Read Your Data. That Is the Whole Offer.

Enterprise security teams have to name everyone who can decrypt regulated data. On most clouds that list includes the cloud provider. Model weights and training checkpoints carry the same obligations as payroll records, so the review stalls before a GPU is ever booked. CoreWeave‘s answer, reported on 22 September, moves the key custody boundary into the customer’s own key store. The AI cloud keeps ciphertext and nothing else.

Key custody is a list of names, not an algorithm

Auditors do not ask which cipher you use. They ask who holds the key and who can make a copy. The standard cloud answer is that the provider can, and that its operators are covered by policy. Remote Key Encryption responds to that directly. It runs client-side, inside the customer’s own compute boundary, with keys generated and stored in a secrets manager, key management system, or hardware security module the customer already operates. No key is imported provider-side.

Rotation, expiration, and revocation run on the customer’s existing schedule and tooling. CoreWeave says lifecycle is driven through that infrastructure rather than through a parallel set of controls, and that its approach to lifecycle management is patent pending. The encryption algorithms underneath are standard ones. Access to the nodes stays behind support access controls, so a company engineer cannot reach a node without the customer’s express permission.

Ciphertext at rest is not confidentiality in use

Key custody covers stored data and the decrypt list. It does not cover plaintext in memory while a training job or an inference server is running. If the threat model includes the provider’s own staff or a compromised hypervisor, key management is the wrong control. That problem needs confidential computing, where memory stays encrypted and the environment is attested before anything is released. Those are two different products, and a buyer should not let one claim stand in for the other.

Scope is the second thing to read carefully. The first release protects data on AI Object Storage. Training clusters pull data through other paths too, including network file systems and local scratch. Ask which of those paths still hand the provider a readable copy, because the answer decides whether the control actually covers the workload that worried the auditor in the first place.

The identity path decides whether any of this holds

A key store fronted by identity is only as strong as the identity path. CoreWeave IAM federates with Microsoft Entra and Okta, so the enterprise directory stays the source of truth, and automated user provisioning syncs users and groups across CoreWeave Kubernetes Service, AI Object Storage, and the console. Training clusters are the harder case because Slurm carries its own POSIX identity. SUNK packages Slurm for Kubernetes, and its provisioning creates the POSIX user and groups, syncs SSH keys, and sets up the Slurm account the moment a federated user appears.

The launch shape matters for planning. Limited availability comes later this year, IBM is the launch partner, and the first keys come from HashiCorp Vault, Vault Enterprise, or any key management and hardware security product that speaks the Key Management Interoperability Protocol. IBM acquired HashiCorp in 2025. If your stack is not on that list, the useful question is when it will be, not whether the feature exists.

Three questions to put to any cloud making this promise. Where is the key generated, and can the provider ever hold a copy? Who can rotate and revoke, and what happens to a running job when rotation fails? Which storage paths are covered today, and which ones still leave the provider able to read your data?

Related reading. Our piece on what a supply chain audit actually asks for covers the evidence a reviewer accepts. The closer look at why AI pilots die in production covers what fails after approval, which is usually infrastructure rather than the model.