Skip to main content
Bureau of AI
Category: Privacy & Data Protection

Secure Multi-Party Computation

Also known as: MPC, SMPC, Multi-Party Computation, Secure Multiparty Computation
Simply put

Secure Multi-Party Computation is a cryptographic method that lets several parties jointly compute a result using each of their inputs without any party having to reveal its own private data to the others. In effect, the parties can collaborate on a calculation and learn the answer while keeping their individual inputs secret. It is one approach used to enable computation on sensitive data without directly sharing that data.

Formal definition

Secure Multi-Party Computation (MPC/SMPC) is a generic cryptographic primitive that enables a set of distributed parties to jointly compute an agreed-upon functionality over their combined inputs while keeping each party's input private, revealing only the intended output. As commonly defined, the goal is to carry out distributed computing tasks securely such that no party learns more about the others' inputs than can be inferred from the output itself. Related threshold schemes apply MPC principles to distribute secrets or operations (for example, splitting a private key across multiple parties so that no single point holds the complete secret). This entry addresses the cryptographic concept and does not specify particular protocols, security models (such as semi-honest versus malicious adversaries), or performance and deployment trade-offs, which vary by implementation and are out of scope here based on the available evidence.

Why it matters

Secure Multi-Party Computation addresses a recurring tension in AI governance and data-driven collaboration: organizations often need to combine data or jointly compute results across institutional boundaries, yet they are constrained by confidentiality obligations, competitive sensitivity, or privacy requirements. MPC is one class of privacy-enhancing technique that allows parties to obtain a shared result while keeping their individual inputs private, which can reduce the need to pool raw sensitive data in a single location. This can matter for use cases where data sharing would otherwise be legally or contractually restricted.

For risk and compliance functions, MPC is relevant because it changes where sensitive data is exposed during a computation, potentially narrowing the surface over which confidential inputs are disclosed. As applied in threshold schemes, MPC principles can also be used to distribute a secret or an operation across multiple parties so that no single party holds the complete secret—for example, splitting a private key across multiple parties, as described in industry material on key management. This distribution of trust is often cited as a way to avoid a single point of compromise, though the degree of protection depends heavily on the specific protocol and implementation.

It is important not to overstate what MPC provides. MPC is a cryptographic method for computing on inputs without revealing them; it is not, by itself, a complete governance or data-protection program, and the available evidence here does not establish specific performance characteristics, adversary models, or regulatory sufficiency. Whether an MPC deployment meets any particular legal or supervisory expectation depends on factors outside the scope of this entry.

Who it's relevant to

Privacy and data protection specialists
Professionals evaluating privacy-enhancing techniques may consider MPC as one method for enabling computation on sensitive data without directly sharing that data. Its relevance in any specific context depends on the applicable legal framework and the details of the implementation, which this entry does not assess.
Model risk and data governance teams
Teams overseeing how data is combined across institutional or organizational boundaries may treat MPC as a control that changes where individual inputs are exposed during a joint computation. It should be evaluated as a risk-reducing measure rather than one that eliminates risk, and it does not by itself constitute a complete governance program.
Security architects and key management practitioners
Those responsible for protecting secrets such as cryptographic keys may be interested in threshold schemes that apply MPC principles to split a private key across multiple parties, so that no single point holds the complete secret. The security benefit depends on the specific scheme and implementation.
Compliance and legal professionals
Practitioners assessing collaborative or cross-party data use may encounter MPC as a technical option that keeps individual inputs private while producing a shared result. Whether it satisfies any given contractual or regulatory requirement is a fact-specific determination outside the scope of this entry.

Inside MPC

Cryptographic protocol for joint computation
Secure Multi-Party Computation (SMPC) is a class of cryptographic techniques that allows multiple parties to jointly compute a function over their combined inputs while keeping each party's individual inputs private from the others.
Input privacy guarantee
The defining property is that no participating party learns anything about the other parties' inputs beyond what can be inferred from the agreed output of the computation.
Secret sharing
A common building block in which sensitive data is split into shares distributed across parties, so that no single party holds a reconstructable copy of the original value.
No trusted third party required
SMPC is typically designed to achieve the result that would otherwise require a trusted intermediary, without any single participant or external party gaining access to the raw combined data.
Threat model and adversary assumptions
Protocols are commonly specified against defined adversary models (for example, honest-but-curious versus malicious participants), and their guarantees hold only within the assumptions of that stated model.
Relevance to AI governance and model risk
In AI contexts, SMPC can be applied to enable collaborative model training or evaluation across data holders without pooling raw data, which is a privacy-preserving control rather than a substitute for broader governance or model risk management.

Common questions

Answers to the questions practitioners most commonly ask about MPC.

