No Secret Before Proof: Confidential Computing for AI

A company encrypts customer records in storage and transit, then sends them to an AI server whose host, hypervisor, device firmware, runtime, and application join the trust problem. Who can see or alter the data while the model uses it?

Confidential computing can reduce that exposure by running work inside a hardware-backed trusted execution environment, or TEE. But buying a “confidential VM” does not prove that the intended model, container, driver, and policy received the data. The reader decision is therefore: does the workload have an in-use threat that a TEE can meaningfully reduce, and can the organization make data and model keys unavailable until fresh evidence proves the complete approved runtime is present?

This guide explains the mechanism, residual risks, and a testable attested secret-release architecture.

Start with the adversary, not the hardware SKU

Before comparing products, name the protected asset, the party that must not access it, the moment of exposure, and the acceptable failure:

Customer documents and proprietary model weights may be decrypted only inside release R-27; a cloud administrator, compromised host kernel, hypervisor, or neighboring tenant must not read or modify them. Loss of service is acceptable; silent execution in an unapproved runtime is not.

This identifies distrusted layers and whether failing closed fits the service.

NIST IR 8320, finalized in May 2022, describes hardware-enabled security as the physical foundation of layered platform security. That is the verified foundation. ZharfAI analysis: use confidential computing only when the hardware root changes a named trust relationship—not automatically for public data, an accepted host, or risks that sit inside the application.

Classify the adversary explicitly:

• infrastructure operator: a privileged person or compromised control plane outside the guest;
• host software: a malicious or exploited hypervisor, host kernel, driver, or management agent;
• co-tenant: another workload attempting memory or device access;
• physical or supply-chain actor: a stronger adversary who may exceed the TEE's threat model;
• guest attacker: malicious code, a vulnerable server, poisoned dependency, prompt injection, or user abuse inside the protected environment.

The last category is decisive. A TEE tries to protect the guest from parts of its hosting environment. It does not make unsafe guest code safe.

Know exactly what the TEE changes

A TEE normally contributes three different properties:

1. isolation: selected memory and execution state are protected from specified components outside the TEE;
2. measurement: hardware or protected firmware records claims about the platform, boot chain, guest, or device state;
3. attestation: signed evidence lets a remote verifier appraise those claims before another system trusts the workload.

These are not interchangeable. Memory encryption may omit integrity; isolation without attestation leaves placement as a provider claim; attestation without a relying-party decision changes nothing.

The AMD SEV-SNP technical paper gives a concrete boundary: private guest memory is protected from an untrusted hypervisor, with integrity defenses against replay, corruption, aliasing, and remapping. It also excludes guest availability guarantees, requires normal protection such as TLS for shared I/O, and does not generally eliminate physical attacks or architectural side channels.

Do not generalize this boundary. Record the processor generation, firmware, TEE mode, guest policy, device path, attestation service, and exclusions. A product label is not a threat model.

Decide whether confidential computing earns its complexity

Use the control only where it closes a material gap:

Compare hardened compute, a confidential VM, and a smaller enclave. The broad guest is easier but enlarges the trusted base; the enclave reduces trusted code but demands application changes. GPU and interconnect support narrow options further.

Estimate lifecycle cost: reproducible images, attestation, reference-value updates, key policy, capacity, cold start, incident response, regional recovery, and staff able to interpret failed claims.

Draw the plaintext path and the trusted computing base

Trace every plaintext location: client, gateway, preprocessing, queue, CPU and GPU memory, pinned buffers, caches, temporary storage, output filters, logs, dumps, traces, and downstream tools. A protected kernel does not help if the gateway logs prompts.

For each stage record:

• who can read or modify plaintext and whether memory is private, shared, or device-visible;
• the code identity, digest, key, and system allowed to release that key;
• how output leaves, what evidence proves protection, and what deletion, crash, retry, and recovery do.

Define the trusted computing base, or TCB: every hardware, firmware, verifier, guest, runtime, application, and policy component whose compromise breaks the promise. It is not only the CPU; unnecessary guest services join the practical TCB.

Bind this inventory to the AI release passport. Policy needs immutable identities for the guest, kernel, boot configuration, application, model server, driver, and model policy. latest is not a reference value.

Turn attestation into an authorization decision

