What Actually Leaves Your Machine

There is a lot of vague fear about AI assistants and privacy, and most of it misses the point. The assistant is not rummaging through your hard drive. It is receiving exactly what you — or your editor integration — hand it. The problem is that developers hand it far more than they realise.

A typical AI-assisted session sends: the code you selected or pasted, the surrounding files the tool reads for context, your prompt (including the question you typed and any error message you included), and metadata like file paths and project names that help the model give a relevant answer. Error messages are a sneaky one: a stack trace can contain internal hostnames, database table names, user IDs, and request details you would never deliberately share.

Whether the vendor keeps that data, and whether it is used to train future models, depends on the vendor, the plan, and the settings — and those change. The only safe posture is to behave as if anything you send could be stored, and to check the current terms and retention settings for the exact tool you use, rather than trusting a blog post (including this one) about what some tool does.

The Real Danger Is Not Your Code

Most source code is not worth stealing, and most developers know it. The dangerous leak is the secret sitting next to the code. It happens like this: you are debugging a failing API call, you paste the function, and the function contains a hardcoded key. Or you paste your configuration file to ask why the connection fails, and the file contains a database password. Or you paste a log that includes an authentication token.

Consider the difference between these two versions of the same code:

# Never paste this version anywhere outside your own machine:
API_KEY = "sk-live-9f2a7b4c1d8e6f0a3b5c7d9e1f2a4b" # Paste this version instead:
import os
API_KEY = os.environ["MY_SERVICE_API_KEY"]

The second version asks the same debugging question and leaks nothing. That is the whole discipline: make your code safe to share before you share it, not after. If a secret has already been pasted, treat it as compromised. Revoke it, rotate it, and check the provider logs for unfamiliar use. Deleting the conversation does not un-send the data.

The Fix: A Checklist You Can Use Today

  • Secrets live in environment variables, never in code. No keys, tokens, passwords, or private keys in source files, config files, screenshots, or prompts. If a value looks like a secret, it is one.
  • Redact before you prompt. Before pasting, replace real hostnames, user IDs, customer data, and internal URLs with placeholders. Ask about the logic, not the production data.
  • Trim the context. If your tool lets you limit which files it reads, limit them. The assistant does not need your whole repository to fix one function.
  • Check retention and training settings. Open the vendor settings for the tool you actually use and confirm whether prompts are retained and whether they are used for training. If there is an opt-out, decide deliberately instead of leaving the default.
  • Review every diff before you commit. AI suggestions can reintroduce a hardcoded secret, add a dependency you did not vet, or quietly change behaviour. The diff is your last checkpoint — read it like you wrote it, because you are shipping it.
  • Scan before you push. Add a secret scanner to your pre-commit checks so a mistake gets caught on your machine instead of in a public repository or a shared snippet.

Browser-Run Code Is Not the Same as Cloud AI

This distinction matters, and it is worth stating carefully. When code runs in your browser tab, the computation happens on your machine — running it does not by itself send your code anywhere. That is genuinely useful for quick experiments and for checking a snippet before you share it.

But it is not a privacy guarantee for the whole product. The moment you click an AI assistant feature, use a cloud execution service, or share a link, something leaves your machine — a prompt, a snippet, or both. So do not let a true statement (“this runs in my browser”) become a false one (“therefore nothing here ever leaves my machine”). Check the terms for each feature you use, and treat AI features as cloud features unless the vendor clearly says otherwise for that feature.

If You Suspect a Leak, Act in the First Hour

Speed matters more than certainty here. First, revoke and rotate the secret — do not wait to confirm whether someone used it, because by the time you confirm, the damage is done. Second, search your repository history and your provider's usage logs for unfamiliar calls or unexpected access. Third, tell your team: a quietly rotated key that nobody knows about will break someone else's local setup, and a teammate who does not know about the incident may paste the same secret again tomorrow. Write down what leaked, where it went, and what you changed, while the details are fresh. That short note is what turns one person's mistake into a team's lesson.

Make It a Team Rule, Not a Personal Habit

Individual discipline fails under deadline pressure. The teams that avoid leaks make it structural: secrets are impossible to commit because the scanner blocks them, example configs contain placeholders instead of real values, and onboarding includes a five-minute “what never to paste” briefing. New hires copy what the codebase does, so make the codebase do the safe thing by default.

A good test: take any snippet your team shared this week — in chat, in a ticket, in an AI prompt — and ask whether it would be safe if it were public tomorrow. If the answer is no, the snippet was never the problem. The workflow was.

Try the discipline on a real snippet: paste a redacted function into CoderFile's browser editor, run it, fix it, and then share it only after you have checked the diff for secrets. The habit takes a week to build and saves the incident you never have to explain.