9 min read - Google Confidential G4 Is GA: Test the Attestation Path First

Google Cloud made Confidential Computing on G4 instances generally available on 21 October 2026. The release joins an AMD-protected virtual machine to an NVIDIA RTX PRO 6000 Blackwell GPU, with encryption and attestation intended to protect model weights, prompts and other data while computation is under way.

The new control fits an AI workload whose threat model includes privileged infrastructure access. It is not a shortcut to a compliance claim, a residency decision or a secure application. A buyer still has to decide what evidence the workload must present, who verifies it and which secrets remain unavailable when verification fails.

The first pilot should therefore test an attestation and key-release path, not merely confirm that a model can answer requests on a confidential VM.

What became generally available

The Google Cloud announcement says Confidential G4 is available in 36 zones on Compute Engine VMs and GKE nodes, across several consumption models. Google describes three mechanisms: non-exportable hardware keys, remote attestation and memory encryption. It also says existing Ubuntu images, NVIDIA drivers and CUDA-X libraries can run without application refactoring.

Google reports less than 3.5% throughput degradation in its tests of Llama 3, Llama 3.3, ResNet-50 and SDXL on one machine shape. Treat that number as a vendor benchmark, not a capacity plan. The same post states that results depend on the workload, configuration and hardware. Measure latency, throughput, cold starts and failure recovery with your own model, context size and traffic pattern.

One nearby announcement is still future tense. Google says Confidential Space support for this setup is expected to reach general availability in the coming weeks. Do not put that capability into a current architecture decision until its status and regional support are confirmed.

A confidential GPU answers one security question

Normal encryption covers stored data and network traffic. A model server must decrypt prompts, retrieved documents and weights to use them. Confidential computing adds a hardware-enforced execution environment and evidence about that environment, so a verifier can decide whether it matches an approved state before releasing protected material.

The Confidential Computing Consortium's attestation explanation describes this as a policy decision backed by hardware evidence. Its secure key-release example withholds a decryption key when firmware or another measured component does not meet policy. The protection therefore depends on both parts: fresh evidence and a decision that changes what the workload can access.

For teams handling private documents, proprietary models or shared research data, a confidential GPU can reduce exposure to parts of the host infrastructure. It cannot repair an overbroad service account, a poisoned retrieval index, prompt injection or an API that returns sensitive output to the wrong caller.

Build the verifier before moving sensitive data

A successful console launch proves that the platform accepted a configuration. It does not prove that your organisation will reject an unexpected configuration next month.

Start by writing an attestation policy that an engineer and a security reviewer can read. Name the allowed machine type, CPU and GPU mode, guest image, Secure Boot requirement, driver and firmware expectations, and the verifier that owns each reference value. Record how updates enter the approved set. A policy that accepts every signed version gives the supplier a root of identity but leaves your acceptance decision undefined.

Then make evidence fresh. Google's Confidential VM attestation guide shows a nonce in its GPU evidence flow, separates evidence collection from verification and distinguishes driver attestation from device attestation. The same guide recommends Secure Boot for stronger driver verification. A saved report without a challenge can be useful for diagnosis, but it should not authorize a new release of secrets.

Run verification outside the workload being judged. The verifier should compare measurements and reported settings with the approved policy, leave a compact decision record, and fail closed when evidence is missing, stale or unknown. Keep payloads and secrets out of that record. Store the policy version, evidence digest, workload identity, time and decision reason instead.

Finally, connect the result to a consequence. Release a model-decryption key or data credential only after the expected evidence passes. If an application receives all secrets before attestation, the report becomes an observation rather than a control. NVIDIA's confidential-VM workflow likewise separates cloud-provider provisioning from the tenant's responsibility to attest the GPU and run the application.

This evidence can join the runtime record discussed in our guide to model ancestry and execution evidence. Keep the claims separate: an attestation says something about a measured environment, while model provenance says where an artefact came from.

Test the awkward operational cases

Confidential G4 adds constraints that should appear in the pilot plan. Google's creation guide documents one G4 machine type for this path, AMD SEV as the confidential-compute setting, GPU quota needs and an NVIDIA Confidential Computing licence fee. Cost comparison should include that fee, capacity access, idle time and the engineering work around verification. The announcement's throughput number covers none of those items.

The supported-configuration page says an existing VM cannot be converted in place. It also lists storage and network constraints and states that confidential NVIDIA GPU instances do not support multi-node workload clusters. A team that trains across nodes, depends on a specific disk type or expects live migration needs a separate design review.

Attestation also has a failure path. Google's current documentation notes a possible GPU measurement mismatch and gives a full stop and restart as the workaround. Put that case into an operational test: confirm that secrets remain withheld, the alert reaches a named owner, the instance can be replaced, and the service recovers without someone disabling verification to restore traffic.

The pilot should answer four practical questions:

1. Can a fresh instance prove the expected CPU, GPU, boot and driver state before receiving secrets?
2. Does one changed or unknown measurement block key release and produce a useful decision record?
3. What happens to requests while an instance is being replaced after failed attestation?
4. Can the team update an approved driver or image without opening the policy to every future version?

If the test ends at successful inference, it has skipped the reason to pay for confidential computing.

Choose it for the threat model, not the label

A small or mid-market team may not have staff to maintain a custom attestation service, yet it cannot afford a control that only one specialist understands. Prefer a small policy, a documented verifier and one workload with a clear data owner. Make a second engineer reproduce the failure and recovery procedure before expanding the design.

Procurement should ask for exportable evidence and precise boundaries rather than a confidential-computing badge. Which components are measured? Which party supplies reference values? Where does verification run? What event revokes an accepted measurement? Which storage, network, administrator and application paths remain outside the protected boundary?

Google's GA release makes confidential GPU inference easier to buy. The engineering decision remains specific: identify the privileged access you need to exclude, prove that an approved environment is running, and keep the keys away when it is not. Exceev's services approach can connect that threat model to a tested cloud architecture and an operating handover.

Sources and limitations

We opened and reviewed every source below on 21 October 2026.

• Google Cloud's Confidential G4 GA announcement establishes the release date, stated availability, mechanisms, software compatibility and vendor-run performance results.
• Google Cloud's GPU Confidential VM creation guide documents the machine type, AMD SEV setting, provisioning options, quota and licence-fee requirement.
• Google Cloud's supported-configuration page supplies the conversion, storage, network and multi-node limits.
• Google Cloud's attestation guide documents CPU and GPU evidence, Secure Boot, nonces, verification and the current measurement issue.
• NVIDIA's confidential-VM documentation explains how CPU trusted execution extends to GPU memory and divides provider and tenant duties.
• The Confidential Computing Consortium's attestation note supplies an independent explanation of remote attestation and policy-gated key release.

We did not deploy a G4 instance, verify regional capacity, inspect pricing, reproduce Google's benchmarks or test the documented attestation issue. Product support, limits, performance and fees can change after the review date. The architecture patterns above are recommendations, not a security guarantee, certification, legal opinion or finding that a workload meets privacy, residency or compliance duties.