Is It Safe to Share an AI Chat Link? What Leaks and How to Revoke It

It is safe to share an AI chat link only when everything in that chat could be posted in public without harm. A public share link turns your conversation into a fixed web page that anyone holding the URL can open, and URLs travel further than people expect. For colleagues, use an organization only share; for customers, send a short written summary instead of the link.

The rest of this guide explains why, and covers revoking, policy and breach reporting. Every fact about a specific AI product comes from that maker's own help pages, read on 22 October 2026. These features change often, so check the linked pages before you write policy around a menu name.

Key takeaways

• A shared chat is a snapshot in every assistant we checked. Later messages stay private, but everything up to the moment of sharing is frozen into a page at its own URL.
• On consumer plans the link is the only key. Whoever holds it, and every system that touches it, can read the chat.
• Links leak through ordinary plumbing: DNS lookups, chat app previews, email link scanners, browser sync and public posts. The October 2026 Muse report showed chat titles in hostnames making thousands of shares findable through passive DNS data.
• Business plans change the picture. Claude Team and Enterprise restrict sharing to the organization, Microsoft 365 Copilot requires recipients to sign in, and Google Workspace admins can switch Gemini public links off.
• Revoking a link stops new views. It does not recall copies, previews, imports or screenshots that already exist.
• Never put secrets, customer personal data, unreleased financials, security findings or proprietary code into a chat you might share. Assume any chat might be shared.
• A shared chat that exposes personal data can be a personal data breach under GDPR even if nobody malicious opened it. Record it, assess the risk, and decide on notification within 72 hours.

What actually happens when you share an AI chat?

When you press Share, the assistant does not give your colleague a live window into your account. It copies the conversation as it stands, stores that copy as a separate object, and gives it a URL. Whoever opens the URL sees the copy.

Each maker's help pages describe this snapshot model in their own words:

• Claude (Anthropic). "Anyone with the link can view the chat snapshot," and messages sent after sharing stay private. Unsharing and sharing again updates the snapshot. A second Anthropic article says recipients see earlier messages, artifacts and your name, that shares are view only, and that raw connector or MCP data is not shown.
• Gemini (Google). The public page "shows the chat as it appeared when you created the public link," anyone with the link can read it, and Google does not add your name or account to the URL or page.
• Microsoft Copilot (consumer). Recipients see a copy of the conversation from when the link was generated, and anyone with the link can open it.
• Microsoft 365 Copilot (work or school). Viewers see content "exactly as it appeared when it was shared," and must sign in.
• ChatGPT (OpenAI). OpenAI's shared links FAQ says anyone with access to a shared link can view the conversation, and advises against sharing sensitive content. OpenAI's help center refused our automated fetch, so we read its text through search results only; confirm the ChatGPT details on the page itself.

Public page, private page or something in between

Three sharing models are in use, and they carry very different risk.

1. Bearer link. Anyone with the URL can read the page without signing in. This is the default for consumer Claude, consumer Gemini public links, consumer Copilot and ChatGPT. Security depends entirely on the URL staying secret and hard to guess.
2. Signed in, scoped to an audience. The URL alone is not enough. Microsoft 365 Copilot shares open only for people in your organization who sign in with a work account. Claude Team and Enterprise shares are limited to the same organization. Claude's "share with specific people" option, available on all plans, binds the invite to the email address you entered, so a forwarded email will not open for anyone else.
3. Sharing through a document system. Google's Workspace admin page describes sharing Gemini conversations through Google Drive, where your existing Drive sharing rules apply and recipients must be signed in.

The first model is a public web page with an unlisted address. The other two are access controlled documents. Most trouble comes from treating the first as if it were the second.

Does a shared chat include my files and images?

It depends on the product:

• Anthropic says attached files are not included in a public Claude share. Its newer article says attached files are not shown "unless shared within your organization."
• Google says uploaded images in a shared Gemini chat can be downloaded by viewers, and generated artifacts such as Canvas documents, images and videos are included.
• Microsoft says a Microsoft 365 Copilot share includes prompts and responses, but referenced files, emails, meetings and chats open only for people who already have permission.

