← Back to Blog

Researchers Just Broke Partial TEE Architectures Used to Protect AI Models. Here Is What That Means for Confidential AI.

·9 min read

A new paper from Rutgers University demonstrates that a common approach to securing AI inference — splitting computation between a trusted CPU enclave and an untrusted GPU — is fundamentally broken. The attack recovers model secrets with 100% accuracy. Here is why ConfideAI's infrastructure is not affected.


On February 11, 2026, researchers at Rutgers University published a paper titled "Vulnerabilities in Partial TEE-Shielded LLM Inference with Precomputed Noise" that demonstrates a devastating attack on a widely used approach to securing AI inference. The paper shows that systems which split computation between a trusted CPU enclave and an untrusted GPU can be completely compromised — model weights stolen, integrity checks bypassed — using a straightforward algebraic attack.

The research is significant because it does not target a specific implementation bug or a hardware side-channel. It identifies a structural flaw in the design pattern itself. Any system that uses a precomputed static basis to obfuscate data sent between a TEE and an untrusted GPU is vulnerable, regardless of implementation quality.

For mental health practitioners using AI tools for clinical documentation, this paper underscores a point we have been making from the beginning: not all "secure AI" architectures are created equal. The distinction between partial TEE protection and full TEE protection is not a marketing nuance. It is a fundamental difference in security design.


What Is a Partial TEE Architecture?

To understand the vulnerability, it helps to understand what Trusted Execution Environments are and why some systems use them partially.

A TEE is a hardware-isolated region of a processor where code and data are protected from everything outside it — including the operating system, the cloud provider, and even someone with physical access to the server. Intel TDX and NVIDIA Confidential Computing (on H100 GPUs) are current implementations of this technology.

The challenge is that modern large language models require enormous computational power, and most of that power comes from GPUs. Older TEE designs were limited to CPUs, which created a problem: the TEE could protect data at rest and in transit, but the moment data needed to be processed by a GPU for AI inference, it had to leave the secure enclave.

Partial TEE-Shielded Execution (PTSE) emerged as a workaround. In a PTSE architecture, the CPU runs inside a TEE, but the GPU operates outside the trust boundary. To protect the model and data, the system uses cryptographic obfuscation — adding noise, scrambling weights with secret permutations — before sending data to the untrusted GPU. The TEE then reverses the obfuscation when the results come back.

This approach was always a compromise. It traded full hardware protection for performance. The Rutgers paper shows that compromise has a concrete cost.


What the Researchers Found

The core vulnerability is a classic cryptographic flaw: the reuse of secret keying material.

In a partial TEE system, the CPU enclave needs to add random noise to data before sending it to the untrusted GPU, then remove the noise effect when the results return. Generating truly fresh noise for every operation would require the TEE to perform expensive matrix multiplications internally — operations that would make the system 37 to 55 times slower, according to the paper's benchmarks. For a LLaMA-3 8B model, the secure approach would add over 2 seconds of latency per token. That is unusable for any practical application.

To avoid this bottleneck, systems adopt a precomputation shortcut. At startup, the TEE generates a small, fixed set of noise vectors (typically 10) and stores their precomputed effects. During inference, all "random" noise is constructed by combining these same basis vectors with fresh coefficients.

The problem is that this noise is not truly random. It is permanently confined to a low-dimensional subspace — a predictable mathematical structure that an attacker can characterise and then exploit.

The Rutgers researchers developed two attacks:

Confidentiality attack. By sending a small number of queries and observing the outputs, the attacker characterises the noise subspace, constructs a filter to cancel it out, and then recovers the secret permutations that protect the model weights. For LLaMA-3 8B, a single layer's secrets were recovered in approximately 6 minutes. Even for a 405-billion-parameter model, the attack takes under two hours per layer.

Integrity attack. Systems like Soter and TSQP use hidden fingerprints — known-answer challenges mixed with real data — to verify that the GPU has not tampered with computations. Because these fingerprints are also generated from a static basis, the attacker can identify and isolate them, then tamper with genuine computations while passing all integrity checks.

Both attacks achieve a 100% success rate once the noise subspace is fully characterised. The researchers also tested countermeasures, including random subset sampling and increasing the basis size. Neither worked. The flaw is structural.


Why This Matters: Partial vs Full TEE

The critical distinction is between partial and full TEE architectures.

In a partial TEE system, the GPU is untrusted. Data must be obfuscated before leaving the TEE, and de-obfuscated when it returns. This creates the performance bottleneck that forces the precomputation shortcut, which creates the vulnerability.

In a full TEE system, both the CPU and the GPU operate inside hardware-secured enclaves. The data never leaves the trust boundary during processing. There is no untrusted GPU. There is no need for obfuscation. There is no precomputed noise basis. The entire attack surface described in the Rutgers paper simply does not exist.

