Is Your AI Keeping Your Secrets? How to Make Sure AI Tools Handle Your Data Securely

Prompts have quietly become one of the most revealing things we write. We paste in contracts to summarize, customer emails to rewrite, medical results to decode and half-finished business plans to stress-test. We tell an AI what we are worried about, what we are hiding from our boss and what our salary negotiation strategy is. Most of us would never put any of that in a public forum, yet we hand it to a chat window without thinking twice.

The problem is not that AI tools are inherently reckless. It is that the question of where your words go after you hit send is rarely visible in the product itself. Two assistants can look identical on screen and treat your data in completely different ways: one keeps your conversation on a server where staff and future models can read it, the other never sees it in readable form at all.

If you spend serious time on prompt engineering, knowing the difference is part of the craft. A great prompt that leaks your client’s data is not a great prompt. This guide walks through what actually happens to your inputs, the questions to ask any AI tool before trusting it, and the habits that keep you safer no matter which model you use.

What Actually Happens to a Prompt After You Hit Send

A prompt does not travel straight from your keyboard to a model and back. It passes through several layers, and each one is a place where your data can be stored, read or reused. Understanding those layers is the first step to judging whether a tool is behaving securely.

1. Transport. Your prompt is encrypted in transit to the provider’s servers, as with almost any modern web service. This protects you from eavesdroppers on public Wi‑Fi, but it says nothing about what happens once the data arrives.

2. Storage. Most assistants save your conversation history so you can return to it. The important question is how it is stored. If the provider holds the keys, the provider (and anyone who compromises it or compels it legally) can read your chats. If only you hold the keys, nobody else can.

3. Logging. Separate from your visible history, many services keep server-side logs for debugging, abuse monitoring and analytics. These logs are often retained for a period of time even if you delete a conversation.

4. Human review. Some providers allow employees or contractors to read a sample of conversations to improve quality or check for misuse. This is usually disclosed in a privacy policy, rarely in the interface.

5. Training. Unless you have opted out (or the provider never does it), your prompts may be used to train future models. Once that happens, there is no practical way to pull your data back out.

6. Third parties. Plugins, connectors and MCP servers, browsing features and analytics vendors can each receive a copy of some or all of your input.

The uncomfortable truth is that the default settings of many popular tools sit toward the permissive end of every one of these layers. That is not a scandal; it is a business choice. But it means that “secure” has to be something you verify, not something you assume.

Five Questions to Ask Before Trusting an AI Tool With Your Data

You do not need to read a forty-page privacy policy to make a sound decision. Five questions cover most of what matters, and the answers are usually findable in a few minutes.

1. Are my conversations used for training, and is that on by default? Look for an explicit statement, not a vague “we may use data to improve our services.” If training is on by default, find the opt-out and switch it off before you paste anything sensitive. Be aware that opting out of training does not always mean opting out of logging.

2. Who can read my chats on the provider’s side? The strongest answer is “nobody, because they are encrypted with keys we do not hold.” A weaker but acceptable answer is a clear policy on human review with a way to opt out. A red flag is silence.

3. How long is data retained, and does deletion actually delete? Some tools delete the visible conversation but keep a copy in logs for weeks or longer. Look for a stated retention window and for whether deletion applies to backups and logs, not just the interface.

4. Where is the data stored and under which laws? Jurisdiction matters. It determines who can compel the provider to hand over data and how much legal protection you have. Providers based in countries with strong privacy law and a track record of resisting over-broad requests give you an extra layer that no setting can replicate. The EU’s GDPR, for example, requires data protection by design and by default, which is a useful benchmark even if you are not in Europe.

5. Can I verify any of this? Marketing claims are cheap. Open-source client code, independent security audits and transparency reports let you (or people you trust) check that the product does what it says. A tool that invites scrutiny is behaving differently from one that asks for faith.

