Meta Disputes Claim Muse Read Private Messages Without Permission

Meta disputes a claim that its Muse AI agent read a user's private messages without permission.

The dispute was stated on Sept. 30 by Andy Stone, Meta's VP of Communications, in response to a first-hand account from Inc. columnist Jason Aten. Stone said the company does not believe Muse read messages without user consent. TechCrunch

Aten's account was published on Sept. 19 under the headline "Meta's New Muse AI Agent Read My Private Messages. I Never Asked It To". In that piece, Aten reported that Muse had read his private messages without being asked to do so. Inc.

Stone described the Messages integration in the Muse app for Mac as entirely opt-in. He stated that Muse cannot read Messages content unless the user enables both Full Disk Access and the Messages connector.

The enablement sequence requires explicit action in the app. A user must first grant Full Disk Access and then choose an access level of None, Read only, or Read. Those options are grayed out if Full Disk Access is not enabled.

Granting Full Disk Access invokes the macOS Settings interface. That step requires manual user confirmation and triggers a full restart of the Muse app.

David Singleton, an executive in Meta Superintelligence Labs, said letting Muse read Mac messages involves three separate application-level permission steps plus built-in macOS system-level protections. Singleton said those macOS protections cannot be circumvented even if the Muse application had a bug.

The broader context here is the gap that often opens between permission architecture and user mental models. On paper, a flow that requires Full Disk Access, a connector toggle, and an explicit access level, all gated by an operating system prompt and an app restart, is explicit consent. In practice, users click through multi-step onboarding quickly, especially when an agent promises to be helpful, and later have no memory of granting access.

In my view, that gap explains why this class of dispute keeps recurring around agents with local data access. Engineers tend to define consent as the state of the toggles. Users tend to define it as what they intended in the moment they asked a question. Both definitions are coherent, but they collide when an agent surfaces personal data the user had forgotten it could see. For a tech-literate audience, the relevant question is not only whether the bits were legally accessible, but whether the agent made its current scope visible at inference time.

Looking at what this means for agent builders, the permission primitives described here are necessary but probably insufficient. Granular levels such as None, Read only, and Read give control. Operating system mediation prevents silent bypass. What is still missing in most implementations is continuous disclosure, a short statement of which stores were consulted to produce a given answer, and easy revocation scoped to a single task. Those patterns would reduce surprise without removing capability.

Worth flagging alongside that point is the long arc. Agents that can work across calendars, files, and messages will be genuinely useful precisely because they can connect context the user does not want to retype. My kids grew up assuming software could already do that, and they were impatient when it could not. The engineering task now is to preserve that usefulness while making access legible. An opt-in that is technically rigorous and also obvious in retrospect is the standard to design toward.