Summary

  • VAST DataEnclave is a preview confidential-AI design intended to let a model provider and an enterprise keep their respective assets encrypted while a verified workload runs on third-party infrastructure; shipment is expected in the first quarter of 2027.
  • Hardware-signed attestation evidence can describe a measured CPU, GPU and software state, but it does not itself grant a business entitlement. The model owner and the enterprise still need independent policies for releasing their own keys.
  • The commercial acceptance test is a bounded release system: fresh, purpose-bound evidence; explicit behaviour during failure; a measured revocation horizon; reconciled records; and an exit path that moves policy and receipts to another verifier or host.

The scarce asset in enterprise AI is not always compute. It can be permission to bring a valuable model into contact with data that cannot leave a controlled environment. Model builders resist placing proprietary weights under a customer or cloud administrator’s control. Enterprises resist sending regulated records, designs or operational history into a provider’s service. A larger market becomes possible only if neither side has to surrender its secret merely because a third party operates the machines.

VAST Data’s DataEnclave announcement proposes that separation. The design combines confidential virtual machines with CPU and GPU trusted-execution environments. A workload produces hardware-signed evidence about its measured state; a verifier appraises that evidence; and protected assets are decrypted only after the relevant owner decides the result satisfies its policy. VAST says guest memory, GPU memory and NVLink traffic can remain hidden from infrastructure administrators and other tenants.

That arrangement changes the trust transaction. The host still supplies placement, power, cooling and network service, and therefore retains considerable operational power. It is not supposed to receive the model provider’s key or the enterprise’s data key. Each owner keeps its key-management system in its own trust domain. The model provider can decide whether a particular confidential virtual machine may receive model weights. The enterprise decides which data and prompts enter the workload and uses network controls to govern what may leave.

The product is in preview, not general availability. VAST says shipment is expected in the first quarter of 2027 through VAST and participating manufacturers including Cisco and Supermicro. The 24 September distribution repeats that timetable and ecosystem support. Neither source supplies a customer deployment, production benchmark, price, contract value or realised saving. The market case therefore rests on an architecture and a future delivery commitment, not an observed commercial outcome.

A verified machine is not an authorised transaction

Remote attestation answers a deliberately narrow question. NVIDIA’s attestation documentation describes cryptographic verification of claims about hardware and software. Its reference flow for proprietary models links a signed workload image, reference values, a fresh nonce, evidence appraisal and a key broker. Stale evidence, unexpected firmware or measurements, revoked collateral and unapproved state should be rejected.

Those checks can support a release decision. They do not contain the whole decision. A machine may be genuine and correctly measured while the requesting tenant, purpose, jurisdiction or data version is not permitted. A workload may pass at launch and later call an application interface in a way that exposes information. Attestation does not prove that a model is accurate, lawful or suitable for a particular business task. Nor does it prove that a permitted output cannot reveal sensitive information.

The distinction is explicit in RFC 9334. An Attester produces Evidence. A Verifier appraises it under one policy and returns an Attestation Result. A Relying Party then applies its own policy when deciding what to do. The architecture separately identifies the owners of those policies. A manufacturer’s endorsement may help authenticate a device, but it need not be sufficient to authorise access.

For DataEnclave, there are at least two relying decisions, not one. The model owner decides whether to release model keys. The enterprise decides whether to expose a dataset, prompt, retrieval source or decryption key. Both may inspect evidence about the same workload, yet they need not share the same threshold. The model owner might care about an approved image and GPU state; the enterprise may add tenant identity, purpose, location, retention and egress conditions. Calling the workload “attested” must not silently collapse these policies into the verifier’s defaults.

Freshness creates a clock, not certainty

VAST says attestation occurs for every workload launch, including a new replica, and again when a running workload requests another key. That is a useful boundary because scale-out cannot inherit trust merely from the first instance. A fresh nonce also reduces the value of replaying an old result. Yet freshness is a window, not a guarantee. RFC 9334 notes the unavoidable race: state can change immediately after evidence is generated.

Every commercial promise therefore needs a time statement. How long does a released key remain usable inside a running confidential virtual machine? What forces re-attestation? Does a policy change affect an existing process, only its next key refresh, or only a new launch? What happens during a verifier outage or when endorsement collateral expires? “Continuous” protection is too vague unless the contract names the event that reopens the release decision.

Revocation illustrates the problem. VAST says that withdrawing an entitlement prevents new confidential virtual machines from obtaining the model keys they need. The reviewed public material does not establish that an already-running instance is immediately terminated or that a key already in protected memory becomes unusable. That is not proof of a defect. It is the difference between a launch-control claim and a kill-switch claim. A buyer should time that difference and write it into the acceptance record.

Separation does not remove the operator

Confidentiality can reduce the operator’s ability to inspect plaintext without removing its control over service. VAST expressly says the design does not guarantee availability: an operator can decline to run a workload or stop it. That candour is important. A regulated enterprise may preserve secrecy and still lose an inference service during a commercial dispute, outage, patch cycle or capacity shortage.

The failure policy should be different at each stage. A new launch with no fresh evidence should normally fail closed. A running clinical or industrial process that cannot contact its verifier may need a short, pre-authorised grace interval, a safe shutdown or a local fallback; blindly continuing and abruptly stopping create different harms. An air-gapped deployment adds another question: how are reference values, revocations and hardware collateral updated without turning isolation into stale trust?

VAST’s technical account describes two useful records. The infrastructure side keeps workload-lifecycle logs. The data or model owner can retain the attestation and key-release record, including the evidence, policy used and policy changes. Neither record is complete alone. One can show that a machine started or stopped; the other can show why a secret was or was not released.

The buyer should be able to reconcile the two without exposing the underlying model or data. A receipt should bind the workload image, reference values, CPU and GPU evidence, nonce, tenant, purpose, jurisdiction, asset version, policy version, decision, key identifier and relevant lifecycle event. Negative decisions and unavailable components belong in the record too. A log of successful releases alone cannot reveal false rejection, operational exclusion or pressure to weaken a policy.

Portability is part of the control

Confidential AI can create a new switching boundary even when the ciphertext is portable. Reference-value stores, verifier rules, key-broker integrations, exception histories and attestation receipts may be harder to move than a model file. If a second provider cannot interpret them, the first verifier becomes a commercial gatekeeper whose decision history is trapped inside its own service.

An exit test should therefore precede deployment. Export a policy and its reference values. Re-appraise a representative receipt with a second verifier. Move one key-release path to another broker. Reconcile both parties’ records after the move. Prove that revocation and the denial history survive. Portability is not a promise that every verifier will reach the same conclusion; it is the ability to reconstruct what evidence existed, which policy acted and why a decision followed.

Evidence boundary

Product architecture, separation of keys, launch-time attestation, stated revocation behaviour, records, availability limits and delivery timing come from VAST’s launch release, technical article and the newswire version. NVIDIA supplies implementation context through its reference architecture and attestation documentation. RFC 9334 supplies the independent role and policy model. The acceptance tests and market interpretation are editorial analysis.