The sail-leakage package is local-only
The package reads the file (or DataFrame) you give it and returns a report. It makes no network requests, sends no telemetry, and has no server component — there is nothing in its dependency chain that talks to the network. Verifying this is as simple as reading its source; there are five detector modules and an orchestrator, nothing else.
The VS Code extension
The extension's setup wizard runs the installed sail-leakage package in
a local Python subprocess on your own machine, the same way the package itself works from a
terminal. The sidebar states this directly: "Runs on this computer. Your patient data is never
uploaded." That line isn't marketing copy sitting next to the mechanism — it describes what the
code actually does, which you can check in
the extension's source.
What isn't built yet: AI-assistant fix suggestions
A future feature (an MCP server offering LLM-assisted fix suggestions inside the editor) is fully designed but not implemented — no server, no AI-assistant-facing code, and no network path for your data exist anywhere in the codebase today, confirmed by direct search of the repository, not inferred from a roadmap. There is exactly one data-sharing mechanism in the design; the privacy line an assistant view would show is required to be generated from that same mechanism, not written next to it as separately-worded marketing copy. Its three tiers, reproduced directly from the source spec below:
| Tier | What may leave the machine | When |
|---|---|---|
| 1. Aggregate metadata | Counts, flags, verdicts, thresholds and other summary numbers | Default, always |
| 2. Code snippets | Code (for example a suggested fix) | Only after a separate, explicit opt-in, and only after the user has seen a pre-send preview of exactly what will be sent |
| 3. Raw data values | Nothing | Never. Not gated by a setting: there is no path that can carry a data value |
Tier 3 is enforced by construction, not by a switch that could be turned on: every
payload that can leave the machine is built from a closed schema with an allowlist, and the code that
reads the dataset has no route to the outbound path other than through that schema. Any cloud API key
the feature eventually uses would live in VS Code's SecretStorage (your OS keychain),
never in a settings file, and a local-model option (e.g. Ollama) would sit alongside the cloud option
so a network call is never required at all, for either tier 1 or tier 2.
HIPAA: architectural reasoning, not a compliance certification
Because tier 3 architecturally never transmits raw data values, and tier 2's code snippets require a separate opt-in plus a pre-send preview the user can review before anything leaves the machine, the LLM-suggestion feature — once built — is designed so that no patient data (PHI) is transmitted to any third party by default, and can only be sent at all in a form the user has explicitly reviewed first. That architecture is the reason a Business Associate Agreement (BAA) with an LLM provider would likely not be required for the default, tier-1 path: no PHI leaves the machine to begin with. This describes the architecture, not a legal compliance certification. I'm not a lawyer, and this isn't a substitute for your own institution's compliance review confirming this satisfies your specific HIPAA obligations before you rely on it — the same standard this project holds itself to in DATA_ACCESS.md for MIMIC-IV's own data-use terms.
Full technical detail, including the payload-schema and pre-send-preview requirements this summary doesn't try to fully reproduce: PHASE_5_DATA_SHARING.md.
This project's own data handling
The research behind SAIL was built on credentialed MIMIC-IV data under a PhysioNet Data Use Agreement, which restricts what can be published at row level. See DATA_ACCESS.md for exactly what that means and what this repository does and doesn't contain as a result.