How To Secure Agents for the Masses: Meta's Muse Agent uses your accounts and payments to take action

A malicious web page can fool an AI agent into working against you.

Share
Flowchart illustrates data process from user control to external services in Meta's Muse AI agent system.

A malicious web page can fool an AI agent into working against you. Meta built an agent on the assumption that such an event will happen, and designed it so that such prompt-injection exploits won’t lead the agent astray.

What’s new: Meta introduced Muse, a personal AI agent based on the Muse Spark 1.3 model. Controlled via the Muse app or WhatsApp, it reads and sends emails, browses the web, fills out forms, makes purchases, and keeps working even if the Muse app is closed. Interactions train Meta models unless users opt out.

  • Features: Connects to apps including browsers, email clients, calendars, Instagram, and Facebook as well as cars, smart-home devices; selectable read and/or write access per service; scheduled and event-triggered background operation; memory is readable, editable, forgettable; activity log; output includes documents, PDFs, web pages, dashboards; transactions via Stripe Link; support planned for Shop Pay and 1Password
  • Availability: U.S. only, 18 and over via iOS, Android, muse.ai, WhatsApp
  • Price: Free (up to 100 million tokens per week), $20 (up to 500 million tokens per week) and $100 (up to 3 billion tokens per week)
  • License: Proprietary
  • Undisclosed: Muse Spark 1.3 parameter count, architecture, knowledge cutoff, and training data; Muse prompt-injection classifier evaluations; Muse agent evaluations

How it works: Muse agents are designed with security in mind. Each agent runs on a VM (an isolated, dedicated virtual machine with a Linux operating system, browser, storage, and memory). The VM holds the agent’s workspace, the user’s files, and credentials for every connected service. To protect against attempts prompt-injection attacks, the VM is divided into two zones: (i) a sealed runtime cell where the agent and its tools handle untrusted data and (ii) services outside the cell that hold passwords and decide what the agent can do.

  • The agent’s harness, the user’s workspace, and tools sit inside a Linux container with its own file system and virtual network interface. The VM limits its requests to the operating system and privileges it holds there, and administrator rights inside the runtime cell do not extend to the host machine. The cell can reach external services only via local channels. Operating-system outines verify which process is on each end, and the channels carry no passwords or access tokens.
  • Muse Spark 1.3 never sees credentials. A credential service outside the runtime cell processes passwords and access tokens, while the agent works with stand-in tokens. A separate agent called Sentinel, which runs on the same VM but outside the runtime cell, approves each request and swaps in the real credentials as the request leaves the VM. Meta says this makes it impossible for malefactors to steal credentials via prompt injection, since the agent holds no credentials. Connectors to external services like calendars run outside the cell as well, and they receive only the credentials they need. The email connector strips temporary passcodes and password-reset links before the agent reads a message.
  • Only Sentinel can permit an action proposed by Muse Spark 1.3. It inspects outbound each request and checks each connector’s call against permissions the user has set; then Sentinal allows it, denies it, or asks the user to decide. The system also tracks which tool processes have read user data. A process that hasn’t read user data can reach a short list of pre-approved destinations on its own, while one that has must ask the user for approval.
  • When Sentinel asks for user input, the agent stops, and the request goes to the Muse app as a system dialog rather than as a message in the conversation. This way, prompt-injected text can’t manufacture a user’s approval. An approval is bound to one connector or destination and purpose. Users can constrain approvals to cover one action, session, task, or time span, or all future uses. Sending emails and making purchases always requires user verification, and purchases on unfamiliar sites use a single-use card number from Stripe’s Link wallet, valid only for the specific merchant, amount, and time span.
  • Meta trained Muse Spark 1.3 to resist prompt injections and added three layers of additional protection. (i) Data from a source outside the system is labeled untrusted as it enters the model’s context. (ii) An ensemble of classifiers, which were trained separately from the model, screens every file and tool output. This process runs outside the cell, so that an attacker can’t disable it. (iii) In the browser, a sub-agent reads a structured summary of each page — the accessibility tree that screen readers use — instead of the page’s code. It can’t run JavaScript, so instructions buried in scripts or markup never reach it. Other classifiers watch for injection attempts hidden in page text, images, and downloads, and still others block the agent if it tries to route personal data to a destination the task didn’t call for.

Yes, but: Meta says it evaluated Muse Spark 1.3’s ability to resist prompt injections using an unpublished dataset, and it has not provided accuracy metrics for the classifiers that screen incoming data. Instead, the company offers a bug bounty of up to $300,000 for a valid report and up to $130,000 for a successful prompt injection. 

Behind the news: Muse incorporates design features proposed by security researchers before Meta’s current AI lab existed. In April 2025, Google DeepMind and ETH Zurich researchers led by Edoardo Debenedetti proposed CaMeL, which separates a model that plans from a model that reads untrusted data and enforces written policies before tool calls. Two months later, independent developer Simon Willison identified the “lethal trifecta” for AI agents: private data, untrusted content, and a way to send data out. Willison argued that the only safe option is to avoid combining them. Muse processes all three but routes outgoing data through a component the model can’t override, according to Meta. A classifier trained on past prompt injections may catch 99 percent of new ones, but that remains an unacceptable risk, Willison wrote. Accordingly, Meta built the container, credential separation, and Sentinel to hold when initial layers fail.

Why it matters: Security is a major risk for current agents. Most agentic harnesses include a system prompt that tells the model to ignore instructions it finds in content and a classifier that recognizes such instructions, but clever hackers can evade these defenses. Meta assumes the model will be fooled, and it built controls at the operating-system level that should hold regardless of the model’s actions. Meta detailed the protections that sit outside the model: a container the agent can’t escape, credentials it can’t hold, a gatekeeper it can’t override, and approvals that don’t pass through conversations. Developers who build agents for sensitive tasks can adapt this approach.

We’re thinking: Meta says it will release Muse Spark’s weights eventually. But it’s the harness, more than the model, that keeps the Muse agent safe. We hope Meta will open-source that software, too.