Nobody broke in. Someone clicked "share," and a default did the rest.
Over the weekend of July 25, shared Claude conversations and Artifacts started showing up in Google and Bing results. Someone on Reddit noticed it first, ran the query site:claude.ai/share, and got back a list. Inside it, according to the reporting, were things nobody meant for a search engine: a real patient medical report, clinical trial results with patient names attached, employee reviews, documents stamped internal use only, and in a few cases crypto wallet keys. By Sunday, after Anthropic added a noindex tag, the Google results had largely cleared. Bing and Brave held on a little longer.
The story went viral as a data breach. It was not a data breach, and that distinction is the whole point. No one broke into Anthropic. No database leaked. Every one of those pages existed because a person clicked "share." The failure was not that a wall came down. The failure was that a default was set one notch more open than anyone using the button understood.
This piece is about that gap, because it is the most common and least dramatic way private information ends up public, and because it is a design problem you can actually fix.
Anthropic's position is straightforward and, on the mechanics, correct: a shared link is user-initiated public content, and the company does not hand chat directories or sitemaps to search engines. Nobody submitted these pages to Google. Google found them the way it finds everything, by following links, and a page carrying no instruction to keep crawlers out is a page a crawler will index.
That is the hinge. "Public if you have the link" and "publicly discoverable" feel like the same thing and are not. A link-only page is private in practice as long as the only path to it is someone sending it to you. The moment that page has no noindex tag and gets referenced anywhere a crawler can reach, "you need the link" quietly becomes "here is the link, ranked and searchable." Anthropic's share dialog did warn that the link was public and that anyone with the link could view the chat. What it did not say was that the page could be indexed, so "anyone with the link" quietly grew to include anyone running a search. The warning covered access. It never covered discoverability, and those are the two things people conflate.
Worth noting: this is not a one-vendor story. OpenAI hit the same failure mode about a year earlier with shared ChatGPT chats and later pulled the feature. Grok had its own shared-chat indexing incident. Three different companies, one underlying shape. When a mistake recurs across an entire category, it has stopped being a bug and started being a default the category keeps getting wrong.
Calling this a breach points you at the wrong fix. A breach says: someone got in, harden the walls. This was the opposite. The walls were never the issue. A user opened the door on purpose, because the door was labeled "share" and they wanted to share, and the warning it gave, that the link was public, never said the room was the open, searchable internet.
Two things failed, and neither of them is an intrusion.
The first is the default. The safe state of a share link is not indexed. Discoverability at search-engine scale is a different, larger permission than "anyone with this URL can view," and it should be something a user turns on deliberately, not something that ships on by inheritance. A noindex tag is one line. Shipping it by default is the difference between a page that is quiet and a page that is broadcast.
The second is consent clarity. The label on the button set an expectation the system did not keep. People carry a mental model of "share" that comes from email and messaging apps, where sharing means sending to named recipients. Claude's dialog did warn the link was public, which is more than nothing, but "anyone with the link" describes access. The word it left out was discoverable, and that is the word that turns a shared page into a search result.
We build products with share and public-link features, so this is a design we have opinions about. The posture is the one we bring to everything: the safe state is the default state, and the interface tells the truth about what an action does.
Concretely, a share link we ship carries noindex by default. Discoverability is a separate, explicit toggle a user reaches for, with plain language about what it means, not a silent property of the link. The action is labeled for what it actually does: "create a public page anyone can open" reads differently from "share," and it should, because it is a different thing. Links can expire, so a page shared for a moment does not stay live and crawlable forever. And on anything that could carry sensitive content, we would rather warn once too often at the point of sharing than let a medical report or a set of keys walk out on a URL nobody remembers generating.
None of that is exotic. It is the fail-closed habit applied to one button: assume the more exposed outcome is the one you do not want by default, and make the user opt into it on purpose. The reason it matters is that defaults are decisions. Every default is a choice the builder makes on behalf of every user who never opens the settings, and most users never open the settings.
If your team uses AI tools, and it does, this is not really a story about one chatbot. It is a reminder that share defaults across the tools you use rarely match what your people think they are doing. The practical move is not to ban sharing. It is to govern it.
Assume anything your team shares out of an AI tool can be indexed, because across three vendors now it has been. Decide, on your side, what is allowed to go into these tools and what is allowed to come back out as a public link: patient data, customer records, anything under an internal-use label, credentials of any kind. That is a policy decision, and it belongs in your governance rather than in the hope that every vendor got the default right. The vendors will keep improving. Your exposure in the meantime is yours to manage.
This is the same principle we apply when we deploy AI inside a client operation: policy lives in the tool layer, not in a training reminder, and the default is the cautious one. A person who has to opt in to the risky action makes far fewer expensive mistakes than a person who has to remember to opt out of it.
This is not a claim that Anthropic did something uniquely careless. They shipped a fix quickly, the mechanics of their position hold up, and the same default has caught the two largest names in the category before them. Treat this as an industry pattern, which is what it is.
It is also not a technical incident writeup. We are not reconstructing exactly which pages were indexed or for how long; the reporting is still settling and the specific counts are not the lesson. And it is not a sales pitch for a specific engagement. The design posture above is how we think about defaults, not a scoped proposal for your product.
When private information ends up public, it is far more often a share default set one notch too open than a wall someone broke through, and the fix is to make the safe state the default and the risky one a deliberate opt-in.
If you are rolling AI tools out across a team and the question "what could leak, and how" is open, that is a conversation worth having before something ends up in a search result. We do not need a long brief. We need the tools your team actually uses, the kind of data that moves through them, and where the public-sharing surfaces are. On the call we will tell you where your real exposure is, what we would change first, and whether an AI governance engagement is even the right SDS answer for you.
We do not take every engagement, and we will tell you whether we are the right partner.