Meta built its personal agent a private computer, but trust still needs receipts

01

WHAT ACTUALLY CHANGED

Meta launched Muse in the United States on September 8 for adults using iOS, Android, the web, or WhatsApp. It is not merely a new chat personality. Meta says Muse can keep working after the app closes, manage several tasks, build tools, browse websites, fill forms, send messages, book travel, and prepare purchases.

That usefulness creates an uncomfortable list of things the agent may need: private files, an inbox, a calendar, saved preferences, account access, and permission to communicate with the outside world. Meta's answer is Muse Secure VM, a dedicated Linux virtual machine in the cloud for each user. The agent's workspace runs inside an isolated runtime cell, while credentials and durable application data remain in separate services outside that cell.

Muse itself is not the final permission authority. A separate system called Sentinel reviews connector actions and every network request. It can allow, deny, or pause an action for the user. Approvals appear through structured controls outside the conversation and can be limited to one action, one session, one task, a fixed time, or an ongoing permission.

Real credentials are kept away from the main agent. Muse uses surrogate tokens inside its workspace, and Sentinel inserts the real credential only at the approved network boundary. Meta says the email connector also filters password-reset links, login links, and one-time codes so inbox access does not quietly become the master key to a person's digital life.

Purchases receive another set of brakes. Muse can use Stripe Link, with Shop Pay planned later, and every payment requires user approval. The system issues a single-use card tied to a merchant, amount, and limited time. Meta also opened a public bug bounty that offers as much as $300,000 for valid Muse security reports, including prompt-injection attacks with demonstrated impact.

02

WHY THIS MATTERS

Personal agents become interesting at exactly the point they become frightening. Reading a calendar is handy. Combining the calendar with email, a browser, payment access, persistent memory, and unattended background work creates enough authority to save real time or manufacture a remarkably efficient disaster.

Meta's architecture is a serious acknowledgement that model obedience is not a security boundary. Muse is expected to encounter hostile websites, misleading messages, and instructions hidden inside files. The company is using operating-system isolation, credential separation, network controls, classifiers, and explicit approvals because asking the model to please behave would be security theater with nicer punctuation.

The separate approval path may be the most important design choice. An instruction appearing inside the same chat that an attacker can influence is not much of a lock. Sending the request directly from Sentinel to a deterministic accept-or-reject control gives the user a clearer place to understand what will happen before an email leaves or money moves.

The privacy story has an asterisk at launch. Meta says Muse conversations and VM data are not shared with its advertising systems, and people can opt out of model training. It also says sanitized conversations and agent trajectories may be used for training by default. Most importantly, the current architecture does not technically prevent Meta from accessing VM data when needed to support, secure, or operate the service.

Meta plans a Confidential VM later this year that would encrypt the complete environment with a key only the user holds, preventing even Meta from accessing it. That is the stronger privacy promise, but it is not today's product. The honest test for Muse is therefore not whether the launch diagram looks reassuring. It is whether outside researchers can inspect the controls, break the weak parts, and see the fixes arrive faster than the permissions expand.

03

WHERE IT COULD HELP

• Delegate email, calendar, travel, and web tasks that continue in the background
• Give an agent read access before granting narrower write permissions
• Use single-purpose approvals for messages, purchases, and data transfers
• Keep account credentials outside the model and its editable workspace
• Review an agent activity log before increasing its authority