VAST DataEnclave Brings Confidential Computing to AI Models — What Enterprises Should Verify Before Trusting It

The enterprise AI privacy problem is often described as a choice between capability and control. A company can send sensitive information to a powerful external model, or keep the data inside its own infrastructure and accept a narrower set of models. Confidential computing is designed to make that tradeoff less rigid.

VAST Data's newly announced DataEnclave is an example of that direction. The company says the capability is integrated with its DataEngine and uses NVIDIA Confidential Computing to create a hardware-isolated runtime in which proprietary or open AI models can operate against sensitive enterprise data. VAST positions the system for customer data centers and trusted cloud environments, including deployments where neither the customer wants its data exposed nor the model provider wants its weights visible to the infrastructure operator.

On September 23, Sharon AI also announced plans to bring DataEnclave into its AI Factory platform across Australia and Asia-Pacific, including onshore and potentially air-gapped environments.

The architecture is important because modern AI increasingly requires two valuable assets to meet: private data and expensive model intellectual property. Neither side necessarily wants to hand its asset to the other in plaintext.

Confidential computing protects data while it is being used

Traditional encryption is well understood for data at rest and data in transit. A database can encrypt stored files, and TLS can protect information moving over a network.

The difficult moment is computation. A processor normally needs usable data in memory to perform work. That creates an exposure window in which privileged software or infrastructure components may be able to inspect information.

Confidential computing attempts to reduce that exposure through trusted execution environments. Workloads run in hardware-isolated memory, and cryptographic mechanisms can verify the state of the environment before secrets are released.

VAST describes DataEnclave as using confidential virtual machines, CPU trusted execution environments and NVIDIA GPUs operating in Confidential Compute mode. The company says guest memory, GPU memory and interconnect traffic remain protected during processing.

That matters for AI because model inference can involve both sensitive prompts or datasets and proprietary model weights.

Attestation is the part buyers should understand

The word "enclave" sounds secure, but the operational mechanism that deserves close attention is attestation.

Remote attestation allows another party to verify that a workload is running in an expected hardware and software state. A model provider could, in principle, keep model weights encrypted until the target environment proves that approved protections are active. An enterprise could apply a similar approach to keys that unlock sensitive datasets.

This creates a more controlled meeting point. The infrastructure operator should not need unrestricted visibility into either asset merely because it owns or manages the machines.

For buyers, the key questions are practical. What measurements are included in attestation? Who defines the trusted configuration? Where are encryption keys held? What happens when firmware or software is updated? How quickly can trust be revoked if a vulnerability is discovered?

A confidential-computing product is only as operationally useful as its key and attestation lifecycle.

Sovereign AI is a major use case

Data sovereignty has become a central constraint for organizations adopting AI. Governments, healthcare providers, financial institutions and other regulated businesses may face rules or contractual requirements about where information can be stored and processed.

Sharon AI's DataEnclave announcement emphasizes onshore deployments in Australia and the Asia-Pacific region. That illustrates why confidential AI is commercially interesting: organizations may want access to sophisticated models without moving sensitive data into an overseas general-purpose AI service.

But "onshore" and "confidential" solve different problems. Data residency addresses location. Confidential computing addresses exposure during processing. An enterprise may need both, plus contractual, identity and retention controls.

Teams should therefore avoid treating sovereign AI as a single checkbox. They should map each regulatory requirement to a technical or contractual control.

Model providers gain something too

The privacy problem is symmetrical. Enterprises worry about their data, while model developers worry about distributing valuable weights.

Closed model weights represent substantial training investment and can contain intellectual property a provider does not want copied from a customer environment. This is one reason the most capable proprietary models have often been delivered through provider-controlled APIs rather than installed directly inside a customer's data center.

A properly attested confidential runtime can create another deployment model. Encrypted weights can be delivered to infrastructure the model company does not operate, then unlocked only inside a verified execution environment.

If that pattern proves robust, regulated customers could gain access to models that previously could not be deployed close to their data.

That would be a meaningful shift in AI distribution, not merely a security feature.

Confidential does not mean automatically safe

Confidential computing addresses a specific threat: unauthorized inspection or manipulation of data and code at the infrastructure layer. It does not solve every AI security problem.

An application with legitimate access to a confidential runtime can still request the wrong information. An agent can still receive excessive permissions. Prompt injection can still manipulate a model into using an authorized tool in an unintended way. A poorly designed retrieval system can still expose records to the wrong user.

The enclave also cannot make inaccurate model output correct.

Organizations therefore need to layer controls. Identity determines who can initiate work. Authorization limits which data and tools a workload can reach. Application controls constrain agent behavior. Logging and audit systems record consequential actions. Data governance determines which information is eligible for processing.

Confidential computing protects an important layer beneath those controls; it does not replace them.

Performance and operability need real testing

Security mechanisms can introduce operational tradeoffs. Attestation, encrypted memory, protected I/O paths and constrained runtime configurations can affect performance, debugging and observability.

The correct benchmark is not whether a confidential GPU can run a model. It is whether the complete protected workload meets latency, throughput, cost and reliability requirements.

Enterprises should test representative inference jobs using real model sizes and data flows. They should measure startup and attestation time, steady-state performance, failure recovery and upgrade procedures. They should also determine what telemetry remains available without weakening the confidentiality boundary.

A system that is cryptographically elegant but impossible to operate during an incident will be difficult to use in production.

Air-gapped AI changes the deployment conversation

VAST and Sharon AI both highlight deployments in highly controlled environments, including air-gapped scenarios. That is particularly relevant for sectors where external network connectivity is restricted.

Running modern AI in an air-gapped environment creates challenges beyond installing a model. Organizations need a process for updates, vulnerability fixes, model revisions and audit data. Every artifact crossing the boundary needs provenance and validation.

Confidential computing can protect runtime assets, but offline operations still require disciplined software supply-chain management.

What enterprises should verify before adoption

A serious evaluation should begin with the threat model. Identify which parties are not trusted: cloud administrators, hardware operators, customer administrators, model providers or external attackers. Then determine which of those threats the enclave architecture actually addresses.

Request documentation for attestation, key management, firmware dependencies and recovery. Test how the environment behaves after an update. Verify how logs are generated and who can read them. Measure the actual workload instead of relying on generic accelerator specifications.

Finally, confirm the exit path. Sensitive AI infrastructure can become deeply integrated with storage and model distribution. Organizations should know how data, keys and workloads can migrate if requirements change.

DataEnclave reflects a broader transition in enterprise AI. The question is moving from "Can we send this data to an AI model?" toward "Can the model securely come to the data?" Confidential computing provides a credible technical mechanism for that second architecture. Its value will depend on whether enterprises can verify the trust boundary, operate it reliably and combine it with the identity and application controls that AI still requires.