NVIDIA GPU Confidential Computing Is a Key-Release Protocol

A team encrypts model weights before sending them to a GPU service. The hard question is who can obtain the decryption key after the workload starts. Confidential computing connects that question to GPU hardware, firmware, boot measurements, runtime policy and attestation. The security property is a protocol decision, not a marketing adjective.

Attestation is evidence; policy makes the decision

NVIDIA describes attestation as cryptographically verifying claims about hardware and software. Its suite includes remote attestation, reference integrity manifests and certificate-status services. A verifier evaluates evidence against reference values and policy. This can support a decision to release a secret, but the evidence alone does not decide which versions, settings or operators an organization should trust. (NVIDIA Attestation)

The flow is easier to audit when divided into four steps: the platform and workload produce identity and measurement evidence; a verifier checks signatures, freshness and reference values; policy decides whether this exact configuration is acceptable; and a key broker releases model or data secrets only to the approved workload.

If a deployment accepts any validly signed device, it has verified authenticity but not necessarily the configuration the owner intended. Reference values and accepted versions need owners, review cadence and revocation paths.

The system must also define what happens when the verifier cannot make a confident decision. Unknown measurements, missing evidence or an unavailable verification service should not silently fall back to releasing a key. That fail-closed behavior is an engineering recommendation derived from policy-gated secret release; the owner still needs to verify the actual implementation and error path instead of assuming a service default is safe.

Deployment mode defines who is inside the boundary

NVIDIA distinguishes confidential bare metal, confidential virtual machines and confidential containers. They differ in operating model and trust boundary; they are not interchangeable labels. Its confidential-bare-metal threat model assumes the model owner controls the host OS, drivers, workload, attestation policy and key-release policy on a dedicated host. That owner’s privileged software and administrators remain trusted. The infrastructure operator may remain outside the runtime plaintext boundary after handoff and verification, subject to the supported hardware, topology and configuration. (overview, threat model)

This can protect a model from an infrastructure provider, or sensitive input from an operator with host-level access. It does not automatically hide end-user inputs from the model owner or workload. Nor does confidential computing prevent an application from logging values, returning them in outputs or sending them to an unapproved service.

This is why a threat model must name the adversary. “Protect the model from cloud admins” and “protect a customer’s prompt from the model operator” are different requirements and may need different trust arrangements.

Multi-GPU fabrics add another edge to verify

A multi-GPU workload moves data beyond the local GPU boundary. NVIDIA’s PPCIE documentation describes a mode that, to reduce performance impact, trusts NVLink data and permits plaintext traffic under specified confidential-computing configurations. This is a concrete design trade: understand the protected path and its trust assumptions for the topology in use. Verifying one GPU does not prove every link, switch and peer path inherits the same property. (PPCIE verifier documentation)

Supported hardware, firmware, software and modes can vary. Request the exact platform mode, components covered by attestation, evidence-validation policy, key-release behavior, and failure behavior when evidence is stale, unknown or revoked.

Pay attention to the boundary between modes. NVIDIA’s overview places the guest OS inside the tenant-controlled area for confidential VMs, while confidential containers rely on a confidential pod boundary and control-plane separation. The bare-metal model assigns the host OS and drivers to the model owner. A cloud offer saying “GPU confidential computing” is incomplete until it names the mode, the operator it excludes and the components the customer still trusts.

A practical review checklist

Before placing sensitive model weights or data in a GPU workload, ask: Who owns the protected asset and which operators are the adversary? Is the deployment bare metal, a confidential VM or a confidential container? Which CPU, GPU, firmware, driver, boot and fabric measurements are checked? Who owns reference values and approval policy? Does key release fail closed? Which administrators remain trusted? What may appear in logs, dumps, telemetry and outputs? How are updates, key rotation, revocation and incidents handled?

These questions expose the operational work around the hardware: measurement ownership, policy review, key lifecycle, workload hardening and output controls. A general “confidential” label does not answer them.

An acceptance exercise can make the claim concrete. Capture a known-good report and verify it passes policy; alter an approved measurement or use an unsupported firmware state and check that the request is denied; rotate a test secret and confirm the new key reaches only the intended workload. Repeat after firmware or driver updates. This does not replace a security assessment, but tests the control path linking the hardware capability to the data-protection promise.

Attestation can give a model owner stronger evidence about the machine receiving a secret. Hardware protections can reduce exposure to infrastructure administrators in supported modes. Neither replaces the owner’s responsibility for privileged software or proves that the application behaves safely. For deployment decisions, use the current versioned threat model and compatibility matrix; do not infer a provider’s configuration from a product page.

The central engineering artifact should be a policy test: known-good measurements pass, altered or revoked measurements fail, and the key broker releases nothing on uncertainty. That is how a GPU security feature becomes a reviewable system guarantee—with explicit limits—rather than an untested promise.