Skip to main content

Muse memory needs a privacy check for the people in your messages

Reported people profiles bring relationship context into the agent's memory. VM isolation, editing controls and training choices address different risks.

Three wooden figures connected by blue thread, with the central figure on a glass tile
TechKili · AI-generated illustration with Cloudflare FLUX
Share this article:
In this article

Muse's relationship memory makes a privacy decision about more than the person opening the account. WIRED's October 3, 2026 report describes internal instructions for building pages about people in a user's life, with context accumulated over time. Meta launched the agent on September 8; the report does not establish when those instructions first entered service.

For someone connecting messages or a calendar, the useful question is what the assistant retains and infers about the people represented in that material—not only whether it can send a message safely.

Source messages and generated memory are different

The reported instructions organize people-related context into facts, relationship history and possible follow-up actions. That describes an intended memory structure, rather than independently proving that every user has the same populated profiles.

Meta's help documentation confirms a broader point: Muse learns from information directly shared in conversations, patterns it observes and connected-service context, using a file-based memory system. It says users can ask for changes or manually edit that information.

A message can contain one person's account of another person's circumstances. Turning it into durable context introduces an additional judgment: which statement is a fact, whose perspective it represents and whether it remains current. TechKili's assessment is that reviewing the generated memory matters alongside reviewing the original access grant. A secure container cannot make an inference accurate or ensure that the person described would welcome it.

Isolation does not settle every data choice

In its September 8 architecture and data-policy explanation, Meta describes a dedicated, isolated virtual machine for each user and an external permission authority for actions. It says the system described there permits Meta access when necessary to operate, support or secure the service. That document presents Confidential VM as a future capability; it does not establish that a reader's account has it.

Meta says conversations and VM data are not shared with its advertising systems. Separately, it says sanitized interaction trajectories can be used for model training, with an opt-out in settings. Those are company policy and architecture statements; they answer different questions from what a memory file contains about a contact.

A model-training switch, a permission to send an email and an edited memory entry should therefore be evaluated separately. None, by itself, demonstrates that every copy or record of an earlier conversation has been erased.

Inspect the context before broadening access

Start by identifying the task that needs a connector, then inspect the memory it produces. Look for unsupported relationship judgments, mistaken identities and information that no longer serves the task. Use Meta's documented editing controls rather than assuming that better personalization always requires more connected data.

Our coverage of Apple's planned macOS access-consent changes explains the separate question of what an app is allowed to read. Muse adds a downstream question: what does an agent turn that access into? A narrower initial connection gives a user a more manageable basis for assessing that answer. This article does not demonstrate a breach or independently audit Muse's current execution.

Sources