Privacy
Where your
code actually goes.
Blacksite reads your code and sends parts of it to a language model provider you choose. That is the entire point of it. Here is the exact shape of that, so you can decide before you install rather than after.
At a glance
| Where it goes | What |
|---|---|
| Your model provider Anthropic, OpenAI, OpenRouter, or AWS Bedrock — whichever you configured |
Your messages and conversation history. Files, selections, diagnostics, terminal output, and workspace context relevant to your request. Whatever a tool call retrieves. Your enabled Base Context topics, on every request. |
Your machine.blacksite/ in your workspace |
The codebase index and map, plans, tickets, base context, map notes, agent memory, execution logs, attached reference files, and the embedded database and vector store. |
| Your OS keychain VS Code SecretStorage |
Your API keys. Never written to settings files, to your workspace, or to any log. |
| Us | Nothing. There is no Blacksite server and no telemetry. |
No server in the path
Blacksite is bring-your-own-key. Requests go directly from your machine to your provider's API using your credentials. Your code is not proxied through, logged by, or visible to any infrastructure operated by Blacksite, because no such infrastructure exists.
No telemetry
No usage analytics, no crash reports, no metrics — not even anonymized ones. The only network requests Blacksite initiates on its own are model-catalog lookups to your configured provider and the update check below.
Update checks
On startup, Blacksite checks whether a newer GitHub release exists. That request carries no identifying information beyond what any HTTP client sends. Disable it with blacksite.updates.checkOnStartup.
The part you have to check yourself
Your provider's
policies are the policy.
This is the most important sentence on the page, and it is the one Blacksite has no control over.
Whatever data-retention and model-training policies your provider applies to API traffic are the policies that govern your code. Blacksite cannot change them and does not try to.
They differ meaningfully between providers, and between consumer and enterprise tiers of the same provider. If you are working under a confidentiality obligation, read your provider's terms and configure your account accordingly — that is the layer where those controls exist.
Related: do not point an agent at a workspace holding live production credentials. An agent with your cloud CLI profile is an agent with your cloud account. Approvals & Safety covers the deny lists that make that concrete.
What the agent can reach
The agent can read and edit files, run shell commands, drive a browser, query your language servers, and call MCP servers you configure. Two gates stand in the way of all of it:
- Every file edit is shown as a diff before it touches disk.
- Every file-write, network, or destructive command raises a modal prompt naming the tool and the exact operation.
Beyond those, three settings control what is even possible: an allowlist, a deny list that overrides everything, and an auto-approve list. Tool families can be disabled entirely — a disabled family is not advertised to the model at all.
Shell execution and browser automation are genuinely powerful. Treat granting them the way you would treat running an unfamiliar script — which is one more reason the source is public and readable.
Verifying any of this
Don't take it
on faith.
The full source is available and the shipped bundle is not obfuscated. Every network call the extension makes is in there to read — which is the whole reason it is published.
Questions about data handling for a commercial deployment: mgriffith@blacksite-agent.com