Security & data handling

Where it runs, what leaves, and what we cannot read.

Written so you can evaluate MemBridge without booking a call, and so you can forward this page to whoever has to sign off. Current, including what we do not have yet.

Where it runs

MemBridge is a daemon on each developer's machine. It binds to 127.0.0.1 and is not reachable from your network. The desktop app is an Electron window pointed at that local daemon, so the app and the CLI show you the same thing running in the same place.

  • Desktop app: macOS on Apple Silicon, and Windows.
  • CLI: macOS, Linux and Windows, on Node 18 or newer. Same daemon, same dashboard.
  • The Windows build is not code-signed yet, so Windows will show a SmartScreen prompt on first run. The macOS build is signed, notarized and stapled.

What it reads

The session transcripts your agents already write to disk, for the projects you have added. MemBridge does not instrument your editor, does not proxy your agent's traffic, and does not read your source tree looking for content to upload.

Secrets are stripped before anything is written to disk or sent to your team. That runs at every boundary, including on data arriving back from teammates, so a secret one person's redaction missed does not land on everyone else's machine.

What leaves the machine, and when

Nothing about your work leaves until you turn on team sync. That is a separate, deliberate step after install, not a default.

Once it is on, what syncs is what your sessions concluded: summaries, decisions and file paths. Not your source code. Two things are unrelated to your work content and happen regardless: anonymous usage counters tied to a random install id, which you can turn off with the diagnostics setting or MEMBRIDGE_NO_DIAGNOSTICS=1, and a check with GitHub about every six hours for a newer release.

What the server can and cannot read

Team sync stores data in Supabase, hosted Postgres that we operate, running in AWS us-west-2 (Oregon). Content is encrypted on your machine before it is sent, using libsodium.

  • Each summary is encrypted once with a random symmetric team key (crypto_secretbox).
  • That team key is distributed by sealing it to each member's public key (crypto_box_seal). Members unseal it locally with their private key.
  • The server never holds a key that can decrypt content. Neither can we as the operators.

What is deliberately not encrypted: routing metadata. Project, author, timestamp, tool and session id stay readable, because sync and access control cannot work without them. So the server can see that a person worked on a project at a time, using a tool. It cannot see what they concluded. "End to end encrypted" covers the content, not the fact that you were working.

People joining and leaving

Removing someone mints a new team encryption key, sealed only to the people who remain. They keep whatever they already decrypted locally, which is unavoidable for anything already delivered, but they cannot read anything shared after that point.

Access is per project. You choose which projects are shared with the team and which stay private to your machine, and the app shows the full grid of who can see what.

Who controls the sharing settings

Sharing settings are per-machine, and the person at that machine controls them. An administrator cannot enforce them org-wide today, and changing one is not recorded in the audit trail. The audit trail covers membership and invite events: join, invite, revoke invite, role change, member removal and team rename.

If central policy enforcement is a requirement where you work, tell us before you pilot.

Sharing your verbatim prompts defaults to on for fresh installs. It is deliberately not a global default: anyone who installed while it was off stays off, and their setting is never flipped for them by an upgrade. You can turn it off at any time in Settings.

Retention, export and deletion

Synced team data is retained indefinitely today, and there is no self-serve way to delete it from the backend or export it yourself.

membridge remove is a local operation. It strips the injected blocks, restores your files exactly, and deletes the local history on that machine. It does not reach the server. If you want your team's synced data removed, email [email protected] and we will do it by hand.

What we do not have yet

As things stand today:

  • No SOC 2 and no ISO 27001. We have not been audited.
  • No SSO and no SCIM. Team membership is invite-based today.
  • No formal support SLA. We are early and we answer email quickly.
  • The Windows desktop build is unsigned. Covered above.

If any of these is the thing standing between you and a pilot, tell us. Knowing which one blocks real teams is how we decide what to build next.

Reporting something

If you find a vulnerability, email [email protected] and we will respond. The source is available to read under the Functional Source License 1.1 (FSL-1.1-ALv2), so you can check any of this yourself.