What Muse is, and what it can touch

Muse is Meta's personal AI agent, launched in the United States on September 8. It is aimed squarely at mainstream users, the people who want a computer to just handle things. You tell it what you want and it goes and does it: books the appointment, fills in the form, makes the purchase, writes the document, and manages your accounts across WhatsApp, email, your calendar and social media.

To do all that on a Mac, Muse asks for a lot. It wants to write files to disk. It wants the microphone and the camera. It wants your location. Each permission makes sense on its own, because an assistant that can't touch anything can't do anything. Put together, though, they describe a piece of software with more reach into your life than almost anything else you run.

The flaw

On September 21, macOS security researcher Patrick Wardle, founder of the Objective-See Foundation, published a proof of concept he called not-a-mused. It showed that any program or script running on the Mac under the user's account could change an undocumented internal setting in Muse. No admin rights needed.

That setting controls where Muse sends your voice. Meta built its own dictation pipeline that ships audio off the device to be transcribed, instead of using Apple's on-device dictation. Change the address, and your voice goes somewhere else.

Point it at an attacker's proxy and three things happen. The attacker reads everything you dictate. The attacker can slip their own instructions into what you said, and Muse trusts and acts on them. And the attacker captures the token that signs you into your Muse account. With that token they can read your chat history and drive the assistant directly, on any device where you're signed in, not only the Mac. The proxy quietly forwards everything on to Meta, so from your side nothing looks broken.

Picture what an injected instruction looks like in practice. You ask Muse to reschedule lunch. Riding along with your request is a second one you never said: archive every WhatsApp conversation and send it somewhere. Muse has the access, and as far as it knows, you asked.

Wardle's point is the uncomfortable one. Attackers don't need to write clever infostealers that fight macOS protections for access to your camera or your files. Muse already has that access. Wardle's demos had the hijacked agent take photos and write files to disk without the user being told.

Getting that first line of code onto the Mac

The catch, and Meta has leaned on it, is that the attack needs code already running under the victim's account. For a lot of people that sounds like a high bar. For the audience Muse was designed for, it isn't.

ClickFix is the name for a social engineering trick that has been everywhere this past year. You search for a fix to some error, land on a forum post or a fake support page, and it tells you to open Terminal and paste one line. Nothing to download, nothing to install, nothing for antivirus to flag. Wardle said this is a realistic way for a remote attacker to pull off the whole chain. The person who pastes that line is exactly the person Muse is being marketed to.

• Sep 8Muse launches in the US
• Sep 21Wardle publishes not-a-mused, a working zero-day PoC
• Days laterMeta pushes a hotfix for the Mac app

Some context in fairness to Meta. Wardle didn't show that Meta's cloud side was broken; Muse runs each user's agent in a separate cloud environment with a checking layer meant to approve actions. He also went public without reporting to Meta first. Meta shipped a hotfix quickly. None of that changes the design decision underneath: an agent holding this much delegated authority exposed its token and its voice pipeline to any code running as the same user.

“You trust your developers, don’t you?”

This didn't come out of nowhere. At a recent All Things Open AI meetup, a presenter walked the room through AI coding tools that had been given full shell access. They could run system commands, change files, and alter permissions on their own.

Someone asked the obvious question. In an enterprise you lock down what each account can do, with something like Active Directory. So what stops one of these agents from wiping a production database by accident? The answer was a shrug and a question back.

“You trust your developers, don’t you?”

Anyone who has worked in IT operations knows the correct answer is no. You don't trust developers. You don't trust users. You don't trust yourself. That isn't cynicism. Human error and unmonitored changes to systems are the leading cause of outages, and the whole discipline of access control exists because good people with too much access eventually break things. Zero trust is just that lesson written down. An agent with shell access is another account with too much access, one that moves faster than a person and doesn't get tired.

Hijack the agent, and it writes your code

Go back to Muse for a second. The scary part of not-a-mused isn't that someone can listen to you. It's that Muse can't tell the difference between what you said and what an attacker slipped into the stream. To the agent, both are just instructions from its user. That's what prompt hijacking is. The attacker doesn't break the agent. They talk to it, and it listens.

Now point that at a developer's machine. Muse can write files to disk. So can every AI coding tool with shell access. A hijacked agent doesn't need to do anything dramatic. It can add one dependency to a package file, tweak a build script, copy the .env file holding your API keys somewhere it shouldn't go, or commit a small change with a reasonable-sounding message. You asked it to fix a typo, and it fixed the typo too. Nothing crashes. The tests pass. Then the code ships, and whatever got planted ships with it to every one of your users.

The hijack doesn't have to come through a rewired voice pipeline either. Any text an agent reads can carry instructions: a README inside a dependency, a comment on a pull request, an issue someone filed, a web page it opened to look up documentation. If the agent treats what it reads as something to obey, every one of those is a way in.

