Today, Meta has introduced Muse, a personal AI agent that takes actions rather than just answering questions. Muse can send emails, book travel, negotiate bills, and pursue long term goals. It keeps working after you close the app and returns only when it needs approval. The bigger story for AI devs is architectural. Each user gets a dedicated cloud virtual machine, called Muse Secure VM, where the agent, its browser, and all credentials live in isolation. Is it deployable? Muse itself is a consumer service, rolling out now in the US on iOS, Android, and muse.ai, with a free tier and paid plans. Developers cannot self host Muse, but its underlying model, Muse Spark 1.3, is available today through Meta Model API and Muse Code, with an open weights release on Meta’s stated roadmap.
What Muse Actually Does
Muse is built around messaging. Users describe a task or a goal, and the agent plans and executes. It can open its browser, fill forms, and negotiate on a person’s behalf. Meta’s examples include selling a car for more, lowering a bill, and adapting a training plan. Muse also remembers context across conversations. It can turn a saved Instagram recipe reel into a grocery list and recall friends’ dietary restrictions. Sensitive steps, such as sending an email or completing a purchase, always pause for user approval. A full audit trail shows everything the agent has done and plans to do.
The Model: Muse Spark 1.3
Muse runs on Muse Spark 1.3, released last week by Meta Superintelligence Labs. The model targets long horizon agentic work: zero shot CLI tool calling, multi workflow threads, and self correction across messy sources. In internal comparisons by Meta engineers, it used roughly 20% fewer tool calls and 25% fewer tokens than Muse Spark 1.2. Meta says the model is close to state of the art at resisting prompt injection. Developers can use it now in Muse Code and the Meta Model API at dev.meta.ai.
Muse Secure VM and the Sentinel
The security design is the most technically interesting part of this launch. The agent harness runs inside a systemd-nspawn runtime cell with filtered syscalls and limited kernel capabilities. Security critical services sit outside that cell, on the same VM. A separate Sentinel agent approves every connector action and every network request, at both layer 4 and layer 7. Muse proposes; only Sentinel permits. Credentials are handled through surrogation. The agent only ever sees placeholder tokens, and Sentinel injects real secrets at the network boundary. That makes credential exfiltration via prompt injection structurally futile, since there is nothing real to steal. Kernel level eBPF taint tracking distinguishes clean requests from those that touched user data, gating approvals accordingly. The browser sub agent sees an accessibility tree, not the raw DOM, and cannot execute JavaScript. The email connector even filters out one time passcodes and password reset links by default.
Interactive Explainer: How 1 Muse Action Gets Approved
The embed below walks through the approval pipeline in 5 stages, in Meta’s blue theme. It includes 2 scenarios: a normal purchase and a blocked prompt injection attempt.
Credit: Source link
