How Snowfence stops data leaking through AI tools
Snowfence runs on every company laptop and in front of every server’s AI calls. It checks each prompt, upload and tool call (an action an AI model asks an agent to take) against rules the security team sets. Sensitive data is stopped before it leaves. Everything else passes untouched, so people keep using the AI tools they like.
What problem does Snowfence solve?
People at work use AI tools all day: chat apps such as ChatGPT, Claude and Gemini, coding assistants such as Cursor, Copilot and Claude Code, and agents that act on their own. Every one of these tools reads things (files, web pages, tool results, the clipboard) and sends things (prompts and uploads) to a cloud service. Those are the two steps of a data leak.
Agents don’t just suggest any more. They run commands, call tools and write scripts. A hidden instruction in a web page or a document, called a prompt injection, can steer them into sending data out.
Most security tools see one piece of this. A prompt scanner sees prompt text. A browser extension sees one browser. A network gateway sees destinations. None of them can say “this process read the customer list two minutes ago, and now it’s uploading to a site nobody has seen before.”
The core idea: a leak is a read, then a send
Snowfence watches both steps and connects them.
- Blocking the read is best. A protected file, such as a password store or SSH keys, stays closed to AI tools.
- If a read gets through, Snowfence remembers it. Whatever read sensitive data may only send it to places approved for that data afterwards.
- Every send is checked against what was read and where it’s going.
That link between what was read and what is sent is what separate tools miss.
Where Snowfence checks
Snowfence works at the points every AI tool has to pass through, so it doesn’t depend on other vendors’ plug-ins, which they can change or remove.
| Where | What Snowfence checks |
|---|---|
| The network | Where each request is going. For AI model services, it also reads the prompt and the model’s reply, decrypting them on the machine itself, so nothing is copied off it. A tool call is the model telling an agent to act, such as “upload this file”. One that would send data somewhere it isn’t allowed is cancelled before the agent sees it |
| The operating system | Its core, the kernel, which sees which files an AI tool opens and which programs it starts. On a managed laptop, one enrolled in the company’s device management (MDM), the operating system checks with Snowfence first, and Snowfence can say no |
| Tool connections (MCP) | The Model Context Protocol (MCP) is how AI tools call other tools, such as a ticket tracker or a database. Snowfence checks every call, and every response |
| The browser | Pastes and uploads into AI websites, through Snowfence’s own browser extension. The network checkpoint lets a browser reach AI sites only when the extension vouches for it, so a browser without it can’t reach them at all |
| Sign-in | At sign-in to a company AI service, the laptop proves Snowfence is running. A laptop where it has been switched off can’t sign in |
Rules your security team sets
The security team writes rules per team and per kind of data: what passes, what passes with an alert to the security team, what asks first (the person sees what is going where, and decides), and what never leaves. For example, everyday prompts and source code are allowed, keys and secrets ask first, and customer data may go only to the company’s own AI accounts.
An ask needs a person present. Snowfence counts one only when the AI tool runs under their own login at the screen, started from an app they use directly, such as a developer’s terminal. Scheduled jobs, build servers and remote logins count as nobody there, so an ask becomes a block.
The rules also list protected files, such as SSH keys or .env files that hold API keys. On top of that, Snowfence scans prompts and uploads for keys, card numbers and other patterns, so a key pasted into a prompt is caught even if no file was read.
Snowfence knows what data is by where it came from. Data from the CRM (the system that holds customer records) is labelled customer data, and the label follows it into every file written from it. Snowfence also knows which account is signed in to each AI service, so a rule can say “customer data may go to the company’s ChatGPT workspace, but not to a personal ChatGPT account.”
On servers
Servers, pipelines and cloud agents call AI models too. A server has no person at the keyboard and no device management, so Snowfence isn’t installed on each one. Instead, the company runs the Snowfence gateway in its own cloud or data centre, and services send their AI calls through it. The company’s firewall lets AI services be reached only from the gateway. The gateway applies the same rules and labels as on laptops. The rules say what data each service can read, such as “the ticket summariser reads the customer database”, so its calls carry that label. The gateway forwards or refuses each call.
A worked example: customer data
- A coding agent on a developer’s laptop reads a customer export from the CRM. The operating system checkpoint sees the read. Snowfence labels what it read as customer data, and remembers that this agent’s session holds it.
- The agent writes a summary to a new file. The label follows the data into that file.
- The agent tries to upload the summary to a personal ChatGPT account.
- The upload reaches the network checkpoint. Snowfence sees customer data going to an account the rules don’t approve for it, and blocks it.
- The agent gets an error that says why and names the approved route: the company’s ChatGPT workspace. The developer gets the same message as a notification.
- The security team sees the read, the new file and the refused upload as one story on a timeline, with the labels and times, not the content.
A second example: an API key
- A coding agent tries to open a
.envfile, which the rules list as protected. On a managed laptop, the operating system checks with Snowfence first, and the file stays closed. A protected file is closed to AI tools outright, so there is no ask. The agent gets an error with the reason, the developer gets the same message as a notification, and the refused read appears on the security team’s timeline. - On a laptop that isn’t managed, Snowfence sees the read but can’t refuse it. The agent copies a key from the file into a request to an AI service.
- The request reaches the network checkpoint. Snowfence scans its content and finds the key.
- Keys ask first. If the developer started the agent in their own terminal, they are present: they see where the key is going and the approved route, and decide. If the agent runs on its own, such as in a scheduled job, there is nobody to ask, so the request is blocked and the security team is told.
What people see
Snowfence only decides. Every check ends in one of four answers: allow, alert, ask or block. It never edits what people send.
- Allow: nothing happens. This is the answer for everyday work.
- Alert: the request goes through, and the security team is told.
- Ask: the person sees what is going where, why it matters, and the approved route. They can take that route, or send once with a reason.
- Block: a clear no, with a plain reason and an approved way to finish the job.
An agent gets the same reason as an error message, so a well-built agent can take the allowed route on its own. Cancelling an agent’s tool call is a decision too: the action is stopped, and nothing anyone wrote is changed.
Privacy nudges and verified calls
Two smaller features use the same checkpoints on the laptop, for meetings rather than AI tools.
Some mistakes aren’t anything a rule should block. Privacy nudges point them out, locally, with one click to fix them: a call that is still recording after most people left, or a notetaker the company doesn’t use joining a meeting. Snowfence never stops or deletes anything itself, and no audio, transcript or names leave the laptop.
Verified calls let a managed laptop prove to the other side of a call that only approved apps used its microphone, camera or screen during the call. The proof covers that laptop only, not phones or other devices.
What Snowfence can’t stop
Snowfence stops leaks that pass through its checkpoints. Some routes don’t, and it doesn’t claim to stop every attack.
- A photo of the screen, or a second device.
- Personal devices. Snowfence covers company laptops and servers only.
- File reads on a laptop that isn’t managed. Snowfence sees them but can’t refuse them. It still checks every send.
- File reads on servers. There, Snowfence checks AI calls at the gateway, not which files a service opens.
- An administrator on the laptop who switches it off. Snowfence can’t stop that, but it records it, and that laptop loses access to company AI services.
- Agents running in a vendor’s cloud. Snowfence controls who signs in to them, not what they do there.
The security page says what Snowfence keeps, and what it never sees.
Related
Updated