GPU Confidential Computing: What Encryption and Attestation Each Establish

Begin with the access you need to restrict

A request for a secure GPU environment leaves the most important purchasing question unanswered: whose access to which information must be restricted, and when? A buyer concerned about access to stored model files has a different requirement from one concerned about a host administrator inspecting data during inference. Both requirements can apply to the same service.

State the intended restriction before comparing product labels. Identify whether the protected material includes model weights, input prompts, retrieved documents, intermediate results or outputs. Then identify the actor of concern: for example, the infrastructure operator outside the workload's execution boundary. This makes it possible to ask whether the offered mechanism addresses that particular relationship.

The questions below support a technical comparison of claims. Security acceptance requires the appointed specialists to assess the actual system and application threat model; this article supplies neither a deployment procedure nor a compliance determination.

Follow one inference request through three data states

The Confidential Computing Consortium distinguishes stored data, data moving across a network and data being processed. Consider a model file on storage, a request arriving at an endpoint and the inference process consuming that request. Describing the file as encrypted at rest says something about its stored representation. It does not describe the protection of the data after it becomes available to executing software.

TLS addresses a communication channel between peers. RFC 8446 defines TLS 1.3 around that channel's security properties. For a buyer, the location of the receiving endpoint matters: a protected connection to an API gateway does not by itself establish protection for processing beyond that gateway. Ask where the channel terminates and what happens to the request next.

Confidential computing addresses the processing state through an attested hardware-based trusted execution environment, or TEE. Its hardware-backed isolation concerns unauthorized access or modification within the defined boundary. It complements the storage and transport protections. A locked cabinet, encrypted SSD and TLS endpoint cannot substitute for identifying that execution boundary.

References: [C1][T1]

Locate the CPU, GPU and transfer boundary

NVIDIA's Secure AI white paper, WP-12554-001_v1.3, dated August 14, 2025, describes Hopper and Blackwell GPUs participating with CPU confidential virtual machines. Its bounce-buffer path keeps payloads encrypted in shared, nonsecure memory before they reach protected GPU storage.

It also describes direct-device integration using TDISP and IDE where components support it. These are architecture descriptions, not universal GPU capabilities. Obtain current qualification for the exact CPU, GPU, complete system, firmware, driver and operating mode.

Ask the supplier to identify the protected regions and intervening paths. A supported architecture does not establish the running state of the offered equipment.

References: [N1]

Read attestation as an evaluated claim

Attestation provides evidence about an environment. Depending on the implementation, relevant claims can concern hardware identity, firmware and configuration. The CCC's explanation distinguishes obtaining authentic evidence from judging its values against an acceptable baseline. A validly sourced report and an acceptable reported state are different questions.

RFC 9334's RATS architecture names three roles. The attester produces evidence; the verifier appraises it under a policy and produces attestation results; the relying party uses those results in its decision. Thus, attestation is not another encryption layer. It informs a decision about whether to trust an environment for a particular purpose.

Ask what was assessed, which reference values and policy were used, who trusts the verifier and which decision depends on the result. Freshness matters too: RFC 9334 explains that evidence and policies can become outdated as state changes. A report from an earlier configuration cannot silently establish today's state.

Keep four propositions separate in the offer: the hardware supports a feature; the required mode is enabled; evidence about the identified environment meets the selected policy; the application's complete protection requirement is satisfied. Evidence for one proposition does not automatically establish the next.

References: [C2][R1]

CC-192: compare two offers against the same inference requirement

Fictional example CC-192 concerns an enterprise evaluating an inference service. Its stated requirement is to restrict the infrastructure host operator's access to input documents while they are being processed. The two offers below are invented documentary examples, with no actual deployment or test outcome.

Offer A specifies encrypted storage for uploaded documents and TLS to the inference API. It names a GPU but supplies no description of protected CPU or GPU execution and no attestation scope. Those statements address storage and a communication path. They leave the buyer's processing requirement unanswered. The appropriate finding is insufficient evidence for that requirement, rather than a declaration that the service has failed a security test.

Offer B identifies a proposed CPU confidential VM, a GPU execution boundary, protected transfers between them and the exact configuration to be qualified. It identifies evidence for the CPU environment and GPU, the verifier and the policy against which the evidence would be assessed. This is a more relevant explanation of the requested mechanism, but the proposal is still a claim awaiting assessment.

B's attached data-flow description also places the public API gateway outside the proposed execution boundary. It leaves unanswered whether that gateway can retain document contents or whether the inference application records them in logs available to the operator. Those questions matter even if the CPU and GPU evidence is acceptable: the buyer asked about operator access to the input documents, not only access through host memory inspection.

The buyer can therefore distinguish two unresolved positions. A has not described the required execution protection. B has described a relevant proposed boundary but has not yet accounted for the complete input path and logging behavior. Request the missing explanation from each offer's responsible owner. Neither offer receives a secure-system label from this comparison.

Resolve the application, release policy and operating assumptions

NVIDIA's self-hosted confidential-model reference architecture illustrates the application limit. Its Trust & Threat Model page, updated June 4, 2026, excludes vulnerable inference code and application payload logging from its protections. The operator can also interrupt service. Those boundaries belong to that reference architecture.

For an actual offer, ask which application code is inside the assessed boundary, what it is allowed to disclose, and where inputs, outputs and logs go. Identify the parties trusted to approve the workload and operate its supporting services. Protecting code against outside modification does not answer whether the code's intended behavior satisfies the buyer's data-handling requirement.

Where the design uses attestation to inform key release, identify the policy owner, the covered environment and the decision that a missing or unacceptable result prevents. The CCC describes this relationship between assessment and release. Request its intended behavior and responsible owner rather than treating a passing report as evidence that the release policy exists or is enforced.

Finally, name who maintains the supported configuration, handles changes that affect the assessment and resolves failed evidence checks. Review availability, recovery and application acceptance separately. A confidentiality claim cannot supply those operating responsibilities.

References: [N2][C2]

Keep the physical handoff separate from security acceptance

If the chosen environment involves customer equipment, its physical installation still needs a defined scope. Equipment identities, rack positions, cable endpoints and unresolved physical items can help the appointed platform team reconcile what was installed. Those records answer a different question from attestation or application security acceptance.

Leviathan's rack-and-stack service covers agreed equipment mounting, IT cabling, labels and physical installation records within an authorized project package. The confidential-computing assessment, attestation operation, key-release design and application security remain with the customer's separately appointed specialists.

Use the related rack-and-stack service and project inquiry for the surrounding physical work. Share equipment models, site, released rack and cable plans, receiving team and desired work window. Keep sensitive workload information out of the initial inquiry. The useful outcome is a clear physical handoff that the responsible platform team can connect to its own assessment.

References: [L1]