Mark Zuckerberg says Muse was “built from the ground up for privacy and security.” Amazon has blocked it over security risks. Both of those things are true at the same time, which tells you most of what you need to know about how AI assistants are being shipped right now.
The vulnerability itself is the kind that makes security people put their coffee down. Muse, Meta’s new AI assistant, holds an authentication token. Any local app or terminal command can reach that token. Once it does, it has full control of the assistant. That’s it. That’s the whole chain. No sophisticated exploit, no memory corruption, no clever social engineering. Just an unreasonably privileged process leaving its keys in a place where anything running on your machine can pick them up.
Privilege is the vulnerability
I keep coming back to the word “privileged” in describing Muse, because that’s the actual story. A zero-day in a note-taking app is annoying. A zero-day in something that can act on your behalf across a platform as large as Meta’s is a different category of problem. The value of a general-purpose assistant comes from how much it can do without asking permission each time. That same property is what makes a compromised assistant so dangerous.
Every agent vendor is making the same bet: give the thing broad access, because broad access is what makes it feel magical. The failure mode of that bet is that your security perimeter collapses down to a single credential. Steal the token, inherit the privileges. There’s no gradient. Either the attacker has nothing or they have everything the assistant has, which by design is a lot.
Amazon’s block says more than Meta’s blog posts
Companies don’t block popular software casually. Blocking something employees want to use generates internal friction, help desk tickets, and arguments with teams who feel slowed down. When a company the size of Amazon decides that friction is cheaper than the risk, that’s a real signal from people who had to justify the decision internally.
Compare that to Meta’s security posture, which so far consists of claims. Claims are free. I’ve reviewed enough tools to know the pattern: the marketing page describes the architecture the team intended to build, and the vulnerability report describes the one they actually shipped. The gap between those two documents is where users live.
What makes this particular gap awkward is that security was the pitch. Muse wasn’t sold as fast or clever or cheap. It was sold as trustworthy. When trustworthiness is the differentiator and the differentiator breaks, there isn’t much left to fall back on.
What this should change about how you evaluate agents
If you’re deciding whether to run an AI assistant with system-level access, the questions worth asking have shifted. Feature comparisons matter less than these:
- What can this thing do if someone else is driving? Assume the credential leaks. What’s the worst outcome? If the answer is “reads my email and can send messages as me,” you’ve described an incident, not an inconvenience.
- Where does the auth token live, and who can read it? File permissions, OS keychain, memory only. This is a boring question with a very informative answer.
- Does the assistant scope its permissions per action, or hold one credential for everything? Fine-grained scopes turn a total compromise into a partial one.
- Is there an audit trail you can actually read? If the assistant acts on your behalf, you need to know what it did and when, especially after something goes wrong.
- How fast does the vendor patch, and do they tell you? Disclosure behavior predicts future disclosure behavior.
The uncomfortable part
Muse is gaining popularity. It got the CNBC segment, the stock rally chatter, the founder-influencer video treatment. None of that changed because of a zero-day, and that’s the part I find genuinely discouraging. Adoption curves and security posture are running on separate tracks, and the adoption track is faster.
That’s not unique to Meta. The whole agent category is shipping capability first and containment later, on the assumption that users will forgive breaches faster than they’ll forgive a product that feels limited. So far that assumption has held up.
My take: Muse isn’t uniquely bad, it’s just the one that got caught this week. The design pattern behind this bug — one very powerful process, one reachable token, no meaningful isolation — is present in a lot of tools currently being described as production-ready. Meta has the resources to fix this quickly, and probably will. The question I’d want answered is why a product marketed on security shipped with a local privilege path this direct in the first place, because that answer says something about process, not just code.
Until then, if your security team blocked it, they were doing their job.
🕒 Published: