26 Keeping data secure from the cloud
Any prompt you send to an LLM provider goes to that company’s servers. So it’s worth being deliberate about what you include in your prompts — the data you send is covered by that provider’s privacy policy, not yours. Some subscription products (e.g. an institutional Copilot licence) claim to keep your data private; public consumer products tend to retain the right to use whatever you type as a prompt. If you put your best research ideas into a public chatbot, it’s plausible those ideas resurface, in some form, to a different user asking something similar later.
We explore data privacy risks in more detail in an upcoming study. My collaborator, James Smith, has developed an R package confideR, which you can run to audit potential data privacy risks in your current R session.
Before using an LLM on data you didn’t collect entirely yourself, check the IP and ethical constraints that apply — human survey data in particular may come with restrictions on sending it to a foreign server, or on revealing any of it to a third party at all, LLM or otherwise.
If your data is sensitive, you have a few real options.
26.1 Option 1: A locally hosted LLM
Run a model on your own computer instead of calling out to a provider. Section 8 walks through the setup — installing Ollama, choosing a model, and the hardware you’ll need. Locally hosted models are fine for simpler tasks if you have reasonably capable hardware (a decent GPU helps a lot); they won’t match the top hosted models on harder tasks, and can be slower to respond.
26.2 Option 2: Keep data separate from code development
Use the LLM to help write the code that analyses your data, but never give it the data or the results. I’d recommend keeping sensitive data in a directory entirely outside your project folder, so an agent can’t stumble into it by accident — and double-check the agent isn’t feeding its own analysis output back into a prompt, which would leak the same information a different way.
It helps to generate simulated data with the same structure as your real data to use for code development — you get a working pipeline with zero privacy risk, and (as a bonus) a built-in verification step, which we’ll come back to properly in Section 6. There’s an R package called fakedataR aimed at exactly this kind of synthetic-data generation for privacy purposes — I haven’t put it through its paces yet, so treat that as a pointer to investigate rather than a recommendation, and check its current state before relying on it.
26.3 Option 3: Ignore sensitive folders
Some agents can be told to ignore specific folders — for example, a repository-level custom instruction to GitHub Copilot, or Cline’s .clineignore file.
Remember prompts aren’t 100% precise the way code is — there’s still a chance the agent wanders in anyway. If something is genuinely sensitive, keep it elsewhere on your computer entirely, and check every action before approving it.
26.4 Option 4: A no-data-retention provider
OpenRouter has a “no data retention” toggle in your profile, which filters the providers it routes to down to ones with a no-retention policy. Worth checking whether your provider of choice offers something equivalent.
For a hypothetical version of the topa/coral-cover project where the GPS coordinates (coordx, coordy) had to stay confidential (e.g. to protect an endangered species location), pick which of the four options above you’d use, and explain what you’d tell an agent’s README to keep it from ever seeing those two columns.