Architecting a Zero-Operator-Access AI Assistant on Confidential Computing Infrastructure
Hardware-rooted enclaves keep AI model data encrypted even from cloud operators.
Encryption protects data in two states: at rest, on a disk, and in transit, across a network. The third state, data in use, sits outside that protection. Before a model can generate a response, an input prompt must be decrypted and loaded into memory. At that instant it sits in plaintext, reachable by anyone with access to the host: cloud administrators, the hypervisor, or an attacker who has compromised the host operating system.
This is not a misconfiguration. None of them need to break any encryption. They read plaintext directly from RAM.
Confidant AI is built on the premise that this exposure cannot be solved by policy alone. Agentic AI compounds the exposure. The more autonomous the system, the more such moments accumulate.
What hardware-rooted TEEs do that software controls cannot
Confidential computing addresses the data-in-use gap by moving the root of trust from software managed by the cloud vendor to the CPU itself. A Trusted Execution Environment, or TEE, creates a hardware-enforced enclave where data is decrypted only inside a trusted zone. The host OS, the hypervisor, and the cloud provider see only ciphertext. The boundary is enforced by the silicon, not by an access-control rule that an administrator could edit.
The mechanism is worth describing precisely because it explains why the guarantee holds. Inside the CPU package, data is computed in plaintext within L1 and L2 caches and registers. The memory controller at the package boundary transparently encrypts data before it leaves the CPU die. As a result, DRAM always holds ciphertext. The hardware refuses.
Two technologies define the current state of this architecture. Intel TDX and AMD SEV-SNP are VM-based TEEs that protect the memory and execution state of an entire virtual machine from an untrusted hypervisor or host OS. Their advantage over earlier enclave designs is practical: they provide larger protected memory space and better software compatibility. That makes them a workable substrate for hosting large model states in cloud LLM inference, where a model's weights and intermediate activations can exceed the capacity of older, process-scoped enclaves.
The principle underlying privacy-first AI assistants embeds this hardware enforcement directly into service architecture. Confidant AI places TEE-backed confidential computing inside its infrastructure so that data remains physically inaccessible to operators regardless of their administrative privileges. Model weights gain the same protection as input data. The weights become intellectual property shielded by silicon, not by contract.
Extending hardware trust from CPU to GPU for LLM inference
But what happens when the model is too large to run inside the CPU alone? The architecture must extend the hardware trust boundary to the GPU. That extension creates a specific vulnerability at the seam: data leaving a CPU TEE to traverse the PCIe interconnect to a GPU is exposed unless the channel itself is encrypted and the GPU is enrolled in the trust boundary.
GPU confidential computing closes this gap through two coordinated mechanisms. Data is encrypted before it traverses the PCIe interconnect. Inside the GPU, it is placed in a Compute Protected Region in GPU high-bandwidth memory, where it remains inaccessible to the host driver and to other tenants. The trust chain runs from CPU package, across an encrypted interconnect, into a protected GPU memory region. At no point does plaintext model data sit anywhere the operator can read. Google Cloud's Confidential G4 VMs, pairing NVIDIA RTX PRO 6000 Blackwell Server Edition GPUs with confidential computing, are now available in preview in every region where standard G4 is offered. They deliver confidential inference and fine-tuning with minimal performance impact.
Performance remains a live concern. Confidential compute capabilities on NVIDIA Hopper GPUs show impact small enough to make confidential LLM inference practical at near-production levels, but the overhead is not zero. A February 2026 paper found that a widely adopted optimization, precomputed static secret bases to accelerate cryptographic operations in partial TEE-shielded inference, introduces a classic cryptographic flaw: the reuse of secret keying material. Full GPU-mode confidential computing avoids this vulnerability class. It also requires hardware that not every deployment can access.
How remote attestation turns a hardware guarantee into a verifiable one
Hardware isolation alone is not sufficient. Remote attestation provides that proof. Before processing starts, the enclave generates a cryptographically signed measurement of its code, configuration, and hardware state. A remote party can verify this measurement against a known-good reference without trusting the operator.
The gates attestation controls run deeper than a single check. Model weights remain encrypted until attestation passes, and a key broker releases decryption keys only to a workload whose measurement matches the expected value. Outbound credentials and privileged tool access are granted at run time, conditioned on a valid attestation report, rather than at deploy time. The pattern is consistent: attestation-verified identity, then policy evaluation, then scoped secret or tool release.
Google Cloud's Confidential Space applies this pattern to remove the workload operator from the trust boundary. It runs a hardened minimal container OS that disables SSH, the sshd daemon, OS Login, and other cloud-specific remote access tooling. The privacy claim becomes verifiable and auditable, not merely asserted. A contractual commitment or a written privacy statement cannot substitute for a machine-verifiable cryptographic proof that does not depend on trusting the operator.
The same attestation discipline now extends to the client channel. Google Cloud has released open-source Prompt Encryption SDKs that establish an attested TLS session between the client and an inference server running inside a TEE. The inference endpoint is the only point of decryption. This completes an end-to-end private inference channel.
Why exactly does attestation independence matter? Because the entity verifying the workload should not be the same entity operating the infrastructure. If the cloud provider both runs the machine and vouches for what it runs, the relying party is still trusting the provider. Independent attestation breaks that circular dependence.
Isolating agent identities and enforcing least-privilege access inside the enclave
Hardware isolation and attestation secure the compute environment. Agent identity isolation must be designed explicitly, and the scale of the problem makes that design urgent. Non-human identities now outnumber human identities at ratios of 45:1 to 144:1 in enterprise environments, reaching 500:1 in some hyper-automated sectors. The vast majority carry privileges exceeding what their function requires. Traditional credential models were not built for this.
The structural risk is that conventional API keys or client credential flows grant agents broad, persistent privileges. When an agent is compromised through prompt injection or behavioral drift, those privileges define the blast radius. No standing API key with broad access persists between tasks.
The on-behalf-of chain preserves user identity context through the agent invocation, so the resource server can verify whose authority the agent acts under. This is the ID-JAG pattern, the Identity Assertion JWT Authorization Grant, a profile combining OAuth 2.0 Token Exchange (RFC 8693) and the JWT Profile (RFC 7523) that generates proxy authority dynamically rather than statically. Whoever controls the infrastructure must not be able to substitute a different agent identity or intercept the agent's credential requests. This is where the TEE boundary enforces what the identity protocol assumes.
Regulatory direction is hardening along the same lines. The May 2026 Five Eyes guidance on agentic AI requires giving each agent a distinct identity, a cryptographically anchored principal with its own unique keys or certificates, with continuous runtime authentication. It calls for avoiding broad or unrestricted access to sensitive data, monitoring and logging agent behavior and tool usage, and retaining human oversight over high-impact or irreversible actions. These requirements map directly onto the architectural controls: distinct identities, scoped tokens, and attestation-gated tool release.
What the full zero-operator-access stack looks like assembled
Zero-operator-access is not a single technology. It is a composition of four layers, each of which must hold for the guarantee to be meaningful: hardware isolation, GPU trust extension, remote attestation, and agent identity isolation. The CPU TEE establishes the hardware root of trust and protects the inference VM from the host and hypervisor. Agent identity isolation inside the enclave ensures that even within the attested environment, each agent's credentials are scoped, short-lived, and on-behalf-of the user.
End-to-end prompt encryption completes the channel. The layers depend on each other in sequence. Without the CPU TEE there is no root of trust. Without GPU trust extension the root cannot reach the model. Without attestation the isolation cannot be verified. Without agent identity controls the attested environment can still leak privilege. The composition is what produces the guarantee, not any single component.
The architecture is already in production, not merely on paper. Google Cloud's Confidential Space for AI workloads combines a hardened minimal container OS, hardware-signed attestation for both CPU and GPU, and a key broker that releases model weights only to attested workloads. NVIDIA's zero-trust AI factory reference architecture, published March 2026, formalizes the same composition: CPU TEE, confidential GPU, confidential containers, and a Key Broker Service that withholds model decryption keys until attestation passes.
Confidant AI follows the same principle from a different starting point. The stated goal is for users not to have to choose between a capable AI assistant and one that cannot see their data. That framing puts it alongside the other production deployments of this stack, each arriving at the same composition because the threat model forces it.
Where the zero-operator-access claim has real limits
The TEE architecture addresses the insider-operator threat model, but honesty about its limits is what distinguishes a real architectural guarantee from marketing language. Transformer attention patterns, KV-cache access, and speculative decoding have not been systematically studied in TEE contexts as side-channel surfaces. That gap is a research question, not a resolved defense.
Known hardware attacks raise the bar of what "zero" actually means. The TEE.Fail attack, disclosed in October 2025, used a DDR5 memory bus interposer to extract attestation keys from Intel TDX and ECDSA signing keys from AMD SEV-SNP, demonstrating attestation forgery. It required physical hardware access and root-level kernel privileges but was achievable with commodity equipment. In March 2026, researchers extracted the SGX Global Wrapping Key from Intel Gemini Lake, enabling decryption of root keys burned into hardware fuses. That compromise is unpatchable at the silicon level.
One might argue these attacks render the entire architecture moot. An attacker who previously could read VM memory through a compromised hypervisor now needs a side-channel attack, a physical interposition device, or a root-of-trust compromise. Full GPU-mode confidential computing avoids this, but requires hardware not universally available.
What teams actually need to decide before building on this stack
Understanding the architecture is necessary but not sufficient. Teams face several concrete decisions before a zero-operator-access design can be built and maintained in production. The answer determines whether physical-interposer resistance matters or whether attestation against a cloud insider is the operative goal.
Hardware availability is a real constraint. Full GPU-mode confidential computing on NVIDIA Hopper or Blackwell hardware avoids the partial-shielding vulnerability class but is not universally available across all cloud regions or instance types. Operator-independent attestation is the stronger design, and it is moving from an architecture pattern to a production feature across major cloud providers.
Agent identity lifecycle design is an early decision, and it has long-term consequences. Just-in-time credential issuance requires an identity broker that can issue scoped tokens at task start and revoke them at task end. That broker must be designed before agents are deployed. Retrofitting it is far harder. The May 2026 Five Eyes agentic AI guidance, the December 2025 CISA and NSA operational technology guidance, and the August 2025 BSI and ANSSI LLM zero-trust principles collectively define expectations that map to specific architectural controls: distinct agent identities, continuous authentication, scoped access, and human oversight for high-impact actions.
The deepest design principle sits beneath all of these decisions. Adding TEEs, attestation, or agent identity controls to an existing system that was not designed for them is significantly harder and less reliable than designing for zero-operator-access from the first architectural decision. That principle, more than any individual technology choice, is what separates a coherent privacy guarantee from a set of controls bolted onto an architecture that was never meant to hold them.
