Is it actually safe to tell an AI chatbot personal things?

"Safe" is not answerable; "safe from whom" is. Ranked by how likely they are to matter: someone with access to your unlocked device or account, your employer if you are on a work account, the provider's own routine processing (training defaults, safety classifiers, human review, memory features), third-party analytics embedded in the chatbot's website, a breach, and legal process. Most everyday questions are fine once the account is configured; identifiable details about other people, credentials and full identifiers are not.

Can my AI chats be used against me in court?

Yes. Chat logs have been preserved, produced and treated as evidence. In the NYT–OpenAI litigation, Judge Sidney Stein affirmed an order on 5 January 2026 compelling production of a 20 million-conversation sample of consumer ChatGPT chats from December 2022 to November 2024, and affected users were never notified. Talking to a chatbot also creates no privilege: in United States v. Heppner (S.D.N.Y., 10 February 2026), Judge Rakoff held that a defendant's AI-generated defence documents were never protected in the first place, because Claude is not an attorney and the consumer terms defeated any reasonable expectation of confidentiality.

Will the AI leak my secret to another user?

This is the fear most people have and the least likely path. Models do memorise training data and it can be extracted — Nasr, Carlini and colleagues demonstrated it against production systems in 2023 — but your chat would have to be eligible for training, survive into a corpus, be trained into a model deployed months later, and then be surfaced by an undirected attack that cannot ask for you specifically. Meanwhile an unlocked laptop, an employer's admin console or a misconfigured database exposes conversations today, in full, on demand.

Does deleting the conversation or using temporary mode fix it?

Partly. Both are genuinely good against the most likely threat — someone reading your sidebar. Neither prevents the request reaching the provider, and deletion is a content operation: billing and usage records, safety classification scores and anything under a legal hold run on separate clocks, and a preservation order overrides the delete button entirely.

What is the single most effective thing I can do?

Ask the general version of your question. Keep the specifics that shape the answer — jurisdiction, dates, sequence, amounts, exact wording — and drop the ones that identify a person: names, employers, addresses, account numbers, and source files whose properties still carry an author. It costs nothing, needs no product, works against every threat on the list, and keeps working when a setting, a vendor or a court does not go your way.

Should You Tell an AI Your Secrets?

Published August 15, 2026 · Facts last verified August 15, 2026

This article is general information, not legal advice. For advice about your own situation, consult a qualified lawyer in your jurisdiction.

The question in the title usually gets one of two answers, and both are useless.

The first is never tell it anything. It is easy to say, impossible to follow, and quietly self-defeating: the whole value of these tools is that they answer your question rather than a generic one. Advice nobody can follow is not caution — it is a way of feeling careful while changing nothing.

The second is relax, it's encrypted. This one is worse, because it is confident and wrong. Transport encryption protects your message from strangers on the network. It has never protected it from the company at the other end, from a court, or from whoever else is signed into your laptop.

People who work in security do not answer questions like this with a yes or a no. They build a threat model: what am I protecting, who could realistically get at it, how likely is that, and how bad is it if they do. Then each precaution is judged on which specific row of that list it covers. This is not a mindset reserved for experts. It is just the difference between "is this safe?", which is unanswerable, and "safe from whom?", which is not.

So let us actually build one.

First, This Is Not a Hypothetical Habit

Whatever anyone thinks people should disclose, the measured reality is that they already disclose a great deal.

In a KFF tracking poll fielded 24 February – 2 March 2026 among 1,343 US adults, 32% said they had turned to an AI chatbot for physical or mental health advice in the past year. Of those, 41% had uploaded personal medical information — test results, doctors' notes — to get a personalised explanation. That works out to 13% of all adults, rising to roughly 19% among 18–29 year-olds. In the same poll, 77% of adults said they were concerned about the privacy of medical information given to AI tools, including 65% of the people who had uploaded some. Concern and disclosure are not in conflict; they coexist comfortably in the same person on the same evening.

