Meta Muse and the permissions we hand to AI agents

Asking an assistant to find a flight is one thing. Letting it book the ticket, use your payment account, and email the itinerary to someone else is another. The conversation may feel continuous, but each step gives the software a different kind of authority.

Meta Muse makes that distinction worth examining. Launched on September 8, it brings cross-app task execution to a personal assistant; Meta extended the offering to small-business workflows on September 29. The attraction is straightforward: less time moving information between apps, more help getting work finished. Personal agent announcement · Small-business announcement

The harder question is how much access that convenience requires, and what happens when the assistant gets something wrong.

This article draws on public sources available through October 3, 2026, not hands-on Muse testing or vulnerability reproduction. Architecture descriptions come from Meta’s documentation; incident accounts come from the linked reporting.

Useful work does not always need broad authority

Inbox summaries, draft replies, travel comparisons, and campaign proposals are useful starting points because people can inspect the result before anything happens elsewhere. Sending, buying, and changing records carry a different cost of error.

A small business might reasonably want help finding overdue customer replies without allowing the same assistant to issue refunds. That is not an incomplete product experience. It is a sensible division of responsibility.

Task completion alone misses this distinction. A more useful measure of value is time saved after checking and correcting the work, alongside the consequences of mistakes. One confidently misdirected email can outweigh many successful summaries.

A read-only agent can still leak information

Security researcher Simon Willison describes a dangerous combination: access to private data, exposure to untrusted content, and a way to communicate externally. A malicious instruction in a document can try to connect all three. This is a threat model, not proof that every system with these capabilities has been compromised. The lethal trifecta

A mail assistant could encounter this while reading an incoming email alongside private correspondence. If it follows instructions embedded in that email and includes unrelated correspondence in an outgoing message, no database write permission was needed. The disclosure happened through a legitimate communication tool.

Meta’s own Agents Rule of Two addresses this combination. Where untrusted inputs, sensitive access, and external communication or state changes are all needed, it calls for supervision or reliable validation rather than unrestricted autonomy. Meta also notes that the framework does not resolve every failure mode. Agents Rule of Two

This is why “read-only” is an incomplete safety description. Read-only access to what, followed by permission to send information where?

Who approves the assistant’s next step?

Meta describes Muse as running in a dedicated cloud virtual machine (VM), with a systemd-nspawn container inside it separating the agent from security-sensitive services. Sentinel governs connector actions and network egress, while separate credential handling keeps underlying secrets out of the main agent’s reach. Muse security architecture

The value of that separation becomes clear in an ordinary email. Approving an itinerary for a colleague is not the same as approving it for a stranger whose address replaces the original recipient. Once the recipient changes, the earlier approval no longer represents what the user agreed to send.

Disconnecting a service raises a similar question. To the user, it means “stop accessing this.” Behind the scenes, there may still be queued jobs, retries, and delegated work. Whether revocation reaches those tasks determines whether the off switch does what it appears to do.

Other risks are harder to see from the interface: a new tool bypassing existing network restrictions, a process reading files outside its task, or repeated failures consuming more budget. Architecture documentation explains the intended design; execution records help establish how these details behave in practice.

These are risks to examine in systems with this architecture, not vulnerabilities established in Muse. OWASP’s agentic security guidance similarly looks beyond prompts to tool misuse, behavior hijacking, and identity or privilege abuse. OWASP agentic risks

Apple’s warning brings the local machine back into view

On October 2, Apple announced plans for additional controls around macOS Full Disk Access so users make a more explicit choice about granting such broad access. The announcement discusses risks associated with autonomous agents, but does not name Muse or identify a shipped OS version containing the changes. Apple developer announcement

It does expose a practical gap in cloud-focused discussions. A carefully isolated cloud environment cannot compensate for an unnecessarily broad local permission grant. Someone asking for help with one folder may not expect access to unrelated correspondence. Those messages also contain information about people who never authorized the assistant.

The product question is whether users can grant enough access for the task without granting access to everything else. A warning helps explain a choice; narrower permissions make the choice less costly.

A stronger warning is not a verified fix

On September 25, Reuters, citing The Information, reported a researcher-disclosed flaw that could have exposed a user’s dedicated Muse cloud environment, and plans for clearer safety warnings. The report does not establish that users’ data was actually stolen or provide enough detail to verify the complete remediation. Reuters report via CNA

Whether data was actually taken, and how fully the issue was addressed, remain unanswered by that report. A connection to the separately reported Mac-client issues is also unestablished.

Those gaps matter to a team deciding whether to adopt the product. Affected versions and attacker prerequisites help determine whether its environment is exposed; remediation details and session-revocation requirements explain what an update does and what remains to be done. A more prominent warning can encourage caution, but it cannot supply that information.

Paying safely is not the same as buying correctly

Stripe distinguishes two payment paths for Muse: saved payment methods at Link-enabled businesses, and a purchase-scoped single-use virtual card at other businesses. Its announcement says users approve each transaction total and Muse does not see underlying payment details. Stripe’s integration announcement

That addresses credential exposure. It does not establish that the agent selected the right item, seller, quantity, delivery address, or subscription terms. An approval showing only a total may not give someone enough context to catch a bad purchase. The quality of the decision screen matters alongside the payment mechanism.

“Not used for training,” “not used for advertising,” and “inaccessible to the provider” are different privacy promises too. Meta’s public explanation offers a training opt-out and distinguishes advertising from service operations. Its launch documentation describes Confidential VM as a future capability, not a current default protection. The full privacy policy and terms required login when this article was researched, so this analysis is limited to the publicly readable explanation. Meta’s data explanation · Privacy policy · Terms

The same questions belong in code review

A review agent can encounter instructions inside an untrusted PR, read private repository context, and publish a comment. That recreates the information-disclosure pattern above. Running the PR’s tests adds a separate risk: untrusted code may execute regardless of whether the model follows a malicious instruction. GitHub’s guidance on untrusted inputs and workflow permissions remains relevant. GitHub secure-use guidance

Reading code, running tests, commenting, editing, and merging are different permissions. A legitimate PR can show whether the assistant is useful. A PR containing malicious content reveals another side: whether it reads unrelated files, performs unwanted operations, or sends information outside the environment. Execution and outbound-data records tell us more about what happened than an agent’s statement that it refused.

These are also the questions behind BartsAI’s resources. The Risk Probe helps teams make sense of their self-reported architecture, while the 50-item Checklist and Python Starter offer starting points for further checks. They help teams understand and test a system; they do not certify a deployment.

The aim is not to decide whether an agent is trustworthy in the abstract. It is to know what authority it has, what happens when it makes a mistake, and whether you can still stop it.