When AI Conversations Become Public: An Analysis of DeepSeek Shared Links

An AI chat becomes public at the moment its sharing model says that anyone with the link can read it. The harder question is whether “anyone with the link” also includes people who never received the link directly but discover it through a search engine.

That is the question raised by David Konitzny’s analysis on LinkedIn. He reports finding DeepSeek /share/ URLs in Google results and argues that the product’s sharing flow makes the exposure easy to underestimate. His article is an independent observation, not a DeepSeek incident notice or a comprehensive measurement of all indexed pages. That distinction matters: the claim is serious, but the evidence should be described as a test result rather than as proof that every shared conversation is searchable.

Definition: A shared AI conversation is a public webpage containing the messages selected by the person who created the share link.

Example: A user shares a harmless question-and-answer exchange, but the same chat also contains a private prompt that was selected accidentally or remains visible in the shared page.

Key takeaway: “Only people with the link” is not the same as private when the URL can be forwarded, logged, crawled or discovered.

Business impact: AI adoption creates a new class of data-loss risk at the interface layer: a model may be secure while a share button turns sensitive context into a public page.

What the DeepSeek sharing flow does

According to Konitzny’s walkthrough, DeepSeek’s web interface lets a user create a share page and choose which questions and answers to include. A warning explains that anyone with the link can view the conversation. The user can later manage or delete shared links through settings.

That is a normal and useful product pattern for publishing a conversation with a colleague, customer or community. The privacy boundary is the link itself. The page does not need to be indexed for the risk to exist: a recipient can forward it, a browser can store it, a workplace security tool can record it, and an external service can copy it.

Search discovery would add another path. Instead of guessing or receiving a URL, someone could find the page through a query that targets the share directory. Konitzny says he observed this behavior with a site: search and could expand the result set beyond Google’s initial “most relevant results” view. Because the finding comes from an individual test and may change as pages or indexing rules change, it is best treated as a warning signal that deserves verification—not as a complete census of exposed chats.

The product lesson is still clear: the phrase “anyone with the link” should trigger public-web handling. It should not be interpreted as a private collaboration mode.

Why this is different from a database breach

DeepSeek has also been the subject of a separate, well-documented infrastructure exposure. In January 2025, Wiz reported finding an unauthenticated ClickHouse database associated with DeepSeek. Wiz said the database exposed more than one million log lines, including chat history, API secrets, backend details and operational metadata, and that DeepSeek secured the exposure after responsible disclosure. WIRED’s report described the same incident as a leak of system logs, user prompts and API authentication tokens.

That event was an infrastructure failure: sensitive operational data was reachable through an exposed database. The shared-link issue is a product and user-behavior problem: a user intentionally or accidentally creates a public page, and the page may be more discoverable than expected.

They should not be merged into one incident. But they belong to the same risk category. AI privacy is not only about model training or the database behind the service. It includes logs, URLs, browser behavior, access controls, metadata, sharing features and the assumptions a user makes while clicking a button.

The interface is part of the security boundary

People often discuss an LLM as though it were the entire product. It is not. The model generates an answer, but the surrounding application decides what is stored, what is logged, what can be shared, which fields are included, and who can open the resulting URL.

This is why the DeepSeek privacy guidance from Kaspersky treats shared chats as a separate risk from ordinary conversation history. Its practical warning is simple: anyone who obtains a public share link can read it, so confidential work should not be placed in a conversation that will later be shared. The same guidance recommends reviewing shared links and deleting old ones when they are no longer needed.

The broader architecture is familiar from any AI agent. The model is one component; the tool permissions, memory, file store, network access and human-facing controls determine what the system can actually expose. A polished chat interface can hide those boundaries behind one convenient button.

A privacy review should therefore ask questions that model benchmarks do not answer:

• Does a share action create a public page or an authenticated workspace object?
• Which messages, attachments, metadata and tool results are copied into it?
• Can the page be crawled by search engines?
• Can the owner revoke access reliably, and how quickly?
• Do old links remain accessible after deletion or account closure?
• Are URLs and page contents recorded by analytics, referrers or security scanners?
• Is the warning prominent enough for a user to understand the real audience?

For teams turning that review into controls, AI Magazine’s roundup of 10 AI privacy tools maps the main product categories, including consent management, data-loss prevention, sensitive-data discovery and personal-data redaction.

Why search indexing changes the mental model

A private message has an intended recipient. An unlisted URL has an intended recipient plus everyone who can obtain it. An indexed URL has a potential audience defined by a search engine’s discovery and ranking systems.

That difference is easy to miss because the sharing dialog may show the link as a long, random-looking string. Randomness is not access control. A high-entropy URL can reduce accidental guessing, but it does not prevent forwarding, browser history collection, referrer leakage, automated crawling or an exposed page being copied elsewhere.

Search engines also create a false sense of disappearance. If a page is removed from the result set, cached elsewhere or no longer appears for one query, that does not prove the underlying content was never accessed. Conversely, a search result for one page does not prove that all pages in the same directory are indexed. This is another reason to avoid putting sensitive data into a share link in the first place.

The right default is to treat a public link as public at creation time, not to wait for evidence that someone found it.

What users should do now

The safest workflow is short:

1. Inspect the entire conversation before sharing. Select only the messages needed for the recipient, then read the resulting page as if you were an outsider.
2. Remove sensitive context before the chat exists. Do not paste passwords, API tokens, customer records, private contracts, personal identifiers or unreleased code into a hosted AI tool.
3. Prefer a controlled transfer for confidential material. Copy a sanitized answer into an approved workspace with access management instead of publishing a public chat page.
4. Review old shared links. Delete links that no longer serve a purpose, and do not assume deletion from the sidebar automatically removes every stored copy.
5. Ask for a private mode when the audience matters. A real account-bound or permissioned workspace is materially different from a URL anyone can open.

These steps are not specific to DeepSeek. The same reasoning applies to any chatbot, notebook, document assistant or agent platform that creates public links.

What AI providers should make explicit

The best fix is not another warning buried in a pop-up. The interface should make the audience unmistakable: Public link — anyone with the URL can read this, followed by a separate confirmation when the conversation contains attachments, tool results or high-risk terms.

Providers should separate “share with named people” from “publish to the web.” They should add expiration dates, revocation that is easy to verify, access logs, workspace policies and organization-level controls that disable public sharing. Search indexing should be blocked by default for conversational pages, but noindex should be treated as defense in depth, not as authentication.

The system should also show users exactly what will be copied: selected messages, uploaded files, citations, metadata, timestamps and any hidden tool output. A user cannot make an informed decision about sharing a page if the page contains more than the visible chat transcript suggests.

For enterprise deployments, public-sharing events deserve the same monitoring as file uploads and external invitations. A security team should be able to discover active public links, identify the owning account, revoke them centrally and confirm the content is no longer accessible.

The larger AI privacy lesson

The DeepSeek shared-link analysis is valuable because it moves attention away from model intelligence and toward product mechanics. A powerful model can produce impressive answers, but the real privacy boundary is built from mundane details: a checkbox, a URL, an index directive, a retention setting and a delete button.

The 2025 database exposure showed what happens when infrastructure is left open. The 2026 shared-link observation highlights a different failure mode: users can publish content without fully understanding the audience created by the interface. The responsible response is neither panic nor dismissal. It is to use public sharing only for content that is safe to publish, verify the access model before trusting it, and demand that AI products make their boundaries legible.

An AI conversation is not private because it feels like a private conversation. It is private only when the system enforces that audience.