Cryptographic Operator Exclusion as a First-Class Design Requirement for AI Assistants

TEE-backed assistants use hardware-rooted isolation and remote attestation to keep prompts and other inference data inaccessible to the infrastructure provider. Cryptographic operator exclusion should be a foundational design requirement because software controls cannot reliably exclude an administrator who controls the systems beneath them. Users need to establish whether that protection covers the assistant’s whole working environment, including its model call.

Why operator access to inference data is a structural problem, not a configuration one

An administrator enters a container and reads the conversation history or model weights available inside it. No application password needs to be broken. The administrator already controls the layer on which the application depends, while prompts and outputs exist in plaintext memory during inference. In conventional centralized deployments, the orchestration layer and deployment toolchain assume this operator visibility.

Forough, Kogias, and Haddadi’s 2026 survey describes the underlying exposure. A cloud provider with hypervisor access can read LLM weights and user context in plaintext despite application-layer protections. Prompt guards, output classifiers, and function-call sandboxes operate above that access boundary. They cannot keep data secret from an adversary below that boundary. The operator’s underlying power is structural, and changing an application permission does not remove it.

What operator exclusion means as a technical property

Operator exclusion prevents the entity running the infrastructure from reading the sensitive data processed inside the protected environment. Policy does not merely forbid access. Hardware-rooted isolation and cryptographic controls make that access unavailable within the system’s stated threat model. Encryption at rest and in transit do not establish this property because neither protects plaintext in RAM during computation.

The distinction becomes sharpest at the application boundary. Schambach et al.’s 2026 EnclaveX research shows that a Kubernetes administrator can retain API privileges and use kubectl exec to enter a confidential VM. VM isolation alone can still let an administrator read sensitive application data. The architecture addresses that gap through application-layer protection, with encryption keys released only after successful attestation. A confidential VM is not automatically an operator-excluding application.

Remote attestation makes the property testable before disclosure. It lets a user check through cryptography that the code they expect is running inside a genuine TEE with a known security configuration before they provide inputs. Breckenridge et al.’s 2026 πCreds research applies this principle to a credential-processing pipeline, including verification of which model processes the data.

How Trusted Execution Environments make operator exclusion enforceable by hardware

Trusted Execution Environments isolate protected code and data from privileged system software, subject to the boundary each platform implements. The host does not hold the memory-encryption keys. Hardware holds and manages those keys and protects memory so that looking outside the protected boundary does not give access to plaintext. This moves enforcement below the software layer that an infrastructure administrator controls.

The survey maps six platforms, including Intel SGX, Intel TDX, AMD SEV-SNP, ARM TrustZone, ARM CCA, and NVIDIA H100 CC. They differ in isolation granularity, deployment role, and performance tradeoffs. They are not interchangeable security labels. EnclaveX combines Intel TDX memory isolation with NVIDIA H200 GPU TEEs and application-layer attestation through SCONE. Vaswani et al.’s 2022 research describes Graphcore’s experimental ITX extensions, which keep code and data encrypted outside the IPU, including over the PCIe link.

Attestation connects that hardware boundary to the remote user. A cryptographically signed report, rooted in keys from the hardware manufacturer, gives evidence about the protected environment and the software stack that should be running. Key release can then depend on successful verification. This is the bridge between isolation and trust. Without it, the user has no equivalent basis for determining whether the promised environment is the one receiving their secrets.

Why agentic AI systems make the operator-exclusion gap materially worse

A single inference call exposes a prompt and its response. An agent can expose a much longer history. It maintains memory across sessions, holds service credentials, invokes APIs, and receives tool outputs across pipelines that no single party fully controls. The same privileged access can reveal the context the agent has built up and the credentials it holds for downstream services.

The survey maps this expanded exposure across perception, planning, memory, action, and coordination. A compromised orchestrator can intercept inter-agent messages before application-layer encryption takes effect, while a rogue agent can poison a collaborative pipeline using protocols such as MCP and A2A. Hardware isolation protects against privileged access to the infrastructure, while controls inside the protected application must also deal with malicious content and tool behavior.

The 2025 EchoLeak exploit, CVE-2025-32711, illustrates that second distinction. A malicious email triggered Microsoft Copilot to exfiltrate sensitive data without user interaction by exploiting its tool-calling behavior. The survey also cites evaluations in which over 75% of adversarially crafted shell commands executed successfully against unsandboxed agent runtimes. Neither finding shows that a TEE on its own stops agent misuse. They show why protecting inference while leaving memory and action boundaries unprotected is an incomplete design.

The architectural requirement is to protect the agent’s memory, tool execution, and communication channels as well as inference. The research prototypes approach this wider boundary from different directions, and their differences provide more useful evaluation criteria than an unsupported vendor ranking. The central tests are the scope of isolation, the conditions for releasing keys, and the evidence available to the user.

The Omega system, described in 2025 research cited by the survey, attempts a broad agentic architecture. It isolates agents, models, and user data while supporting secure communication among agents and tools. Nested confidential execution keeps tenants isolated from one another, while attestation services and trusted boot help multiple parties trust the system. EnclaveX tackles a narrower but decisive problem. Its application-layer key protection keeps an administrator who can access the VM from using that access to read the application’s protected data.

