Risk 1 — The reported Mac Messages incident (USER-REPORTED, DISPUTED, NOT A CONFIRMED BREACH)
This must be stated precisely, because the popular version of this story overstates it.
What was reported. Inc. columnist Jason Aten published a column on 2026-09-19, "Meta's New Muse AI Agent Read My Private Messages. I Never Asked It To." His account, from his own words in that column:
- He installed Muse on 2026-09-08 on an iPhone and a Mac mini he keeps for testing agents.
- He says he "explicitly" chose not to let Muse access his messages, calendar, or other personal information during setup.
- Days later Muse sent a push notification proposing that a conversation he had with his podcast co-host Stephen Robles about new iPhones would make a good column, and flagged a message from his editor about having a column ready.
- Asked how it knew, Muse told him: "When a notification pops up on your paired Mac, the text of that notification gets relayed to me… I can't open your Messages app, scroll threads, or read history. It's the incoming notification stream only, not access to your texts."
- Aten dug further and wrote: "Muse does sync your messages from the local Messages database and uploads that information as a data source. On my device, it had been activated and synced to row 187,462 of my Messages database." He immediately adds: "I'm not sure how many messages that equates to."
Three corrections that matter.
- "187,000" is a database row offset, not a message count. Aten himself says he does not know how many messages it maps to. Media shorthand ("187,000 iMessages") is not supported by the source.
- "Synced" is not "exfiltrated." Aten reports a local sync feeding an internal data source. He does not report that the data was sent to an attacker or misused externally. Apple's own 2026-10-02 statement describes the risk as developers using Full Disk Access in ways that "could put users at risk" — a forward-looking risk, not a confirmed exfiltration.
- It is a single user's report with no logs and no independent reproduction. No outlet located for this story tested Muse. No adjudicator has ruled. It is not a confirmed breach.
Meta's response (COMPANY CLAIM / FACT that the statements were made).
- Andy Stone, Meta VP of Communications, on X, 2026-09-30: "Let's set the record straight: the Messages integration in the Muse app for Mac is entirely opt-in. You have to enable both Full Disk Access and the Messages connector for Muse to be able to read your Messages content. It can't read your Messages unless you do this. And it can be revoked at any time."
- David Singleton, Meta Superintelligence Labs, on Threads, replying to Aten directly, described "three separate steps of application-level permissions and built-in macOS system-level protections" that "can't be circumvented even if the Muse application had a bug," including that Full Disk Access triggers a macOS Settings confirmation and a full restart of the Muse app. Singleton also said Muse's own notification-banner explanation was wrong — Meta's executive conceded that much.
The unresolved contradiction. Meta's entire defence rests on Full Disk Access having been enabled on Aten's machine. Aten states in his column that the Muse Mac app settings pane showed Full Disk Access not enabled and that it "does not appear in the Security and Privacy settings at all." Three outlets (TechCrunch, Decrypt, a third-party analysis) report no logs and no test. The dispute is live and unadjudicated as of 2026-10-02. Aten says he contacted Meta twice and did not receive an explanation.
Why this still matters for SMB. Even if Meta is right that permission was granted inadvertently, Aten's central argument survives: a system that can end up reading a Messages database without the user realising it is a badly designed consent surface. He writes that granting Singleton's premise, "you should not design a system that way." And Meta's own architecture post concedes the weak point — Sentinel, eBPF taint tracking, and connector policy live entirely on the server/VM side. The Mac Messages connector is client-side, and Meta's public defence of it is two executives asserting what a toggle must have shown.
Material follow-through. On 2026-10-02 Apple said it will add controls so that Full Disk Access "can only be done with very explicit user action," stating that "as AI agents become increasingly capable and autonomous, the risks associated with this level of access will grow substantially." Reuters connected this directly to the Muse complaints. This is a platform-level response to an unresolved product dispute — a bad signal for the whole agent category, not only for Meta.
Risk 2 — Consent errors now carry financial weight
A permission mistake on a consumer agent costs a user embarrassment. The same class of mistake on Muse for Small Business can publish a campaign, message a customer list, or move money in a storefront. Meta's approval model is the mitigation; the approval model is also the thing under dispute.
Risk 3 — No published effectiveness evidence
FACT. Meta has published no accuracy, reliability, cost or time-saved data for Muse for Small Business. The launch materials consist of a prompt to try, an owner testimonial (Tom Mulholland, Mulholland Grocery, Malvern, Iowa, describing a ~65-hour week and saying Muse is "taking over a few" of the owner roles), and a partner quote from Canva. Treat all as COMPANY CLAIM.
Risk 4 — Ad-adjacent data in an agent
Meta's own post says Muse VM data is not shared with Meta ad systems, while acknowledging that Muse's browsing can indirectly influence which ads a user sees. For a business user, an agent with a live ad account and a browsing history is an advertising-feedback loop that Meta controls on one side. That is a conflict-of-interest question Meta has addressed in policy terms only.
Risk 5 — Trajectory training default
Meta says trajectories used for training are sanitised for key PII, and that an opt-out exists. The default is opt-out, not opt-in — and the sanitised data now includes small-business books, ad accounts and customer records, not just a personal inbox.
Risk 6 — Agent identity and platform blocking
Reported contemporaneously with the dispute (via Decrypt and Decrypt's citing outlets): Amazon blocked Muse from shopping on its site on 2026-09-21, saying the agent does not identify itself while browsing and appears to capture customer credentials. Meta's own security post says the browser sub-agent "sees an accessibility tree snapshot of the page — not the raw DOM" and that a credential store is injected at point of need. Both accounts are COMPANY CLAIM on a contested point; treat the Amazon block as reported, not adjudicated.