Money looks similar. In a Harris Poll survey for NerdWallet (2,003 US adults, fielded 23–24 June 2026, published 22 July 2026), 26% of Americans had asked an AI chatbot personal finance questions. Among those who had, 77% shared some form of personal information: 15% uploaded bank or credit card statements, 14% health insurance documentation, 10% account numbers, and 9% typed in their Social Security number.

Sit with that last figure, because it is the clearest evidence that a blanket "don't" is not working. Nobody believes pasting an SSN into a chatbot is prudent. Roughly one in eleven of those users did it anyway — not out of recklessness, but because in the moment the tool felt like a calculator, and a calculator is not a party you disclose to. That instinct is the actual problem, and a rule cannot fix an instinct. A picture of who is on the other side can.

The Four Questions

The Electronic Frontier Foundation's Surveillance Self-Defense guide frames security planning as six questions: what do I want to protect, who do I want to protect it from, how bad are the consequences if I fail, how likely is it that I will need to protect it, how much trouble am I willing to go through, and who are my allies. Four of them do the heavy lifting here:

What am I protecting? Not "my privacy" in the abstract — the specific fact. A diagnosis. A salary. An immigration status. A plan to leave. Somebody else's name.
From whom? A named party with a reason to care. "Everyone" is not an adversary; it is an anxiety.
How likely is it that they get it? Not "is it possible" — everything is possible. By what route, step by step, does it actually reach them?
What happens if it does? Embarrassment, a lost job, a custody outcome, a deportation, physical danger. These are not the same thing and should not attract the same caution.

Almost every bad decision about AI and secrets comes from skipping question two and answering question three with a feeling.

The Adversary List, Ranked by How Likely It Is to Matter

Here is the honest ordering, most likely first. Notice that it runs roughly opposite to the order in which these things get discussed.

1. Someone Who Can Reach Your Screen or Your Account

By a wide margin, the most probable reader of your AI chats is a person you know: a partner, a flatmate, an adult child, a colleague who borrows your laptop, anyone passing a device you left unlocked.

The reason is structural. Nearly every mainstream chatbot keeps a permanent, titled sidebar of everything you have ever asked, restored automatically on any device where you are signed in — and those auto-generated titles are miniature summaries. A year of them is a table of contents for your private life. There is no lock on the sidebar, no separate password, and usually no prompt to re-authenticate.

This threat needs no attacker, no vulnerability and no court. It needs an unlocked screen. It is also the one people mention least, because it is not futuristic — and it is the one most likely to actually happen to you this year. The mechanics of shared and work machines are covered in using AI on a shared or work computer.

2. Your Employer, If You Are on a Work Account

Second most likely, and second most underrated. A work-provisioned AI account is not your account. The business and enterprise tiers of the major products exist precisely so an organisation can administer them: user management, retention settings, audit and compliance export. That is not a scandal — it is what a company is paying for, and what its own regulators expect it to have.

The practical consequence is simple. Treat anything typed into an employer's AI account as sitting in a system your employer administers, on exactly the same footing as your work email. A resignation letter, a grievance, a health issue you have not disclosed, a job search — those are the classic mistakes, and they get their own article in why you shouldn't draft resignation letters in your work ChatGPT.

3. The Provider's Own Routine Processing

Third: nothing goes wrong at all, and your conversation is simply handled the way the product is built to handle it.

That covers training on consumer conversations where it is the default and you have not changed it (the per-provider opt-out settings are here); automated safety classifiers scoring every input and output, with flagged material kept on a far longer clock than the chat itself; human review of flagged or sampled conversations; and memory features that lift facts out of one conversation and carry them into every future one, which is a different and more durable kind of storage than a chat log — see what AI memory features actually remember.

The likelihood here is not a risk estimate. It is 100%, by design, on whatever settings you are using right now. The only open question is what those settings are — which is why the settings checklist is the highest-yield twenty minutes available on this subject.

4. The Analytics and Advertising Vendors You Never Chose

Fourth, and genuinely surprising to most people: the model is not the only thing receiving data when you use a chatbot's website.

