On September 8, 2026, Meta launched Muse in the United States, a personal AI agent that can send emails on a user's behalf and handle tasks such as shopping and travel arrangements. Because it keeps working toward a goal even after the app is closed, users are entrusting the AI with ongoing tasks and access to personal data. Meta's answer is a dedicated virtual machine for each user, plus "Sentinel," which reviews actions independently of the AI doing the work. To understand Muse, it helps to look at where this design stops the convenience of autonomous operation, and whose approval it requires.
A Personal Computer That Keeps Working After the Conversation Ends
Muse is available on iOS, Android, and the web at muse.aiu, and users can also talk to it through WhatsApp. Basic use is free, and a subscription is offered for people who want to use it more. Support for AI glasses is planned, but according to Meta's announcement for Japan, the launch timing in Japan has not been decided.
What users see is a chat screen, but behind it a dedicated computer is running. It has a place to handle files, a terminal for running commands, and a web browser, and Muse can write the code and tools it needs. Besides reporting search results, it is expected to create documents and build dashboards that track spending.
For travel, for example, the work can go from proposing an itinerary in text to operating booking sites and building a trip schedule. The environment is meant to reduce the burden of giving detailed instructions at every step. Moments when a booking or purchase is completed, however, are built to require the user's approval.
The development team's design explanation says Muse runs in the background in response to schedules and related events, and sends a notification when something meaningful changes or when the user's input is needed. It retains memory across conversations and takes on multiple tasks. The way of using it shifts from a chat that acts only when a person sends a question to one where the user hands over a goal and watches progress.
That calls for a screen where users can check what is being done. Muse has features for reviewing an activity log and approved permissions, and users can read and edit the memory files about themselves. There is also a screen for goals and progress. The intensity of proactive notifications can be adjusted, so users decide how often they want the agent to step in.
This kind of visibility matters more the longer an agent runs. With an immediate reply, you can notice a mistake on the spot. With work done while you are away, if you cannot trace the intermediate decisions and the permissions you granted, you will not know where to correct an error.
Handing Over the Work Without Handing Over the Permissions
An AI that reads external web pages and emails also encounters malicious instructions embedded in them. The problem is "prompt injection," where an AI that should be reading a page's description instead follows an attacker's instructions and begins a different operation.
In a June 2025 explanation, developer Simon Willison identified the combination of access to private data, untrusted external content, and the ability to communicate externally as dangerous. If a booking page contained malicious instructions and the AI could read emails at hand and send them out, browsing could lead to a data leak. This is not an attack confirmed against Muse, but an example of the danger that arises when these permissions are combined.
The Meta technical document explaining Muse's design assumes the AI can be attacked. Inside each user's Linux virtual machine, "Muse Secure VM," it separates the area where work happens from the area that handles safety and authentication. Even administrator privileges in the work container are not directly connected to administrator privileges over the whole virtual machine.
What permits operations on external services and outbound communication is Sentinel, which runs outside the work area. Muse requests that it "wants to execute" something, and Sentinel decides whether to allow it, deny it, or ask the user, based on the user's settings and other factors. The design avoids a setup in which the code the AI writes for its work could freely rewrite the safety mechanism itself.
Separation also applies to credentials. The proxy tokens Muse handles are swapped for real credentials when an approved communication goes out. This lets the model use permitted services without directly seeing things like API secret keys.
Hiding credentials, however, does not protect all of a user's information. If the AI is allowed to read the body of emails, the risk of that content being sent out remains. Defenses that reduce exposure of secret keys and defenses that restrict where read data can be sent play different roles.
With email integration, that difference becomes even more pressing. An inbox also receives login codes and password-reset links for other services. Meta says its built-in email integration removes these using fixed rules and a classification model. The measure is meant to ensure that merely allowing access to the inbox does not put other accounts within reach.
Preventing Approval Fatigue While Stopping Payments
Muse tracks, at the kernel level, processes that have read personal data and removes automatic permission for communications from those processes. If tracking is not possible, it falls back to the normal approval procedure. Even processes that have not read personal data must pass limited automatic-permission conditions and checks such as the communication destination.
Asking for confirmation every time does not necessarily make people feel safe. When there are too many notifications, people start approving without looking at the content. The development team also cites this problem of becoming accustomed in its design explanation. Balancing usability and safety means increasing the time the agent can act autonomously while reliably making it stop for operations that are hard to undo.
For that reason, user approval is treated as a clear allow-or-deny action, separate from ordinary conversation. Answers from the confirmation screen are returned directly to Sentinel and tied to the target service and purpose. The design does not read a vague acknowledgment in chat as broad permission to operate.
For shopping, the approval is made specific down to the amount. According to Stripe's announcement, Muse asks for the user's approval of the total transaction amount for every purchase. At more than one million businesses that support Link, users can use payment methods they have saved in Link. For other businesses, it issues a single-use virtual card limited to the approved purchase.
In other words, it would be inaccurate to say a new card number is used uniformly at every merchant. There is a route that connects to existing Link payments, and a route that uses virtual cards to cover other merchants. Both share the same points: Muse is not shown the user's original payment information, and the user approves the amount for each purchase.
Meta says it ties this virtual card to the merchant, the amount, and the validity period. The idea is to grant the permission needed for shopping while not granting permission that could be reused at another store or for another amount. Stripe's wallet for agents has been offered for some time, and this announcement represents its integration into Muse.
Of course, even with purpose-limited payments, the possibility of choosing the wrong product does not disappear. Limiting the leakage of payment information is separate from whether the shopping decision is correct. What users can verify on the approval screen, and how easily they can spot mistakes, will be a factor in deciding whether to actually delegate work.
The Distance Between "Safe" and "Invisible to Meta"
The current Muse Secure VM does not make it technically impossible for Meta itself to access data. Meta states that it restricts employee access through operational policy, while access needed to operate, protect, and support the service remains possible.
The table below organizes the explanations Meta and Stripe published on September 8 by what is being protected. It maps the "Muse Secure VM," "Coming Soon: Muse Confidential VM," and "Our Policy Around Data" sections of Meta's technical document to Stripe's payment announcement. It is not the result of an independent penetration test; it compares the design and terms of service at launch.
| What is protected | Measure at launch | Remaining conditions and distinctions |
|---|---|---|
| Credentials such as passwords | Stored separately from the work area and used for needed communications | Separate controls are needed for sending data viewed after authentication |
| Operations and communications with external services | Sentinel reviews them and asks the user when needed | Depends on the scope the user permits and the effectiveness of the review |
| Payment information | Link integration, purpose-limited virtual cards, and total-amount approval for each purchase | Does not eliminate errors in product selection or in what is approved |
| Meta's access to data inside the VM | Restricted by operational policy | Confidential VM, which blocks access cryptographically, is planned within the year |
| Use of conversation and operation history for training | Major personally identifiable information removed; users can opt out in settings | A separate policy from not sharing data with advertising systems |
Hiding credentials, controlling outbound transmission, and preventing Meta's own access are separate protections. The name "dedicated VM" alone does not determine which data is protected from which party.
"Muse Confidential VM," planned for later this year, aims to encrypt the entire VM with a key held only by the user, so that even Meta cannot access its inside. According to the technical explanation, it is at the stage where a small number of testers are using it and external auditors have been given the design and code. Meta also plans audits that can be checked continuously from outside after it launches. When evaluating the current Muse, this future protection cannot be counted in advance.
Caution is also needed about how data is used. Muse says it does not share conversations or data in the VM with Meta's advertising systems, but conversation and tool-operation history is used for model training after major personally identifiable information is removed. Users can opt out in settings. In addition, actions on sites Muse visits on the user's behalf may indirectly affect advertising. Non-sharing with advertising, use for training, and activity on third-party sites should not be taken as a single promise.
Meta itself does not say Muse can completely prevent attacks, and it is soliciting vulnerability reports alongside the launch. Can it stop dangerous transmissions in real operation without getting in the way of legitimate work? When Confidential VM arrives, can third parties verify the scope of the protection? If such verification advances and the time recovered by delegating exceeds the effort spent on confirmations, a personal agent could become established as something people trust with their daily work.