If a tool gives good answers to all five, you can be fairly relaxed about what you type into it. If it fails two or more, treat it like a public space: fine for brainstorming headlines, not for the quarterly board memo.

Prompting Habits That Keep Your Data Safer, Whatever the Tool

Even with a trustworthy assistant, how you write prompts changes your exposure. These habits cost almost nothing and remove most of the risk.

• Strip identifiers before you paste. Names, email addresses, account numbers and company names are rarely needed for the model to do good work. Replace them with placeholders (“Client A”, “[email]”) and swap the real values back in afterwards. The output quality is usually identical.

• Describe the shape, not the secret. If you want help structuring a sensitive document, give the model the structure and a sanitized sample rather than the whole file. “Here is a contract clause about termination; make it clearer” works without the actual party names and amounts.

• Separate the sensitive step. Use the AI for the parts that are not sensitive (outline, tone, formatting) and do the final merge with real data yourself, offline or in a tool you have vetted.

• Check what the tool can reach. Browsing, file uploads, code execution and connected apps each widen what the assistant can access. Turn off what you do not need for the task in front of you. Connected sources also open the door to indirect prompt injection, where text in a document or web page hijacks the model; OWASP’s Top 10 for LLM Applications ranks it the number-one risk, and our guide to prompt security covers how to defend against it.

• Audit your settings once a quarter. Defaults change. Training opt-outs get reset after updates. A five-minute review of your privacy settings a few times a year catches most of this.

• Treat shared and temporary chats as public. A shareable link to a conversation is, in effect, a published page. Assume anyone could end up with it.

None of this makes prompting harder. If anything, placeholders force you to think more clearly about what the model actually needs, which tends to produce better prompts. If you want to check that sanitized inputs are not costing you quality, a simple prompt lab lets you compare outputs with and without the real details.

What a Privacy-First Assistant Looks Like in Practice

It helps to have a concrete example of what good answers to those five questions look like, because the gap between “we take privacy seriously” and an actual architecture is wide.

One of the clearer examples right now is Lumo, the AI assistant from Proton, the Swiss company behind Proton Mail. Its privacy model is built around a few specific choices: stored chat history is protected with zero-access encryption, so only the account holder can decrypt it; the service runs a no-logs policy for prompts and replies; conversations are not used to train models; and the servers are controlled by Proton in Europe. There is also a “Ghost mode” that discards a conversation as soon as you close it, which is a useful default for one-off sensitive tasks. The client code is open source, which answers the “can I verify this?” question better than a policy page can.

It is worth being precise about what that does and does not mean. A model still has to read your prompt in plain text to answer it, so the protection is about what happens before and after processing: Proton describes prompts as encrypted in a way only its GPU servers can decrypt, and the stored history as unreadable to anyone but you. Nobody should treat any cloud assistant as a place for secrets that would be catastrophic if exposed, and Proton itself says as much. But as a baseline for everyday professional work, this is the kind of design the five questions are meant to surface.

Lumo is not the only route. Running an open-weight model locally with a tool like Ollama keeps data on your machine entirely, at the cost of convenience and capability. Enterprise tiers of mainstream assistants typically offer contractual no-training and retention terms that consumer plans do not. The right choice depends on how sensitive your work is and how much friction you will tolerate. The point is to choose deliberately, with the answers in front of you, rather than defaulting to whichever tab was already open.

The Short Version

Before you paste anything you would not want on a billboard into an AI assistant, run through this:

• Training on my conversations is off, or never happens

• The provider cannot read my stored chats, or has a clear human-review policy I have opted out of

• I know the retention window and that deletion covers logs

• I know which country’s law applies to my data

• The product’s claims are open to verification

• I have stripped names, numbers and identifiers from this prompt

• Only the connectors and features this task needs are switched on

Prompt engineering is about getting the most out of a model. Data hygiene is about making sure the model, and the company behind it, does not get the most out of you. Treating the two as part of the same skill is what separates a careful practitioner from a lucky one.