Meta Muse makes permission scope the first adoption test
Meta says its consumer agent can use email, calendars, payments and a browser. Start with reversible work and expand access only after reviewing real behaviour.
Meta has launched Muse, which it says can use connected services, operate a browser and keep working after its app is closed. The company’s launch page was published at 19:00:51 UTC on 8 September 2026. Meta says the initial United States rollout covers iOS, Android, the web and WhatsApp.
Meta says Muse is designed to send email, fill forms, book travel and make purchases on a person’s behalf. Permission scope therefore comes before convenience as an adoption question. A user first needs to know which data the agent can read, which actions it can take and how reliably it stops for approval.
What Meta says Muse can do
Muse combines a model, a persistent workspace, built-in connectors and a browser. Meta’s product-design account says the agent has a file system and terminal, can write code for a task and can work on several jobs in the background. Users can inspect an activity log, memory files and approved permissions. Meta says the default browser experience allows ordinary browsing but stops for actions that are hard to undo, such as sending an email or making a purchase.
Meta says people choose services one at a time and can separate read access from write access where the service permits it. TechCrunch reports that Muse can use built-in connectors, create a connection to a public API or use its browser when an API is unavailable. That range increases usefulness and changes the threat surface: the agent may process untrusted email, documents and web pages while holding authority to act elsewhere.
TechCrunch’s launch report independently reported the main rollout surfaces and broad connector categories. It did not independently validate Meta’s security architecture. The release is also geographically limited: Meta says Muse is rolling out in the United States, not globally.
Meta’s security design remains vendor evidence
Meta’s security account describes a dedicated cloud virtual machine for each user. The main agent and its tools run inside a restricted runtime cell, while credential storage, built-in connector code and other security-sensitive services sit outside it.
Meta says a separate component called Sentinel is the sole permission authority for connector actions and network access. The agent proposes an action; Sentinel can allow it, deny it or ask the user. Approval requests are shown through a structured interface rather than inside the agent conversation. Grants can be limited to one action, a session, a task or a period of time. Meta also says actual credentials are inserted at the network boundary, so the agent works with surrogate tokens instead of seeing passwords and service tokens directly.
These boundaries address genuine risks, but the evidence is still Meta’s description of its own system. Index Us did not inspect the implementation, run prompt-injection tests, examine the private red-team results or verify that every connector enforces its stated scope. Meta says it opened its previously private Muse bug-bounty program to anyone at launch. That and the architecture document provide material for scrutiny; neither proves that the deployed service is secure.
The same evidence boundary applies to privacy. Meta says conversations and data stored in a Muse virtual machine are not shared with its advertising systems. The security document separately says conversation and tool-use trajectories may be sanitised and used for model training unless the user opts out in settings. A planned Confidential VM is intended to prevent Meta from accessing the contents cryptographically, but Meta says that version will arrive later. Users should not assume the launch service has that property.
Start below the maximum authority
The Australian Signals Directorate’s Australian Cyber Security Centre, CISA, NSA and partner agencies recommend careful adoption of agentic AI. Their guidance says organisations should begin with low-risk, non-sensitive work and should not grant broad or unrestricted access, especially to sensitive data or critical systems. It also identifies prompt injection, privilege creep, ambiguous goals and incomplete visibility into agent and tool actions as connected risks.
That advice applies to a personal agent even when the interface feels less like enterprise software. Primary email can contain password resets, one-time codes, confidential attachments and conversations involving other people. A calendar reveals location and relationships. Health, home and payment services turn a mistaken action into a physical, financial or privacy consequence. Connecting everything at launch makes it difficult to know which authority produced a result or how to contain a failure.
A safer trial can grow in four stages.
- Use public information without an account connection. Ask Muse to research a low-stakes topic or assemble options that a person will review. Check whether its browser record shows the pages used and whether it stops when information is ambiguous.
- Add one read-only, low-sensitivity source. A test calendar or purpose-built email account is easier to reason about than a primary inbox. Define the task narrowly, then inspect the activity log for unrelated reads, unnecessary retention and unexpected follow-on work.
- Allow one bounded, reversible write action. Create a draft event, a draft message or a shopping list rather than sending, publishing or buying. Confirm that the approval names the destination, action and scope, and that revoking the permission prevents another attempt.
- Treat high-impact services as a separate decision. Payments, account settings, primary email, health data and smart-home controls should wait until lower-risk trials show consistent behaviour. Keep a human approval for every irreversible action even if the interface offers a broader grant.
This staged trial tests whether the complete service respects the authority a user intended to delegate; it does not benchmark Muse against another agent. Record the initial request, connected service, permission type, approval shown, actions taken, data touched, errors, intervention and final outcome. Repeat enough tasks to expose inconsistent behaviour instead of relying on one successful example.
An approval needs enough context to be useful
An approval prompt helps only when it lets the person understand the consequence. “Continue?” is weaker than a request naming the recipient, amount, account, data being disclosed and whether the permission will persist. Frequent prompts can also train people to accept them without reading.
Meta says Muse uses structured approval cards and places friction around actions that are difficult to reverse. A trial should verify that claim at the boundaries that matter to the user: whether a drafted email needs another approval before sending; a changed purchase amount produces a new request; browser navigation can transmit personal data before the checkout prompt appears; and a task-scoped permission expires when the task changes.
The activity log needs to support the same examination. A readable record should connect the user’s request to the agent’s plan, service calls, approvals, errors and result. It should make it possible to distinguish a mistaken model decision from a permission configuration or third-party service failure. An audit trail that cannot answer what happened is only a history screen.
What would justify wider use
The launch puts a persistent, tool-using agent in a mainstream consumer setting. Meta’s published architecture addresses real problems with isolation, credential exposure and delegated authority. The documentation also acknowledges that the agent can make mistakes and encounter attacks through the data it reads.
Evidence for wider trust would include detailed independent security testing, transparent resolution of bug-bounty findings, connector-specific scope documentation, reliability results across ordinary tasks and external review of the promised Confidential VM. It should also be possible for users to export, inspect and delete relevant data and confirm that a training opt-out behaves as described.
For now, Muse should earn each new permission through bounded work that remains visible, reviewable and reversible. This analysis is based on public documentation and reporting. Index Us did not use Muse, connect an account, test its security controls or independently verify Meta’s capability, privacy or reliability claims.
Sources
- Meta — Introducing Muse
- Meta Research — How we built safety into Muse
- Meta — How we designed Muse
- ASD ACSC and partners — Careful adoption of agentic AI services
- TechCrunch — Meta debuts its Muse AI agent
Last reviewed: . See our editorial policy for how we test, source and correct our work.