Even where a file is excluded, the model's answer about the file is included. If you uploaded a customer contract and asked for a summary, the summary is in the share. Your prompts are always in the share.

Is a shared chat indexable by search engines?

None of the help pages we read made a promise either way about search indexing. That does not mean the pages are indexed. It means you should not rely on a guarantee you have not seen in writing, and you can test the behaviour yourself (see the walkthrough).

The control that keeps a public page out of search is the noindex rule. Google's Search Central documentation says it can be a robots meta tag or an X-Robots-Tag HTTP header, and once Googlebot sees it the page drops out "regardless of whether other sites link to it." It also warns that if robots.txt blocks the page, the crawler "will never see the noindex rule," and the URL can still appear in results when other pages link to it. So a share link posted on a public forum or issue tracker can surface in search unless the share page carries a readable noindex.

How do shared links become discoverable?

A share URL is a secret only in the loosest sense. Every system that sees the string can read the page. These are the paths we see most often.

DNS: the Muse case

On 20 October 2026, Slashdot summarized an Ars Technica report that Meta's Muse assistant had exposed thousands of shared conversations. Per that summary, researchers at a firm called Claroc enumerated 6,800 share links and, after opening a few hundred, found material clearly not meant to be public. Each share link lived on its own subdomain of cf.metaaiusercontent.com, and the conversation title was part of that subdomain alongside a long random string. Passive DNS services record historical lookups, so anyone searching those databases could list the hostnames. The researchers were quoted as saying "It took one query." Meta suspended the sharing feature while it considers changes. Hacker News commenters disagreed about how much randomness the hostnames carried, and we could not settle that from primary sources. We could not fetch the Benzinga report cited in some coverage and found no Meta help page on Muse sharing, so everything about Muse here is attributed to that reporting.

Why does a hostname matter so much? RFC 9076, the IETF's DNS privacy document, explains that a single lookup "reveals both the originator of the query and the query contents," that recursive resolvers see nearly all of a user's queries, and that passive DNS collection and long retention create lasting exposure. The path of an HTTPS URL travels inside the encrypted connection. The hostname goes to the DNS resolver first, where resolvers, network monitors and passive DNS sensors can log it.

The lesson for product teams: secrets belong in the path, never in the hostname. The lesson for users: if a share link looks like your-chat-title-abc123.something.com, your chat title is being sent to every resolver on the way.

Link previews and unfurling

Paste a link into a team chat tool and the tool usually fetches the page to build a preview. Slack's developer documentation says its servers "must fetch every URL in a message to determine what kind of content it references," reading OpenGraph and X Card tags, and that links in user messages unfurl by default. Two consequences follow. A third party's servers have now opened your share page. And the preview text is stored in that tool's history, searchable by everyone in the channel, including future members and guests. If the preview shows the first line of your prompt, people learn the gist without clicking.

Email scanners, shorteners and referrers

Many email security systems rewrite links and fetch them before the recipient clicks. URL shorteners log every expansion. Analytics on any page that links to the share can record it as a referrer. None of these are attacks; each is just another place the URL is stored.

Public posts, browser sync and forwards

The most common leak is the plainest. Someone pastes a share link into a public GitHub issue, a forum answer or a social post to show "how I got the assistant to do this." Crawlers find that page and may follow the link. Separately, share URLs sit in browser history that syncs across devices, appear in screenshots with the address bar visible, and get forwarded to "someone who might know." In the bearer model nothing records any of it.

A bearer link has no audience. Its audience is whoever ends up holding the string, and the string is copied by design into DNS logs, chat histories, email gateways and browser sync. That is why the safe default for anything sensitive is a share that requires sign in, or no share at all.

How do the major assistants differ in sharing and revoking?

This table summarizes each maker's own documentation. "Not stated" means the page we read did not cover the point, not that the feature is absent.

Three details change what "revoke" means in practice.

