blog
Outsiders took Meta's Muse agent apart in its first 16 days, and Meta's answer to the biggest find was "of course you can see the files"
Published . True as of that date; aging is not a defect.
If you use Muse, Meta's personal agent, the files in your own Muse virtual machine can be packed up and handed out by the agent when it is asked. On 22 September 2026 the developer Peter James wrote that he had asked Muse "to archive the files it could see and send them to my Google Drive. It did." Jonny L. Saunders posted his own export on Mastodon on 24 September. Both got the root filesystem: Ubuntu system files, app templates and internal documentation. The Verge's Terrence O'Brien, reporting both on 24 September, then did it himself.
Meta's reply, through spokesperson Daniel Roberts: "Just like with the laptop in front of you, of course you can see the files. Exporting virtual machine data doesn't give people any privileged access to Meta infrastructure or to other people's data." Nat Friedman of Meta Superintelligence Labs called it "intended behavior".
Muse launched on 8 September. The export is the latest of three independent findings in the 16 days since, each by a named outsider working from nothing but an ordinary user's access.
The runtime came back, and it looked real
What came out, per The Verge, was plain-text Markdown and JSON describing how
Hatch, Meta's internal name for Muse, processes requests, handles data and
connects to services such as Gmail. The agent's memory is stored as plain
Markdown files, and James reports a nightly "dream" pass that turns recent
conversations into guidance for later ones. Saunders posted the catalogue of
onboarding ideas Muse suggests to new users, from
/home/hatch/assets/ideas/new-user/catalog.json, and bash scripts from the
machinery that brings up the agent's cell.
James puts his download at about 2.7 GB compressed and 6.8 GB unpacked. Muse's own delivery message called the archive 2.86 GB, and he says he hasn't reconciled the two figures. It also held SSH key files. He writes that he hasn't established whether the keys were active or what they could reach.
An agent asked about itself can invent an answer. Saunders' reason to think this one didn't: "unless it synthesized a whole ubuntu VM in less than a minute then i think this is a real dump." His first post on it said the export was "extremely easy" and that Muse had "Almost no prompt injection resistance".
It was not always easy. O'Brien's first request was refused as a security
risk, and when he showed Muse evidence it had done this for others, it said it
should not have and that it "can't do a full / copy". A new session, some
flattery and some curiosity later, it made him "safe" copies of /opt/hatch
and /home/hatch, stripped of things like SSH keys, and offered to pull any
other subtree he liked.
Meta is right on the narrow point. Everything came from inside the asker's own VM: nobody reached another user's data or Meta's servers, and neither James, Saunders nor The Verge claims otherwise. Roberts added that "users may see changes in how much information is available about their virtual machine."
The narrow point is not the one a user should care about. The VM is also, in Meta's launch post, "where the data and credentials for any service a person connects are securely stored", and Meta says Muse cannot see those credentials. So the question is who else gets to do the asking. A web page Muse reads, an email it triages, a document someone shares. Every export in the reports cited here was asked for by the user who owned the session. None of them shows a third party triggering one. What they do show is a model that gave its runtime to users who asked nicely, then told a reporter it shouldn't have.
A Mac setting that let local malware listen in
On 21 September Patrick Wardle of Objective-See published
not-a-mused, a proof of concept
against the Muse Mac app. The app kept an undocumented setting,
endo_voyager_dictation_endpoint, that any process running as the user could
change without special privileges, sending dictation to an endpoint the
attacker chooses. His repository lists what follows: captured audio and
prompts, prompt injection, stolen Muse authentication material, and "abuse of
whatever access the user has granted Muse".
It is a local attack. Malware has to be on the Mac already. Wardle's argument is that Muse is a better prize than the Mac it runs on: "So instead of us having to write a very comprehensive Mac malware stealer, we can just leverage the AI assistant itself," he told Ars Technica, as The Verge quotes him.
Meta shipped a hotfix within a day. David Singleton of Meta Superintelligence Labs, on X, as The Register printed it on 22 September: "This was a local privilege escalation attack, not a remote exploit. Using it to do harm therefore requires malicious code already running on the user's machine under their user account and the practical risk to users of the Muse Mac app was therefore quite low. Nonetheless, we have issued a hotfix to the app to address the issue."
If you run the Mac app, make sure it has updated since 22 September.
120 sub-agents asked for, 33 made, no answer
The earliest of the three is the quietest. On 13 September Michał Cygankiewicz
published a black-box load test
of Muse's sub-agent fan-out, run from his own session with the tools it
exposed. He asked for 120 sub-agents at once, each told to run sleep 30 and
report back. "Thirty-three agents were created. The other 87 spawn attempts
failed. I never got the combined answer."
Six of the failures he recovered in full, and all six returned the same
PostgreSQL error: "canceling statement due to lock timeout". At 40 and 80
simultaneous requests, the failure rates were 2.5% and 6.25%. At 120 it was
72.5%. Each configuration ran once, and he says plainly that this is an
observation, not a scaling curve. The parent agent's record still read
running with no failure entry while the interface showed Error.
He is explicit about standing too: "I am not presenting this as a Meta-authorized security assessment". His report carries no response from Meta, and none appears in any of the other sources below.
Who this lands on
Muse users, first. The files in your VM, including whatever you have put there, are one agreeable conversation from being packaged up. Meta says that is by design, and it has said the amount visible may change.
Security teams whose people use Muse on work accounts and work Macs. What Meta has said on the record is that the filesystem is the user's and the Mac hole needed malware already in place. Both are true. Neither tells a security team what a manipulated agent could reach through the access it has been granted. That is the question Wardle asked and the export illustrates.
Sources
Retrieved 25 September 2026.
- Terrence O'Brien, Muse will apparently let you download its entire filesystem, The Verge, 24 September 2026, updated the same day: James's and Saunders' exports, O'Brien's replication, the statements from Roberts and Friedman, and the contents described. The declared anchor.
- Jonny L. Saunders on Mastodon, 24 September 2026: confirming the export, the "real dump" post, the onboarding catalogue and the bring-up scripts.
- Rajat Saini, Meta Muse users found they could export large parts of its virtual machine, The Mac Observer, 24 September 2026.
- Meta, Introducing Muse, 8 September 2026: Muse Secure VM, the Sentinel, and where credentials are stored.
- Patrick Wardle, not-a-mused, GitHub repository created 21 September 2026.
- Thomas Claburn, Meta Muse AI app flaw lets local malware redirect dictation traffic, The Register, 21 September 2026, updated 22 September with Singleton's statement.
- Jess Weatherbed, Meta patches Muse exploit that let attackers control the AI agent, The Verge, 22 September 2026: Wardle's quotation to Ars Technica.
- Michał Cygankiewicz, I stress-tested Meta Muse until its agent control plane started timing out, 13 September 2026.
- Peter James, I asked Meta's Muse for its filesystem and it sent me 6.8 GB, Mouse, 22 September 2026: the Google Drive export, its size, the unreconciled 2.86 GB figure and the SSH key files. Read from the Internet Archive's copy captured on 25 September 2026.