A finance or risk team reviewing a custody provider's architecture may meet the phrase "trusted execution environment" in the appendix, next to a claim that customer keys, model weights or transaction data are processed "confidentially" inside a "secure enclave." The phrase does real work. It also covers a narrower promise than the marketing implies, and a growing list of published attacks shows where that promise ends.
What a TEE actually protects
A trusted execution environment is a hardware-isolated region of a processor in which code and data are shielded from the operating system, the hypervisor and, in principle, the machine's own administrator. The Confidential Computing Consortium, a Linux Foundation project, defines confidential computing as "the protection of data in use by performing computation in a hardware-based, attested Trusted Execution Environment" (Confidential Computing Consortium, scoping document).
The scope is data while it is being computed on. Data at rest is already covered by disk encryption, and data in transit by TLS. The gap a TEE fills is the moment in between, when a value has to sit in plaintext in memory for the processor to operate on it. Without a TEE, a cloud provider's hypervisor, a database administrator or malware with kernel privileges could, in principle, read it. A TEE narrows that exposure to the processor itself.
Implementations differ in what they isolate. Intel's Software Guard Extensions (SGX) protects an "enclave," a memory region an application carves out for itself. AMD's Secure Encrypted Virtualization with Secure Nested Paging (SEV-SNP) and Intel's Trust Domain Extensions (TDX) instead protect an entire virtual machine, which is coarser but easier for existing software to adopt. NVIDIA says its Hopper, Blackwell and Rubin GPUs support confidential computing that safeguards "data, model weights, and inference at runtime" (NVIDIA, product page, vendor material, undated).
Remote attestation: proving what is running
An enclave is only useful to a counterparty who never touches the machine if it can prove what it is. That proof is remote attestation: the processor signs a statement of which code is loaded, using keys that chain back to the manufacturer, and a remote party checks it against a known-good measurement before sending anything sensitive. Signal's Secure Value Recovery, described in a company blog post dated 19 December 2019, is a clear illustration: clients send values into an SGX enclave "over an encrypted channel with the assurance that they are actually being stored and processed by an enclave rather than someone pretending to be one." The enclave then enforces a maximum count of failed PIN guesses, five in the post's example, which even the service operator cannot lift (Signal, 19 December 2019).
Attestation answers "is this the code I expect, running on genuine hardware." It does not answer whether that hardware deserves trust.
The trust that does not disappear: the chip vendor
Confidential computing is often pitched as removing the need to trust a cloud provider. It does that by concentrating trust elsewhere: in the chip manufacturer that designs the silicon, writes the firmware, anchors the attestation keys and ships microcode updates. A flaw in that chain reaches every enclave that depends on it. In February 2025, AMD's CVE-2024-56161, found by Google security researchers and rated CVSS 7.2, was made public: deficient signature verification in AMD's microcode patch loader let an attacker with local administrator access load malicious microcode, with a "loss of confidentiality and integrity of a confidential guest running under AMD SEV-SNP" (The Hacker News, 4 February 2025). The flaw sat in the vendor's trust chain, not in any customer's application.
What has actually broken, and when
Software attacks on Intel SGX
An enclave still shares a physical core, cache and power supply with the rest of the system, and shared resources leak. Plundervolt, CVE-2019-11157, lowered the processor's voltage from software to induce faults in enclave computations; its authors wrote that they "were able to corrupt the integrity of Intel SGX on Intel Core processors" (Plundervolt research site). Downfall, CVE-2022-40982, disclosed in August 2023 by researcher Daniel Moghimi after a one-year embargo, used speculative execution of AVX instructions to expose vector-register contents on sixth- to eleventh-generation Intel Core and first- to fourth-generation Xeon Scalable processors, and SGX was affected (Wikipedia, Downfall).
Physical attacks: Battering RAM
A newer class assumes physical access to the machine. On 30 September 2025, researchers Jesse De Meulemeester, David Oswald, Ingrid Verbauwhede and Jo Van Bulck, of KU Leuven and the University of Birmingham, published Battering RAM, a DDR4 memory interposer costing less than $50. On Intel it gave "arbitrary read access to victim plaintext" or let an attacker write plaintext into enclaves; on AMD it bypassed firmware mitigations for SEV-SNP and allowed backdoors in a confidential virtual machine. Intel, AMD and Arm said physical attacks are "currently considered out of scope" of their threat models; the researchers argued a defence would require a fundamental redesign of memory encryption (The Hacker News, 30 September 2025).
AMD SEV-SNP: StackWarp and Fabricked
Two further SEV-SNP disclosures followed in 2026. StackWarp, CVE-2025-29943, published in January 2026 by researchers at the CISPA Helmholtz Center for Information Security, lets a malicious host manipulate a guest virtual machine's stack pointer on Zen 1 to Zen 5 processors; the researchers showed recovery of an RSA-2048 private key from a single faulty signature. AMD released microcode updates in July and October 2025 (The Hacker News, 19 January 2026). Fabricked, CVE-2025-54510, from ETH Zurich researchers Chris Wech, Benedict Schlüter and Shweta Shinde, became public when an embargo lifted on 14 April 2026. It manipulates memory routing in AMD's Infinity Fabric during initialisation so that a malicious hypervisor can trick the platform security processor into setting up SEV-SNP improperly. According to the report, AMD confirmed Zen 5 EPYC as vulnerable and issued firmware updates for Zen 3 and Zen 4 (SecurityOnline, 20 April 2026).
None of this means confidential computing has failed as a category: each disclosure above was met with patches, firmware updates or a vendor statement. It does mean "TEE-protected" describes a threat model, not a guarantee, and that the model as vendors state it leaves out attackers with physical access to the memory bus.
How blockchains and AI services use TEEs
On public blockchains, TEEs mainly add confidentiality to execution that would otherwise be visible to everyone. Oasis describes Sapphire as a confidential EVM-compatible runtime whose nodes must run in a TEE (Oasis, 31 August 2022, vendor material). Its developer documentation says contract state is encrypted and not accessible to anyone except the contract, and that only an attested compute node can request its state encryption key from the Oasis key manager (Oasis documentation, vendor material). That rests on a different assumption from a zero-knowledge system: confidentiality holds only as long as the hardware and its attestation chain hold.
In AI infrastructure, TEEs let a party rent GPU compute for inference or training without exposing model weights or prompts to the operator, the property NVIDIA describes for its confidential GPUs. Targon, the Bittensor subnet built by Manifold Labs, is described in OSS Capital's July 2025 announcement of the company's $10.5 million Series A as a "Confidential AI Cloud" (OSS Capital, 28 July 2025, investor material). Which TEE technology Targon uses, and how, was not in any material this piece could verify, so it is not described here.
Set beside zero-knowledge proofs and multi-party computation
Zero-knowledge proofs and multi-party computation address the same broad problem, keeping computation private, by different routes, and the three are not substitutes. A TEE hides data during computation but relies on a piece of hardware. A zero-knowledge proof lets a party show that a statement is true, such as that a balance is sufficient, without revealing the underlying value; it relies on mathematics rather than a chip, but proves only the proposition its circuit encodes. Secure multi-party computation, which NIST describes as allowing "multiple parties to jointly (distributively) perform a computation, using everyone's inputs, but without actually sharing the private inputs with one another," removes the single trusted machine by splitting the work across parties. NIST's call for multi-party threshold schemes, NIST IR 8214C, went through public drafts in January 2023 and March 2025 before its final version in January 2026 (NIST, Computer Security Resource Center). Each approach trades hardware trust, computational cost and the narrowness of what can be proven differently, so the useful question about a vendor's privacy architecture is which one it actually uses. The privacy stack in regulated finance is covered in our piece on blockchain privacy, and identity questions in proof of personhood in the agentic age.
Where this sat in the Paris programme
Applied confidential computing had its own slot at Proof of Talk Paris 2026, at the Louvre Palace: "Workshop by Targon - Applied Confidential Computing," on the X Ventures Masterclass Stage on 3 June 2026, from 11:30 to 12:30, presented by Robert Myers of Manifold Labs. No transcript has been published, so this piece attributes nothing to the session beyond its listing. The wider Bittensor presence at the edition is covered in Bittensor at the Louvre.
What is still unresolved
Two points stand. First, "physical attacks are out of scope" is a threat-model choice vendors have made, not a property of the hardware, and Battering RAM put the cost of one such attack under $50; anyone running confidential workloads in a data centre they do not control is relying on the operator's physical security as well as the chip. Second, remote attestation proves code identity, not code correctness or vendor integrity, so a TEE-based system is only as trustworthy as the manufacturer behind its attestation keys. This is not investment, legal or security advice for any specific deployment.