Claude's audit log. Anthropic says Team and Enterprise admins can turn off chat sharing, see and revoke shared chats, and review sharing activity in the audit log. That log answers "who shared what, and when" without asking each person, which is exactly what an incident review needs. Anthropic's "Turn off" control stops sharing for everyone, and the link "stops working immediately."

Gemini's policy switch does not kill old links. Google's Workspace admin page puts the control under Menu, Generative AI, Gemini app, Sharing, scoped by domain, organizational unit or group, with group settings overriding organizational units. Turning public links off stops new ones, but "previously shared links will be accessible until they are deleted from the Gemini app," and changes can take up to 24 hours. Recipients can also continue a shared Gemini chat, and that continuation stays in their activity after you delete your link.

Copilot depends on which Copilot. The consumer history page tells users not to include "sensitive, confidential, or personal information" in shared links and previews what will be shared, but did not describe a per link revoke. Microsoft 365 Copilot has a Stop sharing action, and some conversations cannot be shared at all because of organizational policies or sensitivity label protections.

For Muse, the reporting says sharing was suspended. If you used it, assume existing links may have been listed by third parties and treat sensitive content in them as disclosed.

Which sharing option should you use?

What should never be in a chat you might share?

Any chat might be shared, by you on a busy day or by someone with access to your account. So this is really a list of what should not go into a consumer assistant at all, and should go into a business plan only under your data handling rules.

• Secrets and credentials. API keys, cloud keys, connection strings with passwords, session cookies, OAuth tokens, private and signing keys, .env contents and CI variables. People paste them while debugging and forget. If a secret is in a shared chat, revoking the link is not enough: rotate it, because you cannot know who opened the page or what cached it. Our post on pasting code or secrets into an LLM chat covers the pasting side.
• Customer and employee personal data. Names with account numbers, email threads, support tickets, CRM exports, HR cases, health or financial details. This is the category that turns a careless share into a reportable event.
• Confidential business information. Unreleased results, deal terms, board material, legal advice and anything under a customer's confidentiality clause. Budgets and loan application drafts were among the examples reported in the Muse coverage.
• Source code and architecture. Proprietary code, internal hostnames, infrastructure as code with account identifiers, and stack traces that reveal internal paths and framework versions.
• Security findings. Vulnerability reports, penetration test output, incident timelines and detection rules, valuable to an attacker because they are accurate and current.
• Prompts that carry the sensitive part. "Summarize the attached termination letter for Priya in payroll" leaks the key fact even if the letter is excluded. The prompt is always in the snapshot.

How do you find and revoke links your team has already shared?

This takes an afternoon. Do it before a researcher does.

Step 1: Decide which assistants are in scope

List every assistant people use for work, including personal accounts on work devices. Expense reports, SSO logs, browser extension inventories and proxy logs are the fastest sources. Business plans give you admin controls; personal accounts give you only the user's cooperation.

Step 2: Use the admin controls that exist

• Claude Team and Enterprise: review and revoke shared chats in the admin view, and export the sharing activity from the audit log.
• Google Workspace: in the Admin console, open Menu, Generative AI, Gemini app, Sharing, and review Conversation sharing per organizational unit and group. Existing links survive a policy change, so users still have to delete them.
• Microsoft 365 Copilot: review your tenant's sharing settings and sensitivity label policies.
• Consumer accounts: there is no admin view. Ask people to check their own shared link lists.

Step 3: Search your own systems for share URLs

Most links that matter were posted somewhere you control: chat channels, tickets, wikis, email and repositories. The patterns below are the ones we have observed for each product's share pages. Confirm them by creating a test share in your own account, since makers can change URL formats.

# Search working trees for common AI share URL patterns
grep -rEn \
  -e 'https://(chatgpt\.com|chat\.openai\.com)/share/[A-Za-z0-9-]+' \
  -e 'https://claude\.ai/share/[A-Za-z0-9-]+' \
  -e 'https://(g\.co/gemini/share|gemini\.google\.com/share)/[A-Za-z0-9_-]+' \
  -e 'https://copilot\.microsoft\.com/shares/[A-Za-z0-9_-]+' \
  . 2>/dev/null

