Meta’s AI Can Send Emails and Make Purchases. What Should You Let It Touch?

Meta’s own safety write-up makes the core trade-off unusually explicit. Muse is useful because it can access private data, encounter untrusted content and communicate with the outside world. Those are also the ingredients that make prompt injection and permission mistakes dangerous. Meta says Muse will still make mistakes and is designed to limit the damage when they happen.²

Meta separates the agent from the keys

Muse runs inside a dedicated cloud virtual machine. Meta says the main agent does not see real passwords or authentication tokens. Credential storage sits outside the agent’s runtime cell, and a separate Sentinel system is the permission authority for connector actions and network traffic.^{1, 2}

The useful mental model is not “the AI has my Gmail password.” It is “the AI can request a specific Gmail action through a system that holds the credential.” That is a meaningful security boundary because the model has less secret material available to leak. It does not guarantee that every authorized action is a good one.²

Read and write permissions should be treated differently

Meta says Muse can separate read and write access where the connected service supports it. Reading a calendar to flag a conflict has a different consequence from creating or moving meetings. Reading an inbox is different from sending a message under someone’s identity. The permission should match the job rather than the broadest capability the agent offers.²

This is the practical answer to “what should you let it touch?” Start with the smallest permission that can complete the task, then expand only when the extra autonomy is useful enough to justify the extra consequence of an error. That principle matters more than whether an action sounds impressive in a demo.

Payments add another layer of approval

Muse can use Stripe Link to buy from businesses across the web. Stripe says purchases at Link merchants use the customer’s saved payment method, while other merchants can receive a single-use virtual card scoped to the approved purchase. Consumers approve the transaction total, and Muse does not see the underlying payment details.³

That is a useful example of limiting authority. The agent gets enough capability to finish the checkout, but the payment credential can be narrowed to a merchant, an amount and a limited period. A system that can spend money should not need a reusable card number merely because one is convenient.^{2, 3}

Security architecture is not the same as security proof

That distinction became concrete after launch. Ars Technica reported a macOS zero-day that could let locally running code redirect Muse transcription traffic and gain control of a Muse account. Meta issued a hotfix after the disclosure and said the practical risk was low because malicious code already had to be running on the user’s machine.⁴

The episode does not erase the value of Secure VM, Sentinel or scoped credentials. It shows why an agent with broad privileges deserves a higher security bar. The more an assistant can do across email, files, shopping and other services, the more important it is to treat every permission as an explicit grant rather than a one-time setup screen.^{2, 4}

Muse points toward a much more capable kind of assistant than the chatbots most people first met. It can act, not just answer. That makes permission design part of the product experience. The safest useful agent is not the one with access to everything. It is the one with exactly enough authority to do the job you actually wanted done.