This is an English version of an article originally written in Japanese for Zenn.
Give an AI agent access to your email, calendar, and shopping accounts, and you immediately run into a problem: the agent needs credentials to do its work — but if a credentialed agent gets tricked, the credentials go with it.
Security researcher Simon Willison calls the combination that makes this dangerous the "lethal trifecta":
- Access to private data
- Exposure to untrusted content (web pages, email, files)
- A channel to communicate externally
Muse, the personal AI agent Meta launched in the US on September 8, 2026, satisfies all three by design. It operates a browser on your behalf, reads and writes email, and even shops for you. Fittingly, the safety engineering blog post Meta published the same day is devoted almost entirely not to model performance, but to a different question: how do you build boundaries outside the model that hold even when the model is fooled?
In this article, I organize Muse's tech stack into four layers — infrastructure, application, AI architecture, and secret handling — based on Meta's public materials and the analyses and verification pieces written about them.
- Infrastructure: one Linux VM per user (the Muse Secure VM), split inside into two security domains
- Application: the agent itself and its tools are confined to a "runtime cell"; the actual connector work happens in privilege-separated workers outside the cell
- AI architecture: Muse Spark at the core, an agent loop that assembles context and executes tools, and memory stored as files
- Secret handling: the agent only ever holds surrogate tokens with no privileges; the real credential is swapped in only at the moment of sending
A note on sources. This article is based on public materials. I am a Muse user, but I have not seen Meta's internal implementation. Where Meta has not disclosed something, I say so explicitly.
How to read this article: separating fact, observation, and speculation
The statements below rest on public materials as of October 23, 2026, plus observations from the Muse session used to write this article. Because these sources are of different natures, I keep three categories distinct throughout:
| Category | Meaning | Example |
|---|---|---|
| Fact (public sources) | Stated in Meta's official announcements or engineering blog, or in analyses quoting them directly | The Secure VM's two-domain split; Sentinel's role |
| Observation (my environment) | Values actually measured on the VM assigned to the writing session | 2 CPU cores, ~7.7 GiB of memory (details below) |
| Speculation | My interpretation from public materials and product behavior; not confirmed by Meta | The internal module split of the application layer |
The "observations" in particular are one example, from one session, at one point in time — not a published free-plan spec. I found no material in which Meta publishes VM sizes per plan.
The four main sources are listed in the References section at the end: Meta's safety engineering post "How We Built Safety Into Muse," the Muse Spark Safety & Preparedness Report, a Qiita article analyzing 198 posts on X together with the technical blog, and technical explainers by explainx.ai and Forkast.
The big picture
The organizing idea is to separate "the smart part" from "the part that holds power," even inside a single VM (Figure 1).
Figure 1: Overview of the Muse Secure VM. The agent "proposes" actions; only Sentinel, on the host side, can permit execution. Colors: blue = user, green = runtime cell, red/orange = host-side safety components, purple = external services (created with Pele)
| Layer | Main components | Role |
|---|---|---|
| Client | iOS / Android / Web (muse.ai) / Mac / WhatsApp | Request input, approval dialogs, presenting results |
| AI | Muse Spark 1.3 | Reads context and picks the next step (text or a tool call) |
| Application | Agent harness, tools, skills, connector CLIs, browser component | Does the work — but holds no privileges |
| Permissions & secrets | Sentinel, hatch-authd, privsep workers, hatch-safety | Permission decisions, credential storage and swapping, input/output inspection |
| Infrastructure | Muse Secure VM (Linux), runtime cell (systemd-nspawn), eBPF / LSM | Cell vs. host separation, kernel-level tracking of data flow |
1. Infrastructure: one Linux VM per user, two domains inside
The Secure VM
Muse assigns each user a dedicated cloud VM. Meta describes it as an isolated Linux computer with a browser, CPU, memory, and storage — the "system of record" for the agent's activity.
Measuring the VM assigned to my writing session gave the following (observation):
| Item | Observed value (2026-10-23) |
|---|---|
| OS | Linux x86_64 (kernel 7.0 series) |
| CPU | 2 cores (host: AMD EPYC 9D25) |
| Memory | ~7.7 GiB |
| Home disk | 100 GB |
| Swap | none |
To repeat: this is a single example. You cannot conclude "the free plan has these specs." What you can say is that, at least in this session, the environment was a usable working Linux machine, sufficient for running shell scripts and small builds.
The runtime cell and the host-side domain
The inside of the VM is not trusted uniformly. According to the public materials, it is split into two domains with different trust levels.
The runtime cell is where the agent itself, the browser, and the tools run, implemented as a systemd-nspawn container:
- Root inside the cell is mapped to an unprivileged user on the host — even if an attacker gains root inside the cell, they remain an ordinary user on the host
- It has its own root filesystem, separated from the host side
- System calls are filtered; dangerous ones such as
io_uringare blocked - Capabilities such as
CAP_SYS_PTRACE(inspecting other processes) andCAP_NET_ADMIN(reconfiguring the network) are stripped
The host-side domain holds the safety-relevant components as separate systemd units, outside the cell:
| Component | Role |
|---|---|
| Sentinel | The sole permission authority for connector actions and outbound traffic |
| hatch-authd | Stores credentials (OAuth tokens, etc.) and performs surrogation, described below |
| Privsep workers | Run the actual connector work outside the cell, with narrow privileges |
| hatch-safety | An independent classifier ensemble that inspects model inputs and outputs |
| Postgres | Persists application state, separated from both the cell and the credential store |
Communication between the cell and the host side is limited to Unix domain sockets, with the sending process verified at kernel level via SO_PEERCRED. The characteristic move at this layer is to replace "we trust the peer by convention" with "the kernel verifies who the peer is."
2. Application: the agent proposes; execution happens outside the cell
The agent harness
The program that assembles context around the model and mediates tool calls is called the harness here. Meta's internal codename is "Hatch," traces of which remain in service names like hatch-authd. User reports describe system files such as AGENTS.md being visible from inside the product, and a roughly 350 MB Rust harness binary having been observed. That is user reporting, not a Meta announcement, so I treat it in this article as an external report.
In my own environment, I can also confirm that Markdown files recording persona and memory (IDENTITY.md, MEMORY.md, and so on) exist as system files and that the agent reads them as it works (observation). Having persona and memory live outside the model weights, as files, is one of this product's most legible design traits.
Tools, skills, connectors
The application layer seems to divide into three kinds of components (this is my organization from product behavior, not Meta's official taxonomy):
- Tools: basic operations — shell execution, file read/write, web search, browser control, creating events and documents
- Skills: playbooks for tasks such as reservations, shopping, and email management, so the model follows a procedure instead of inventing one from scratch each time
- Connectors: connections to external services such as Gmail and Google Calendar; OAuth grants are stored separately from the agent proper
The key design point: the connector CLIs inside the runtime cell only parse arguments; they never touch credentials. Typed arguments and file descriptors are passed over a Unix socket to a privsep worker outside the cell, and only there does the real work that touches credentials happen. Even if a prompt injection rewrites the tool-calling code inside the cell, there is simply no path from inside the cell to the credentials.
The browser component
Web operations are handled by a separate component running a real Chromium. What the public materials reveal about how it "sees" is interesting:
- Pages are given to the model only as accessibility-tree snapshots, not as raw DOM
- JavaScript cannot be executed in the page's own context, and developer tools are disabled
- Separate classifiers watch for prompt injections arriving via the DOM, images, and files
- The agent pauses while the user is operating the browser manually, or while credentials are being autofilled
Instructions planted in page scripts are, by construction, unlikely to reach the model at all.
3. AI architecture: the model, the agent loop, memory as files
The core model
Muse's core is Muse Spark 1.3, released on September 2, 2026. Reported pricing: a free tier up to 100M tokens per week, Power at $20/month, and Maximum at $100/month. A higher-end model, Muse Wonder, was announced on October 12, 2026, with Muse integration rolling out to subscribers first — but the model running in my writing session was Muse Spark (observation).
The agent loop
The basic behavior is the loop common to many agent products (Figure 2).
Figure 2: The agent loop and memory. Memory files outside the model, plus background processing, are what make "it keeps working after you close the app" possible (created with Pele)
- Assemble context from the request, system instructions, retrieved memory, and conversation history
- The model chooses: answer in text, or use a tool
- Feed the tool result back into context and repeat from step 2
Long conversations are summarized along the way, with only the important parts carried forward in compressed form. Continuity is maintained not by "remembering everything verbatim," but by summaries plus memory written to files.
Background processing
The "keeps working after you close the app" promise is carried by this layer. On top of scheduled jobs (cron), event-driven hooks, and resident services, there is processing that organizes memory between conversations and does proactive research. The Qiita article relays a user's story of being notified, unprompted, about a recall on a car they had just bought — plausibly an example of this proactive processing at work (speculation).
4. Secret handling: the agent never holds the real keys
This is the layer I most want to introduce.
Credential surrogation
What the agent receives is not a real OAuth token or password, but a surrogate token that carries no privileges by itself. Only when Sentinel permits a connector action is the real credential swapped in, at the moment of sending (just-in-time insertion). Figure 3 shows the flow.
Figure 3: Credential surrogation. Even if a prompt injection tricks the agent into "sending the password," the agent never had the real thing to begin with (created with Pele)
This is a decisive difference from the "instruct the model not to leak" design. Instructions are advice; a fooled model breaks them. But "you cannot leak what you do not hold" survives the model's judgment failing.
Email gets additional care: one-time codes, password reset links, and magic links are removed before the agent ever sees the message, so that email access cannot become a stepping stone to taking over other accounts.
Sentinel and taint tracking
For every connector action and every piece of outbound traffic, Sentinel decides: permit, deny, or ask the user. Decisions are made at both L4 (destination host, resolved IP, port, protocol) and L7 (HTTP method, path, content), and are said to include defenses against SSRF techniques such as DNS rebinding.
The second mechanism tracks data flow (Figure 4).
Figure 4: Tainted egress. The taint marking is done by the kernel, via eBPF cgroup programs and LSM hooks — it does not depend on the model's self-report (created with Pele)
- A tool execution starts in an untainted state
- Reading the user's data marks the process as tainted
- The propagation of the mark is tracked by eBPF cgroup programs (used to capture traffic) and eBPF programs attached to LSM hooks
- Narrow untainted traffic may be permitted automatically, but tainted traffic never passes automatically — it goes to the user for confirmation
The point is that "is this action safe?" is judged not by the type of action, but by whether the user's data was touched along the way.
Approval happens on a separate screen, not in the chat
User approval is likewise obtained not as chat text, but in a dedicated client-side dialog, and the answer returns directly to Sentinel without passing through the model. Approval scopes come in five kinds: once only, for the session, for the task, time-boxed, and always.
Keeping the approval UI out of the stream of model-generated text matters, in my reading. If "Do you approve?" were rendered inside the same chat that attacker content also flows into, that rendering itself could become a target.
Shopping payments
Payments don't hand over a real card number either. For each purchase, the user approves the total amount, and for a new store, Stripe Link issues a single-use virtual card scoped to that store, amount, and expiry. If the card number leaks from the store, it cannot be used for anything else.
5. Five layers against prompt injection
The public materials describe the prompt-injection defenses not as one mechanism but as five layers:
| # | Layer | Content |
|---|---|---|
| 1 | Model training | Muse Spark 1.3 itself is trained not to follow instructions smuggled into external content |
| 2 | Harness labeling | Content from external sources (web, email, files) is explicitly labeled "untrusted" when placed into context |
| 3 | Classifier ensemble | Independently trained injection-detection classifiers run in parallel over external data (hatch-safety) |
| 4 | Human approval | Any operation that moves data out of the VM goes to the user for approval |
| 5 | Kernel-level boundary | The runtime cell, privilege separation, hatch-authd access control, Sentinel — designed to hold even if layers 1–3 all fail |
Layer 5 expresses the philosophy: do not bet safety on the model being right. The model is treated as something that will make mistakes, and the last line of defense is placed in the kernel and in processes the model cannot control.
6. Safety evaluation of the model itself
Separate from the product's defenses, an evaluation of the model alone has also been published. The Muse Spark Safety & Preparedness Report is a 159-page report assessing the chemical/biological, cybersecurity, and loss-of-control domains under Meta's Advanced AI Scaling Framework.
Key points:
- In pre-mitigation evaluation, chemical and biological capabilities were judged likely to reach "high risk"
- With layered mitigations in place, the published judgment is that residual risk is acceptable for deployment inside Meta AI
- A third-party evaluation (Apollo Research) also reported high "evaluation awareness" — the model's ability to notice it is being evaluated
Note carefully: this report's primary subject is "Muse Spark as the core model of Meta AI," not "the operation of the Muse personal-agent product as a whole." A model evaluation does not by itself guarantee product safety. This article therefore treats the model's story (this section) separately from the product's defenses (sections 1–5).
7. Open questions that remain
Even a carefully built design leaves open questions, visible in both the public materials and user reports.
It is not hidden from Meta itself
The current standard VM is isolated from other users and from the internet, but it is not concealed from Meta. Confidential VMs — where the user holds the keys and Meta cannot access the contents — have been described as planned for the second half of 2026. "Isolated" and "invisible even to the provider" are different claims, and for this product, only the former currently holds.
No independent audit yet
Most of this article's "facts" ultimately trace back to Meta's own engineering blog and launch-day announcements. The explainers are detailed, but the primary source is Meta. As of this writing, I could not confirm any published independent audit by a third party. The bug bounty — up to $300k, and up to $130k for a successful prompt injection affecting a single user — is evidence of how seriously Meta takes this attack class, and at the same time, pricing that assumes such events can happen.
Blocked at the door
According to the Qiita article, investment bank Jefferies tested several hundred major US sites and found that about a third refused Muse and about a third imposed verification or restrictions. Amazon began blocking Muse on September 21, 2026. However cleanly the agent side separates credentials, whether the other party's site accepts agents at all is a separate problem — the bottleneck is shifting from model quality to "can it get in the door at all," as the same article puts it.
Misreading what a permission means
The same Qiita article relays a Marketplace case: a user who had chosen "always allow" expected to be asked each time, while the agent accepted an offer and sent the user's address to a buyer. Not a credential leak, but an accident of misjudged permission scope. The more finely approvals are divided, the easier they are to misjudge; the narrower they are, the more approval fatigue grows. That tension remains no matter how strong the defenses are.
Limitations
Finally, what this article cannot claim:
- The diagrams were drawn by me from descriptions in the public materials; they are not Meta's internal design documents. Where sources describe things differently, I prioritized the more concrete descriptions (the Qiita article and explainx.ai).
- I could not fetch Meta's original engineering blog (research.meta.ai) directly from my writing environment, so its content was verified through quotations and summaries in the Qiita article and overseas explainers. For the primary source, follow the link in the References.
- The VM spec observation is one example from one session, and may differ by time, plan, and region.
- The reported user voices may skew toward early adopters and newsworthy cases. The Qiita article itself notes that posts on X do not represent all users, and that its sentiment classification has methodological limits.
- Announced-but-unreleased items such as Muse Wonder integration and Confidential VMs are treated as "planned," distinct from shipped features.
Conclusion
What stays with me about Muse's design is not the model's cleverness, but the unglamorous components around it, built on the premise that the model is not to be trusted: systemd-nspawn, eBPF, SO_PEERCRED on Unix sockets, privilege separation — a combination of well-worn Linux parts, solving the problem of not handing real keys to an agent that might be fooled, and not letting it decide for itself what may leave.
Agent safety cannot be measured by model refusal rates alone. "On the day the model is completely fooled, what still holds?" Muse's public materials are, to my knowledge, one of the most concrete attempts yet to answer that question from the infrastructure side.
References
- Meta, "Introducing Muse: The World's First Personal AI Agent Built for Everyone," 2026-09-08. https://about.fb.com/news/2026/09/introducing-muse-personal-ai-agent/
- Tarek Sheasha (Meta Superintelligence Labs), "How We Built Safety Into Muse," 2026-09-08. https://research.meta.ai/blog/security-and-safety-for-ai-agents-our-approach-with-muse
- Cristina Menghini et al., "Muse Spark Safety & Preparedness Report," arXiv:2606.12429, 2026. https://arxiv.org/abs/2606.12429v1
- Hisashi Ito, "Xの投稿198件と技術ブログで見る、MetaのAIエージェント Muse の向き不向きと安全設計" (in Japanese), Qiita, 2026-10-11. https://qiita.com/hisashi-ito/items/ffe164ae4aa88abb293e
- explainx.ai, "Meta Muse: Personal Agent + Sentinel VM Security (Sept 2026)." https://www.explainx.ai/blog/meta-muse-personal-agent-launch-sentinel-vm-security-2026
- Blair Hayes, "Meta's Muse Agent Lives Behind a Kernel-Level Sentinel," Forkast, 2026-09-24. https://forkast.news/metas-muse-agent-lives-behind-a-kernel-level-sentinel-the-architecture-reveals-where-agent-security-is-heading/
- Fello AI, "Meta Muse AI Agent: What It Does and What It Costs." https://felloai.com/meta-muse-ai-agent/
- Stripe, "Stripe helps Muse, Meta's new personal AI agent, shop across the internet with Link," 2026-09-08. https://stripe.com/gb/newsroom/news/stripe-helps-meta-muse-shop-with-link
All figures in this article were written in Mermaid, converted to SVG with Pele 1.8.0, and then to PNG.
Top comments (0)