Security-conscious engineers do not take privacy claims on faith. "Your data is safe with us" is a marketing statement. "Here is a network trace of the data we transmit, read it yourself" is an engineering argument.
This post makes the engineering argument for Spiderbrain’s privacy model.
What happens during a Spiderbrain analysis
When you open a project in Spiderbrain:
-
Local parsing: the Rust parser reads your source files on your machine. File content is read locally and never transmitted. The parser builds an AST (abstract syntax tree) from each file.
-
Graph construction: from the ASTs, Spiderbrain extracts import relationships, call relationships, and type relationships. The result is a graph: nodes (files) and edges (relationships). File content is not stored in the graph.
-
Source-free serialisation: the graph is serialised into the upload artifact. Each node is identified by a SHA-256 hash of its canonical path (not content). The artifact contains: node hashes, edge lists, directory structure hashes, and metadata (file extension, line count approximation).
-
Upload to the scoring engine: the source-free artifact is uploaded to the hosted scoring engine. The engine computes webscore, spikescore, blindspot score, and community memberships from the graph structure.
-
Scored brain returned: the scored graph (brain) is downloaded to your machine and stored locally (encrypted at rest, AES-256-GCM).
At no point in this process is file content transmitted.
What a network trace shows
If you run Wireshark or Charles Proxy during a Spiderbrain analysis session, you will see:
- DNS queries to the Spiderbrain API domain (expected)
- HTTPS POST to
/v1/score, the upload of the source-free artifact - HTTPS response with the scored brain
The POST body is the source-free graph. You can inspect it. The content you will find:
- Arrays of SHA-256 hashes (node identifiers)
- Edge lists (pairs of hashes with edge type labels)
- Graph metadata (community count, total node count)
- No file names (hashes only by default)
- No file content (the parser discards content before serialisation)
The response you will find:
- Score arrays (one entry per node hash)
- Community assignments (hash → community ID)
- Insight metadata
The hash-only mode
By default, node hashes are computed from the canonical path of the file. This means path information is derivable from the hash only through a rainbow table attack against known path patterns, which is feasible for very predictable paths (e.g., node_modules/react/index.js) but not for internal paths with unpredictable naming conventions.
For teams with stricter requirements, Spiderbrain supports content-only hashing: the node hash is computed from the file content, not the path. In this mode, the scoring engine has no information about file paths at all. Structural queries that return node identifiers return content hashes, which are meaningless without the local source.
The compliance argument
For teams in regulated industries, the network trace argument is the one that matters for compliance review:
- What is transmitted: a source-free structural artifact (hashes + edge lists)
- What is not transmitted: file names, file content, variable names, function names, string literals, comments
- Where it is stored: the scored brain is stored on the Spiderbrain servers (EU region by default) as a source-free artifact
- Who can read it: only your account, via authenticated API calls
The compliance question is typically: "does this tool transmit our intellectual property to a third party?" The network trace answers this directly. The artifact transmitted contains no source code, no file content, and (in content-hash mode) no file names. The intellectual property, the actual code, never leaves your machine.
What this costs you
The source-free model trades semantic richness for privacy. The scoring engine can compute structural scores from the graph topology, but it cannot extract semantic meaning from code content. Insight descriptions are derived from structural patterns, not from reading the code.
For structural use cases, blast radius, community detection, keystone identification, context selection, the source-free model is complete. These capabilities depend on graph topology, not code content.
For semantic use cases, intent extraction, documentation generation, code explanation, source-free analysis requires a local pass. The MCP tools surface structural intelligence from the cloud brain; semantic intelligence is computed locally, on the source your machine holds.
This division is the right architecture for teams where source code is a controlled asset: structural intelligence at cloud scale, semantic intelligence on-premise.
