Meta Muse Is a Well-Governed Agent. It Is Just Not Governed by You.

On 8 September 2026 Meta launched Muse, a personal AI agent that sends email, opens browsers and fills forms, negotiates on your behalf, learns your preferences and completes purchases. It is rolling out in the US on iOS, Android and muse.ai, with AI glasses announced as next. It is free for most of what people need, with paid tiers above that.

Alongside it, Meta published an unusually detailed account of how Muse is secured. It is worth reading on its own merits, because it is one of the better public descriptions of how to contain an agent that holds real credentials. It is also worth reading as a security team, because the architecture makes something uncomfortable explicit: Meta has thought carefully about what Muse is allowed to do, and has no way to know whether it should be doing it inside your organisation.

What Meta built

Muse runs in Muse Secure VM, which Meta characterises as two isolated security domains on one box rather than an LLM-powered agent with root. The agent lives in a systemd-nspawn runtime cell with its own root filesystem on a separate Debian image, a virtual network interface and filtered syscalls. Kernel capabilities are cut back, specifically no CAP_SYS_PTRACE and no CAP_NET_ADMIN. Root inside the runtime cell maps to an unprivileged host user, so compromising the cell does not compromise the host.

Five security-sensitive components sit outside the cell, reachable over Unix domain sockets authenticated with SO_PEERCRED:

Sentinel is the piece worth studying. It resolves every action to allow, deny or ask, and the agent cannot override it. For network egress it evaluates connector policy at layer 4 and layer 7 together: hostname, resolved and final destination IP address, port, protocol, HTTP method and path. On top of that, Meta uses eBPF cgroup programs for kernel-level data flow tracking, so a request carrying tainted data is treated differently from a clean one. Clean requests that fall inside a narrowly bounded auto-allow policy pass without prompting the user, which is how the system stays usable rather than degenerating into consent fatigue.

The agent never sees a real credential. authd mints a surrogate, and Sentinel swaps in the real one only after the concrete request has been authorised.

The browser sub-agent, and the parts Meta chose not to allow

The browser sub-agent is constrained in ways that read like a direct response to the last two years of browser-agent research. It sees an accessibility tree snapshot of the page rather than the raw DOM. It has no ability to run JavaScript in the page context, no script verbs and no exec in the browser process. Chrome DevTools is disabled. The agent pauses when the user takes over or when a credential is being filled.

Classifiers watch for egress of unrelated personal data, prompt injection in the DOM, prompt injection delivered through images and other media, prompt injection in downloaded files, and high-risk form submissions. Compare that list to the failure modes catalogued in securing computer-use and browser agents and it is clear Meta read the same literature. The design decision that stands out is refusing JavaScript execution in the page context outright, rather than filtering it. Capability removal beats capability filtering, every time.

On payments, Muse detects that it is on a checkout page and requires human approval with the exact purchase details every time. At a merchant the user has not bought from before, a single-use card number is issued, tied to that merchant, that amount, and a limited validity window. That is a stronger control than most corporate procurement systems apply to a human, and a useful reference point for anyone thinking through agentic payment governance.

The bounty tells you where Meta expects to be hit

Meta's private bug bounty for Muse pays up to $300,000 for a valid report based on demonstrated impact, including up to $130,000 for a successful prompt injection affecting a single user. Bounty schedules are budget statements about expected attacker behaviour. A six-figure payout for single-user prompt injection says that Meta expects prompt injection to remain viable against a system with four layers of defence against it, and has priced external research accordingly.

This is the honest version of a claim that usually arrives dressed up. Muse Spark 1.3 is described as close to state of the art on injection resistance, untrusted input is labelled at the harness level, and an ensemble of classifiers trained on real datasets and on Meta's own scaled agentic red teaming sits in front of it. And Meta still builds as though all of that will fail, because the deterministic boundaries, runtime cell, privsep, authd ACLs and Sentinel, are what hold when it does.

Where this lands in your organisation

Now the part Meta cannot help with. Muse is a consumer product, distributed through app stores and a browser, that connects to a person's accounts. Some of those accounts are yours.

• The OAuth grant is invisible to your IdP. An employee connecting a corporate Google account to a personal agent creates a grant held by a consumer application. Unless you are enumerating third-party grants against Workspace and GitHub, it does not appear in any review.
• The browser path leaves no device footprint. muse.ai is a website. There is nothing to install, nothing for endpoint management to catch, and nothing in a software inventory. This is the same gap described in what is shadow AI.
• The agent is indistinguishable from the employee. Muse acts with the user's credentials against your applications. Your logs show the employee. They do not show that a Meta-operated VM in another jurisdiction composed the request.
• Payments create a spend path with no procurement in it. A card on file plus autonomous checkout is an expenditure control question before it is a security question.
• Data leaves the perimeter to be useful. Muse works by reading the content it acts on. Meta states that conversations and VM data are not shared with its ad systems, and that trajectories used for training are sanitised of key personal information with a settings opt-out. Those are Meta's commitments to the consumer, not a data processing agreement with you.

None of this is an argument that Muse is badly built. The opposite: it is one of the most carefully contained consumer agents shipped so far, and Meta's forthcoming Muse Confidential VM, intended to cryptographically prevent even Meta from accessing VM data with a continuously audited system open to public inspection, goes further than most enterprise vendors are willing to go.

Two different questions

Vendor-side governance answers the question "is this agent behaving correctly?" Sentinel answers it well. Organisational governance answers a different question: "which agents are operating against our data, with whose credentials, and did anyone approve that?" No vendor can answer the second one, because no vendor can see the whole population of agents touching your environment.

The practical move is not a Muse policy. It is an inventory that includes personal agents as a category, because Muse is the first of these to ship at consumer scale and it will not be the last. Start with the three places the evidence exists: the browser, where the sign-in account tells you whether this is corporate or personal; the OAuth grant list in Workspace and GitHub, where a consumer agent holding a corporate scope is unmistakable once you look; and the endpoint, where companion apps and local AI tooling accumulate. Building an AI agent inventory walks through the sequence.

Meta published its threat model. Most organisations cannot publish a list of the agents running against their own data. That asymmetry is the actual finding here.