Privacy-preserving computation encompasses several distinct technical approaches that get grouped together in analyst reports and vendor positioning. Multi-Party Computation (MPC) and Trusted Execution Environments (TEEs) are both legitimate techniques with real use cases. They are not interchangeable, and understanding where each works well — and where it breaks down — matters considerably for teams designing regulated AI infrastructure.
The short version: for latency-sensitive AI inference on sensitive data owned by a single party processed on infrastructure they do not fully control, TEEs are the current practical answer. MPC is the right tool for a different problem class. This article explains why, with enough technical depth to make the decision defensible to a security architect or compliance team.
What MPC Actually Does
Multi-Party Computation is a cryptographic technique that allows multiple parties to jointly compute a function on their combined inputs without any party revealing their input to the others. The canonical example: two parties each hold a number and want to know whose number is larger without revealing the actual numbers. Garbled circuits, secret sharing (Shamir-based and related schemes), and oblivious transfer protocols are the underlying primitives.
For certain problems, MPC is the natural fit. Cross-institutional fraud detection where two banks want to compute whether a transaction pattern matches a fraud signature in their combined datasets — but neither bank wants to expose their customer data to the other — is a genuine MPC use case. Private set intersection, where parties compute the overlap of their datasets without exposing the non-overlapping elements, is another. These scenarios involve multiple mutually distrusting data owners who need a collaborative computation result without data exchange.
The performance profile of MPC is the key constraint. Garbled circuits have communication overhead proportional to the circuit depth of the function being computed. Secret-sharing-based MPC requires multiple rounds of network communication between parties for each operation. For simple statistical functions or small neural network inference, performance can be acceptable. For a large language model with billions of matrix multiplications, MPC overhead is currently prohibitive — inference latency measures in hours rather than milliseconds for models of meaningful size.
What TEEs Do — and the Different Problem They Solve
A Trusted Execution Environment solves a different problem: a single party owns data and wants to process it on infrastructure they do not fully control, without giving the infrastructure operator visibility into the data or computation. The party trusts the hardware vendor (Intel, AMD) and the software they put in the enclave, but does not need to trust the cloud provider's system administrators, hypervisor, or management plane.
TEEs achieve this through hardware-enforced memory encryption. The CPU manufacturer's hardware guarantees that the enclave's memory cannot be read by the host OS or hypervisor. Attestation provides a cryptographic proof that the code running inside the enclave matches an approved measurement hash. The data owner can verify the enclave is running their approved code before providing the decryption keys — and those keys are released only to the measured, verified enclave.
The performance overhead is qualitatively different from MPC. Memory encryption introduces a relatively modest CPU overhead — typically 5–15% for compute-bound workloads — with no network communication penalty between parties (because there is only one party). For large model inference, this overhead is generally acceptable. The inference throughput inside a TEE for a medium-sized language model is close to native performance, not orders of magnitude slower.
The Threat Model Comparison
The two approaches have different threat models, and clarity about which threat you are defending against is essential for making the right choice.
MPC's threat model: multiple parties each have data; no single party should learn the other parties' input data. The adversary is one of the participating parties acting honestly-but-curious (or in stronger MPC protocols, actively malicious). The computation result may be shared, but inputs are private. There is no trusted hardware or trusted third party — the security comes entirely from the cryptographic protocol.
TEE's threat model: a single data owner wants to process data on infrastructure operated by a third party. The adversary is the infrastructure operator — they have physical access to the servers and software-level access to the hypervisor and host OS. The computation is private from the infrastructure operator. Trust is placed in the CPU hardware manufacturer and the code running inside the enclave. The cloud provider is explicitly not trusted for data visibility.
For regulated AI — a bank running credit scoring on its own customers' data, a hospital running inference on its own patients' records — the primary threat is the infrastructure operator's access to sensitive data during computation. There is one data owner. The TEE threat model is the right fit. MPC's multi-party framework addresses a different scenario.
Where MPC Remains the Right Choice
We are not arguing that TEEs are universally superior to MPC — they address different problems and the choice depends entirely on the use case structure. MPC retains clear advantages in scenarios where:
Multiple data owners with mutual distrust need collaborative computation. A regulatory authority wanting to compute aggregate statistics across multiple banks' datasets without any bank revealing its individual records to the authority or to other banks — that is an MPC use case. The mutual distrust between participating parties means no single party can be trusted to hold a TEE that processes combined data.
Cryptographic security guarantees without hardware trust are required. MPC's security holds under mathematical hardness assumptions without trusting any physical hardware. In adversarial settings where physical hardware tampering is a realistic concern, or where trust in the chip manufacturer is not acceptable, MPC can provide security guarantees that TEEs cannot. This is a niche but real scenario in certain high-security research contexts.
The computation is simple and the latency requirement is loose. For a weekly batch computation that combines data from two parties and where a result in minutes or hours is acceptable, MPC's performance overhead may be tolerable and its trust properties may be preferable. Private set intersection at moderate scale is practical with MPC today.
The Hybrid Approach — When It Makes Sense
Some production architectures combine MPC and TEEs. A realistic scenario: a consortium of financial institutions wants to jointly train a fraud model using their combined transaction data. No institution will provide raw data to a central server. MPC-based federated learning or secure aggregation allows the model gradients (not raw data) to be combined without exposing individual institution data. The resulting model is then deployed inside a TEE on each institution's inference infrastructure, protecting the model weights and live inference data from each institution's own cloud provider.
This architecture uses MPC for the multi-party training aggregation step (where the threat is other participants seeing your training data) and TEE for the inference step (where the threat is the cloud infrastructure operator seeing live customer data). The two approaches are complementary rather than competing in this design.
The complexity cost of the hybrid approach is real — MPC-based secure aggregation is non-trivial to implement correctly, especially for neural network training at scale. Teams evaluating this path should be realistic about implementation complexity and should assess whether the benefits of MPC in the training phase outweigh the engineering overhead, or whether a privacy-preserving alternative for training (differential privacy with local data, synthetic data generation, or standard federated learning with contractual protections) is sufficient for their specific regulatory requirements.
A Practical Decision Heuristic
For platform engineers choosing between MPC and TEE for an AI inference workload on sensitive regulated data, start with these questions:
How many data owners are involved? If one party owns the data and wants to process it on external infrastructure, TEE is the primary tool. If multiple parties own data and need joint computation without exposing inputs to each other, MPC is relevant.
What are the latency requirements? Real-time or near-real-time inference (sub-second to single-digit seconds)? TEE. Batch computation where multi-minute to multi-hour latency is acceptable? MPC becomes feasible for some function classes.
What is the trust model? Distrust of the infrastructure operator but trust in CPU hardware? TEE. Distrust of all parties including the compute operator, with security from cryptographic protocol alone? MPC.
For most regulated AI inference workloads — a bank's transaction model, a hospital's clinical summarization tool, an insurance company's risk scoring pipeline — the answer to all three questions points to TEE. The data is owned by one party (or a clearly defined responsible party). Latency requirements are real-time or near-real-time. The threat is the cloud provider's access, not a malicious co-participant. MPC is the right answer for a different set of problems, and conflating the two leads to architectures that are either infeasible in practice or under-protected for the actual threat model.