The paper itself acknowledges this distinction. The authors note that "recent confidential computing architectures like Intel TDX, AMD SEV, Arm CCA, and NVIDIA's Confidential Computing are beginning to address these limitations" and that technologies like "NVIDIA Hopper Confidential Computing" enable "the secure execution of entire large models." Their attack explicitly targets the older paradigm — systems that were forced to use partial protection because full hardware-secured GPU processing was not available.


How NEAR AI's Architecture Avoids This Vulnerability

ConfideAI's AI processing runs on NEAR AI's infrastructure, which uses a full TEE architecture — not the partial approach targeted by this research.

NEAR AI's implementation uses Intel TDX for CPU-side protection and NVIDIA H100 Confidential Computing for GPU-side protection. Both processor and accelerator operate inside hardware-secured enclaves. The Secure Protocol and Data Model (SPDM) protocol establishes a mutually authenticated, encrypted channel between the CPU TEE and the GPU TEE, ensuring that data remains within the hardware trust boundary throughout the entire inference pipeline.

This means:

  • No untrusted GPU. The GPU is inside the TEE trust boundary. There is no need to obfuscate data before GPU processing.
  • No precomputed noise basis. Because data does not leave the secure enclave for computation, the mask-offload-restore pattern described in the paper is not used.
  • No low-dimensional subspace to exploit. The entire attack chain — characterising a noise subspace, filtering out noise, recovering permutations — has no entry point.

The vulnerability identified by the Rutgers researchers arises from a specific performance optimisation that is only necessary when part of the computation happens on untrusted hardware. NEAR AI's architecture eliminates that requirement entirely.


How ConfideAI Benefits from This Architecture

ConfideAI operates a secure gateway that authenticates users and routes clinical documentation requests to NEAR AI's TEE infrastructure. Clinical content is not stored, logged, or retained on ConfideAI's own servers. Conversation history is stored on NEAR AI's infrastructure, not ConfideAI's; the TEE protections described in this post apply to data during AI processing.

The security of the AI inference itself — the processing of clinical content through the language model — is provided by NEAR AI's full TEE implementation. Cryptographic attestation verifies that each request is processed inside a genuine hardware-secured enclave, not on a standard server.

ConfideAI does not claim credit for designing this infrastructure. NEAR AI built it. What ConfideAI does is make it accessible to mental health practitioners through 20+ evidence-based clinical documentation templates, multi-orientation support, and workflows designed for the full episode of care from referral to discharge.

The Rutgers paper validates the architectural choice that NEAR AI made: full TEE protection, not partial. And it demonstrates why that distinction matters.


What This Does Not Mean

This paper does not mean that all TEE-based security is broken. It means that a specific, widely used design pattern — partial TEE with precomputed noise — is broken. The distinction is important.

TEE technology itself remains sound. Intel TDX and NVIDIA Confidential Computing are actively maintained, independently audited hardware security technologies. The Rutgers researchers explicitly assume a "perfect TEE" in their threat model. Their attack targets the protocol layer above the TEE, not the hardware itself.

It is also worth acknowledging that no security architecture is immune to all future research. TEE implementations face ongoing scrutiny from the security research community, including work on side-channel attacks, attestation verification, and supply chain integrity. This is healthy. Any security technology that is not being tested is not being taken seriously.

What the Rutgers paper does establish is a clear hierarchy: full TEE architectures, where both CPU and GPU operate inside the trust boundary, are structurally more resilient than partial approaches that rely on cryptographic workarounds. For practitioners evaluating AI tools for clinical documentation, this is a meaningful and measurable distinction.


What Practitioners Should Take from This

The Rutgers paper is a technical contribution. But the practical implication for clinicians is straightforward.

When evaluating any AI tool that claims to offer "secure" or "confidential" processing, ask what kind of security architecture it uses:

  • No TEE at all — standard cloud processing where the provider has full access to your data during inference. This is how most consumer AI tools (ChatGPT, generic Claude) operate.
  • Partial TEE — the CPU is protected, but the GPU is not. Data is obfuscated before GPU processing. The Rutgers paper shows this approach has a fundamental flaw.
  • Full TEE — both CPU and GPU operate inside hardware-secured enclaves. Data remains within the trust boundary throughout processing. This is the architecture NEAR AI uses and ConfideAI relies on.

The Rutgers paper reinforces what ConfideAI's AI Documentation Standards paper argued: that the technical architecture of an AI tool determines the actual level of protection it provides. Policy promises and terms of service are not substitutes for structural security.


This post is for informational purposes only and does not constitute security advice. The technical details of TEE architectures are simplified for a general audience. Practitioners should evaluate AI tools based on their specific regulatory requirements and consult appropriate technical and legal advisors.


Sources:

  • Abhishek Saini, Haolin Jiang, and Hang Liu, "Vulnerabilities in Partial TEE-Shielded LLM Inference with Precomputed Noise," Rutgers University, arXiv:2602.11088v1, February 11, 2026
  • NEAR AI Trusted Execution Environment documentation
  • ConfideAI Research, "Using Generative AI for Mental Health Documentation: Why Public Tools Fail Professional Standards and What Safe Use Requires"

More from ConfideAI