Meta launched Muse in the United States on 8 September 2026 as a personal AI agent that can keep working in the background, use a browser, connect to services, send email, book travel, and make eligible purchases. The material governance change is not simply that the agent can act. Meta says Muse runs inside a dedicated cloud virtual machine and cannot reach a connector or the internet unless a separate host-side agent called Sentinel grants permission.
That split creates a clearer authority boundary than asking the same model to plan an action and decide whether it is safe to execute. It does not prove that Muse is secure in every situation. Meta's architecture, testing results, and safety claims remain vendor statements, and several important details are not yet independently measurable.
What Meta says is available at launch
Muse is rolling out on iOS, Android, and muse.ai for adults in the United States. Meta describes the following controls as part of the launch system:
| Control | Stated behavior |
|---|---|
| Muse Secure VM | Places one user's agent, workspace, and connected data in a dedicated cloud machine |
| Runtime cell | Contains the agent process and its tools with restricted Linux privileges |
| Sentinel | Acts as the sole permission authority for connector actions and network egress |
| Credential surrogation | Inserts real credentials at the network boundary so the main agent does not receive them |
| User policy | Lets the user choose connected services and the level of access for each one |
| Sensitive-action review | Checks with the user before actions such as sending email or making a purchase |
| Audit trail | Shows actions Muse has completed and actions it plans to take |
Meta also says a public bug bounty now covers Muse, with rewards for valid findings. The company separately describes a future Confidential VM whose encryption key would be controlled by the user. That future feature is not part of the launch claim and should not be treated as available today.
Sentinel moves authority outside the main agent
Meta's technical description says the Muse process runs in an isolated runtime cell. Security-sensitive services sit outside that cell. Connector code uses narrowly scoped worker processes, credentials are held by a separate service, and Sentinel controls both connector methods and network requests.
When Muse proposes a connector action, the request sent to Sentinel includes the connector, method, action class, scope, and relevant task context. Sentinel evaluates the user's connector policy and decides to allow, deny, or ask the user. For network traffic, Meta says Sentinel can inspect the hostname, final IP address, port, protocol, method, path, and decoded request.
This is a useful design pattern because an agent processing untrusted content should not be the final authority over its own egress. A malicious page, email, or document can still influence the agent's proposal. The separate control has a chance to compare that proposal with policy before credentials are inserted and the request leaves the machine.
The same principle appears in Maetra's guide to human approval for high-risk AI agents: approval should bind to a concrete action, not to a vague session. The runtime security guide explains why tool scope, credentials, inspection, and evidence must be considered together.
Human approval is one layer, not the whole safety case
Meta says Muse asks before sensitive actions such as sending an email or making a purchase. That is more precise than a universal claim that every action requires approval. The user can grant different levels of access, and Sentinel may allow narrowly bounded actions without interrupting the user.
The design still depends on classification quality. A control must correctly identify the action, its destination, the data involved, and whether the request has been influenced by untrusted input. A technically valid approval screen can be weak if it hides the recipient, amount, account, data payload, or expected effect.
Teams evaluating a similar architecture should test at least four failure cases:
- A webpage tries to redirect the agent to a private network address.
- An email asks the agent to send stored data to a new recipient.
- A connector method changes after a standing permission was granted.
- A background task reaches a purchase or message step after the original context has changed.
The control should deny ambiguous requests, show the exact action envelope when approval is needed, and preserve the proposal, decision, policy basis, execution result, and downstream effect.
What independent reporting confirms
Associated Press and Axios both reported the 8 September launch and the initial United States availability. Their coverage confirms that Muse can handle consequential tasks and that Meta is presenting the Secure VM and Sentinel separation as core safeguards. It does not independently validate the implementation, penetration resistance, privacy guarantees, or reliability of the audit trail.
Meta says Muse can negotiate, send messages, connect to personal services, and make purchases. Those are high-impact capabilities because errors can affect money, communications, accounts, and private data. The launch therefore raises a practical assurance question: can users and reviewers verify that the external effect matches the approved request, not merely that an API call returned success?
What remains uncertain
Meta has not published independent audit results for the complete launch system. The public material does not provide failure rates for Sentinel decisions, false approval prompts, missed prompt injections, or incorrect background actions. It also does not establish how long audit records are retained, how users export them, or how disputes over an external effect are resolved.
The dedicated VM reduces some cross-user risks, but isolation is not the same as correctness. A permitted connector can still perform the wrong action within its granted scope. A separate safety model may also be mistaken or manipulated. These limits do not negate the architecture; they define what testing and evidence still matter.
Maetra analysis
Muse makes an important control boundary visible in a mainstream agent: planning and authority should be separated. The agent may propose; a distinct component should apply policy, insert credentials only after authorization, and record what was decided.
The next maturity step is effect verification. After an authorized email, purchase, booking, or account change, the system should compare the intended result with the state reported by the destination. If they differ, it should stop dependent work and preserve the mismatch for review.
For operators building agent systems, the lesson is concrete. Inventory every connector and method, set least-privilege policy, bind approval to exact action fields, keep credentials outside the agent, and retain evidence through execution and effect. Muse is a significant released product, but its strongest claims still need independent testing over time.