# Search full git history, since removed lines remain in old commits
git log -p --all | grep -En \
  'chatgpt\.com/share/|claude\.ai/share/|gemini\.google\.com/share/|g\.co/gemini/share/|copilot\.microsoft\.com/shares/'

For a chat workspace export or an email archive, run the same expression over the exported files and count unique links:

grep -rhoE \
  'https://(chatgpt\.com|claude\.ai|gemini\.google\.com|g\.co/gemini|copilot\.microsoft\.com)/(share|shares)/[A-Za-z0-9_/-]+' \
  ./workspace-export/ | sort | uniq -c | sort -rn > share-links-found.txt

wc -l share-links-found.txt

In tools with a search box, searching for claude.ai/share, chatgpt.com/share, gemini.google.com/share and copilot.microsoft.com/shares finds posted links and their previews.

Step 4: Check which links still resolve, without reading them

You need to know which links are live, not to read everyone's chats. This records only the HTTP status:

while read -r count url; do
  code=$(curl -s -o /dev/null -w '%{http_code}' --max-time 10 "$url")
  printf '%s\t%s\n' "$code" "$url"
done < share-links-found.txt > share-link-status.tsv

# Live links usually return 200; revoked ones often return 404 or redirect
awk -F'\t' '$1=="200"' share-link-status.tsv

Some products return 200 with a "link removed" page, so spot check a few by hand. Only check links found in your own systems. Never enumerate or guess share URLs in a maker's namespace; that is someone else's service and someone else's users.

Step 5: Check whether a live link is marked noindex

url='https://example-assistant.example/share/abc123'   # a link you found

curl -sI "$url" | grep -i '^x-robots-tag'                     # header form
curl -s "$url" | grep -io '<meta[^>]*name="robots"[^>]*>'     # meta tag form

If neither returns noindex, assume the page can be indexed once a crawler finds a public link to it. Also search the public web for your company name plus each assistant's share domain.

Step 6: Revoke, rotate and record

For each live link with sensitive content:

1. Have the owner revoke it using the steps in the table, or revoke it yourself where an admin control exists.
2. If the chat held any secret, rotate it now, whether or not the link appears to have been opened.
3. Remove or edit the message where the link was posted, so the URL and preview leave channel history and public pages.
4. If the link was public and indexed, request search removal once the page returns 404 or carries noindex.
5. Record what was shared, by whom, when, how long it was reachable, who could have opened it, and what you did. You need this for the breach assessment below.

If you build your own share feature, check it against the Muse lesson: the token belongs in the path, generated from a cryptographically secure random source, never derived from titles, user names or sequential IDs.

What should an AI acceptable use policy say about sharing?

Most AI policies answer "may I paste this in?" and skip "may I share this out?" The sharing clause should be short, specific and testable. Adapt this:

AI assistant sharing rules

1. Use only approved AI assistants, on company accounts. Personal
   accounts may not be used for company work.
2. Default: do not share chats. Copy the useful answer into the right
   company system (wiki, ticket, document) instead.
3. If you must share a chat:
   a. Use an organization-only or named-recipient share. Public
      "anyone with the link" shares are not permitted for work chats.
   b. Reread the whole chat first, including your own prompts.
   c. It must contain no secrets, no customer or employee personal data,
      no security findings and nothing marked Confidential or above.
4. Never send a chat link to a customer, vendor or the public.
5. Never post a chat link in a public place (public repositories,
   forums, social media, public tickets).
6. Review your shared links list at least quarterly and revoke what you
   no longer need.
7. If you shared something you should not have: revoke the link, tell
   security at [contact] within [N] hours, and do not delete the chat
   until security has recorded what it contained.
8. Admins keep public sharing disabled where the tool allows it and
   review sharing logs [monthly].

Making it work in practice:

