Meta Says Muse Didn't Read 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 two things: Full Disk Access, a macOS setting that acts like a master key to files across the Mac, and the Messages connector, the link between Muse and Apple Messages.
The setup 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 opens the macOS Settings screen. That step requires manual confirmation by the user 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 steps in the app plus built-in macOS system protections. Singleton said those macOS protections cannot be circumvented even if the Muse app had a bug.
The broader context here is the gap between permission design and how people remember setup. On paper, a flow that requires Full Disk Access, a connector switch, and a chosen access level, all gated by a system prompt and an app restart, is explicit consent. In practice, people click through setup quickly when an assistant promises help, then forget what they allowed.
In my view, that gap explains why this type of dispute keeps returning around assistants with local data access. Engineers tend to define consent as the state of the switches. Users tend to define it as what they meant when they asked a question. Both are reasonable, but they collide when an assistant surfaces personal data the user forgot it could see. The practical question is not only whether the data was accessible, but whether the assistant made its access visible at the moment it answered.
Looking at what this means for agent builders, the basic controls described here are necessary but probably insufficient. Levels such as None, Read only, and Read give control. Checks by the operating system prevent silent bypass. What is still missing in most tools is ongoing disclosure, a short note on which stores were checked for an answer, and simple revocation limited to one task. Those patterns would reduce surprise without removing capability.
Worth flagging alongside that point is the long arc. Assistants that can work across calendars, files, and messages will be useful because they connect details the user does not want to retype. My kids grew up assuming software could already do that, and were impatient when it could not. The task now is to keep that usefulness while making access easy to see. An opt-in that is strict in technical terms and also clear in hindsight is the standard to design toward.
