You never signed up for Muse. It may still hold your messages

The short version

You do not need a Muse account for Muse to hold something you wrote. You need a friend, a relative, or a coworker with one, who connected a service that contains your messages, your calendar invitations, or your documents, and who gave Muse work to do in it.

ZDNET made that point on October 27, 2026, in a piece by Charlie Osborne. This site is not treating that piece as news of a new incident. Nothing in it describes a fresh breach, a new leak, or a feature that launched this week. It is mainstream framing of a thing this blog has tracked since September: Muse builds a picture of the people in a user's life, called person pages, from what that user shares and connects. ZDNET's contribution is to stand on the other side of the thread, with the person who never agreed to any of it.

That person is not completely without a route. Meta publishes one. The route is narrow, it predates this story, and it runs into a problem built from Meta's own two promises. That problem, not a missing page, is the story.

What ZDNET reported, and what it did not

Osborne's piece starts from a simple asymmetry. A Muse user opts in and connects services: Gmail, Google Calendar, Outlook, and Meta's own apps were the examples ZDNET worked with. The user's contacts do not opt in to anything. Through those connections, a user's Muse may read or summarize a thread, a calendar, or other content containing a non-user's travel, medical, job, or financial information. ZDNET also notes Muse may use publicly available web information about that person. The piece puts Muse's scale at over 10 million users, a figure it attributes to Meta's third quarter earnings call.

For Meta's position, ZDNET turns to Meta's own pages, and the next section quotes the main one directly. There is no statement in the piece that Meta responded to ZDNET, declined to comment, or gave a new response on October 27. I found no Meta response dated October 28 to November 3 either. The searches for this post ran first on October 29 and again on November 3. Meta's published pages are still the latest word Meta has put on this.

ZDNET linked two outside voices, and both need their dates attached, because neither is a fresh reaction to the October 27 piece.

The first is Calli Schroeder, senior counsel and director of the AI and Human Rights Program at EPIC. ZDNET links her name to EPIC's own article of October 2, 2026, where Schroeder wrote that, without Meta putting better protections in place, Muse becomes a nightmare for people even when they actively choose not to engage with it. In that same EPIC piece, the section on bystanders makes the underlying point in plain terms: bystanders are not asked for consent, and are not even informed, when a user lets Muse scan their messages. That is attributed comment from a privacy advocate, published three weeks before ZDNET's piece, and I am printing it as comment.

The second is Alexis Shore Ingber, a privacy law expert and assistant professor at Syracuse University's Newhouse School of Public Communications, quoted from a Syracuse University question and answer session published on October 19, 2026. Ingber said there is not much friends and contacts can do. Her position, in the Syracuse original, is that platforms have the responsibility to protect people who do not consent to data collection by default, and that is not happening here. In paraphrase, she also argued that consent based law mostly does not work when data is collected through someone else, that the practical option is asking the person not to share your information, and that access to other people's communications would ideally be opt in. Attributed comment again, not a finding.

What Meta's own page for non-users actually says

Meta publishes a help page titled "Information for people who don't use Muse". It opens by conceding the premise: information about you may be provided to Muse when others use it, even if you do not use Muse directly, through what a user shares and through publicly available information. Because the user chooses what to share and what to ask, Meta says it cannot predict exactly what information about you may be included.

Then comes the promise, and it is worth having in Meta's exact words, because the rest of this post turns on them: "When we process information from external sources about people who don't use Muse, we don't link that information to any Meta account. This information is not stored in a way that allows Meta to reasonably identify which information belongs to a particular person."

Read that the way a lawyer wrote it, because a lawyer did. Not linked is a claim about how records are connected, not a claim that no record exists. Not stored in a way that allows Meta to reasonably identify is a claim with a qualifier inside it. Reasonably is doing work in that sentence.

The same page gives non-users their rights paragraph. You may have a right to object under applicable laws. The page links a Privacy rights request, a form about third party personal information appearing in an AI response, and an opt out form for AI phone calls to businesses. It also says Meta does not sell your information.

And then the catch, in Meta's own logic rather than mine. Meta says it can only honour data subject rights for information linked to a Meta account, or stored in a way that allows it to identify the person. For external source information about a non-user, Meta has just promised the opposite on both counts: not linked, and not stored identifiably. So the request form exists, and the class of data this page is about is, by Meta's own description, the class the form may not be able to reach. A reader who files one and gets that answer has not been lied to by either paragraph. They have been caught between them.

That is a more precise complaint than "there is no route". There is a route. Whether it works for unlinked person page data is the open question, and no source checked on October 29, or in the November 3 recheck, answered it with a worked example.

Person pages, and the confidential VM that is not here yet

Meta's security and privacy page for Muse describes the other half of the mechanism. Muse builds person pages, profiles of people a user interacts with through connected services, aggregating details of the kind a person's contacts would know: employment, relationships, preferences, health details, and similar. Meta says Muse is instructed to reference a person page only when it is clearly relevant to its work for the user. Instructed is a policy word. It is not a technical barrier.

The technical barrier has a name, and it is not available. Meta's help page about how Muse handles privacy, safety and security writes the confidential VM in the future tense. In the future, Muse users will also have the choice to use a Muse Confidential VM. Meta says it is designing that environment to keep people's information private, even from Meta. No date is given on that page. When ZDNET paraphrases that as a confidential VM being currently not available, the paraphrase is fair, but it is a paraphrase. Meta's own words are future tense and dateless.

One earlier item needs its label kept on. TestingCatalog reported on October 20, 2026 that a confidential VM is partially implemented in the web interface, with upgrade prompts and possible limits on voice, media generation, and wearables. That is a single outlet report of a partial implementation, dated before ZDNET's piece. It is not a shipping announcement. Nothing dated October 28 to November 3 turned it into one in the searches run for this post, on October 29 or November 3.