Remote attestation is an evidence flow. RFC 9334, the January 2023 IETF RATS architecture, separates three roles:

• the attester creates evidence about a target environment;
• the verifier appraises evidence against endorsements, reference values, and policy, then produces a result;
• the relying party applies its policy and makes the resource decision.

This prevents accepting any token signed by a known service. A valid signature proves issuer and integrity, not that the claims satisfy this release policy.

Google Cloud Attestation is one current implementation: it gathers endorsements, checks evidence against reference values and policies, and returns signed claims. The portable pattern is attester → verifier → result → relying-party policy → resource decision.

Version the relying-party policy as code:

Absence is not approval. Required but missing GPU evidence cannot mean “GPU trusted.”

Bind the attested workload to the secret channel

Attesting a machine and then sending a key over an unrelated authenticated connection leaves a substitution gap. The receiver of the secret must be the same protected workload represented by the evidence.

A robust pattern:

1. the workload creates an ephemeral key pair inside the protected environment;
2. it requests fresh evidence that binds the public key, a verifier nonce, and relevant workload measurements;
3. the verifier appraises evidence and issues a signed, short-lived result;
4. the key service validates issuer, audience, freshness, claims, policy, and request context;
5. only then does it wrap a narrow data or model key to the attested public key;
6. the workload decrypts inside the TEE, uses the asset, and destroys the session key on completion.

Microsoft calls the resource half secure key release: release key material only after attestation proves an approved TEE. Its Azure Attestation FAQ documents binding workload-generated public keys into attested runtime data so the relying party can establish a channel to that environment.

Attestation describes runtime properties; workload identity names the caller; authorization connects caller, runtime, tenant, task, and resource. Apply the short-lived authority pattern from the credential-brokering guide. Neither token should become a master credential.

Separate keys by asset and owner. Model provider and customer can require the same runtime but different tenant, geography, purpose, and expiry claims. Do not hide every asset behind one attested=true decision.

Treat an AI accelerator as a composite attester

AI crosses CPU and GPU trust boundaries. CPU protection alone does not prove plaintext entered an approved GPU, driver, firmware, or interconnect. Several device claims may need joint appraisal.

NVIDIA's confidential-computing reference architecture requires measured CVM, CPU, GPU, verifier, secure key release, and privacy-preserving logging, with fresh CPU, GPU, guest, launch, and firmware evidence before model-key release. Its attestation documentation, updated August 1, 2026, lists local and remote paths for supported H100-or-newer GPUs and multi-GPU switches.

Those are vendor facts, not deployment proof. ZharfAI analysis: make one composite decision fail closed when a layer is missing, stale, in debug mode, revoked, or inconsistent. Normalize vendor results without discarding claims that change the threat model.

Policy must still cover shared memory, DMA, I/O, model caches, and multi-GPU links. “GPU attested” does not answer those data-flow questions.

Worked example: two owners, one inference runtime

A provider owns model weights; a customer owns confidential case files. Neither trusts the infrastructure operator, and the provider will not release weights to an arbitrary image. They approve R-27: a measured CVM, fixed kernel, minimal container, approved CPU/GPU modes, driver and firmware ranges, disabled debug, and an output filter.

The operating sequence is:

1. The scheduler starts the encrypted image. It cannot fetch either decryption key with its ordinary service identity.
2. The runtime creates an ephemeral key and obtains fresh CPU, guest, GPU, driver, and firmware evidence bound to the key and a verifier challenge.
3. A verifier checks signatures, endorsements, security versions, reference values, freshness, and completeness, returning a short-lived result for R-27 and the session key.
4. The model owner's service checks release, production mode, purpose, GPU, region, and expiry, then wraps only MK-8.
5. The customer independently checks release, tenant T-41, purpose, region, retention, and request authority, then wraps only DK-93.
6. The runtime decrypts, infers, validates, encrypts the response, and erases session material inside the approved boundary.
7. The record joins result digest, policy, release, key identifiers, request identity, time, decision, and receipt—never keys, weights, prompts, case text, or reusable tokens.

If driver, GPU evidence, nonce, image, or policy fails, that owner's key is denied. Retry on a fresh approved host, never an ordinary VM or yesterday's result.