Is secure multi-party computation the same as encrypting data before sharing it?
No. Standard encryption protects data in transit or at rest, but the data must typically be decrypted before it can be used in a computation. Secure multi-party computation (MPC) is a class of cryptographic protocols that allows multiple parties to jointly compute a function over their combined inputs while keeping each party's inputs private, so no party's raw data needs to be revealed or decrypted to the others. Conflating the two overstates what conventional encryption provides and understates the coordination and protocol requirements MPC introduces.
Does using MPC mean an AI system is automatically compliant with data protection requirements?
No. MPC is a privacy-enhancing technique that can reduce certain risks associated with sharing or pooling data, but it does not by itself establish compliance with any particular data protection regime. Whether a given use of MPC satisfies obligations depends on the applicable law, the specific implementation, the threat model assumed, and how residual risks are handled. MPC is a technical control that may support a compliance posture; it should not be presented as a substitute for a legal or governance assessment.
How does the choice of security model (semi-honest versus malicious) affect an MPC deployment?
MPC protocols are commonly specified against a threat model. A semi-honest (or honest-but-curious) model assumes parties follow the protocol but may try to learn from what they observe, while a malicious (or active) model assumes parties may deviate arbitrarily. Protocols secure against malicious adversaries typically carry higher computational and communication overhead. Selecting the model is a governance decision that should reflect the trust relationships among parties and the consequences of a party misbehaving; documenting the assumed adversary model is important because guarantees hold only within that model.
What performance and infrastructure considerations arise when implementing MPC?
MPC protocols generally introduce additional computational cost and communication rounds compared with computing on plaintext, and the magnitude depends on the protocol, the function being computed, the number of parties, and the security model. Practitioners commonly evaluate latency, bandwidth, and the complexity of the target computation before adoption, and may restrict MPC to specific high-sensitivity operations rather than an entire pipeline. Concrete performance figures are implementation-specific and should be measured against the intended workload rather than assumed.
How should MPC fit within existing model risk management and governance processes?
MPC affects how data flows into model development or inference, so it is typically treated as a control that should be documented, validated, and monitored like other components. In many frameworks this includes recording the protocol, the assumed threat model, the parties involved, and the residual risks that remain. It does not remove the need for validation of the models that consume the data, nor for the oversight structures that govern the overall system. The distinction between the cryptographic guarantee and the correctness and performance of the resulting model should be maintained.
What limitations and residual risks should be documented when relying on MPC?
Even a correctly implemented MPC protocol provides guarantees only within its stated assumptions, so limitations such as the assumed adversary model, collusion thresholds among parties, potential information leakage from the computed output itself, and implementation or side-channel weaknesses are commonly documented as residual risks. The output of a jointly computed function can in some cases reveal information about inputs, so MPC is often combined with other measures rather than treated as complete on its own. Clear scoping of what MPC does and does not protect against supports accurate risk reporting.

Common misconceptions

SMPC is the same as, or interchangeable with, homomorphic encryption or federated learning.
These are distinct privacy-preserving techniques with different mechanisms and trade-offs. SMPC distributes computation across multiple parties using cryptographic protocols, and while techniques can be combined, treating them as equivalent obscures their differing assumptions, performance characteristics, and guarantees.
Using SMPC makes a collaborative AI system fully private and eliminates data-related risk.
SMPC protects the confidentiality of inputs during computation, but the agreed output itself may still reveal sensitive information, and the guarantees depend on the assumed adversary model. It reduces certain privacy risks rather than eliminating risk, and does not by itself address governance, accountability, or model risk management obligations.
Adopting SMPC satisfies applicable data protection or AI regulatory requirements on its own.
SMPC is a technical control that may support privacy objectives, but it does not automatically demonstrate compliance with any particular legal or regulatory framework. Its role and sufficiency depend on jurisdiction, context, and how it fits within an organization's overall control environment.

Best practices

Explicitly document the adversary model (for example, honest-but-curious versus malicious) that the chosen SMPC protocol assumes, and verify that this model matches the trust relationships among participating parties.
Assess what the agreed computation output could reveal about individual inputs, since input privacy during computation does not prevent inference from the result.
Treat SMPC as one control within a broader privacy and governance framework, rather than as a standalone guarantee of compliance or risk elimination.
Distinguish SMPC from related techniques such as homomorphic encryption and federated learning when scoping requirements, so that design choices reflect the specific mechanism and its trade-offs.
Validate that protocol guarantees hold under the deployment's actual conditions and stated assumptions, and record any limitations or residual risks that remain.
Coordinate SMPC adoption with model risk management and governance functions so that privacy-preserving computation is reflected in documentation, oversight, and accountability structures.