Security and source quality: what is in the base, what is an option
Two guarantees not to conflate. Built and real: parameter transport is end-to-end encrypted (RSA-OAEP 2048 + AES-GCM 256); the coordinator sees encrypted model updates, never raw data. Option: robustness to malicious or poisoning contributions (robust aggregation, secure aggregation) is an option. Differential privacy is an applied mechanism, without a guaranteed ε budget at this stage.
End-to-end encrypted transport (built)
Once each actor has trained the model on its own data, it shares only the learned parameters, never the data. That sharing is end-to-end encrypted: RSA-OAEP 2048 for the key exchange, AES-GCM 256 for the content, with a session key unique to each exchange. This is a real, working mechanism, not an intention.
A note on wording: this is transport encryption, not computation on encrypted data. Encryption protects the parameters while they travel; it is not the same as running a computation over data that stays encrypted end to end. We therefore never present Mesh as a "secure computation on encrypted data" solution.
What the coordinator does (and does not) see
The coordinator's role is to aggregate the actors' updates to build the shared model. What it receives are encrypted model updates, never raw data, which at no point leaves its holder.
The caveat: until secure aggregation is enabled (see below), the coordinator sees the individual updates once decrypted for aggregation. It does not see the data, but it does see each participant's contribution. Making the coordinator blind to those individual contributions (so it only accesses the sum) is precisely the point of secure aggregation, which is an option.
Robustness to malicious sources (option)
A legitimate question: what happens if a participant provides a poor-quality or even malicious contribution (poisoning)? The mechanisms that harden aggregation against this risk (robust aggregation, contribution bounds, secure aggregation, enclave execution) are offered as an option and are scoped per deployment: none of them is active in the demonstration engine.
What protects today, upstream, is consortium governance: you choose who you co-train with, you frame the common vocabulary, and you set the access rules. Technical robustness to poisoning will reinforce it.
Differential privacy
Differential privacy (DP) adds calibrated noise to reduce the risk of re-identification from the shared parameters. At Mesh, the mechanism follows the form of the reference algorithm of the field, clipping the norm of the update then adding Gaussian noise (M. Abadi et al., "Deep Learning with Differential Privacy", CCS 2016, pp. 308-318, arxiv.org/abs/1607.00133). But it is a noise mechanism, not a guarantee: no ε budget is computed or composed over the training rounds, and ε is precisely what formally bounds the leakage (C. Dwork, A. Roth, "The Algorithmic Foundations of Differential Privacy", Foundations and Trends in Theoretical Computer Science, vol. 9, no. 3-4, 2014, cis.upenn.edu/~aaroth/privacybook.html). DP is therefore a mitigation of the risk, not a figured guarantee.
FAQ: Security and source quality
Can the coordinator see my data?
No. Raw data never leaves its holder. The coordinator receives encrypted model updates. Until secure aggregation is enabled, it sees the individual updates once decrypted for aggregation, never the data itself.
What encryption is used?
Parameter transport is end-to-end encrypted: RSA-OAEP 2048 for the key exchange, AES-GCM 256 for the content, with a session key unique to each exchange. This is transport encryption, not computation on encrypted data.
How do you guard against a participant poisoning the model?
Today, through consortium governance (choice of participants, access rules, framing). The dedicated technical protections (robust aggregation, secure aggregation) are offered as an option and are scoped per deployment: none of them is active in the demonstration engine.
Is differential privacy guaranteed?
Differential privacy is applied as a mechanism to mitigate re-identification risk, but without a guaranteed ε budget at this stage: ε is set per deployment. We do not present it as an absolute guarantee.
Let's look at your threat model
Together we tell apart what is covered today from what is an option, depending on your use case and constraints.