Some of the highest-value applications of frontier AI depend on access to an enterprise’s most valuable data. For many enterprises, regulatory, security, and governance requirements make that access impossible.
Model providers have a similar problem with their proprietary model weights, which they are often unwilling to deploy on infrastructure where another organization’s administrators could inspect them. As long as the enterprise won’t send its data to the model and the model provider won’t send its model to the data, the applications that need both never get built.
Both problems come down to trusting whoever operates the infrastructure where the model and the data come together. If an enterprise runs the model on hardware it owns, the enterprise is the infrastructure operator, and the model provider needs protection from the enterprise’s administrators. If an AI cloud or sovereign infrastructure provider hosts the model instead, that third organization is the infrastructure operator, and both the enterprise and the model provider need protection from its administrators.
Today we are introducing VAST DataEnclave, the confidential AI capability of VAST DataEngine, which lets proprietary models and sensitive data come together on infrastructure that neither of their owners has to trust. DataEnclave runs AI workloads in hardware-isolated environments where models and data are decrypted only inside protected memory that the infrastructure and its administrators cannot access. Before a workload can start, DataEnclave gives the owner of the model or data hardware-signed proof of the environment it will run in, and the owner releases the keys only if that proof meets its security policies. Neither VAST nor the infrastructure operator ever has access to another party’s keys.
From Confidential Hardware to a Confidential AI System
Confidential computing has protected data in use for CPU-based workloads for years, extending protection beyond data at rest and in transit. Hardware-based trusted execution environments isolate a workload from the host infrastructure, including the operating system or hypervisor, and use attestation to produce evidence about the environment a workload will run in.
AI workloads add an additional challenge to protecting data in use, because training and inference operate on unencrypted model weights, prompts, and intermediate results that must be loaded into GPU memory. CPU memory encryption, provided by technologies like Intel TDX and AMD SEV-SNP, cannot on its own form a complete confidential execution boundary around an accelerated AI workload.
To meet that challenge, GPUs now extend the confidential execution boundary into accelerated computing by protecting GPU memory and CPU-to-GPU transfers from the host, and newer GPU platforms also protect the links between GPUs. DataEnclave uses these capabilities to create confidential virtual machines (CVMs) that span both the CPUs and the GPUs, ensuring that the host operating system, the hypervisor, the administrators of the machine, and other workloads on the same infrastructure cannot access a workload’s unencrypted contents.
Turning confidential computing hardware into a confidential AI system requires more than isolation, though. DataEnclave builds on that isolation by proving what is running to the owner of the model or data, giving that owner control over which environments receive its keys, and keeping a record of those decisions.
Verifying the Environment Before Granting Access
DataEnclave divides this work between the untrusted infrastructure where confidential workloads run and the trusted infrastructure of the data owner whose protected data those workloads need. For example, when a model provider deploys its model into an enterprise’s GPU cluster, the model provider is the data owner and its model weights are the protected data. On the enterprise’s untrusted infrastructure, the DataEnclave Runtime launches each workload in its own DataEnclave CVM, and on its own trusted infrastructure, the model provider runs the attestation server and key management system that decide whether that CVM receives its keys.
When a confidential workload is deployed, its CVM boots with no keys or credentials. To obtain them, the CVM asks its hardware root of trust for evidence describing its security posture: the hardware and firmware it is running on, the software it booted, and the restrictions on what the host server can do inside it. The CPU and GPU sign this evidence with keys that never leave the hardware, so the host and its administrators cannot forge it.
The CVM sends this cryptographic evidence to the attestation server, which checks it against the data owner’s security policies. These policies set the requirements a CVM’s security posture must meet, and they can go beyond approved hardware and software. For example, a model provider may prohibit the host from running commands inside the CVM. That restriction is enforced within the CVM and recorded in the signed evidence, so the infrastructure operator cannot loosen it without the CVM failing verification.
Only when the evidence meets the data owner’s policies are the keys released, and they are encrypted so that they can be decrypted only inside that CVM’s protected memory. If verification fails, nothing is released, and a workload packaged as an encrypted container image cannot start at all.
Attestation happens every time a workload launches, including each new replica, and again whenever a running workload needs another key. As a result, a data owner’s control continues after its data is deployed. If a model provider’s license with an enterprise ends, the provider can revoke that deployment’s entitlement on its own attestation server. This requires no involvement from the infrastructure operator and stops new CVMs from receiving the keys needed to run the model.
Because this process follows the IETF’s remote attestation architecture and is compatible with CNCF Confidential Containers, a data owner can use an attestation service it already runs or deploy the DataEnclave attestation server that VAST provides.
Bringing the Model to Sensitive Data
The attestation and key release flow that DataEnclave drives allows a model provider to deploy its model onto infrastructure it does not control, so the model can run where an enterprise’s sensitive data already lives.
Consider a bank that wants to analyze its sensitive data with a proprietary frontier model. Each release of that model arrives as a VAST Application, which packages the model’s inference service with the configuration DataEngine needs to run and manage it, and its container image and weights are encrypted with keys the model provider controls. The bank stores those releases on its VAST Cluster alongside the other software it runs. Deploying the model onto the bank’s GPU cluster uses the same interface or API as any other VAST Application, but because the model runs as a confidential workload, deployment also requires the address of the model provider’s attestation server.
When the bank launches the model, the workload’s CVM first needs the model provider’s keys to decrypt the container image, so it requests them from the provider’s attestation server over an outbound connection. Because the CVM initiates that connection, the model provider never needs a route into the bank’s network. Once the CVM passes verification, it receives the keys, and the container image and weights are decrypted only inside its protected memory. The bank owns and operates the GPU servers, but its administrators never have access to the decrypted container image or model weights.
Just as the model provider decides which CVMs receive its keys, the bank decides which of its data reaches the model. When an investigator asks for a summary of the activity behind an account flagged for possible fraud, a retrieval application such as VAST InsightEngine searches the bank’s internal documents, assembles the relevant excerpts into a prompt, and sends it to the model’s inference API. Search and prompt assembly both happen on the bank’s own systems, outside the model’s CVM, so that prompt is the only bank data the model ever sees. And because the CVM runs inside the bank’s network, the bank’s existing egress controls determine where the model can send anything.
Who Can See What
The bank in this example is both the enterprise and the infrastructure operator. Separating those roles shows what each party can and cannot see when confidential AI workloads run in DataEnclave.
The enterprise | The model provider | The infrastructure operator | |
|---|---|---|---|
Model weights | No. They are decrypted only inside the CVM’s protected memory. | Yes. It owns them. | No. Decrypted only inside the CVM’s protected memory. |
Enterprise data | Yes. It owns the data. | No. Model sees only what the enterprise puts in a prompt. | Not through the CVM. Protected at rest and in transit by the VAST AI OS's cryptographic multitenancy and Tenant Privacy Mode. |
Prompts and responses | Yes. | No. Model processes them inside the CVM, with no administrative path back to the provider. | No. |
These protections cover the confidentiality and integrity of data while it is being processed, but they do not guarantee availability: an infrastructure operator can always decline to run a workload or stop one that is running. DataEnclave governs which workloads run inside a CVM, while the developers of those workloads remain responsible for what enters and leaves through their APIs.
Keeping an Operational Record
Production deployments of confidential AI also need a record of which workloads ran and which policies governed them.
On the infrastructure operator’s side, the DataEnclave Runtime logs the lifecycle of each confidential workload to the VAST DataBase, including which application and version launched, from which CVM image, on which node, at what time, and under which deployment configuration. Because those logs identify what ran without capturing the data it processed, security and compliance teams can query and review them without exposing the models or data inside the CVMs.
On the data owner’s side, any attestation server keeps track of which CVMs it verified and which keys it released. Data owners that deploy the DataEnclave attestation server as a VAST Application get a more detailed record that also includes the evidence behind each decision, the policy that evidence was checked against, and every change the data owner has made to its policies. That record is stored in a VAST DataBase and can be queried with the same tooling as the workload logs.
Because each party keeps its own record, neither the data owner nor the infrastructure operator has to take the other’s word for what happened.
Control Without Having to Trust
Until now, trust between model providers, enterprises, and infrastructure operators has been managed with contracts: model providers license their weights under terms that prohibit extraction, and enterprises get written assurances that their prompts won’t be retained. But contracts only offer recourse after the damage is done, whereas DataEnclave prevents the exposure from happening in the first place. Nothing is decrypted until a service the data owner controls has verified what is running, using hardware-signed evidence that the operator cannot forge.
DataEnclave lets each party in a confidential AI deployment keep control of what it owns. Enterprises can run frontier models next to their most sensitive data without sending that data to a hosted AI service. Model providers can deploy into environments they don’t administer while still deciding, from their own attestation server, where their models run. AI cloud and sovereign infrastructure providers can host and operate these workloads without ever being exposed to the models and data inside them.
For a closer look at how DataEnclave provides each of these protections, the DataEnclave technical whitepaper walks through the complete attestation and key release sequence and follows a confidential model through every stage of its deployment, including the runtime state it keeps on the VAST DataStore. It also covers the options for where the attestation server and key management system run, and lays out the trust assumptions the architecture depends on.
