PySyft 0.10: Remote Data Workflows and Governance

Read the architecture as a chain of decisions

A useful way to evaluate PySyft is to follow the data and the decisions separately. The data owner decides who may connect, which dataset is discoverable, what mock representation is available, which proposed computation may run, and which result may leave. The data scientist decides what question to ask and submits code rather than receiving a general-purpose copy of the table.

That is a different default from exporting a sensitive file and relying on every later recipient to protect it. It is also not a self-enforcing definition of “safe.” The owner still has to specify the policy, configure the environment, review the request, manage identities, and understand what the result can reveal.

The public workflow document describes seven stages: a peer request, owner approval, dataset publication, mock-data synchronization, local development, job submission, and owner review followed by execution and result retrieval. The sequence is the important control surface. A deployment that removes review or broadens output permissions may still use the same library while providing a materially different privacy boundary.

What the 0.10 package split means

The current repository README and changelog identify syft 0.10+ as the successor to syft-client. The new syft package is the sync engine; dataset and job operations are exposed through syft-rds. A data owner that needs the documented background services also installs syft-bg.

uv pip install "syft>=0.10.0" "syft-rds>=0.6.0"
# Data-owner background services are a separate package
uv pip install "syft-bg>=0.3.12"

The corresponding client construction is also explicit:

import syft as sy
from syft_rds import login_do, login_ds

do = login_do(email="[email protected]")
ds = login_ds(email="[email protected]")

That distinction prevents a common migration mistake: treating a bare sync manager as if it were the datasets-and-jobs client. The API reference says the remote data science client owns methods such as create_dataset and submit_python_job; the sync engine handles peers and file synchronization. The changelog also says the old environment-variable names have no fallback and that legacy PySyft 0.9 users should pin syft<0.10 if they depend on the earlier API.

Mock data is the researcher’s development surface

PySyft’s dataset documentation distinguishes a private asset from a mock asset. The mock representation is intended to preserve useful structure such as the schema and, depending on construction, value distributions, while replacing the original values. That makes it possible to test data types, joins, transformations, model interfaces, and output shape without handing over the source table.

The mock is not the scientific answer. A statistic calculated on mock values is a development check, not evidence about the private population. The approved code must run against the private asset, and the result must still pass the owner’s release policy.

“Mock” also is not a universal privacy guarantee. A synthetic representation may expose unusual categories, ranges, sparsity, schema details, or distributional information. The relationship between the mock and the private data determines what can be inferred. An owner should document how the mock was generated, which fields were retained, who can access it, and what a researcher may learn from repeated inspection.

The documentation describes a deployment distinction in which a lower-trust server holds mock data while a higher-trust server can hold the private asset. The operational rule is straightforward: sensitive data must not be uploaded to the lower-trust side. The label alone does not create isolation; the storage path, permissions, credentials, network exposure, logs, and administrative access must agree with the intended boundary.

Remote jobs still need code and output review

The current API exposes a concrete request path. A scientist submits a Python job to a data owner. The owner examines the request, approves or rejects it, and processes approved jobs. A result can then be shared back through the synchronization layer.

# Scientist: request execution
 ds.submit_python_job(
     user="[email protected]",
     code_path="analysis.py",
 )

# Owner: after review
do.jobs[0].approve()
do.process_approved_jobs(share_outputs_with_submitter=True)

The important question is not only “can this code read the dataset?” It is also “what can it cause to leave?” A job that prints rows, emits a unique identifier, counts a rare subgroup, stores values in an error, makes repeated adaptive queries, or writes to an uncontrolled side channel can defeat a narrow raw-data boundary. A job can be technically approved and still produce a result that the owner should not release.

Automation is a policy decision, not a security conclusion

The project documents background services for notifications and approval, including auto-approval objects that can match files by name and, in some cases, by content hash and peer. This can reduce review work for a narrowly defined class of repeatable jobs. It can also turn a mistaken rule into a repeatable release path.

A sensible automation boundary is specific: a known peer, an exact code artifact or tightly controlled set of files, a named dataset, bounded resources, and an output format that has already been assessed. Broad “approve anything from this user” rules are a governance choice with a very different risk profile. The data owner remains accountable for the rule, the version it matches, and the result that it permits.

Manual review is not automatically perfect either. Reviewers need enough context to understand the purpose of the work, the data’s sensitivity, the possible inference paths, and the output. A green approval status is an event in an audit trail, not a mathematical proof that disclosure is impossible.

Privacy-enhancing technologies address different threats

OpenMined’s public PySyft material names access control, federated learning, differential privacy, and zero-knowledge proofs among the privacy-enhancing technologies that can support the workflow. These should not be collapsed into one “privacy” feature.

