Suppose a company rents a GPU server to run a proprietary model. Encrypting the model file in object storage protects the file at rest, but the model must eventually be loaded and used. Can the hosting operator read those weights or the sensitive requests sent to the model? Confidential computing attempts to narrow that exposure.

What the protected environment includes

A confidential virtual machine (CVM) uses hardware-backed protections to isolate parts of its execution from the host. A confidential GPU adds protections for accelerator execution and supported communication paths. The exact arrangement depends on the hardware and software, as explained in NVIDIA's confidential-computing overview.

A model-serving application spans more than those components. It accepts requests, loads weights and returns results. Its database, network endpoints, logging and key-management system might sit outside the protected environment. Draw the boundary around the resources actually covered by the documented security mode, then trace each path taken by plaintext.

The objective also depends on who needs protection. A service owner may want to keep weights secret from the hosting company. An end user may want to keep their request secret from the service owner. Those are different threat models: a CVM operated by the model-service owner does not automatically make that owner untrusted.

Attestation is evidence, not a verdict

Remote attestation allows a platform to report information about its identity or state. The IETF RATS architecture in RFC 9334 describes three roles: an attester that produces evidence, a verifier that appraises it and a relying party that acts on the assessment.

Consider an encrypted model file. A key broker could release its decryption key only after the verifier accepts fresh evidence from the intended environment. The broker needs an authenticated channel that binds the release to that environment. Otherwise an attacker might attempt to relay valid evidence from one machine while requesting the secret for another.

A valid signature does not establish that the software is safe. The verifier still needs trusted reference values, an acceptable firmware and software policy and a way to check freshness. The broker must apply the correct release policy. If an old, vulnerable version is still on the accepted list, authentic attestation might correctly identify an environment the customer should no longer trust.

CPU and GPU reports cover different parts of the machine

Google Cloud's Confidential VM attestation documentation separates CPU and GPU attestation. Depending on the platform, CPU evidence can cover hardware, firmware or boot measurements. GPU evidence addresses the accelerator and relevant components in its own trust chain.

Verifying just the CPU does not establish that an attached GPU is running in the expected confidential mode. Conversely, a valid GPU report cannot establish that an arbitrary application consuming the model's results is trustworthy. The complete evidence and software-loading policy must cover the assets the service promises to protect.

NVIDIA's Attestation Suite provides reference measurements, certificate-status information and verification services. The customer must also decide which verifier to trust and who can change its accepted reference values. A routine firmware update can require a controlled policy update before secrets may be released again.

Limits that matter in a hosted environment

The NVIDIA confidential-VM threat model treats the privileged host as potentially hostile but retains trusted hardware, vendor components, guest software and verification services. Its protection for CPU-to-GPU and GPU-to-GPU traffic depends on the supported configuration.

The documented model does not guarantee availability against the infrastructure operator. That operator may still stop the VM or disconnect its network. Physical invasive attacks and some side channels also lie outside the GPU threat model. Network and storage paths leaving the protected environment require their own protections.

Do not assume that GPU sharing is compatible with confidential computing. The referenced NVIDIA threat model describes whole-GPU assignment to one CVM and excludes MIG, MPS and GPUDirect RDMA from the configurations it covers. Check the supported security mode for the exact hardware and software release. MIG and other GPU sharing mechanisms solve a different problem.

What happens after a key is released?

An approved application can still send sensitive text to a log collector, expose it through an API or accidentally return it to the wrong user. The confidential environment protects against the adversaries in its threat model, not every error inside the trusted application.

For a procurement review, identify where model weights and request plaintext appear, which reports the verifier checks, who controls key release and which paths are excluded. Also ask how the service handles updates and whether the customer can revoke access. Those details establish a concrete confidentiality claim. A confidential-GPU label alone does not.