Public AI chat links: sharing can become publishing

The “Share” button in an AI assistant looks like a convenient way to send a conversation to a colleague. Technically, it often creates an unauthenticated public HTTP resource. Anyone holding the address can open the chat or artifact. If a search crawler or archive visits the page, an unguessable identifier no longer prevents discovery.

Varonis Threat Labs analysed sharing mechanisms across services including ChatGPT, Claude, Gemini, Grok, DeepSeek, Perplexity, Meta AI, Manus and Kimi. Its 29 July report shows that this is not one isolated product defect. Three models collide: the user imagines a private hand-off, the browser sees a public URL, and the organisation may have no visibility into data handled through a personal AI account.

A long token is not access control

Share links generally combine a fixed path with a high-entropy identifier such as a UUID. That makes brute-force guessing impractical. It does not help when the URL appears in:

• a search index;
• browser history or telemetry;
• a chat channel or ticketing system;
• referrer headers or proxy logs;
• a public repository, document or screen recording;
• an internet archive or a recipient’s copy.

After the first disclosure, nobody needs to guess the token. It can be copied, indexed and redistributed. The same principle applies to public cloud-file links: high URL entropy reduces enumeration risk, but it does not replace identity, authorisation or expiry.

noindex reduces discovery, not access

The research notes that most platforms now use meta robots: noindex, an X-Robots-Tag header or robots.txt rules. These are useful controls against accidental indexing, but their scope is limited:

• they are instructions for cooperating crawlers, not authorisation checks;
• they cannot revoke copies already fetched by people, bots or archives;
• they do not block a person who has the URL;
• they do not prevent someone pasting the link into a public channel.

Removal from Google is also not equivalent to deletion from every index and archive. Varonis documented differences between current and legacy share domains and uneven remediation across platforms. A specific service may change, but the threat model persists: a public link is a publishing mechanism.

What can leak from a corporate chat

The greatest risk is not a generic question but the context attached to an answer. A shared conversation may include:

• source code and production errors;
• logs containing tokens, system addresses and customer data;
• files, contracts, tickets and internal decisions;
• system instructions, agent configuration and connected-tool inventories;
• data retrieved from repositories that the assistant can access too broadly;
• material the model summarised but the user was never authorised to publish.

Exposure grows with shadow AI: an employee uses a personal account on a corporate device, outside tenant policy, DLP and retention. The AI provider becomes a publishing layer while the organisation may not even have an inventory of generated links.

An organisational response plan

1. Establish where sharing exists

Inventory approved assistants and popular unapproved alternatives. Check conversations, artifacts, applications and public pages separately. Do not assume an Enterprise-plan restriction also covers a personal account.

2. Limit sensitive data before the model

“Do not click Share” is too weak if a secret has already entered the conversation. Use data classification, DLP, secret redaction and least-privilege connectors. An assistant should see only the resources required for its defined purpose.

3. Treat link creation as a permission change

Creating a public URL should be a logged event. In managed plans, prefer authenticated recipients, expiry, central revocation and administrator visibility.

4. Prepare an exposure procedure

If a link contained corporate data:

1. revoke or delete the share with the provider;
2. preserve the URL, time, owner and conversation scope as evidence;
3. determine whether the page was indexed, archived or forwarded;
4. rotate visible tokens, keys, passwords and sessions — deleting the page is insufficient;
5. assess contractual, legal and communication duties;
6. remediate the root cause: excessive access, missing DLP or unmanaged accounts.

How to train employees

The best message is not “never share AI.” Explain that a public link resembles publishing a web page. Before sharing, the user must review the entire conversation, attachments, quoted material and generated artifacts. When in doubt, send a sanitised extract through an approved channel rather than the full history.

Connect this topic to our enterprise LLM security guide and secrets management practices. Share links provide a simple maturity test: does the organisation control data before the model produces a compelling answer?

Primary facts versus Breachroad analysis

Varonis documents public URL patterns, indexing observations and the limitations of noindex. Platform settings can change quickly, so organisations must verify the documentation and actual behaviour of their subscription. Not every link has been indexed, and public availability alone does not prove that an unintended party read it.

Breachroad’s conclusion is to treat sharing as a publishing operation governed by DLP, logging, retention and incident response. Secure AI implementation training helps teams set those rules, while AI red teaming can test whether public links, connectors and permissions create a practical exfiltration path.