Both sides of this Meta story can be telling the truth, and that is exactly why it should worry anyone shipping an agent.
The short version: Inc. columnist Jason Aten reported that Meta’s Muse AI agent read his private messages without permission. Decrypt reported that Muse had synced messages from the Mac’s private Messages database, which requires macOS Full Disk Access, a system-level permission. Meta pushed back. Meta VP of Communications Andy Stone told TechCrunch that Muse needs both Full Disk Access and the Messages connector enabled to read Messages content, and that this combination can’t be circumvented even if the Muse app had a bug. David Singleton of Meta Superintelligence Labs said the feature was opt-in.
So you have a journalist saying the required Mac setting was off, and a company saying the architecture makes that outcome impossible. Nobody has published a reproducible trace that settles it. That gap is the story.
Permission state is a distributed systems problem
I’ve built enough connector-style integrations to know that “the user granted permission” is not a boolean you can trust at read time. It’s a claim that lives in at least three places, and those places drift.
Think about what a message-reading agent actually involves:
- An OS-level grant, held by the operating system and revocable at any moment from a settings pane the app does not control
- An app-level toggle, the connector switch, held in the app’s own config or in a server-side user record
- A cached index or embedding store, built at some earlier point in time when both of the above were true
- A model context window that may still hold content pulled from that index
Revoke the OS grant and you’ve stopped new reads. You have not necessarily cleared the index. You have not necessarily cleared whatever the agent already pulled into memory, logs, or a conversation thread it can summarize later. A user who flips a switch off and then sees their messages quoted back at them has every reason to say the agent read their messages without permission. An engineer looking at the read path can honestly say the current code cannot access Messages without both grants. Both statements can be accurate descriptions of different layers.
I’m not claiming that is what happened here. I don’t have the logs, and neither does anyone else writing about it. But it’s the failure mode I’d check first, and it’s the one most agent architectures are wide open to.
What this changes about how I build
A few practices I’ve moved from “nice to have” to “non-negotiable” after watching this play out:
Check permission at read time, not at index time
If your agent reads from a cache built an hour ago, re-verify the grant before serving anything from that cache. Treat a cached document the same way you’d treat a fresh API call. The permission check belongs next to the data access, not at the top of a setup wizard.
Make revocation destructive
When a user turns a connector off, delete the derived data. Embeddings, summaries, extracted entities, all of it. If deletion is genuinely impossible, say so in the UI before the user opts in, not after they complain. Soft-disable is how you end up with two parties disagreeing about what your product did.
Log the authorization decision, not just the action
Most of us log “read 412 messages.” Far fewer log “read 412 messages; OS grant present at timestamp X; connector enabled at timestamp Y; source index built at timestamp Z.” The second version resolves this kind of dispute in minutes. The first version produces a week of news coverage where nobody can prove anything.
Show the source on every answer
If the agent surfaces something from a private store, name the store inline. Users form their mental model from what the agent shows them, not from a settings screen they saw once. Surprise is the thing that turns a technical detail into a privacy story.
The trust math is brutal
Agents that touch private data have an asymmetric reputation curve. A hundred correct behaviors buy you very little. One episode where a user believes their texts were read without consent costs you more than a feature ships back. And because agent behavior is probabilistic and stateful, you will not always be able to say with certainty what happened unless you built for that certainty in advance.
That’s the practical takeaway for anyone building in this space. Meta has a communications team and a VP who can issue a public clarification within a day. You probably don’t. Your defense is instrumentation: permission checks tight against data access, hard deletion on revoke, and logs detailed enough that you can answer the question rather than argue about it.
Build the audit trail before you need it. The one thing worse than an agent that reads something it shouldn’t is an agent where you can’t prove it didn’t.
🕒 Published: