How Muse stays safe: Sentinel

Chapter 6 ended on the core problem. You can't guarantee a model won't be tricked, so the system around it has to stay safe even when the model is tricked. Meta's engineering team puts it this way: think of "two isolated security domains on one box, not an LLM powered agent with root."

Here's how a single payment makes its way out of Muse, based on Meta's published design.

Wall 1: a computer of your own

Each user gets a dedicated Secure VM (the cloud computer from Chapter 5). Your data, memory and connected-account credentials live in your VM, not spread across other Meta services. If something goes wrong in one person's VM, it doesn't spill into anyone else's.

Wall 2: the runtime cell

Inside the VM, the agent doesn't get the whole machine. It runs in a runtime cell, a locked-down container with its own filesystem and network interface and a trimmed list of what it's allowed to do at the operating-system level. Even "root" inside the cell is an unprivileged user on the real machine. A hijacked agent is stuck in a small room.

Wall 3: Sentinel decides, the agent proposes

Sentinel runs on the same VM but outside the cell, kept apart at the system level. Meta calls it "the sole permission authority" for connector actions and for all network traffic leaving the VM. The agent can propose an action, and Sentinel decides one of three things: allow, deny, or ask the user. In Meta's words, "Nothing Muse does reaches the internet unless the Sentinel approves it."

Wall 4: the agent never holds your passwords

This is the cleverest part. When you connect an account, the real password or access token goes to a separate credential service. The agent only ever sees a stand-in (Meta says surrogate) token, a placeholder that's useless on its own. When an approved request passes through Sentinel on its way out, the stand-in is swapped for the real credential at the exit.

So even a completely hijacked agent has nothing worth stealing. An attacker who talks it into revealing "your bank password" gets a meaningless placeholder.

Wall 5: taint tracking decides when to ask

Asking about everything would wear you out (Chapter 6), so some requests can be auto-allowed. The question is which ones. Muse tracks taint at the operating-system level: each tool process starts clean, and it becomes tainted the moment it reads your data. Meta says that tainted processes lose auto-allow and fall back to asking you.

The reasoning is straightforward. A request that has never touched your data can't leak it. A request that has touched your data and is trying to leave is exactly what a prompt-injection attack looks like, so that's when a human needs to be asked.

Defense in depth

No single wall here is meant to be perfect. Meta lists layers that stack up: models trained to resist injection, several classifiers that detect injection attempts, human approvals, the runtime cell, privilege separation for connectors, credential stand-ins, and Sentinel checking every action and every outbound request. Each layer assumes the ones before it might fail.

Meta has also announced a Muse Confidential VM, in testing with a small group, where the whole VM is encrypted with a key only you hold, so that "not even Meta can access it." They say they're sharing its design and source code with outside auditors.

The next time any agent asks you to approve something, you'll know what's behind that dialog, and why it's worth reading before you tap.