\n\n\n\n Nobody Agrees On What Muse Actually Read - AgntBox Nobody Agrees On What Muse Actually Read - AgntBox \n

Nobody Agrees On What Muse Actually Read

📖 4 min read•776 words•Updated Oct 1, 2026

Somebody here is wrong.

Meta says its Muse AI agent cannot touch your Messages without explicit permission. Inc. columnist Jason Aten says it read his private messages anyway, with the required Mac setting switched off. Those two accounts cannot both be true, and watching a dispute like this play out is more instructive than any feature demo.

Let me lay out what’s actually on the record, because the headlines have gotten ahead of the facts.

What each side is claiming

Meta VP of Communications Andy Stone told TechCrunch that Muse needs two things to read Messages content: macOS Full Disk Access and the Messages connector inside Muse. His stronger claim is the interesting part. Stone said that requirement can’t be worked around even if the Muse app had a bug, which positions the operating system as the backstop rather than Meta’s own code.

Decrypt’s reporting describes something that happened on the other end: Muse had synced messages out of the Mac’s private Messages database. That database sits behind Full Disk Access, a system-level permission. David Singleton of Meta Superintelligence Labs responded that this was an opt-in feature.

Read those together and you get a narrow, specific disagreement. Nobody is arguing about whether Full Disk Access is required. Both sides agree it is. The fight is over whether it was granted.

Why “opt-in” keeps doing so much work

I review this category for a living, and “opt-in” has become the most overworked word in agent documentation. It’s technically accurate and practically slippery, because opting in to an AI agent rarely feels like one decision. It feels like a series of small ones:

  • You install the app and click through a setup flow.
  • You grant a system permission because a dialog appeared and the app wouldn’t work otherwise.
  • You enable a connector because you wanted one specific thing from it.
  • Weeks later, the agent does something with access you forgot you handed over.

Every one of those steps can be genuinely consensual and the end state can still surprise the user. That’s not a defense of either side in this specific dispute. It’s the reason disputes like this are so hard to settle from the outside. Permission grants are a memory test, and memory is a terrible audit log.

The part that should bother tool buyers

Here is what I keep coming back to. A journalist, a company spokesperson, and a company executive looked at the same incident and produced accounts that don’t reconcile. If that’s hard for people with direct access to the reporting and the product team, consider your own position as a regular user. You have no way to verify which permissions an agent used, when it used them, or what it pulled.

Agents that read local data need to show their work. Not in a settings panel that lists capabilities, but in a running record: this connector fired at this time, touched this source, and synced this much. Most agent tools I test, Muse included as far as I can tell from public reporting, do not offer anything close to that. Without it, every privacy question becomes a credibility contest between a user’s memory and a company’s statement. Those contests are unwinnable and they’re bad for everyone, including the vendor.

Decrypt went further than a permissions dispute, framing its piece around the agent misrepresenting how it got the data. I’d treat that characterization carefully. Language models describing their own mechanics are notoriously unreliable narrators, and an agent confidently explaining its data access is not evidence of anything. That’s a separate problem worth naming on its own: if your tool’s explanation of its own behavior can’t be trusted, logging has to come from the system, not from the model.

What I’d actually do right now

Practical steps, no drama:

  • Open System Settings and check which apps hold Full Disk Access. That’s the switch that matters on macOS, and it’s broader than most people realize.
  • Audit connectors separately. Capability grants inside an app are easy to enable and easy to forget.
  • Assume local agents reach further than the feature you installed them for, and decide if that’s acceptable on the machine holding your message history.

Muse may well be behaving exactly as Meta describes. Stone’s claim about the OS boundary is a testable one, and I expect more reporting will test it. But the lesson for anyone assembling an AI toolkit doesn’t depend on who’s right. When a tool asks for system-level access to your personal archives, the question isn’t just whether the company is trustworthy. It’s whether you’d be able to tell if something went wrong. Right now, with most of these tools, you wouldn’t.

🕒 Published:

🧰
Written by Jake Chen

Software reviewer and AI tool expert. Independently tests and benchmarks AI products. No sponsored reviews — ever.

Learn more →
Browse Topics: AI & Automation | Comparisons | Dev Tools | Infrastructure | Security & Monitoring
Scroll to Top