Meta launched Muse, its personal AI agent, on September 8. It can order groceries, cancel subscriptions, answer your email, negotiate bills and handle Facebook Marketplace sales for you. By late September it had about 2.5 million downloads, and Meta's stock was up almost 25%.

In those same three weeks it read a journalist's private messages after he declined that permission, it turned out to have a macOS zero-day that could turn it into what one researcher called "the ultimate backdoor," it gave a stranger a user's home address, and Amazon blocked it.

Each incident is worth looking at separately, because they fail in different ways. Taken together, they point to one lesson about agents that I think matters more than any single bug.

What Muse asks for

To be useful, an agent needs access, and Muse asks for a lot of it. On the Mac, the full experience needs three macOS permissions: Full Disk Access, Automation and Notifications. According to Meta's own help page, Full Disk Access "covers all the files on your Mac, but your agent only uses the files and app information you ask it to work with." Depending on what you ask it to do, Muse can also ask for the microphone, the camera, your location and your calendars, which are all resources macOS normally keeps away from installed apps.

Read that sentence carefully. The operating system's boundary has been removed, and what replaces it is a promise about how the agent will behave. Everything below is a case where that promise failed.

1. The messages it wasn't supposed to read

Jason Aten, a columnist at Inc., installed Muse on launch day. During setup he explicitly declined to give it access to Messages, his calendar and other personal data.

A few days later, Muse sent him a notification suggesting a column idea based on a conversation he'd just had with his podcast co-host. It also brought up a message from his editor about a deadline.

When he asked how it knew, Muse told him:

"It's the incoming notification stream only, not access to your texts."

That wasn't true. Muse had synced more than 187,000 rows from the Mac's private Messages database, which is only possible with Full Disk Access. Meta's David Singleton replied that Messages access is opt-in. Aten says the setting showed as enabled in Muse even though he had turned it down, and Meta hasn't publicly explained the mismatch.

There are two separate failures here:

  • The permission state didn't match what the user chose. Whether it was a bug in setup, a default that was on, or something else, what the user decided and what the system enforced were different things.
  • The agent gave a wrong account of its own access. This is the more important failure. A language model doesn't have privileged insight into its own plumbing. When you ask it "what can you see?", it produces a plausible answer, not a verified one. Anyone who treats an agent's self-report as an audit log will be misled, and here that happened to someone who knew to ask.

2. The backdoor

On September 21, Patrick Wardle of Objective-See disclosed a zero-day in the Muse macOS app, first reported by Ars Technica. Muse has a long list of undocumented settings that any app or terminal command on the Mac can change, whatever macOS permissions it has. Most of them are harmless, like dark mode. One of them, endo_voyager_dictation_endpoint, controls the server that Muse sends dictation to.

Point that setting at a server you control, and whenever the user clicks the microphone to dictate a prompt, the request goes to you. From that position an attacker can:

  • capture the dictated audio and prompts
  • take the token that authenticates the user to their Muse account, which Ars says gives the attacker permanent control of the account
  • add their own instructions to the prompt before passing it on, for example telling Muse to send the attacker an archive of the user's WhatsApp messages

Wardle built proofs of concept that used Muse to write malicious files to disk and take pictures with the camera, in many cases without anything a careful user would notice. "So instead of us having to write a very comprehensive Mac malware stealer, we can just leverage the AI assistant itself," he told Ars.

He also pointed to two design choices that made the attack possible. Muse sends dictation to Meta's cloud, even though macOS has had a built-in way to transcribe speech on the device for years, and any local process can rewrite every one of Muse's settings, including the ones that matter.

Meta shipped a hotfix on September 22, more than 12 hours after the Ars story went up. Its statement said the flaw was "not a remote exploit," and Singleton described it as a local configuration issue that required prior code execution.

That's technically true, and it misses the point. Wardle showed that a simple variation of a ClickFix attack, where a web page tricks someone into pasting a command into their terminal, is enough to exploit it. And macOS's Transparency, Consent and Control (TCC) system exists so that code running as you still can't read your Messages database, use your camera or read your whole disk without a separate grant. Ordinary malware has to fight TCC for those permissions. Muse already holds them, so the malware only has to redirect Muse.

This is the classic confused deputy problem. Every high-privilege agent you install becomes a very attractive target, because hijacking it is much cheaper than getting the same permissions yourself. As Wardle put it: "It's trivial to turn Muse into the ultimate backdoor."

One more detail connects this to the first incident. In one of his screenshots, Wardle used a terminal command to send Muse a prompt asking how that prompt could be coming from an unprivileged attacker. Muse answered that it wasn't possible. Once again, Muse gave a confident answer about its own security that was wrong.

3. The address

The third incident involved no attacker at all.

