Meta's new AI agent Muse is powered by AMD EPYC Turin host systems, with each sandbox sporting two dedicated cores and 8GB of memory. Blogger Evan Hoffman and analyst Tae Kim both discovered that Muse will run some rudimentary Ubuntu commands if prompted, passing along the output to help identify things like the specs of the host system. More concerning is that Muse seems able to execute commands that might be unsafe, with Hoffman claiming that Muse offered to set up SSH to Muse's private VM.
Imagine if one billion people used a personal AI agent. That's a lot of CPUs and memory pic.twitter.com/ibozUi3a07September 24, 2026
Both Kim and Hoffman asked Muse about the VM's specs, and in both instances, Muse revealed that it's running on AMD EPYC 9D25 CPUs, a high-density Turin chip with up to 128 cores (two of which are generally fused off or reserved). The VMs are running on Ubuntu 24.04 and using Linux kernel 7.0. The systems hosting Muse don't include GPUs. The AI agent revealed that Meta uses separate GPU servers for inference, isolating the agent to CPU-only sandboxes.
The agent suggests that each user gets their own private sandbox that's persistent, which allows us to do some math on how many people an individual tray can host. Assuming a 2P system that offers up to 510 vCPUs with 2TB of memory, hosting up to 254 Muse users. Muse has reportedly passed over 500,000 daily active users as of a few days ago, which would come out to somewhere around 2,000 server trays with dual EPYC 9D25 CPUs and 2TB of memory.
This is just some rough napkin math; don't take it as law. It's possible Meta has CPU-only servers deployed with multiple different chips to host Muse, and it's also possible there's overhead in the configuration. Turin chips support up to 6TB of memory with high-density DIMMs, for instance. Still, EPYC hosts seem popular for this use case, mainly because of their core density, as even a dual-core sandbox can add up quickly when multiplied across hundreds of thousands (or even millions) of users.
Muse isn't completely open. Hoffman shared an example where an attempted command failed due to improper permissions when Muse tried to query the kernel buffer. Presumably, sudo (admin) commands would be blocked as well.
I feel like I could definitely reverse SSH tunnel into my muse's container. I already had it offer to SSH to my private VM and say I need to add its pubkey. Someone good at hacking could really have a field day.September 25, 2026
However, there might still be some security loopholes. Hoffman says that Muse offered to set up SSH into the private Muse VM. With a reverse SSH tunnel — where the destination machine initiates the connection, bypassing the firewall — an attacker may be able to execute more damaging commands.
I’ve seen a couple of posts about this so wanted to demystify. Today, every Muse user gets a free computer in the cloud. It's a real computer, and we’ve designed the security architecture of the Muse Secure VM carefully so you and your Muse can do almost anything you could with a computer sitting under your desk while keeping you and the system safe from threats like prompt injection. We wrote about this at length in our security blog post – https://t.co/7HmiTrzoTd. Activity in the “runtime cell”, which you share with your Muse is unfettered, but sensitive actions are all overseen by the Sentinel, which runs outside of that cell. Similarly, all sensitive secrets - like the passwords you enter into Muse’s secure credential storage - are also stored outside the runtime cell.The runtime cell gets its own root filesystem (including a full Ubuntu linux image) separate from the host filesystem where your other more sensitive data lives. Because it is isolated from the sensitive stuff that runs on the same box, this means that we can, and do, offer users full visibility and control over the files in the runtime cell. Just as you can when you install Linux on your home computer, you can poke around and see all the files that make the system work - both debian system files and the binaries and data files that implement the parts of Muse which run in the runtime cell.This was a very deliberate choice - your Muse Secure VM truly is your own computer in the cloud. You can install software in it, write and compile code, use the browser to surf the web: it is your own Linux box that you can operate as you choose with your Muse. Poking around in this computer doesn't give you any privileged access to Meta infrastructure, or to other people's dataIf I may geek out a little here for a second… As a kid I loved to take things apart to see how they worked. As a teenager I got into computers and soon found myself drawn to C:\WINDOWS\SYSTEM and the system registry, later Slackware’s /dev/, /proc/ etc – I could see how the system was laid out and as I explored what DLL files and .so files actually did, I gradually became able to meld the computer to my own will.We’re really proud to be able to put a real computer in millions of people’s hands with a similar level of transparency. We built a file explorer right into the Library tab of the UI. We want you to be able to see the markdown files Muse writes while it thinks about how to serve you better, and explore the internals of the system if you’d like to.So, when you ask your Muse to show you its entire filesystem, and receive gigabytes of files you’re seeing the full contents of the runtime cell. It’s yours to explore and enjoy!If you’re not a geek like me, or simply want to download the data that you personally have created directly with your Muse, we added a feature for that too in Settings="" > Data controls="" > Download your agent data.September 24, 2026
Meta's David Singleton says this is intended behavior, however, describing Muse as "a free computer in the cloud." Meta has an extensive white paper on the security architecture of Muse published on its research website.
