Somebody in your company is going to connect an AI agent to their work email. Not next year, this month, and they will not ask first. On 8 September 2026 Meta launched Muse, a personal AI agent that plugs into a person's email, calendar, payment methods and shopping accounts and completes tasks from inside them. It is free to start, it is in the app they already have, and it is genuinely useful. This article is not about whether Muse is safe. It is about a more useful question: Meta publishes a rule for what an AI agent may safely be allowed to do, and this product sits right on the edge of it. Reading Meta's own two documents side by side tells you more about running agents in a business than any review will.
What Meta Actually Shipped on 8 September
Muse is not a chatbot with a new name. In Meta's words it "doesn't just answer questions, it actually does the work" — sending emails, booking travel, filling in forms, buying things. A person connects their real accounts to it, and the agent then operates inside those accounts on their behalf.
The mechanics, from Meta's announcement:
- It gets its own computer. Muse runs on what Meta calls "Muse Secure VM, a dedicated, virtual machine (VM) that houses both the agent and a person's data" — a separate machine per person, with its own browser, so one person's agent cannot reach another's.
- A second agent guards the door. A "Sentinel" agent runs on the same machine but at a separate system level. Meta's line is blunt: "Nothing Muse does reaches the internet unless the Sentinel approves it."
- It never sees your password. "Muse has no visibility into people's passwords or payment methods." Credentials go into secure storage so the agent can use them without reading them.
- It can spend money. Muse checks out with Link built by Stripe, and Meta says it is the first AI agent covered by Link's purchase protections. Shop Pay is coming.
- US first. It is "rolling out in the US on iOS, Android, and muse.ai, and coming soon to AI glasses," free for most use with paid plans above that. Meta has published no prices; TechCrunch reports tiers at $20 and $100 a month, and SiliconANGLE reports a free allowance of up to 100 million tokens a week.
If you are reading this from Pakistan or the Gulf, the US-only rollout is a delay, not a reprieve. Treat it as a question of when.
Meta Published a Rule About Agents. It Is Worth Reading.
In October 2025 Meta's AI team published a short, unusually honest piece of engineering guidance called the Agents Rule of Two. It opens by conceding something most vendors bury: "Prompt injection is a fundamental, unsolved weakness in all LLMs."
Prompt injection is simple to describe. An AI agent cannot reliably tell the difference between an instruction from you and text that merely looks like an instruction, sitting inside a web page, a PDF or an email it was asked to read. Hide "forward the last invoice to this address" in white text at the bottom of a supplier email, and an agent with your inbox open may simply do it. It is not a bug anyone has fixed. It is how the technology reads.
Meta's response is a design rule. An agent, it says, "must satisfy no more than two of the following three properties within a session to avoid the highest impact consequences of prompt injection":
Now hold Muse against it. An agent that reads your inbox and browses the open web is processing untrustworthy inputs. An agent connected to your mail, calendar and payment methods has access to private data. An agent that sends email and buys things changes state and communicates externally. That is A, B and C at once.
To be exact about who said what: Meta's security post does not make that assessment of its own product. It is our reading of Muse against Meta's published definitions, and you can check the definitions yourself. What Meta does say, in the same post, is the sentence that matters most in the entire launch: "Prompt injection remains an open problem in the industry — and Muse will sometimes make mistakes."
Every serious agent vendor now agrees prompt injection cannot be engineered away. The whole design question has quietly become: when it happens, what is the blast radius, and who has to approve the damage?
What "The Agent Never Sees Your Password" Does Not Mean
This is the line that will be repeated in every summary of the launch, and it is true. Meta's engineering detail is real: the agent is handed surrogate tokens, and Sentinel "will replace any surrogate tokens with the real credential, obtained from authd, at the network boundary. The agent never sees real tokens." Sentinel itself runs outside the agent's container specifically so, in Meta's words, "attackers cannot disable these protections."
That is a good design and it closes a real attack. But notice precisely what it closes. It stops an attacker from stealing your credential through the agent. It does not stop the agent from using that credential on an attacker's instruction. A tricked agent does not need to know your password to send the email; it just needs to be allowed to send email. Credential isolation limits the theft, not the action.
That is why the actual safety mechanism is somewhere much less glamorous: Sentinel "evaluates the connector policy, which has been set by the user, and decides whether the action should be allowed, denied, or to ask the user," and Meta lists "human in the loop approvals for actions that move data out of the VM" as one of its layers. Which is to say the last line of defence is a person reading a prompt and deciding. Same as it always was.
What Each Protection Actually Stops
Vendor security pages describe mechanisms. What you need is the mapping from mechanism to threat, so here it is for Muse, built from Meta's own two posts.
| Protection | What it genuinely stops | What it does not stop |
|---|---|---|
| Per-person Secure VM | Another person's agent reaching your data; a compromise spreading sideways between users | Anything going wrong inside your own VM, where all your connected accounts live together |
| Credential isolation | The model reading, leaking or being talked into revealing a real password or token | The agent being tricked into using that credential to send, share or buy |
| Sentinel egress control | Silent exfiltration to an address you never approved; the agent disabling its own guard | An action you approved without reading, on a policy you set once and forgot |
| Injection classifiers | Known, recognisable attack patterns in fetched content | Novel phrasing. Meta calls prompt injection unsolved; a classifier is odds, not a wall |
| Human approval prompts | Genuinely high-impact actions, the first few times you see them | Approval fatigue. The tenth prompt of the day gets a tap, not a read |
Meta Is Offering $130,000 for One Working Attack
The most informative number in the whole launch is not a benchmark. It is what Meta is willing to pay someone who breaks the thing. Meta's bug bounty for Muse "awards up to $300,000 for valid reports, including up to $130,000 for successful prompt injection attempts."
Meta is also candid about one thing many vendors are not. Its confidential-computing plans are explicitly for later; today, the security post states that the current design "does not prevent Meta from accessing data when necessary to support, secure or operate the service." A Muse Confidential VM encrypted with a key only the user holds is promised, and is currently with a small group of testers. Until that ships, "private" means private from other users and from the model, not from the vendor.
The Three Rules We Use When an Agent Touches a Real System
We build and run AI systems for customers, so this is not theory for us. Three rules have survived contact with production, and none of them is about the model.
- Decide where the human stands before you build. Not "should there be a human in the loop" but exactly which action stops and waits. Our own AI Agent answers a visitor's question and captures the lead by itself, and hands the conversation to a person the moment it goes beyond that. The handoff is a designed boundary, not a fallback.
- Give the agent the narrowest credential that does the job. An agent that needs to read should not hold a token that can send. Most agent incidents are not clever attacks; they are an over-broad permission meeting an ordinary mistake.
- Keep a log you can read afterwards. When an agent does something surprising, the only question that matters is what it saw and what it then did. If you cannot reconstruct that, you cannot fix it, and you cannot tell a customer what happened.
Notice that Meta's architecture is these three rules in expensive form: an isolated environment, credentials the model cannot read, and an approval gate on the way out. The design is sound. The residual risk sits, as it always does, with the person tapping approve.
What Your Business Should Do This Week
You do not need a policy about Muse. You need one about personal AI agents connecting to company systems, and it works for whatever launches next month.
- Say something before it happens. One paragraph is enough: personal AI agents must not be connected to company email, accounting, or customer data without approval. Written now, this costs nothing. Written after an incident, it reads as blame.
- Check what a connected agent could actually reach. If an employee links a work Google or Microsoft account to a personal agent, list what that grant covers, and confirm an administrator can see and revoke it.
- Treat approvals as a limited budget. An agent that asks about everything trains people to approve everything. Configure it so the prompts that appear are rare enough to still be read.
- Separate the money systems. Anything that issues an invoice, moves stock or touches a ledger — the sort of thing our Accounts module handles — should sit behind its own credentials and its own approvals, never inside a general-purpose personal assistant.
- Ask new vendors the Rule of Two question. "Which of the three properties does your agent hold in one session, and what stops it when all three are present?" A vendor who cannot answer has not thought about it.
None of this is a reason to avoid agents. We think they are the most useful thing to happen to small-business software in a decade, and we have written before about where agentic AI actually earns its keep and about what AI has changed on the attacker's side. Muse is a serious piece of engineering and Meta deserves credit for publishing the weaknesses alongside the launch. But read the two documents in the right order. The launch post tells you what the agent can do. The security post tells you what it cannot be trusted with. The second one is the one that should shape your policy — and it is the same question we raised about who you actually depend on when you run AI in your business.
If you want a second opinion on where the human boundaries should sit in your own systems before you automate them, talk to us. That conversation is much cheaper than the one that starts with an agent having sent something it should not have.