• Tie each rule to a setting. Turn Gemini public links off in Workspace, keep Claude sharing organization only, and use Microsoft's sharing and label policies. A rule that is also a setting survives a deadline.
• Make clause 7 safe to use. People hide mistakes they expect to be punished for. The GDPR clock starts when the organization becomes aware, so you want reports early.
• Revoke, record, then delete. In some products deleting the chat removes the snapshot, which also removes your record of what leaked.
• Train with real examples and collect acknowledgements. A short session showing a share page, a Slack preview and the Muse story beats a page of rules, and a signed acknowledgement is what an auditor will ask for.

Does a shared chat with customer data count as a reportable incident?

Often it is at least something you must assess and record. This is general information, not legal advice; involve your privacy lead or counsel early.

GDPR and UK GDPR

GDPR Article 4(12) defines a personal data breach as a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. The UK ICO's guide stresses that it covers accidental causes and is "not limited to loss or theft." An employee putting customer personal data on a public link is an accidental unauthorised disclosure. Whether anyone opened the link affects the risk assessment, not whether a breach occurred.

Article 33 requires the controller to notify the supervisory authority "without undue delay and, where feasible, not later than 72 hours after having become aware of it," unless the breach "is unlikely to result in a risk to the rights and freedoms of natural persons." Late notifications must explain the delay, and every breach must be documented. The ICO adds that when the risk to individuals is high, you must tell them without undue delay, and that you should "record all breaches, regardless of whether or not they need to be reported." The EDPB's Guidelines 01/2021 on examples regarding personal data breach notification walk through comparable accidental disclosure cases.

When an employee shares a chat, your organization made the disclosure, so the duty for your customers' data sits with you as controller. If you are a processor for the customer whose data leaked, Article 33 requires you to notify that customer without undue delay, and your contract may set a shorter window.

SOC 2

SOC 2 has no notification clock of its own; it tests your commitments. The AICPA Trust Services Criteria expect you to identify and evaluate security events, respond to incidents through a defined process, and protect information you committed to keep confidential. For an AI sharing mistake, an auditor will look for a policy that says what may be shared and evidence staff know it, a record that the event was triaged against your incident criteria, and evidence of the response: revocation, rotation, any customer notice your contracts required, and the change you made so it does not repeat. An unrecorded leak found later is a far worse finding than a recorded one handled well.

Contracts, sector rules and US state laws

Customer contracts and data processing agreements often set their own notice windows and broader incident definitions. Health, payments and financial services rules may apply depending on the data. US state breach laws generally turn on specific data elements, such as government identifiers or financial account numbers with access codes, so whether a shared chat triggers them depends on what it contained.

Common mistakes

• Treating "unlisted" as "private." A bearer link stops being secret the moment it touches DNS logs, a chat preview or a public post.
• Sharing a long running chat. It holds far more than the answer you want to show. Start a fresh chat for anything you intend to share.
• Cleaning the attachment and forgetting the prompt. The prompt is always in the snapshot.
• Revoking and assuming it is over. Revocation does not undo views, imports, stored previews or copied secrets. Rotate and record.
• Deleting the chat before recording it. You destroy your own evidence of what was exposed.
• Turning off public sharing and stopping there. Google's admin page is explicit that existing links keep working.
• Ignoring personal accounts. Admin settings cover business plans only.
• Sending customers chat links. They forward them and open them on personal devices. Send the text.
• Encoding meaning in share URLs. Titles, user names or sequential IDs in hostnames or paths make links discoverable.

FAQ

Can people see my ChatGPT, Claude or Gemini chat if I share the link?

On consumer plans, anyone who holds the link can. Business plans differ: Claude Team and Enterprise shares stay inside the organization, and Microsoft 365 Copilot requires recipients to sign in with a work account in your organization.

Do shared AI chats update when I keep chatting?

No. The products we checked share a snapshot, and later messages stay private unless you share again.

Can shared AI chats show up on Google?

They can if the share page is linked from a public page and lacks a noindex rule crawlers can read. No help page we read promised either behaviour, so test with the curl checks above.

How do I delete a shared ChatGPT link?