This narrows infrastructure exposure; it does not prove accuracy, container safety, output authority, or lawful purpose.

Design failure, recovery, and evidence before launch

New dependencies can stop the service: endorsements, certificate status, verifier, reference values, key service, capacity, and policies that reject a necessary update. Define each disposition:

• evidence invalid: deny; preserve a redacted reason and investigate the platform;
• evidence stale or replayed: deny; issue a new challenge rather than extending the old result;
• claim missing: deny if required; never coerce absence into a permissive default;
• reference value not approved: hold; any emergency exception needs separate authorization, expiry, and review;
• verifier or key service unavailable: use a defined non-confidential degraded service, queue encrypted work, or stop—never release broadly;
• capacity unavailable: route only to another environment meeting the same policy;
• guest incident: revoke release identity and data access even if platform attestation passes.

Drill recovery. Preserve policy, signing authority, revocation, and audit continuity; a new region may use different authorities or claims. Recovery must not widen trust merely to meet RTO.

Protect evidence: RFC 9334 warns it can reveal useful firmware, software, device, or user detail. Minimize, encrypt, restrict, and expire it. The AI audit guide gives the test: preserve input, policy, decision, and effect linkage—not a green-badge screenshot.

Measure assurance and operational cost together

Measure the full path against conventional compute, not one throughput number:

Benchmark the actual model, context, batching, topology, data path, and failure policy. Separate launch overhead from per-request cost; averages can hide an unusable cold-start or capacity cliff.

The attested-release gate

Release no sensitive data or weights until the owner can answer yes:

1. Are the asset, in-use adversary, and matching documented TEE threat model explicit?
2. Is the plaintext path—including shared and accelerator memory, logs, outputs, and recovery—mapped?
3. Is the practical TCB minimized and identified by immutable release values?
4. Are attester, verifier, reference-value owner, policy owner, relying party, and key owner separate and accountable roles?
5. Does policy require fresh, signed, complete evidence for every material CPU, guest, application, GPU, driver, firmware, and link?
6. Is the receiving session key cryptographically bound to the attested environment?
7. Does each owner release a narrow key for a named tenant, purpose, region, release, and expiry?
8. Do missing, stale, debug, revoked, mismatched, or unverifiable claims fail closed?
9. Are application authorization, prompt injection, output validation, model quality, privacy, and legal purpose controlled independently of the TEE?
10. Have performance, revocation, collateral outage, security update, regional recovery, and evidence retention passed drills?

Revisit after any processor, GPU, firmware, driver, guest, verifier, format, reference authority, key manager, runtime, tenant, region, or topology change—and after side-channel disclosure, unexplained denial, emergency exception, plaintext leak, or recovery drill.

The durable principle is not “run AI in an enclave.” It is: make decryption conditional on fresh, workload-bound evidence that the complete approved runtime is present. The TEE narrows one infrastructure threat; everything inside still needs secure code, narrow authority, evaluation, and accountable operation.

Source notes — reviewed August 19, 2026

• IETF RFC 9334: Remote ATtestation procedureS Architecture — published January 2023; attester, verifier, relying-party, evidence, appraisal-policy, freshness, security, and privacy concepts. It is an informational architecture, not a specific attestation protocol.
• NIST IR 8320: Hardware-Enabled Security — finalized May 4, 2022; roots of trust and layered platform security for cloud and edge systems.
• Google Cloud Attestation — reviewed August 19, 2026; a current RATS-aligned provider implementation using endorsements, reference values, policies, and signed claims.
• Microsoft: Secrets and key management in confidential computing — updated May 7, 2025; attestation-conditioned secure key release.
• Microsoft Azure Attestation FAQ — updated June 12, 2026; token verification, runtime-data binding, workload public keys, and secure channels.
• AMD SEV-SNP technical white paper — January 2020; memory confidentiality and integrity design, explicit trusted and untrusted components, and documented out-of-scope threats.
• NVIDIA confidential-computing reference architecture: required capabilities — reviewed August 19, 2026; measured CPU/GPU runtime, fresh evidence, secure model-key release, and privacy-preserving logging.
• NVIDIA GPU and switch attestation documentation — updated August 1, 2026; supported confidential-GPU prerequisites plus local and remote device-attestation paths.