πCreds shows how this works in a pipeline that draws on financial, health, email, and code sources. Data fetching, LLM inference, and credential issuance run inside a TEE-protected enclave, with verification before submission. These are research demonstrations. The survey finds mature hardware primitives for targeted deployments but no broadly established end-to-end security framework for production agentic AI. Important gaps remain in how tools run and how agents trust one another.

The performance objection to confidential inference and what recent hardware evidence shows

Performance cost is the strongest practical objection to confidential inference. EnclaveX evaluates Intel TDX with NVIDIA H200 GPUs using industry benchmarks and distinguishes high-overhead configurations from better-performing ones. Its account attributes the difference to architectural choices rather than an unavoidable cost imposed by TEE primitives.

The ITX evaluation reports less than 5% overhead on standard DNN training workloads and shows that it performs much better than the CPU-based confidential computing systems using AMD SEV-SNP that it was compared with. That evidence concerns training workloads. Separately, confidential inference on NVIDIA Hopper GPUs has shown a performance impact within 7%. These results show that hardware isolation can have low overhead, but they leave open how other workloads or agent architectures will perform.

The alternatives impose a different practical burden. The survey reports two-to-four orders-of-magnitude overhead for fully homomorphic encryption and secure multiparty computation, making them impractical for billion-parameter interactive workloads in its assessment. TEEs offer a workable middle ground, though their guarantees depend on hardware that must be trusted. The remaining questions concern coverage as well as speed. Compound attestation across multi-hop agent chains and GPU-TEE performance at full LLM scale remain open challenges, so inference results cannot settle the whole agentic case.

Why security researchers caution that TEEs alone are not a complete answer

France’s ANSSI said in its October 1, 2025 position paper that technology alone cannot give strong enough guarantees of confidentiality and integrity when a hostile cloud administrator carries out active attacks. Cache timing, speculative execution, and memory-access patterns have all enabled demonstrated attacks against TEE implementations. No single platform protects against an adversary at every privilege tier.

The architectural response starts with the trusted computing base, or TCB. This is the set of hardware and software on which the protection depends. EnclaveX demonstrates why its size and composition are consequential. A VM boundary can exclude the hypervisor yet leave an administrator’s application-access path intact. Application-layer keys and attestation address that gap in its design.

TEEs are necessary but insufficient for this hardware-rooted design posture. Attestation, a minimized TCB, and explicit statements of what remains unprotected belong in the architecture. BSI and ANSSI’s August 2025 joint report, “Design Principles for LLM-based Systems with Zero Trust – Foundation for Secure Agentic Systems,” frames zero trust as a prerequisite for secure agentic deployment. A credible operator-exclusion claim therefore specifies its boundary and assumptions rather than presenting the hardware label as an unconditional guarantee.

How regulatory and institutional pressure is turning operator exclusion from a research goal into a deployment requirement

A confidentiality obligation is not automatically a mandate for a particular chip. The relevant convergence is toward demonstrable controls over access, processing, and accountability, which unrestricted operator access makes harder to establish. Hardware-rooted exclusion can limit that exposure so that protection depends less on an organization choosing to hold back.

The EU AI Act’s Chapter V GPAI obligations have been in force since 2 August 2025, while Article 50 transparency obligations took effect on 2 August 2026. The Digital Omnibus on AI, in force July 27, 2026, moved most high-risk deadlines to December 2027 for Annex III stand-alone systems and August 2028 for Annex I product-embedded systems, leaving GPAI and transparency timelines unchanged. These dates do not themselves define an operator-exclusion architecture. For agents processing EU residents’ personal data, GDPR processor obligations concerning confidentiality, security, sub-processors, and audit assistance create a further reason to scrutinize plaintext access.

Singapore IMDA’s Model AI Governance Framework for Agentic AI, published at the World Economic Forum in January 2026, treats the issue as a design-time concern. The joint zero-trust report looks at how to deploy agents securely through the lens of national security. Baker et al.’s 2025 RAND research looks at cryptographic assurance for international AI verification and acknowledges that much research work remains. Together, these directions strengthen the case for verifiable safeguards without establishing that TEEs alone satisfy regulatory obligations.

What it means to build an AI assistant with operator exclusion as a foundational requirement

A foundational requirement constrains the design before deployment choices harden. For operator exclusion, those constraints include VM-level memory protection, application-layer key management tied to attestation, secure inter-agent channels, and tool-execution boundaries. Retrofitting an encrypted inference call into an environment designed for operator visibility cannot, by itself, close the other paths.

Users should be able to verify the model’s identity and the TEE’s security properties before providing sensitive inputs. Keys should be released only when attestation establishes the expected stack, and the trusted computing base should be kept as small as the design permits. Low-overhead inference evidence also weakens the assumption that this discipline necessarily requires sacrificing useful capability.

The unresolved agentic gaps set the next design obligations. A protected model does not establish protected tools, and one attested component does not establish trust across an entire agent chain. A principled assistant architecture makes those limits explicit while treating their resolution as required work. With first-class operator exclusion, the system must account for every place a secret crosses its protection boundary, and any claim about its strongest component must fit within that full account.