MaruOpsInfrastructure and AI notes

About (Korean)Contact (Korean)

Confidential G4 Reaches GA: What GPU Data-in-Use Protection Covers

Several servers mounted in an equipment rack

Reference photo · Several servers mounted in an equipment rack · Photo: Abigor / Source / CC BY-SA 3.0 · Resized for listings; illustrative photo, not the tested environment

Google Cloud announced general availability of Confidential G4 using NVIDIA RTX PRO 6000 Blackwell Server Edition GPUs. The offering describes hardware isolation, memory encryption, and remote attestation for protecting data and models during computation. Google Cloud official announcement

Remote attestation checks evidence about an execution environment before sensitive data is released. Evaluate who verifies that evidence and under which conditions keys are delivered, rather than stopping at a statement that GPU memory is encrypted.

On this page

Data at rest, in transit, and in use have different boundaries

Disk encryption protects stored data, while TLS protects data moving across a network. Model execution introduces another boundary because the workload must use data in memory. Confidential computing applies hardware-based isolation to that processing environment. It complements storage and transport protection rather than removing the need for either one or replacing application-level authorization.

GPU execution involves inputs, model weights, and intermediate state across memory and device paths. Evaluate the supported CPU environment, drivers, and container runtime together with the GPU. Record the approved configuration and its versions. Otherwise a deployment can silently move to a different image while operators continue assuming that the original security properties apply.

Attestation is a decision before releasing a secret

Remote attestation verifies cryptographic evidence about an execution environment. Isolation and encryption establish a protected boundary; attestation helps another party decide whether that boundary matches an approved configuration. Merely collecting evidence is different from enforcing a decision based on it. The useful question is what access is withheld when verification fails, and which component enforces that restriction.

For example, a design could release a model-decryption key only to an approved environment. That requires a policy defining acceptable configurations and changes. A driver update may require revisiting the policy. Establish that process and the emergency recovery procedure before production, so an update failure does not encourage operators to bypass verification just to restore service.

Output and application behavior still need controls

A hypothetical medical-document summarizer illustrates the remaining boundaries. Protecting execution can reduce risks from outside the approved environment, but an application writing source text into error logs introduces another exposure path. So does an output store accessible to every operator. Define access and retention separately for input records, diagnostics, generated answers, and saved results.

For performance evaluation, compare protected and ordinary configurations using the same model, driver, and input lengths. Examine preparation time, throughput, long-request latency, and errors. Vendor measurements under particular conditions are not predictions for every workload. Record results with the intended security policy enabled so that an unsecured quick experiment is not mistaken for the cost of the production design.

Scope a confidential-GPU evaluation

  • Check supported regions, VM or GKE configuration, and driver combinations.
  • Test that failed attestation prevents data and key release.
  • Control access to input, output, logs, and checkpoint storage.

The announcement lists Confidential Space support on a separate forthcoming GA schedule. Do not assume every related capability shares G4’s current availability.

Announcement reference date: 2026-10-22 · Checked: October 24, 2026