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 – 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 data If 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.

We appreciate this report and have issued a hotfix to the Muse Mac app. 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. We take every report of a possible security problem very seriously, including those that arrive as published exploit code (like this one). We strive to be extremely transparent about privacy and security in Muse as we know this is important to maintain your trust. Therefore, here’s a little more detail on this issue: - Muse's dictation is powered by a server-side speech model. The app shipped with an internal setting that allows the endpoint used by this feature to be redirected to a different URL, which is useful during debugging and development. - The setting lives in the app's local preferences, which macOS allows any program running under your user account to modify. Changing this requires malicious code already running on your Mac. This is not remotely exploitable, and it does not involve Muse's servers or the Secure VM that isolates agent tasks. - Overriding this setting would let an attacker proxy audio dictation requests and capture the access tokens the Muse app uses to drive the Muse agent – expanding malware already present on your computer into the Muse agent. Our hotfix removes the endpoint setting from production builds entirely, which closes this vulnerability. - We are grateful for the work of the security research community and potential security issues can be responsibly disclosed via our bug bounty program, which pays up to $300,000 for exactly this class of finding.

Power user @Muse feature - custom connectors 🔧. Muse has tons of connectors for popular services built in. Even better, Muse can write its own software and run it in the VM you and your Muse share in the cloud. So you can connect Muse to any service with an API.

One threat we’re particularly focused on is prompt injection, and we handle it in layers. The model is trained to recognize and resist it. The harness marks anything coming from an untrusted source. Deterministic code checks the result. And an ensemble of classifiers runs where the agent can't reach them.

Muse is out today. An agent like this is a different kind of system to design. It reads your mail, spends your money, runs your code. Getting that right took real care, and our technical post walks through exactly how. We designed security in.