On 4 May 2026, researchers at the IMDEA Networks Institute published LeakyLM, an audit of the web interfaces of ChatGPT, Claude, Grok and Perplexity. They found more than a dozen third-party trackers embedded across the four, and the findings are specific. ChatGPT's web app transmitted conversation URLs and page titles — which typically reflect the subject of the chat — to Google Analytics. Perplexity sent conversation URLs and the user's email address to the analytics service Datadog. Claude forwarded email addresses, an account identifier and conversation URLs to a set of server-side trackers. Grok was the worst case, sending conversation URLs and page titles to Google, DoubleClick, Meta and TikTok, with verbatim message text exposed through Open Graph metadata collected by TikTok. The researchers also noted that these conversation permalinks carry weak access control, so possession of a URL can be enough to reach the content. Perplexity discontinued its Meta Pixel on 3 April 2026; the broader pattern was still live at publication, and none of it is disclosed anywhere a user would see it.

The point is not that any one of these companies is villainous. It is that "the provider" is never a single party. It is the provider plus its analytics stack, its support tooling, its error monitoring and its marketing tags — and nothing in the interface tells you they are there.

5. A Breach — Theirs, or a Vendor's

Fifth: someone gets in, or the door was never shut in the first place.

The freshest example is not a sophisticated attack. In early 2026 an independent researcher found that Chat & Ask AI, a consumer AI app with more than 50 million downloads, had left its Firebase backend with security rules set to public — anyone holding the project URL could read the data without authenticating at all. The exposure covered roughly 300 million messages belonging to about 25 million users: complete chat histories, the models used, timestamps and settings. Codeway, the developer, fixed it across its apps within hours of responsible disclosure, which is the right response. The detail worth keeping is the researcher's follow-up — scanning 200 iOS apps with the same technique, 103 of them had comparable Firebase misconfigurations. This is not a rare failure mode. It is close to the default failure mode of a mobile backend built in a hurry.

The larger providers have had their own incidents, including one that arrived through an analytics vendor rather than the front door. We catalogued them — the 2023 ChatGPT caching bug, DeepSeek's unauthenticated database, Muah.ai's 1.9 million emails joined to intimate prompts, and OpenAI's Mixpanel supply-chain exposure — in what happens to your chats in a provider data breach. One pattern runs through all of them, and it is the most useful thing on this page to internalise: the damage was never the text alone. It was the join between the text and a name.

6. Legal Process

Sixth: a court, a regulator or an opposing party asks, and the provider complies because it has to.

Two documented realities matter here. The first is that you can be swept in without being party to anything. In the copyright litigation between The New York Times and OpenAI, a preservation order froze output log data that would otherwise have been deleted, and on 5 January 2026 Judge Sidney Stein of the Southern District of New York affirmed the order compelling production of a 20 million-conversation sample to the plaintiffs' legal team. By OpenAI's account, that sample was a random draw of consumer ChatGPT conversations from December 2022 to November 2024. Inclusion turned on your conversation having been retained and falling inside that dataset and date range — not on who you are, what you asked, or anything you did. Affected users were not notified and had no opportunity to object. The safeguards relied on were sampling, de-identification and a protective order.

The second is that talking to a chatbot about a legal problem creates no legal protection. In United States v. Heppner (S.D.N.Y., 10 February 2026), Judge Jed Rakoff held that a defendant's roughly 31 AI-generated defence-strategy documents were not protected in the first place — Claude is not an attorney, and the consumer terms defeated any reasonable expectation of confidentiality. Read the shape of that holding precisely: protection never attached, which is a different and worse thing than protection being waived. Several civil courts have since shielded a litigant's AI queries as work product, a separate doctrine with separate rules, and one New York court quashed a subpoena served directly on OpenAI for a party's entire account. No appellate court has ruled. The whole line of cases is unpacked in your AI chats can be subpoenaed and AI and attorney-client privilege.

Likelihood for most people in any given year: low. Consequence when it lands: among the highest on this list, and entirely outside your control once it starts.

7. A State Actor Specifically Interested in You