• Access control answers who may request, execute, or receive an artifact. It does not by itself bound what an approved result reveals.
• Federated learning can avoid a single central training copy, but model updates, gradients, checkpoints, coordination traffic, and inference responses need their own analysis.
• Differential privacy provides a formal statistical guarantee only when the mechanism, neighboring-dataset definition, privacy budget, composition, and implementation are specified and evaluated. NIST’s guidance on evaluating differential-privacy guarantees is a useful independent reference for that work.
• Zero-knowledge proofs can prove a suitable statement without revealing a witness. They do not automatically authorize a researcher, inspect arbitrary code, filter outputs, or secure a compromised endpoint.
• Isolation can limit a job’s access to files and services. It remains an engineering boundary that needs configuration review, patching, monitoring, and adversarial tests.

Choose a mechanism from the threat model. Identify the protected asset, possible attacker, trusted parties, release channel, and acceptable loss before claiming that a PET solves the problem.

Current release and development signals

As checked on September 12, 2026, PyPI listed syft 0.10.0, uploaded August 26, 2026, and syft-rds 0.6.1, uploaded the same day. The repository tags endpoint included v0.10.0 at commit b9280077. The GitHub releases endpoint still showed v0.9.6b6 from April 2025 as its newest listed release, so a tag, a package publication, and a GitHub release page are not interchangeable signals.

The public dev branch was active on September 11, with recent commits updating ShieldGemma notebooks, output filtering, pinned notebook versions, and CI reporting. Those commits show ongoing work; they do not establish that every notebook, experiment, or branch feature is a stable supported behavior in the package a reader installs.

The public repository’s advisory endpoint returned an empty list at the time checked. That is not a security certification, a complete vulnerability assessment, or proof that a deployment is safe. It is only the result of that public endpoint at that time.

Independent historical corroboration is narrower than current product evidence. Budrionis, Miara, Miara, Wilk, and Bellika’s 2021 IEEE Access paper, “Benchmarking PySyft Federated Learning Framework on MIMIC-III Dataset,” documents a federated-learning evaluation. It is useful evidence that PySyft has been studied technically, but it is not a benchmark of the 0.10 package split, a production security review, or a performance promise for a present workload.

Privacy-preserving access is not anonymity

Keeping raw records with the data owner addresses a custody and access problem. It does not make the researcher anonymous, hide the owner, erase timestamps, or prevent inference from released outputs. Authentication, peer requests, code submissions, job histories, errors, result downloads, and collaboration records can all identify participants or reveal activity.

Confidentiality, integrity, accountability, anonymity, and differential privacy describe different properties. PySyft’s remote workflow primarily changes the path by which code reaches data and by which approved results return. It does not make these properties equivalent. A sequence of individually approved aggregates can still be differenced. A small group can be exposed by a combination of outputs. A model can memorize information. A log can retain a value that the result filter removed.

The accurate claim is therefore bounded: PySyft can support privacy-preserving access patterns in which raw data need not be copied to the data scientist. The deployment still needs an explicit threat model, output policy, identity and retention controls, and tests that verify the claimed boundary.

Limitations and governance boundaries

• Documentation is not a deployment audit. Public examples show an intended workflow; they do not inspect a particular host, identity provider, storage account, container, or network.
• Mock data is not automatically anonymous. Its disclosure properties depend on generation, metadata, rare values, distributions, and how closely it tracks the private asset.
• Approval does not equal safe release. Code and output review can be incomplete, especially when repeated queries, side channels, or hidden dependencies are possible.
• Automation increases the importance of rule design. Auto-approval should be narrow, content-aware, revocable, and recorded as a policy decision.
• PETs are not interchangeable. Access control, federated learning, differential privacy, proof systems, and isolation mitigate different failure modes.
• Version state changes. Pin the exact 0.10-era package set and retest migrations from the legacy API before relying on an example.
• Current activity is not maturity evidence. Commits, tags, downloads, stars, and claims on a project page do not establish adoption, support, benchmarks, or security assurance for a specific workload.
• This is not a security review. A real deployment needs technical testing, legal and regulatory analysis, operational ownership, and an incident plan appropriate to the data.

Bottom line

PySyft 0.10 is best evaluated as a remote data science workflow with explicit boundaries: the researcher explores a mock, the owner keeps control of the private asset, code arrives as a reviewable request, approved work runs near the data, and selected results return. The package split makes the implementation boundary more visible, but it also makes version pinning and API verification more important.

Use the workflow to reduce unnecessary raw-data movement, not to claim magic anonymity. Decide what the mock reveals, who may connect, which jobs may run, what outputs may leave, which PETs fit the threat model, and how policy changes are audited. The privacy result comes from the combination of software, configuration, people, and governance.