Meta Pauses Muse Sharing After Internal Chats Were Found

Meta paused Muse’s conversation-sharing feature on October 20 after researchers found internal business documents behind discoverable public links. For a marketing team using AI to prepare a report, the immediate job is to check who can open the shared result. Review that separately from approval of the assistant’s access to company data.

Meta told Ars Technica that “we’ve paused this functionality while we review this report”. Its statement also said it was considering changes to how links can be discovered.

Claroc’s October 20 update supplies an important check on that response: none of 40 previously accessible shares opened in its retest. The researchers said historical records still contained their addresses and titles.

The content and the trail it left behind require separate answers.

Sharing created another audience

Claroc published its research on October 18, based on checks made October 7–8 and a report to Meta on October 8. It found more than 6,800 share addresses after filtering misleading results, but opened only a few hundred. Those counts don’t establish 6,800 sensitive documents or affected people.

Among the reported examples was a marketing company’s internal revenue review intended for its CEO. SOAM hasn’t accessed the exposed documents. The category alone makes the relevance clear: a document that belongs in a management conversation had a route to readers outside it.

In their published findings, Claroc Research Team described how little effort discovery required:

“It took one query.”

These were shares users had created. The research doesn’t establish that ordinary private Muse conversations were open, and the team reported no evidence of misuse.

For a founder-marketer, that distinction matters when deciding what to review. Start with work actually shared through the feature. Treating every private conversation as a confirmed exposure would send the review in the wrong direction and overstate what the evidence shows.

The address disclosed the subject

Muse put conversation titles into the address’s hostname, the part a browser looks up to find a server. Historical DNS services could record those names and make the shares discoverable without a recipient forwarding the link.

Spamhaus’s explanation of passive DNS describes a history of observed connections between domain names and internet addresses. A record can outlast a change to the current website. It doesn’t contain a copy of every page, or establish who read a document.

That helps explain why closing a page doesn’t necessarily remove its subject from historical records. A title can disclose that a sensitive project exists even after the file itself stops opening. Teams reviewing a share therefore need to check both access to the content and what the address says about it.

This differs from the SalesBleed finding in Salesforce’s AI workflows. There, researchers showed how incoming public text could steer an agent with private access. Here, the issue appeared when a result left the assistant through a user-created share.

Permission to work and permission to share

Meta’s September 29 small-business announcement positioned Muse to work with Meta ad accounts and services including Shopify and Slack. The company promised that publishing, sending, and spending would require approval. SOAM’s earlier coverage examined that expanded view of a business’s working data.

Approval remains useful. It lets someone decide whether an action should happen. The shared-link finding adds a question about the result: which readers does that approval actually admit?

Asaf Aprozper, Claroc’s co-founder and CTO, raised that ownership problem in a public LinkedIn post about separate LinkDrift research:

“after an application is approved and someone creates a share, who checks whether that access is still appropriate?”

That comment wasn’t a reaction to Muse. It describes the continuing responsibility after a tool has passed its initial review. Claroc sells application-security monitoring, so its interest in that responsibility is commercial as well as technical.

A marketing lead can approve an assistant’s connection to a store while keeping the resulting internal analysis restricted to colleagues. The sharing step needs to preserve that distinction. An agent’s useful access to business context doesn’t settle who should see its output.

Meta’s pause and the failed retest links are meaningful counter-evidence to an account of a continuing, verified exposure. The sample still can’t establish the status of every earlier share. Keep both limits in the incident review.

For teams that used the feature, assign someone to review their own exported work and record which links have been closed. If sharing returns, test the recipient controls with harmless content before using an internal report. An intended colleague should be able to open it, and someone outside the permitted group shouldn’t. A share feature that only offers a public page belongs with material approved for public release.