Shared AI chats keep reaching Google. The fix is upstream of the share button

On Saturday 25 July 2026, someone on Reddit typed eleven characters into Google and found other people's conversations with Claude.

The eleven characters were site:claude.ai/share. That is a search operator, not an exploit. It tells Google to return only results from one path on one domain, and it is the same thing an SEO analyst uses fifty times a day to audit a client's site. By Monday, 404 Media had published, and by Tuesday everyone from TechCrunch to Futurism had gone through what was sitting there.

We want to walk through this one properly, because the coverage mostly stopped at "shared chats got indexed, here is how to unshare them." That is useful advice and we will get to it. But the interesting part is underneath, and it is the same thing that happened to OpenAI eleven months earlier, to xAI three weeks after that, to Google's own Bard in 2023, and to Anthropic itself in September 2025. Five events, four labs, one wall.

What was actually in there

We are going to be specific rather than gesture at "sensitive data," because the specificity is the argument.

Joseph Cox at 404 Media, who broke it, found cryptocurrency wallet keys, API keys and login credentials, personal information including names and addresses and phone numbers, an AI-powered therapy app somebody appears to have vibe-coded, meeting notes, and a dashboard built to analyse medical billing data.

Futurism went through the results separately and found a detailed medical report on a named patient, clinical trial results with patient names attached, documents carrying the names and phone numbers of primary-school-aged children, company documents marked internal use only, and employee reviews containing personal information about the workers being reviewed.

The volume estimates vary and we will not pretend to a number we cannot stand behind. Ground News reported around 200 conversations across more than two dozen pages of results. Other outlets put it near 600. Nobody has published a verified count, and Anthropic has not given one.

Artifacts were caught in the same net, through a different route. These are the documents and mini-apps people build inside Claude, and they are served from /public/artifacts/, a path not listed in robots.txt at all. Internal dashboards and project plans carrying client data turned up alongside the conversations. That distinction matters practically: unsharing a chat and unpublishing an artifact built inside it are two separate actions, so anyone auditing their own exposure has to do both.

The technical failure, which is genuinely elegant

Here is where most coverage got it slightly wrong, and where it gets interesting.

The early reporting said Anthropic's share pages had no noindex tag. Matt G. Southern at Search Engine Journal actually went and checked the crawl rules on 27 July, and found something more subtle. The noindex was there. It just could not be read.

Anthropic's robots.txt at claude.ai disallows /share/* under User-agent: *. Separately, a live share URL returns an X-Robots-Tag: none header, which Google treats as equivalent to noindex, nofollow. Two protections. Both correct in isolation.

The problem is that the second one lives inside the door the first one locks.

Google's own documentation is explicit that a noindex directive only works if the crawler is permitted to fetch the page and read it. If robots.txt blocks the path, Googlebot does not open the page, so it never sees the header telling it not to index. And critically, Googlebot does not need to open a page to record that the page exists. If it finds the URL linked from somewhere else on the web, a forum post, a social post, a public Slack archive, it can list that URL in results without ever crawling it.

So the instruction "do not index this" was sitting behind the instruction "do not come in here."

Anthropic's answer, and why it is both correct and not enough

Asked what went wrong, Anthropic did not describe a bug. It described a design.

Spokeswoman Amie Rotherham told TechCrunch that the company gives people control over sharing conversations publicly, does not hand chat directories or sitemaps to search engines, and that the links are "not guessable or discoverable unless people choose to share them" themselves. When someone shares a conversation, the position goes, they are making that content publicly accessible.

Every factual claim in that statement is true. Sharing does make a page public, the URLs are not enumerable, and Anthropic was not publishing a sitemap of everyone's conversations. It still does not answer the question, because the question is not whether the page was technically public. The question is whether the person who pressed share understood that "public" meant "eligible for a Google result." Those are different things, and the gap between them is where the medical report ended up.

Google's spokesperson Ned Adriance made the same point from the other side, telling TechCrunch that "Neither Google nor any other search engine controls what pages are made public" on the web, and that site owners hold the crawl and index controls. He is right. The controls existed. One of them was placed where it could not be reached.

Incident breakdown: five events, one shape

None of this is new, which is the part that should worry you. OpenAI went through it in July 2025, when shared ChatGPT conversations turned up in Google carrying resumes, API keys and business plans, and the company pulled the feature within days.

A month later xAI's Grok was worse: hundreds of thousands of conversations indexed with no opt-in and no warning at all, some of them containing instructions the platform should never have produced.

Anthropic itself had a smaller version of this in September 2025 and said it had blocked the crawlers.The July 2026 Claude incident is not an anomaly. It is the fourth or fifth time the industry has learned that a share button and a search index are closer together than anyone pressing share understands.

Removal from Google is not removal from the internet. OpenAI's cleanup is the clearest case. Google complied and delisted, but by then more than 100,000 conversations had been captured by the Internet Archive, and as of the reporting OpenAI had not asked Archive.org to take them down. Those are still there. Deleting the conversation from your ChatGPT history never deleted the public share link either, which is the kind of detail people only learn afterwards. The same applies to Claude right now: old links still resolve for anyone who saved one, and caches outlive delisting.

The part that actually matters if you run security somewhere

Everything above is a story about share buttons. Share buttons are a vendor's problem and, mostly, a vendor's fix. If that were the whole story, our advice would be four sentences long and we would not have written this.

Here is the thing that changes the shape of it.

In every one of these incidents, the sensitive data was already in the conversation before anyone pressed share. The wallet key was typed into a prompt. The patient record was pasted into a prompt. The clinical trial results, the employee reviews, the children's phone numbers, the API credentials, all of it was in the chat before any link existed.