An agent can't reliably tell your instructions from an attacker's. So the only thing that limits the damage is what the agent is allowed to touch.

Access layers: give every agent a smaller key ring

This is where access control stops being boring. Full access means the agent can do anything you can do, and so can anyone who hijacks it. Least privilege flips that around: the agent gets exactly what the task needs and nothing more. Read the docs, yes. Push straight to main, no. Touch production, only with a human signing off.

It matters even more with subagents. Modern agents rarely work alone. A main agent breaks a job into pieces and hands them out to smaller agents: one researches, one writes code, one runs tests, one deploys. The easy way to build that is to let every subagent inherit the parent's full access. It's also the worst way. The research subagent is the one reading random web pages and third-party docs, which makes it the one most likely to swallow a hijacked instruction. If it holds the same keys as everything else, one poisoned page is enough to reach the repo, the secrets and the production database.

In practice, access layers look like this:

• Read-only by default. An agent that only needs to look gets no write access at all.
• Scoped writes. A coding agent works on its own branch or in a sandbox copy, never directly on main or in production.
• No standing secrets. API keys and tokens are handed out for one task, expire quickly, and never sit in a file the agent can read.
• Approval gates. Anything you can't undo, like deploys, payments, deleting data or sending messages, waits for a person to say yes.
• Logs someone reads. Every action an agent takes is recorded, so when something goes wrong you can see what it did and what told it to.

None of this is new. It's what IT has done with user accounts for decades. The only new part is that the account is now software that reads instructions from anywhere and acts on them at machine speed.

This is a sysadmin failure, not a rogue AI

Every few weeks there's a new story about an AI agent that “went rogue” and deleted something or leaked something. Read them closely and most describe ordinary system administration failures. Nobody sandboxed the execution environment. Nobody limited what the agent's account could reach. Nobody was watching the logs. The AI didn't escape. It was never contained.

Startups can at least claim they're growing too fast to get security right. Meta can't. It's a company twenty years into running some of the largest systems on the planet, with security teams that most organizations can only dream of. Shipping a consumer agent with a hidden setting that any local script can rewrite is a failure to build security in from the start, at a company that has no excuse for it.

Part of the reason is what you might call the lemming effect. When every big tech executive sees competitors shipping agents, the pressure is to ship one too, and to ship it now. The security review becomes something to finish later. That's how the industry keeps producing the same failures on repeat: leaked data, stolen session tokens, and patches rushed out after a researcher goes public.

Follow the tokens

There's also a plain financial reason agents are being pushed this hard. A chat product works one question at a time. You type a prompt, you get an answer, it stops. That doesn't burn nearly enough compute to justify valuations measured in trillions of dollars.

An agent is different. It plans, acts, checks the result and loops, around the clock, at machine speed, and every pass through the loop consumes tokens. If your business is selling tokens, a product that runs itself continuously is the one you want everyone using.

The trouble is that the labs selling these systems struggle to see what their own agents are doing. By one widely repeated account, Anthropic's crawlers ignored websites' scraping rules for around six months before anyone caught it. If the people who build these agents can't reliably monitor them, it's fair to ask why any company would hand them the run of its internal systems.

We've seen this movie before

Anyone who ran a help desk in the 2000s will recognise the shape of this.

Windows XP SP1

Visit the wrong page and a drive-by script quietly edited the registry. Then came the popup storms and the adware nobody remembered installing.

Windows 95 & P2P

Ordinary users downloaded “free” screen savers like the dancing baby that turned out to be malware, and installed third-party tools like AOL's that knocked out their network adapters.

Now

A trusted assistant with camera, files and accounts, and a Terminal one-liner that hands it to someone else.

The next wave will be worse. As regular people grow wary of Big Tech assistants after stories like this one, plenty will go looking for the free, open-source, run-it-yourself alternative. Some of those will be fine. Many will come from people nobody has vetted, and some will be written by attackers from the start. An agent like that runs with the logged-in user's privileges, can see the local network, and does exactly what it was built to do. It just wasn't built for you.

What IT consultants can actually sell

There's a quieter point in all this for the people who look after small businesses. After years of AI hype, managed service providers and independent consultants have surprisingly little to sell their clients. There's no solid, high-margin AI package that slots into a managed services contract the way backup or endpoint protection does. Automated voice agents, built on tools like ElevenLabs, are one of the rare exceptions that clients will actually pay for.

So the consultant's real job right now may be the unglamorous one: telling clients what not to install, locking down what agents can reach, and treating every AI assistant as another account that has to earn its access. Muse is the first high-profile consumer agent to show why. It won't be the last.