Last, and honestly: if a well-resourced government is targeting you by name, your choice of chatbot is not your primary problem, and no consumer product — ours included — should be sold to you as the answer. That threat model needs operational security advice from people who specialise in it, and it usually starts with the device rather than the service. Most readers are not in this tier, and pretending otherwise is how privacy writing turns into theatre.

And the One Everybody Actually Worries About

Absent from the ranked list, deliberately: the model will remember my secret and tell somebody else.

The underlying phenomenon is real. Language models do memorise fragments of their training data, and it can be pulled back out — Nasr, Carlini and colleagues demonstrated exactly that against production systems including ChatGPT in "Scalable Extraction of Training Data from (Production) Language Models" (arXiv, November 2023; published at ICLR 2025), using a divergence attack that raised the rate of emitted training data roughly 150-fold.

But look at what that path requires before it reaches you. Your conversation has to be eligible for training under your tier and settings; it has to survive filtering and de-duplication into a corpus; a model has to be trained on that corpus and deployed months later; and then somebody has to run an undirected extraction attack and happen to surface your fragment — with no way to ask for yours. Compare that with your brother-in-law opening your laptop, or a database with public read rules.

That is the inversion worth taking away. The frightening path is slow, indirect and undirected. The paths that actually expose people are boring, fast and specific. Most people's worry is pointed at the wrong end of the list.

The Second Axis: What It Costs If It Fails

Likelihood is only half of a threat model, and it is the half that gets all the attention. Some disclosures are unlikely to be exposed and catastrophic if they are, which changes the calculation completely.

Three categories deserve separate treatment however improbable exposure seems:

Irreversible facts about you. A password can be rotated and a card reissued. A diagnosis, a sexuality, an immigration status, an addiction, a psychiatric history — none of these can be un-disclosed. Anything in this class should be judged on consequence alone, because likelihood cannot be driven to zero.
Secrets that are not yours. Your client's name, your patient's file, your friend's confession, your employer's unreleased numbers. Here you are not accepting a risk — you are assigning one to somebody who never agreed to it. Professional duties of confidence have no "but it was only an AI" exception, and neither does a friendship.
Situations where asking is itself the evidence. Sometimes the content is unremarkable and the fact of the question is the entire exposure: researching divorce lawyers, drafting a whistleblower complaint, pricing a competitor, planning to leave a controlling partner. In these cases a stored, identity-linked record is damaging even if nobody reads a word of it, because the timestamps and titles are enough on their own. That is the subject of the metadata problem.

Four Questions to Run Before You Press Enter

Compressed into something usable in the five seconds you actually have:

Whose secret is this? If the answer is "somebody else's", stop and strip it. This is the one with a victim other than you.
Who could ask for this record — and would they get it? Not would they bother. Could they obtain it: an employer through an admin console, a party through discovery, a stranger through a breach.
If this appeared next to my name, what breaks? Mild embarrassment and losing custody of a child are both "privacy". Treat them differently.
Does the answer I need actually require the identifying details? This is the question that resolves most cases, and almost nobody asks it.

The Technique That Does the Most Work: Ask the General Version

Most sensitive prompts are two things fused together — a genuine question, and a pile of identifying detail that is doing no work at all in the answer.

"My employer, a 40-person logistics firm in Rotterdam, put me on a performance plan two weeks after I told my manager Erik about my MS diagnosis — I'm Jan Visser, here's the email chain" contains one question and a complete identification of at least three people. The model needs the jurisdiction, the sequence of events and the timing. It does not need the names, the company, the city or the email headers. Remove them and the answer comes back the same.

This is not a trade-off between privacy and usefulness. Specificity that matters — jurisdiction, dates, order of events, the exact wording of a clause, dosages, amounts — should stay. Specificity that identifies — names, employers, addresses, account numbers, case numbers, and the raw file with its author fields intact — is what you drop. The habit takes about a week to build and covers more of the list above than any product setting does.