The share button did not create the exposure. It moved data that was already sitting somewhere it should not have been.

The asymmetry is the whole point. You have no leverage over steps 3 and 4, and less than none over step 6, since a crawler finding a link is not an event anybody controls. Once a page reaches step 7, delisting from Google does not retrieve it from the Internet Archive, and unsharing a link does not close a cached copy.

Step 2 is different. It happens on a device you administer, in a browser you can manage, by an employee you employ, with data you own. That is the only place in the chain where prevention is even possible. Everything after it is incident response.

How much data is moving through step 2

More than most people assume, and the research is consistent across independent sources.

A survey of employed US adults published on 29 July 2026, two days after the Claude story broke, found that nearly two in five had entered work information into a personal AI account their employer does not control. Internal emails and documents were the most common category, followed by financial figures, customer information, contracts, HR records and source code.

Most respondents did not know this could carry legal exposure. We would treat a legal characterisation in a survey commissioned by a litigation firm with some caution, but the behavioural pattern matches what two independent vendors see in instrumentation, and when survey data and telemetry agree we tend to believe the direction.

That is the real condition of most enterprises right now. Not "we have decided our AI risk posture." Closer to "we do not know what is happening and we hope it is fine."

What FireTail does about step 2

FireTail cannot un-index a page. We cannot retract a share link, purge a Google cache, or reach into the Internet Archive. Nobody can sell you that. If a wallet key is already sitting in a cached snapshot, that key is burned and the only correct response is to rotate it.

What we do is sit at step 2, which is the only place where the outcome is still undecided.

Seeing what is actually happening

You cannot govern what you have not found, and most of this traffic is invisible to the tools you already own, because it runs through personal accounts in a browser. FireTail discovers AI usage across the workforce through a managed browser extension and workspace scanners, without an SDK or a code change anywhere.

The distinction that matters for this story is that discovery covers both sanctioned and unsanctioned tools. The lawyer asking about self-reporting was almost certainly not using a corporate seat.

Stopping the paste before it becomes a prompt

This is the actual answer to the incidents above. If the API key never enters the conversation, the share button is harmless.

FireTail ships guardrails that block categories of content at the point of entry. Reading them against the 404 Media and Futurism findings is uncomfortably neat:

Two things about how these run, both from our July 2026 release, and both of which matter more than the list itself.

They evaluate locally at the endpoint rather than making a round trip, which is the difference between a control that survives contact with an engineering team and one that gets ripped out for adding latency. And they are multilingual, with a remote fallback for non-English, which closes a gap people rarely think about. Your data loss prevention rules were almost certainly written in English. Your employees do not all prompt in English.

When a guardrail fires, the block page names the specific guardrail that triggered, so the employee learns why rather than just hitting a wall. And if a guardrail is unavailable or still preparing, it is skipped cleanly and reported rather than breaking the workflow, which is the design decision that determines whether a security control stays deployed.

Governing by topic, not just by pattern

Pattern matching catches an API key because an API key looks like an API key. It does not catch a lawyer asking whether they need to self-report an ethics breach, because that is just English sentences.

Topics are how you catch the second kind. You name a topic, describe what it covers, and the guardrail generates its own example prompts and embeddings in the background. Each topic carries a risk score.

There is also a Discovered Topics view that surfaces what your workforce is actually raising with AI, which is the closest thing we have seen to answering "what are my people using this for" without reading anyone's messages one by one. Scoring holds across languages, so a prompt in Finnish or Japanese is categorised the same way an English one would be.

Knowing what happened, in a form an auditor accepts

If something does get through, the argument you will be having in three months is evidentiary. Logs record which guardrails were evaluated, whether they blocked, and what intervention fired, which means the governance decision and the interaction live on the same timeline instead of in two systems you have to reconcile by hand.
‍

Every interaction, by what the guardrail did about it. Blocked and bypassed are different numbers, and both matter.

What we would do this week

Ordered by how much they matter, not by how hard they are.

Rotate anything that could have been in a shared chat. If your engineers use AI assistants, assume credentials have been pasted at some point, because the telemetry research says they have. Rotation is cheap. Certainty is not available.

Get your people to audit their own shared links. In Claude that is Settings, then Privacy, then Shared Chats. Unsharing kills the direct link. It does not remove the page from a search index or a cache, and artifacts are unpublished separately from the chat that produced them, so both need doing. Send that as two lines of instruction, not a policy document.

Find out what tools are actually in use before writing any rules. Not the approved list. The real one. Every incident in this post involved a tool being used for something nobody had sanctioned, by someone who was just trying to get work done.

Write the rule at the data layer, not the tool layer. "Do not use ChatGPT" fails, because there were eighty-plus AI platforms in the environment we were looking at while writing this, and there will be more next quarter. "Credentials never leave the network in a prompt" holds regardless of which tool appears next.

Treat a share link as a publication. Not as a message. The moment one exists, assume it can be indexed, cached and archived, and that all three are permanent. That is not paranoia. It is what happened four times to four companies who each thought their configuration was correct.

Anthropic's defence, that sharing makes content public, is technically correct. Grok's implementation, which published without asking, was worse. OpenAI's checkbox at least tried to tell people, and thousands of them still clicked it without understanding. Google fixed this on Bard in 2023 and it happened three more times afterwards at three other companies.

That is not four mistakes. That is a structural gap between how people understand these tools and how the tools behave, and vendors will keep closing individual instances of it while the gap itself stays open.

Which is the argument for owning step 2. You cannot fix the industry's consent model. You can decide what leaves your organisation in a prompt, before any of the rest of it becomes your problem.

‍