OpenAI's FAQ says to use the trash icon in the conversation's menu, or Settings, Data Controls, Shared links, Manage to delete one or all links. Copies recipients imported may remain.

How do I unshare a Claude chat?

In the Share dialog, switch from Public to Private or use Turn off. On Free, Pro and Max, Settings, Privacy, Shared chats lists your shares. Team and Enterprise admins can see and revoke shared chats.

How do I delete Gemini public links?

On gemini.google.com, open Settings & help, then Your public links, and choose Delete public link or Delete all links. Copies posted elsewhere and other people's continuations remain.

Can my company admin turn off chat sharing?

On business plans, usually yes: Claude Team and Enterprise admins, Google Workspace admins for Gemini, and Microsoft 365 tenants for Copilot. Consumer accounts have no admin.

Is sharing an AI chat with customer data a GDPR breach?

If the share made personal data available to people who should not see it, it is likely a personal data breach, even if accidental. Record it, assess risk, and notify within 72 hours of awareness unless it is unlikely to result in a risk to individuals.

What happened with Meta Muse shared conversations?

Per reporting summarized on Slashdot on 20 October 2026, researchers found about 6,800 Muse share links through passive DNS records because share subdomains included conversation titles. Meta suspended sharing while it considers changes.

Fix it without waiting for upstream

A shared chat link is not a dependency bug, and nothing here revokes a link. The connection is what often sits inside those chats: people paste vulnerable code and manifests into assistants to ask "how do I fix this CVE?", then share the conversation. If the fix arrives as a reviewed pull request, there is less reason to paste and share at all.

In incidents like this one, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

Safeguard's fit here is indirect. It does not see, revoke or monitor share links in any AI assistant. Where it helps is governance: its compliance suite (generally available) has areas for policies, controls, evidence, risks and vendors, so you can hold the sharing rule above as a policy, track staff acknowledgement and training against it, log a sharing mistake with its remediation, record your AI assistants as vendors, and show an auditor evidence that people know the rule. The demos show the other half: doing security work in tools that keep context on your own machine, with an approval at each step, instead of in a chat you later share.

This demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which Safeguard tools Claude may use. A tightly scoped connector lets the assistant work from permissioned data rather than documents people paste in, and Anthropic's docs say raw connector data is not shown in a shared chat.

Click through it at your own pace, or open it full screen.

This is a real Safeguard CLI session. You ask the interactive terminal to "fix the lodash CVE in this repo." It reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. It is the same "how do I fix this?" conversation people often have in a shareable web chat, kept in your terminal.

Click through it at your own pace, or open it full screen.

This real Android session sends work to a computer running the CLI, then approves the command on the phone with Allow once, Allow for turn or Deny. When a teammate needs to weigh in on a fix, an approval on a device you control is a narrower handoff than forwarding a chat link.

Click through it at your own pace, or open it full screen.

To try the CLI, download it from safeguard.sh/download and follow the CLI docs. For a single product deep dive, read what recipients see when you share a Claude chat, and for coding agent setup, is Claude Code safe to use at work.

Quick check

Sources

• Anthropic: Sharing and unsharing chats
• Anthropic: Share a chat with specific people
• Google: Share your chats from Gemini Apps
• Google Workspace Admin Help: Turn Gemini app conversation sharing on or off
• Microsoft: Share conversations and responses in Microsoft 365 Copilot
• Microsoft: Conversation history in Microsoft Copilot
• OpenAI: ChatGPT Shared Links FAQ
• Google Search Central: Block search indexing with noindex
• IETF RFC 9076: DNS Privacy Considerations
• Slack developer docs: Unfurling links in messages
• Slashdot: Meta Muse exposes users' personal, business secrets when they share conversations
• Hacker News discussion of the Muse report
• GDPR Article 33: Notification of a personal data breach to the supervisory authority
• UK ICO: Personal data breaches, a guide
• EDPB: Guidelines 01/2021 on examples regarding personal data breach notification

Last reviewed: 22 October 2026. AI assistants change their sharing features often; check each maker's linked help page for current behaviour.