Put together, the honest sentence is this: today, what stands between your messages and Meta is policy wording, plus the access choices of the person you sent them to. It is not an environment designed to keep your information private from Meta. Meta says that environment is coming. Meta does not say when.

How this differs from the contacts story

This blog has covered the neighbouring story, and the two are easy to blur. In early October, Kim Komando wrote the consumer version of it for account holders: Muse builds profiles of a user's friends, family, and colleagues, updates them, and a user can take steps to limit what Muse learns.

A user can. That is still the difference, even after the correction above.

If you hold the account, there is a surface to work on: connections you can remove, permissions you can narrow, a history you can read, a subscription you can cancel. If you are the contact, your surface is one help page, a right to object that depends on your local law, and a request form that Meta says works only for linked or identifiable information. Your strongest practical lever is not on that page at all. It is asking the account holder.

What you can actually do, from the wrong side of the account

Ask the person. If someone tells you their Muse reads their messages, you can ask what they connected, and ask them not to run Muse over threads that include you. Ingber, in the Syracuse session, landed in the same place: there is not much a contact can do beyond asking someone not to share their personal information. That is a social fix, not a technical one, and it depends on the person agreeing. Some will.

Use the route Meta publishes, and keep the reply. File the Privacy rights request or the objection your local law gives you, if you believe Muse holds information about you through someone else's account. Go in clear eyed: Meta's page says it can only honour rights for linked or identifiable information, and a refusal on that ground is a real possibility. A refusal is also evidence. If you get one, it is the first worked example of the catch described above, and this site wants to hear about it.

Write as if a second reader exists. Once a Muse user has connected an inbox or a calendar, a message you send them can be read and summarized, and details from it can sit in a person page about you, under the limits Meta describes. Messages about health, money, children, or work that you would not want summarized by a service you never joined are better handled in a call, or in a thread you know is not connected. That is not a satisfying answer. It is the one the current product shape leaves.

Quick answers

Frequently Asked Questions

Q: Is Muse reading messages from people who never consented?

A: Through the account holder, yes, in this specific sense: Muse works in services a user connects, and those services contain messages from other people. Meta's published limits are about linking and identification, quoted in this post. Whether that arrangement counts as consent for the other people in the thread is the argument ZDNET's piece is having, and the piece contains no new Meta response to ZDNET.

Q: How is a person page about a non-user built?

A: Per Meta's pages, Muse creates profiles of people its users interact with through connected services, aggregating details a person's contacts would know, and Meta says Muse is instructed to reference a person page only when it is clearly relevant. For information from external sources about people who do not use Muse, Meta says it is not linked to any Meta account and is not stored in a way that allows Meta to reasonably identify whose it is.

Q: I have a Facebook or Instagram account but never joined Muse. Am I a non-user here?

A: For Muse, you did not sign up, and that is ZDNET's framing. Meta's non-user promise quoted in this post is narrower than it first reads: it covers information from external sources about people who do not use Muse. What Meta does with information it already holds about you from its other services is a different question, and Schroeder's EPIC piece is largely about that wider collection. This post does not merge the two.

Q: Can the account holder delete what Muse holds about me?

A: A user can change their own connections and permissions, and that can stop further work over a thread. Whether a user action deletes a person page already built about someone else is not answered in the sources checked for this post, so this page leaves it as unknown rather than promising that it does.

Q: What should I tell Muse users who message me?

A: One question does most of the work: did you connect this account to Muse? If the answer is yes, write accordingly, and move anything sensitive to a call or an unconnected thread. If the answer is no, nothing in this post applies to that thread.

Q: What happens next with this story?

A: Three things can change the box at the top of this page: Meta responds to ZDNET, a reader reports what actually happened when they used Meta's Privacy rights request for non-user data, or the confidential VM ships with a date and a way to confirm it is on. The second one is the sighting this story is missing: has someone else's Muse ever surfaced something you sent them, and if you have no Muse account, what happened when you tried to do something about it?

Sources

• ZDNET, Charlie Osborne, October 27, 2026, 12:58 pm ET, at zdnet.com/tech/muse-users-share-contacts-data-privacy-cost/. Framing, connectors, and the links to EPIC and Syracuse as published there.
• Meta, "Information for people who don't use Muse", meta.com/help/superintelligence/4532990443643263/, checked October 29, 2026. Non-user promise, right to object, and Privacy rights request wording as published there. The page shows no calendar date; it is marked updated six weeks ago.
• Meta, "How Muse handles your privacy, safety and security", meta.com/help/superintelligence/1047255454427887/, checked October 29, 2026. Confidential VM in future tense, no date given.
• Meta, security and privacy page for Muse, ai.meta.com/security-and-privacy/, checked October 29, 2026. Person pages description as published there, paraphrased in this post.
• EPIC, Calli Schroeder, "Meta's Mass Data Collection Is Not A-Muse-ing", October 2, 2026, at epic.org. The bystanders section and the quote ZDNET links.
• Syracuse University Today, "Q&A: How Other People's Choices Shape Your Privacy in the Age of AI Agents", October 19, 2026, at news.syr.edu. Alexis Shore Ingber's comments as published there.
• TestingCatalog, October 20, 2026, reporting a partial confidential VM implementation in the web interface. Single outlet, snippet and report level, no Meta date.
• Kim Komando, October 9, 2026, consumer explainer on Muse profiles of a user's contacts and the controls a user has. Cited for the account holder side only.
• Recheck, November 3, 2026: DuckDuckGo searches run that evening, and the day's demand-log sweeps, found no Meta response to ZDNET dated October 30 to November 3, no new non-user control or deletion path in that window, and no date or shipping announcement for the confidential VM.