Two practical notes. Pasting a document defeats it: a redacted-looking PDF can still carry the client's name in its properties, so a screenshot or plain text beats the source file. And if you use an anonymising service, this part remains your job rather than the service's — no gateway can know that "Erik" is a real person.

What Each Defence Actually Buys You

The payoff of a threat model is that you stop asking whether a precaution is "good" and start asking which rows it covers. Nearly every popular defence covers one or two of them and does nothing whatsoever about the rest.

Temporary or incognito chat mode — covers row 1, the sidebar, and covers it well. It does not stop the request reaching the provider, and retention in these modes is not zero; see what incognito mode really does and the temporary-chat fine print.
Deleting the conversation — covers row 1, and part of row 5 going forward. It is a content operation: billing records, usage aggregates, safety classification scores and anything under legal hold run on their own clocks, and a preservation order overrides the delete button outright.
Turning off training — covers exactly one part of row 3. No effect on retention, on breaches, or on legal process. Necessary, nowhere near sufficient.
A VPN — covers your IP address and your network operator's view. It does nothing at all once you are signed into an account, which is the anchor that matters; the full accounting is here.
Paying with your own card — actively works against you, by binding a legal name and billing address to everything else. Rarely thought of as a privacy decision. It is one of the biggest.
Running a local model — covers rows 3 through 6 completely, because nothing leaves the machine. The cost is capability and speed, and row 1 gets slightly worse, since the transcripts now sit on your device. Honest measurements in local LLMs versus a private gateway.
An anonymising gateway — covers the link between you and the query across rows 3 to 6, and removes row 4 by construction, since you never load the provider's tracker-laden web app. It does not cover row 1, does not cover row 2 on a machine your employer controls, and does not touch the words you typed.
Not typing the identifying details — covers every row on the list, costs nothing, requires no product, and is the only defence that still works when everything else fails.

So: Should You Tell an AI Your Secrets?

With the model above in hand, the answer splits into three groups, and only one of them is a "no".

Tell it — most things, without agonising. Symptom questions, contract clauses, money worries, awkward emails, the thing you are too embarrassed to ask a professional. Privacy theatre that costs you a good answer to a real problem is a bad trade, and the realistic alternative is usually not "ask a lawyer" but "guess". Configure the account once — training off, memory reviewed, history off if you share a device — and then use the tool.

Tell it, but strip the anchor. Health, money, legal, career, family. Ask the general version: keep the details that shape the answer, drop the details that name a person. Keep this class off a work account, off shared devices, and away from a payment identity where you can.

Do not put it into any cloud chatbot, on any tier, in any mode. A short list, and short on purpose: credentials, keys and full identifiers such as Social Security or passport numbers, which have no upside in a prompt at all; identifiable information about other people who did not consent — clients, patients, sources, colleagues; material you are under a duty or a legal hold to preserve or not disclose; and anything you could not survive seeing surface verbatim, with your name attached, in a court exhibit or a news story. That last test sounds dramatic. It is precisely the test that twenty million sampled ChatGPT conversations never gave their users the chance to apply.

How Secret Chat AI Fits — and What It Does Not Fix

Secret Chat AI is built for one specific part of this model, and it would be dishonest to imply it covers the rest.

What it does. Secret Chat AI removes you from your queries — it does not remove the data from your messages. Your prompt reaches the model through our gateway under our credentials, from our servers: no IP address of yours, no browser fingerprint, no account of yours, no payment identity. We build no profile of you, and no conversation is ever associated with you. Registration takes an email, but it is used only for account access and payment and is never stored against your prompts — so retention may still apply at the provider, while your query arrives anonymized rather than linked to your identity. You use the model as a stranger. Since the join between a name and the words is what made every breach and every subpoena on this page damaging, that link is the thing worth attacking. It also removes row 4 by construction: you never load a provider's web interface, so its analytics and advertising tags never see you at all.

