Meta's Muse drew 521 points and 556 comments on Hacker News in the brief's 01:30 UTC snapshot, giving the launch more comments than points within hours. That discussion is a measure of attention, not proof that Muse is safe or unsafe. The part developers should examine sits below the personal-assistant pitch: every user gets a dedicated Linux virtual machine, while a second agent called Sentinel holds the sole authority to approve network traffic and connector actions. Meta has designed the main AI as code that may be mistaken or manipulated, then put operating-system controls around it, according to the company's technical account of Muse security.
Meta launched Muse on September 8 as a separate app that can also be messaged through WhatsApp. It can browse websites, fill forms, send email, book travel and keep working after the user closes the app. Purchases and other sensitive actions pause for approval. The launch announcement says Muse is rolling out in the US on iOS, Android and the web, with support for AI glasses due later. Access begins with a free tier, followed by paid plans for heavier use. Associated Press reports that the initial service is for people aged 18 and over.
A second agent controls the exit
A Muse instance is an isolated Linux machine with a browser, storage and enough compute to compile code or run scheduled work. The main harness and the files and tools it uses sit inside a systemd-nspawn container. Root in that container maps to an unprivileged user on the host. Meta also gives the container a separate root filesystem, removes capabilities including CAP_SYS_PTRACE and CAP_NET_ADMIN, and blocks system calls such as io_uring, the security design says. Those limits assume that model-level refusals may fail.
Services with more authority live outside that runtime cell. A component named hatch-authd stores OAuth tokens and issues substitute credentials. Privilege-separated workers execute built-in connector code. A safety service examines model requests and responses, while durable state lives in a separate PostgreSQL database. The components communicate over Unix sockets with peer credentials and access-control lists. Meta's architecture description says connected-service tokens remain inside the user's VM rather than a central credential store, but the main model and any code it writes cannot read the real secrets.
Sentinel is the choke point. When Muse asks a connector to do something, Sentinel receives the method, action class, scope and the context of the user's request. For browser traffic it can inspect the hostname, resolved IP address, port, HTTP method, path and decoded request before allowing it out. If a request needs authentication, code in the runtime gets a surrogate token. Sentinel replaces that token with the real credential only after it approves the outbound request. This just-in-time substitution narrows one common failure mode: a prompt injection cannot simply ask the model to print an API token it never sees.
Meta also tracks whether a process has read user data. A clean process may use a narrowly defined automatic permission. Once it reads protected data, or the system cannot verify its state, it loses that path and returns to the approval flow. The implementation uses eBPF programs attached to control groups for network interception and Linux Security Module hooks for taint propagation. The tainted-egress system attempts to answer a hard agent question: did untrusted input influence the process that is about to send something outside the VM?
Consent lives outside the chat
When Sentinel needs a decision, it sends a pending action directly to the Muse client and stops execution. The approval appears as a structured dialog outside the conversation, separating the authoritative consent path from text found in a web page or email. Grants can apply once, for one session, for one task, until a deadline or indefinitely. Meta's design account says the activity view shows what Muse is doing and records approved permissions. Users can inspect and edit the memory files that guide its future work.
Connector permissions can separate reading from writing when the service supports it. Meta gives Gmail as an example: a user may allow message reading while withholding permission to send or change settings, even when Google's OAuth scope is broader. The email connector also filters one-time passcodes, password-reset links and magic-login links using deterministic rules plus a classifier. A calendar worker cannot obtain an email credential merely by changing a request parameter because workers have credential allowlists tied to their control groups, according to the published architecture.
Money gets another boundary. Muse detects checkout pages and requires approval for every purchase, including sites where a card is already stored. At launch, Stripe Link can issue a single-use card restricted to one merchant, one amount and a limited period. The agent sees that temporary payment instrument rather than the regular card number. Meta says Shop Pay and 1Password support are coming later, details that remain promises until those integrations ship in the consumer release.
Prompt injection moves below the model
Muse combines private information, hostile web content and outbound communication. Security researcher Simon Willison calls that combination the lethal trifecta for AI agents: an instruction hidden in an email, document or image can try to make a model retrieve private data and send it elsewhere. Muse cannot avoid that combination because reading personal accounts and taking action are the product. Meta instead labels external material as untrusted, runs several injection classifiers and uses Sentinel to limit what a successfully manipulated model can do.
The browser reflects the same approach. A separate browser subagent sees an accessibility-tree snapshot instead of the raw page DOM. It cannot execute JavaScript in the page, use Chrome DevTools or retrieve credentials inserted by the broker. Muse pauses while a person takes over the browser or enters a credential. Classifiers inspect text, images and downloaded files for injection attempts, and the system can stop personal data from leaving through an unrelated browser action. The launch materials provide no independent test results showing how reliably these controls catch attacks without blocking legitimate work.
Meta does not publish an attack-success rate, false-positive rate or the underlying evaluation set in its launch materials. It says employees have used Muse since early 2026, private researchers tested adversarial cases and red teams supplied further attacks. The company has now opened a public bug bounty paying up to $300,000 for valid reports, including up to $130,000 for a prompt injection affecting one user. The payout terms provide a public severity target. Findings from that program will be more useful evidence than a clean product demo or an angry comment thread.
Meta remains inside the trust boundary
The dedicated VM separates one user from another and keeps the agent away from raw credentials. It does not, at launch, cryptographically exclude Meta. The company's security post says operational policies restrict employee access, while Meta may still access VM data when needed to support, secure or operate Muse. That distinction matters because a personal agent may contain email, calendar data, generated files, memory and authentication tokens in one place.
Meta says Muse conversations and VM data do not feed its advertising systems. Browser activity can still affect ads indirectly because a merchant sees Muse's visit as the user's activity and may later target that user on Instagram. Model interactions, tool calls and subagent handoffs can be sanitized and used for training by default; users can switch that training use off. The same data-policy explanation says users can inspect, edit and download their files and the agent's memory.
A planned Confidential VM would encrypt the whole environment with a key held only by the user, which Meta says would prevent the company from reading its contents. A small trusted-testing group is using that version, and Meta has shared design material and source code with external auditors. The stated plan is to launch it later this year with a continuously inspectable audit. Until then, Muse's strongest privacy claim applies to isolation from the agent and other users, while access by the service operator remains governed by policy.
The public test starts with permissions
Agent builders can take one clear lesson from Muse: generated code does not get to define its own authority. Credentials, connector code, approvals and outbound traffic need enforcement outside its reach. Muse assigns those jobs to separate processes and the host kernel. That design can reduce the effect of a bad model decision, but it also creates new code to test: policy matching, token substitution, taint tracking, browser brokering and the Sentinel model itself. Meta's own statement that Muse will make mistakes is the right starting assumption for reviewing those boundaries.
A cautious user can start with read-only access, prefer one-time or task-scoped grants, inspect the activity log and withhold payment or send permissions until the agent's behavior is predictable. Those controls are part of Muse's documented permission system, though their defaults and clarity will matter as much as their existence. The next evidence to watch is specific: public bounty findings, independent testing of Sentinel, delivery of Confidential VM, and whether Meta publishes failure rates for prompt injection and mistaken actions. Muse has shipped the containment design. Its performance under ordinary inboxes and an adversarial web now has to be measured.