In short: Runtime boundary separation is the security design behind Meta's Muse. The agent reasons inside an unprivileged, credential-free container, while a separate host-side supervisor called Sentinel holds every real permission. The agent proposes actions; Sentinel decides, swaps surrogate tokens for real credentials at the network edge, and escalates sensitive steps to you for approval.
Agent security usually gets argued at the prompt layer. Muse is built the other way around: the load-bearing work happens below the model, in how Meta split one virtual machine into two territories that do not trust each other. What follows is a white-box walk through where that line sits, and what it costs the agent to cross it.
Why does an autonomous agent need a boundary at all?
Meta launched Muse on September 8, 2026: a consumer agent running on the Muse Spark model, reachable through WhatsApp and dedicated mobile apps. It books travel. It negotiates bills. It sends email from your address and initiates payments using one-time virtual cards through Stripe Link. An agent acting across your personal accounts needs exactly the two things a language model should never casually hold: live credentials, and an open path to the internet.
Picture a contractor you have hired but do not trust. You lock them in a room with a desk, paper, and a slot under the door. They can think, draft and plan all day. They cannot open the safe, because the safe is in another room. They cannot walk out, because someone else controls the door. When they want something done in the world, they write it down and slide it under. A supervisor on the other side reads the plan, decides whether it is allowed, and executes it with their own keys.
That is the shape of Muse's security model, and it inverts the usual approach. Most agent safety work happens above the model: system instructions, refusal training, output classifiers. All of it is probabilistic — it lowers the odds of a bad action without ever ruling one out. Meta's stated design goal for Muse is different in kind, because the boundaries are meant to hold "even if Muse is persuaded to behave badly." That is a containment argument, not a persuasion argument. For the wider threat model this architecture answers, the Five Eyes security playbook for adopting agentic AI lays out the risks that make containment worth the engineering.
What does Muse actually do, and what can it touch?
Input: a request in plain language. Find a flight under $400 on Thursday. Output: actions taken against real accounts — a search run, a form filled, a message sent, a card charged. Between those two ends sits the part most explainers skip, which is where the request physically executes and what it borrows to get there.
Every Muse user gets a dedicated cloud VM — the Muse Secure VM, as AI Weekly noted at launch. The wording in Meta's own writeup is precise: "two isolated security domains on one box, not an LLM powered agent with root." One machine. Two territories. The agent occupies one of them and owns neither.
On one side is the runtime cell, where the model reads, reasons, plans and drafts tool calls. On the other side sit the credential store, the safety classifiers, the connector code that actually speaks to Gmail or Stripe, and Sentinel, the process that authorises every crossing. Durable application state gets a third home again: a Postgres database separate from both the runtime cell and the credential store, per Meta AI Research's account of how it built safety into Muse. An agent that goes wrong cannot quietly rewrite its own history, because its history is not in its reach.
The connector layer is where an agent's real power comes from — mail, calendar, payments, whatever else the user has authorised — and it is precisely the surface that turns a chatbot into something with consequences. Anyone thinking through how MCP-first connectors will run a business through AI agents is describing the same reach Sentinel exists to broker. In Muse, the agent does not run that connector code. It asks for it.
How is the runtime boundary drawn inside the Muse Secure VM?
The runtime cell: an agent with its capabilities stripped
The core agent executes inside an unprivileged systemd-nspawn container. Kernel capabilities are stripped. There is no host root access. This is not a courtesy sandbox the model might talk its way out of by asking the right way, because the enforcement lives in a layer the model has no ability to address. Vellum's official Muse breakdown and Meta's own post agree on the container and the absent root privileges.
Everything valuable lives outside the cell
Credentials, safety classifiers and the connector code that touches services like Gmail or Stripe run outside the container as separate systemd units. They talk to the agent over Unix domain sockets with peer credential checks — the receiving side verifies who is calling at the kernel level rather than trusting an identity the caller asserts. AlphaSignal's writeup on Muse's approval broker is the source for the stripped capabilities and the socket-level peer checks; Meta's post does not describe them at that granularity.
A daemon named hatch-authd holds the credentials, third-party OAuth tokens included, inside the user's own VM rather than in centralised Meta infrastructure. It also performs credential surrogation. The agent receives a surrogate token: a placeholder that authenticates nothing anywhere, useful only inside a request Sentinel will later process. The main agent never sees the sensitive credential. Not "is instructed not to log it" — never receives it.
Meta describes the result as defence in depth beneath the agent. The runtime cell limits system access. Privilege separation restricts which code can see which credentials. authd applies ACLs. Sentinel evaluates every action. Four separate mechanisms would have to fail together, and they fail for different reasons, which is the entire point of stacking them. It is the same idea as the guardrail tier in the eight layers of an AI agent architecture, pushed down out of the application and into the operating system.
What does Sentinel actually decide?
Sentinel is the sole permission authority for connector actions and network egress. Not one check among several — the only one. It evaluates every action the agent proposes and all traffic attempting to leave the runtime cell, and AlphaSignal reports it handles the traffic side with eBPF taint tracking, following data as it moves rather than pattern-matching destinations after the fact.
The credential swap is the neatest part of the design. The agent assembles a request carrying its surrogate token. Sentinel receives that request, decides, and injects the real credential at the network boundary, so the outbound call is properly authenticated while the model that composed it never handled a raw secret. Exfiltration through a poisoned tool result stops being a question of the model resisting temptation. There is nothing in the model's context worth stealing.
Sensitive actions — sending email, spending money — trigger an approval prompt that Sentinel generates and delivers to the user through the Muse app or WhatsApp. Because the prompt originates outside the container, the isolated agent can neither suppress it nor forge one. The component asking for permission is not the component that grants it.
Here is the whole boundary in a single view: what the agent proposes, what Sentinel decides, and what the agent is left holding in each case.
| Capability | Which side owns it, and what the agent holds instead |
|---|---|
| Read a web page | The agent proposes the fetch; Sentinel evaluates the egress. The agent holds a request, not a route. |
| Log into a service | Sentinel decides; hatch-authd supplies. The agent holds a surrogate token that authenticates nothing on its own. |
| Send an email | Sentinel decides, then escalates to the user. The agent holds a draft and an approval it cannot grant itself. |
| Spend money | Sentinel decides and routes through a one-time Stripe Link virtual card. The agent holds an amount and a merchant, never a card number. |
| Reach the open internet | Sentinel decides, with eBPF taint tracking on outbound traffic. The agent holds no unsupervised network path. |
| Read a credential | Neither side gives it to the agent: hatch-authd keeps it in the user's VM and Sentinel injects it at the network edge. The agent holds a placeholder. |
Read down the second column and the pattern falls out on its own. Every row where something could go badly wrong resolves on the host side, and the agent is left holding a description of an action rather than the means to perform it. Set that against the probabilistic tier — the classifier stack described in the seven-layer defence against AI hallucinations — where each added layer shaves a percentage off a failure rate. A permission broker outside the blast radius is not shaving a percentage. It has removed the capability.
What this pattern means if you are building agents
Design so the model is structurally incapable of holding a secret. Instruction-level rules about credential handling are only as reliable as the model's compliance under adversarial input, and adversarial input is the normal operating condition for anything reading the open web. Surrogation retires the question entirely. If the reasoning component never receives the token, no jailbreak extracts it.
Put the approval broker outside the blast radius. An approval prompt rendered by the same process that wants the approval is theatre — it protects against user error and nothing else. Sentinel's prompts survive a fully compromised agent for one boring structural reason: the agent has no write path to them.
Separate identity from action. hatch-authd knows who you are, the connector units do the work, and the agent only says what should happen. Splitting those three across privilege domains means an attacker who lands in one still has to break out to reach the others, which is why Meta's framing stresses privilege separation and ACLs beneath the agent rather than good behaviour above it. That is the trust-and-safety ring the 2026 agentic architecture reference framework draws around a reasoning core.
Then be honest about what has been verified. Meta documents the two-domain VM, Sentinel's sole authority, hatch-authd's surrogation and the separate Postgres. The container internals, the socket peer credential checks and the eBPF taint tracking come from third-party breakdowns rather than Meta's post. Nobody outside Meta has audited the boundary running in production, and Trending Topics has already flagged the trust questions that arrive with it. An architecture that is correct on paper still has to be correct in code.
Key takeaways
- Muse's safety story is an OS-level trust boundary, not a better-behaved model. The operating rule is that Muse proposes and Sentinel decides.
- The agent runs unprivileged in a systemd-nspawn container with stripped kernel capabilities and no host root; credentials, safety classifiers and connector code all sit outside it as separate systemd units.
- hatch-authd keeps credentials and OAuth tokens in the user's own VM and hands the agent surrogate tokens; Sentinel injects the real credential at the network boundary.
- Sentinel is the only authority over connector actions and network egress, and it generates the approval prompts for email and spending that the agent cannot spoof or bypass.
- The containment is deterministic by design — meant to hold even if the model is fully jailbroken — which is a categorically different guarantee from any prompt-level guardrail.
FAQ
What is runtime boundary separation?
Splitting one machine into two isolated security domains so that the component doing the reasoning is never the component holding credentials or reaching the network. In Muse that split is the runtime cell on one side and the host-side safety domain on the other, with every crossing brokered by a supervisor rather than assumed to be safe.
What is Sentinel in Meta's Muse?
A host-side process running outside the agent's container as the sole permission authority for connector actions and network egress. It evaluates every action the agent proposes, injects real credentials at the network boundary in place of surrogate tokens, and generates the user approval prompts for sensitive steps — prompts the isolated agent cannot suppress or fake.
Does the Muse agent ever see my passwords?
No. A daemon called hatch-authd stores credentials and third-party OAuth tokens inside your own VM rather than in centralised Meta infrastructure, and performs credential surrogation so the agent only ever receives a placeholder. Sentinel substitutes the real credential at the network boundary, after the model has finished composing the request.
Does this stop prompt injection?
No, and the design does not claim to. It limits blast radius instead of preventing the injection: a persuaded agent still holds no keys, has no host root and has no unsupervised network path, so the attack lands on a component with nothing worth taking. Meta's stated goal is that the boundaries apply even if Muse is persuaded to behave badly.
Where does Muse run?
On a dedicated per-user cloud VM called the Muse Secure VM. The agent itself runs in an unprivileged systemd-nspawn container inside that VM, durable application state lives in a separate Postgres database, and credentials live in a separate daemon again — three distinct homes on one box.
If you are drawing these boundaries in your own stack, start with the threat model rather than the diagram: the guide to securely adopting agentic AI works through the containment decisions this architecture turns into code.