What we hold, plainly. Your chats live in your own browser's local storage, not in a server-side archive; a prompt exists on our side only for as long as it takes to fetch your answer, and an hourly sweep clears anything orphaned by a closed tab. We keep an anonymous device token for free-tier limits and marketing attribution, basic visit data against it (referring site, landing page, UTM parameters, user-agent and a two-letter country code — never a stored IP address), and ordinary infrastructure telemetry such as IP addresses, request timestamps and error codes for at most 30 days. The Session Privacy Reports we generate as deletion receipts are archived durably, and they carry provider, model, deletion status and response identifiers: metadata, not prompt text. We are not a zero-data service and will not describe ourselves as one.

What it does not fix. Three limits, stated directly. Row 1 is still yours: your history sits in your browser, so anyone with your unlocked device can read it exactly as they could read any other tab — what does not exist is a server-side archive for anyone else to pull. Row 2 is still yours: on a laptop your employer administers, endpoint software sees your screen whichever service you use. And the words are still yours: your text reaches the provider verbatim, so redacting identifying details before sending remains your responsibility, as our Terms of Service and Disclaimers set out. Anonymity is not privilege, not a legal exemption, and not a way to withhold anything a court is entitled to.

Frequently Asked Questions

Is it actually safe to tell an AI chatbot personal things?
"Safe" is not answerable; "safe from whom" is. Ranked by how likely they are to matter: someone with access to your unlocked device or account, your employer if you are on a work account, the provider's own routine processing (training defaults, safety classifiers, human review, memory features), third-party analytics embedded in the chatbot's website, a breach, and legal process. Most everyday questions are fine once the account is configured; identifiable details about other people, credentials and full identifiers are not.
Can my AI chats be used against me in court?
Yes. Chat logs have been preserved, produced and treated as evidence. In the NYT–OpenAI litigation, Judge Sidney Stein affirmed an order on 5 January 2026 compelling production of a 20 million-conversation sample of consumer ChatGPT chats from December 2022 to November 2024, and affected users were never notified. Talking to a chatbot also creates no privilege: in United States v. Heppner (S.D.N.Y., 10 February 2026), Judge Rakoff held that a defendant's AI-generated defence documents were never protected in the first place, because Claude is not an attorney and the consumer terms defeated any reasonable expectation of confidentiality.
Will the AI leak my secret to another user?
This is the fear most people have and the least likely path. Models do memorise training data and it can be extracted — Nasr, Carlini and colleagues demonstrated it against production systems in 2023 — but your chat would have to be eligible for training, survive into a corpus, be trained into a model deployed months later, and then be surfaced by an undirected attack that cannot ask for you specifically. Meanwhile an unlocked laptop, an employer's admin console or a misconfigured database exposes conversations today, in full, on demand.
Does deleting the conversation or using temporary mode fix it?
Partly. Both are genuinely good against the most likely threat — someone reading your sidebar. Neither prevents the request reaching the provider, and deletion is a content operation: billing and usage records, safety classification scores and anything under a legal hold run on separate clocks, and a preservation order overrides the delete button entirely.
What is the single most effective thing I can do?
Ask the general version of your question. Keep the specifics that shape the answer — jurisdiction, dates, sequence, amounts, exact wording — and drop the ones that identify a person: names, employers, addresses, account numbers, and source files whose properties still carry an author. It costs nothing, needs no product, works against every threat on the list, and keeps working when a setting, a vendor or a court does not go your way.

Conclusion

The useful question was never "should you tell an AI your secrets". It was: which secret, to which system, against which adversary, and what happens if that goes wrong.

Run it honestly and the ordering surprises most people. The catastrophe they imagine — a model volunteering their confession to a stranger — sits at the bottom of the list. The things that actually expose people sit at the top and are almost embarrassingly mundane: a sidebar left open on a shared laptop, an account their employer administers, a database with public read rules, a random sample of twenty million conversations pulled into a lawsuit that had nothing to do with them.

Every one of those gets its force from the same thing — a durable record with a name attached. So the two defences that generalise are the two that attack the name. Do not type the identifying details in the first place, and where you can, send the question through something that never learns who is asking.

Should You Tell an AI Your Secrets?
A Realistic Threat Model