Muse, the Meta assistant that reads Messages, Calendar and Notes

Muse, Meta's assistant, now has a native Mac app, and that app can read Messages, Calendar and Notes. The review in The Verge, published on 19 September, sums it up as a contradiction: it works well as an assistant and it still makes you uneasy. The detail that explains it best is not technical. Jason Aten, a contributing editor at Inc Magazine, posted on Threads that he asked Muse to describe itself and the assistant could not do it.

That slip looks like an anecdote. It is not. A system with read access to your message history, your calendar and your personal notes should at least be able to say what it is and what it is looking at. When it cannot, the user loses the only instrument available for gauging risk: understanding the scope of what they just authorised.

The permission matters more than the tone

The public conversation about Muse is about the feeling, about whether it comes across as sinister or merely odd. We think that is the wrong argument. What a desktop app changes is not the assistant's register, it is the surface it reaches. On most Macs, Messages, Calendar and Notes are the most sensitive archive on the machine: private conversations, addresses, a person's actual schedule, drafts nobody meant to publish.

In the Claude ecosystem the same problem is framed differently. MCP forces you to declare which server connects and which tools it exposes. Permissions are granted per tool rather than in bulk. Hooks let you intercept a call before it runs, at PreToolUse, and stop it if a condition is not met. None of that guarantees good behaviour, but it does let you answer, at any moment, the question of what the model can touch and with what.

That is where the practical difference sits: an assistant that cannot articulate its own scope, versus an access model where the scope is a configuration file you can read and audit.

What this means for anyone building integrations

If your job is connecting models to a company's data, Muse works as a free case study. Three things we take from it:

1. Broad access reads as intrusion even when it is useful. The Verge piece does not question the quality of the assistant, it questions how comfortable it is to have it inside. An internal rollout with access to the whole team's mail or calendar will hit the same resistance, and anticipating it at the design stage is cheaper than handling it at the complaint stage.
2. Being able to describe itself is not cosmetic. An assistant should be able to list its sources, its current permissions and its limits. It is the first thing any security lead asks about and the last thing that usually gets built.
3. Granularity before trust. Granting all of Messages because you need to find one quote is the modern version of handing out admin rights to install a printer. When the architecture allows it, access is scoped to the specific use case.

The missing context

Coverage of Muse arrives just as desktop assistants stop being a chat in a tab and start operating on the file system and on native apps. Claude Code is heading into that same territory from a different starting point: a command line tool, explicit permissions, skills and subagents invoked on demand. The result is less polished and considerably easier to explain to a legal department.

This is not about who wins. The two approaches solve different things, and Meta's is aimed at a user who does not want to configure anything, which is most people. But the friction The Verge describes is not fixed by better prose in the answers.

Our position, after building a fair number of integrations with access to real data: an assistant that cannot explain itself has a product problem before it has a privacy problem. If the system cannot say what it touches, the only defence left to the user is not installing it.