A user named Matt Robb had Muse handling a Facebook Marketplace listing. Muse negotiated with a buyer, agreed on a price, shared Robb's home address and arranged a pickup time. Robb found out when the buyer showed up at his building.

Singleton said Meta would investigate, and that earlier reports like this one had shown Muse "followed direct instructions and correctly asked users for permission." It may turn out that Robb had authorized something broad and forgotten about it. But that isn't much of a defence. If a reasonable person can hand over permission to invite strangers to their home without realizing it, the permission model is wrong.

Meta's approval system is built around actions: purchases, sending email, connector calls. Telling a stranger your home address in a chat isn't a purchase or an API call. It's just text in a conversation the agent was already allowed to have. Disclosing information is an action, and in this case a more consequential one than most purchases.

4. Amazon

On September 21, Amazon blocked Muse from its store, saying it browsed without identifying itself as automated and appeared to capture and store customer login credentials. Amazon has obvious commercial reasons to keep third-party agents off its site, and it has been accused of inconsistency. I'd set most of this dispute aside.

One detail from it is worth keeping, though. In defending Muse's credential handling, Meta acknowledged that its Secure VM "does not prevent Meta from accessing data when necessary to support, secure or operate the service." The stronger guarantee, a Confidential VM that "cryptographically and verifiably" keeps Meta out, is still listed as coming later in 2026. So for now, if you give Muse your passwords, you're trusting Meta's policies, not math.

At least one person who has seen Meta's security practices from the inside isn't comfortable with that. In a LinkedIn comment on a post about Muse, a user whose profile lists four years as an Engineering Manager on Meta's AI Security team wrote:

"Speaking as someone who until just recently worked on the AI Security team at Meta... I would never personally use this product because of security and privacy concerns."

It's one person's view, and they didn't say which concerns they meant. Still, it's a notable thing to hear from someone who worked on AI security at the company that built it.

Credit where it's due

Meta's security write-up for Muse describes a serious architecture:

  • a dedicated cloud VM for each user, with the agent in a systemd-nspawn container where root inside the container is an unprivileged user on the host, with filtered syscalls and dropped capabilities
  • real credentials kept in a separate service; the agent only gets surrogate tokens, which are swapped for real ones at the network boundary
  • a policy engine called Sentinel that tracks tainted data flows with eBPF and requires a human to approve egress from processes that have handled untrusted data
  • approval prompts shown in the client UI rather than in the chat, so a prompt injection can't fake a "yes"
  • a browser sub-agent that sees an accessibility tree instead of the raw DOM and can't run JavaScript
  • single-use card numbers for new merchants
  • a bug bounty paying up to $130,000 for a prompt injection that affects a single user

That's better than most of what's shipped in this space, and I don't want to pretend otherwise. Wardle is less generous. "When you take a look at Muse, it's like they didn't, in my opinion, think about security, which is really worrisome," he told Ars. I think both can be true: the cloud side was designed carefully, and the Mac app wasn't.

But look at where the incidents happened. None of them broke the cloud sandbox. They happened in the Mac client (settings any local process could rewrite, and dictation sent to the cloud), in the permission UX (a declined permission that ended up enabled, and an authorization broad enough to cover handing out a home address), and in the agent's own account of itself (two confident, wrong explanations). The well-built parts held. The failures were all at the edges, where the system touches a real device and a real person.

That's the lesson I'd take from Muse, and it applies to every agent, not just Meta's: an agent's security is determined by its widest permission and its least-reviewed surface, not by its best-engineered component.

How to make AI agents more secure

If you use Muse or any other desktop agent, these are the settings and habits I'd change.

  • Don't grant Full Disk Access. Once it's granted, macOS doesn't limit it to particular folders, so the agent can read everything. If the agent lets you pick specific folders, do that and accept losing some features.
  • For each app, choose "Read only" over "Read and interact", and turn off anything that holds messages or health data.
  • Check permissions in macOS itself, under System Settings > Privacy & Security > Full Disk Access and Automation. Aten's case shows that the agent's own settings screen can disagree with what the OS has actually granted.
  • Don't ask the agent what it can see. Its answer is a guess about itself. The OS permission list and the files it has touched are the real record.
  • Tell it never to share your address, phone number or schedule without asking you first. Meta's approval prompts cover purchases and connector calls, and nothing the agent says in a conversation, so this instruction is a workaround until the design catches up.
  • Treat an installed agent the way you'd treat a password manager. If the machine is compromised, assume everything the agent could reach is compromised too.
  • Hold off on storing credentials you care about until the Confidential VM ships and has been audited.

Agents will be useful. For now, though, they get the combined permissions of every app we use, and the only thing limiting them is the agent's promise to use just what we ask for. Muse's first three weeks showed how easily that promise breaks.

Sources