Confidential computing is three different trust models with one label
Silicon, math, and a quorum of nodes all ship under the same label. The phrase sets your threat model.
On 22 June, two companies shipped products they both called confidential computing. Anjuna, a Palo Alto enterprise vendor, announced Overwatch, a governance layer for AI agents that runs attested inside a Trusted Execution Environment, a region of a processor that walls code and data off from everything else on the machine, including the cloud provider hosting it. The same day, Arcium, a self-described encrypted supercomputer on Solana, listed its token. It offers what it calls confidential execution with no special hardware by splitting each input into shares spread across a network of nodes so that no single node ever holds the cleartext.
Both aim to provide compute on sensitive data without exposing it. One asks you to trust a chip and the other is built so that you do not have to.
That means if you're a buyer and you type the phrase into a search engine you will find at least three product categories that are actually quite distinct. They don't really even share a threat model, performance profile, or, in fact, a definitive answer to the one question that decides what confidentiality means in each case: what, exactly, are you trusting to keep the data secret.
The roots of what confidential means
The first root of trust is silicon, and it is the meaning the enterprise and standards world treats as definitive. The Confidential Computing Consortium defines the term as protecting data while it is being processed inside a hardware-based trusted execution environment, with the whole guarantee resting on a hardware root of trust. Anjuna's platform is an example of this because data stays encrypted in use, shielded even from anyone with administrative access to the infrastructure. All you are trusting is that Intel, AMD or Nvidia built the enclave as specified, that its firmware and microcode are sound, and that no one with physical access to the server can reach inside. In exchange you get close to native performance and the ability to run existing applications with few or no changes, which is why the cloud providers and regulated enterprises have standardised on this meaning.
The second root is math, and a different set of companies uses the identical word for the opposite arrangement. Zama describes itself as a confidentiality protocol, and uses fully homomorphic encryption to run computations directly on encrypted values, so the data is never decrypted, even during processing. The guarantee rests on a cryptographic hardness assumption rather than on a manufacturer. What you trust here is the mathematics, and the price you pay is performance, since computing on ciphertext is heavier than plaintext.
Root number three leans on a quorum, and it is reached by splitting the data rather than the difference. Arcium leans on secure multi-party computation, secret-sharing each input across a cluster of nodes and computing over the fragments so that no single node ever holds a whole value. Two separate thresholds govern the arrangement, and they are easy to run together. The first is the trust model for the computation itself: Arcium's main protocol, Cerberus, is dishonest-majority, so the inputs stay private as long as one node in the cluster is honest, only the collusion of every node breaks confidentiality, and cheating nodes can be identified and slashed. A faster alternative, Manticore, drops to an honest-but-curious model with a trusted dealer for heavier machine-learning workloads. The second threshold is separate and governs output. A result is decrypted only when a minimum set of key-holders cooperate. What you trust, in each case, is a specific claim about who is not colluding, and Arcium sets that against both rivals, arguing it removes the hardware trust it attributes to enclaves and the performance penalty it attributes to FHE.
Then there's zero-knowledge systems. These do not let an untrusted party compute on your secret data at all; they let the holder of the data prove a statement about it without revealing it. But that is a different problem. It's verifiable disclosure rather than confidential computation, which is why ZK tends to show up as a component inside the other three.
Where each root stops
Silicon's weakness is trust placement. A TEE moves the secret beyond the reach of the operating system and the cloud administrator, but it does so by decrypting the data inside the processor, which means the chip vendor and the physical machine are now inside your trust boundary. The cryptographic camps point to a long research record of side-channel and physical attacks that reach into enclaves, and to the more basic objection that a hardware root of trust requires trusting a hardware maker who can err or be compelled. The enterprise rebuttal is that a hardware root is the strongest one on offer today and that the alternatives remain too slow for most production work. The disagreement is about which trust is acceptable.
Math's familiar weakness is speed; FHE has historically been too slow for general use, which is why the camp's roadmaps lean so heavily on GPUs and dedicated accelerators, an irony worth noting given that the hope is for freedom from special hardware. But encrypting data does not, on its own, establish that the correct program ran on it. The Confidential Computing Consortium makes the point that code integrity is out of scope for the FHE model, whereas a TEE measures and attests the code at load time. Zama answers the integrity question by arguing that its FHE computations are publicly verifiable because anyone can recompute them, but that is a property of running the computation in the open.
Quorum's weakness is the assumption it is named for. The guarantee is only ever as strong as the trust model in play: under Cerberus, confidentiality falls only if every node in a cluster colludes; under the honest-but-curious Manticore, it assumes the nodes are not actively cheating in the first place. Either way the cryptography assures non-collusion but what about if the nodes fail independently, rather than being nominally separate operators with correlated incentives or shared infrastructure? That is a decentralisation question, which is why these networks lean on staking, slashing, and a roster of named independent operators. MPC also pays in expressiveness and liveness: branching is expensive because revealing which branch executed would leak information, and every node must stay online and in sync for a computation to finish.
The roots do not stay separate
Zama is described as an FHE system. But its litepaper shows the protocol resting on FHE for the computation, an MPC committee to hold the network's decryption key so that no single party can decrypt a result, and zero-knowledge proofs to confirm that users encrypted their inputs correctly. Follow the secrecy of that system to the decryption of a result, and it bottoms out on a non-collusion assumption among the key-holders. Arcium, the quorum system, combines MPC, FHE and ZK as well, and lets builders tune the trust assumptions per workload.
So the question is about which root anchors which stage of the computation, and where the composed system's secrecy actually bottoms out once you trace it to the end.
Asking the question
The enterprise world has a decade of installed meaning behind hardware enclaves; the chain-native world has taken the same words for architectures built specifically to avoid trusting hardware.
So yeah, confidential computing isn't a simple category. It's useful to put these questions to any system that claims it: what is the root of trust, what does that root fail to defend, and where does the secrecy bottom out once the primitives are composed?
