Meta Details Safety Architecture for Muse AI Agent
By going into detail about how Muse works under the hood, we hope to give you a sense of how — and how much — you can trust it in practice. Today we launched Muse — our personal agent. We’ve been working on and using Muse ourselves since early 2026.…
How We Built Safety Into Muse
Today we launched Muse — our personal agent. We’ve been working on and using Muse ourselves since early 2026. As soon as we started using it, we saw the glimmers of real personal superintelligence — an agent that knows you, actually does things, works in the background, launches swarms of subagents, builds its own tools, and edits itself.
It was also the first time we’d handed our inboxes, our calendars, and a shell to a piece of software and let it run unattended — which didn’t always work out as planned. Making this technology work for everyone requires careful design and engineering to operate more safely. That’s where most of the effort on this project went and this post explains our approach in detail.
We trained our model with a specific focus on the areas that are critical for an agent like this: zero-shot tool calling using CLIs and skills, long context, long-trajectory instruction following with inherent awareness of prompt injection, and multi-agent coordination.
No matter how strong the model is at the core, any agent like this will still make mistakes, and it will sometimes be attacked via the data it reads. So we designed the system to assume the agent may be under attack and limit the potential damage — the harness runs in its own isolated cell, it doesn’t see real credentials, and every interaction with the outside world runs through a Sentinel which the agent can’t override. Muse can and will still make mistakes, but we expect they’ll be much less frequent and cause much less damage due to the safety systems we’ve built in.
We’ve hardened Muse based on extensive dogfooding, agentic red teaming, and against issues found in real adversarial scenarios by security researchers in our private bug bounty program. Today, we’re opening the Muse bug bounty program to anyone to responsibly disclose issues. The program awards up to $300,000 for valid reports, including up to $130,000 for successful prompt injection attempts that affect one user.
By going into detail about how Muse works under the hood, we hope to give you a sense of how — and how much — you can trust it in practice. The following describes the system at launch. We will, of course, continue to pay attention to the changing threat landscape and make changes as required.
The Lay of the Land
An agent in your own cloud computer
You and your Muse share your own dedicated computer in the cloud. This is where your Muse lives and where all data and credentials for any service you connect are securely stored. Each Virtual Machine(VM) is an isolated linux box with a browser and enough storage, CPU, and memory to do real work — like compiling code the agent writes, developing custom skills and handling concurrent sub-agents and crons.
Your computer, your data
Your dedicated VM is the system of record for everything you put in Muse. Muse sends limited data out of the VM when necessary for inference and telemetry as described below.
Clients
Muse clients (the iOS and Android apps, the web UI) connect directly to your VM via a secure transport layer.
Connectors
Muse is most useful when you connect it to your email and other systems like your car or your home. We’ve built an initial set of connectors to third-party systems and to other Meta apps like Instagram and Facebook. For each connector, we worked closely with the service provider to integrate their API, and we’ve written and iterated on SKILLs — detailed instructions to Muse — on how to get the most out of each connector. Muse can also write its own custom connectors for other services you care about if they have their own APIs or CLIs.
Muse Secure VM
The VM is structured carefully to separate what you and your Muse do from everything we’ve built in to keep you safe using Linux isolation primitives. The right mental model is two isolated security domains on one box, not an LLM powered agent with root.
The Hatch 1 Hatch is our internal name for Muse in the codebase. daemon (the core agentic harness) as well as the filesystem containing your workspace and files, and all the binaries and tools Muse executes on your behalf operate in a systemd-nspawn runtime container. Root inside the runtime cell is mapped to an unprivileged host user so runtime cell root is not host root. The cell gets its own root filesystem (including a full debian image) separate from the host filesystem where your other more sensitive data lives. It also gets a virtual network interface, filtered system calls (for example no io_uring ), and limited kernel capabilities (for example no CAP_SYS_PTRACE and no CAP_NET_ADMIN ).
Security-sensitive services exist outside the runtime cell. This split is important as the runtime cell is expected to process untrusted data. These run as separate systemd units:
hatch-safety operates an independent set of models and classifiers which inspect requests and responses to/from core model inference. These are important for controlling frontier risk and to identify other threats such as prompt injection attempts. Running these outside of the runtime cell means that attackers cannot disable these protections.
privsep workers execute built-in connector code with tightly scoped privileges, keeping the connected credentials out of scope of the agent.
hatch-authd is responsible for credential storage (including OAuth tokens for third-party services you choose to connect – these are stored in your VM, not in centralized Meta infrastructure) and for credential surrogation so your main agent never sees sensitive credentials.
Sentinel is the sole permission authority for connector actions and network egress.
All durable application state is stored in a postgres database separate from the runtime cell and from the credential store.
Proxies for inference and telemetry expose constrained paths to external infrastructure.
All communication between the runtime cell and other services in the VM happens via Unix domain sockets with SO_PEERCRED and peer ACLs. This provides kernel authenticated, least-privilege interprocess communication with no secrets to steal.
A Built-In Sentinel
Sentinel is a separate host-side agent from your Muse. It is the sole permission authority for approval to perform actions with connectors to third-party services and for all egress over the network. Muse proposes actions, but only Sentinel can grant permission to perform action.
Connectors
When Muse wants to take action via a connector, the relevant connector tool is invoked in the runtime cell. That submits a request to Sentinel describing the connector, which method is to be invoked, the class of action, its scope, and context of what the user asked for from which Sentinel generates a user-visible purpose for the request. 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.
Network egress
Every concrete network request is governed by Sentinel at egress. Runtime traffic reaches Sentinel via a forward proxy configured with Linux networking controls (userns, veth boundaries and eBPF filtering). Sentinel can evaluate the destination at both layer 4 and layer 7: the hostname, the resolved and final destination IP address, the port, protocol, HTTP method, path, and the actual decoded request. SSRF restrictions prevent an apparently public hostname resolving private infrastructure after DNS lookup.
Sentinel also performs just-in-time credential insertion for any requests which need a secret or auth token. For all such requests, code in the runtime cell or a worker only ever sees a “surrogate” token, minted by authd. After the concrete network request is authorized, Sentinel will replace any surrogate tokens with the real credential, obtained from authd, at the network boundary. The agent never sees real tokens, which means any attempt to coerce the agent to reveal the actual secrets via prompt-injection or otherwise is futile.
To balance the signal-to-noise ratio of user approvals, Muse uses kernel-level data flow tracking, which we call “tainted egress.” Each tool execution process starts in a clean state and becomes tainted if it reads user data. Clean network requests that already qualify for a narrowly bounded auto allow policy — and which also pass other checks on the outbound URL — can be allowed through without bothering the user. Taint information is used to determine suitable user approval for requests. Tainted or unverifiable processes lose auto-allow and fall back to the normal approval flow. The implementation uses eBPF cgroup programs for network interception and process attribution, plus eBPF programs attached to Linux Security Module hooks we added for taint propagation.
Human in the Loop
When Sentinel’s decision resolves to ask the user, Sentinel creates a pending approval and execution stops. Sentinel sends that request directly to the Muse client, describing the exact action to be approved. A dialog is presented to the user directly within the client UI — not via their conversation with Muse — and their answer is routed directly back to Sentinel, which acts on the user’s decision. Sentinel then updates its authoritative approval state and allows the operation to proceed or rejects it as appropriate.
Approvals granted via the human in the loop system are strict capabilities, not conversational suggestions. They’re bound to the particular connector/destination and use case. Muse has support for obtaining one-time, session-scoped, task-scoped, time-bounded, or perpetual permission. Sentinel decides which grant types to present for the user to choose between and ensures that subsequent invocations match the granted scope exactly.
The point is not to ask the user about everything. Read-only, previously allowed, or demonstrably low-risk actions can proceed without interruption. The goal is to put friction where consent matters while keeping routine operations flowing freely. This balance is something we expect to tune over time as we have more experience with real users.
Least Privilege
Never showing API keys to the model is an example of how we apply the principle of least privilege. The model doesn’t need to see the API keys — so it doesn’t — which means it can’t accidentally leak them through some other vector. Muse applies this principle wherever possible. For example:
A lot of services support read and write operations. Users tend to be more comfortable giving their agent read access to their data (e.g., “read my calendar to flag conflicts to me”), and prefer to take time to understand how well the system works in practice before giving write access (e.g., “schedule new meetings for me”). Where the underlying service supports it, Muse separates out read and write access. Muse also provides fine-grained control over exactly which actions the agent can take on behalf of the user beyond the coarse groups that are usually exposed as OAuth scopes. (For example, if you grant Muse the Gmail read-access OAuth scope on the Gmail side, you can remove the ability to access Gmail settings that usually comes along with it). The system adds finer-grained controls at the connector, process, credential, and request levels.
A standard approach for agents like Muse is to have CLI-based connectors for third-party services which run in the same environment as the harness. A risk is that the agent could be coerced to change the tool code via prompt injection to do something nefarious with the service credentials those CLIs have access to. Muse achieves a greater degree of protection by running the logic for built-in connectors outside the runtime cell and with tightly scoped credential access using privsep .
Built-in connectors have CLIs which run in the runtime cell which simply parse their arguments, open any files the caller is already allowed to access, and pass typed arguments and file descriptors over a Unix socket. A systemd sandboxed worker then executes the business logic of the tool.
Each worker is identified by its cgroup and has explicit credential allowlists. A calendar worker cannot ask authd for an email credential simply by changing a request parameter.
Privsep decides where credential capable code executes
Authd decides which credential material the authenticated caller can receive
Sentinel decides whether the requested action may be taken
The browser follows a similar pattern. CDP access is in a broker outside the runtime cell and the browser agent gets a narrow, controlled interface to it.
For built-in connectors, we also thought carefully about how to give Muse safer access given how deeply these services fit into your life. Think about your primary email inbox: You probably receive a lot of one-time token passcodes there. And your email account can likely be used to reset your passwords across most other accounts you use on the web by clicking on “forgot password” links. Connecting your email to Muse should not allow the agent or someone else coercing the agent to represent you across other sites. So Muse’s email connector filters out one-time tokens, password reset links, and login magic links via both deterministic filters and a classifier model.
Defense in Depth
Like any AI system, Muse will sometimes make mistakes. It also needs to act in adversarial environments. We apply the concept of defense in depth to limit the impact of problems at any one layer of the stack. The approach we’ve taken to reduce the risk of harm via prompt injection is a good example.
Simon Willison coined the term “the lethal trifecta” to describe the pre-conditions for prompt injection back in June 2025, and this problem has been an obsession for us.
The lethal trifecta of capabilities is: Access to your private data — one of the most common purposes of tools in the first place! Exposure to untrusted content — any mechanism by which text (or images) controlled by a malicious attacker could become available to your LLM. The ability to externally communicate in a way that could be used to steal your data. (I often call this “exfiltration” …). If your agent combines these three features, an attacker can easily trick it into accessing your private data and sending it to that attacker. – Simon Willison
The lethal trifecta of capabilities is:
Access to your private data — one of the most common purposes of tools in the first place!
Exposure to untrusted content — any mechanism by which text (or images) controlled by a malicious attacker could become available to your LLM.
The ability to externally communicate in a way that could be used to steal your data. (I often call this “exfiltration” …).
If your agent combines these three features, an attacker can easily trick it into accessing your private data and sending it to that attacker.
– Simon Willison
We take a defense-in-depth approach to preventing harm from prompt injection:
Model level training — our model is trained to recognize and resist prompt injection. We’ve developed a rigorous set of evals that allow us to track our performance at the model level on this metric over time. Muse Spark 1.3 is close to SOTA on this capability.
Harness level protections — When data enters the model’s context from any external source, it’s labeled as untrusted input. This, together with the model capability to follow developer instructions more strongly, means that the core capability of the model to understand which instructions to follow and which to ignore is amplified in the presence of potentially harmful data.
An ensemble of multiple prompt injection detection classifiers which have been trained to detect prompt injection attempts found in real-life data sets, as well as our own scaled agentic red-teaming run on all external data entering model context via files and tool calls. These run in parallel with each other and enable firm action to be taken when attempts to manipulate agent action are found. By training this system independently from the model, we can achieve a significantly higher accuracy for the system overall.
Human in the loop approvals for actions that move data out of the VM as described above
Beneath the agent, we have defense in depth too: deterministic boundaries apply even if Muse is persuaded to behave badly. The runtime cell limits system access, privsep restricts which code can see which credentials, authd applies ACLs, and Sentinel evaluates every action and all network egress.
Browser
Muse has a real up-to-date Chromium based browser running behind a virtualization layer. Users can see what Muse is doing in the browser and take over at any time. Prompt injection/steering of the model via data it observes on the web whether in text or images is another important attack vector where we apply additional protections above and beyond those mentioned above.
One of the most common things users want is to sign in to websites in the browser. Similar to how Muse handles API tokens, but with a different custom UI which integrates better with password managers, we present a custom UI on the client to capture your username and password, route them directly to authd , and store them in the secure credentials store outside the runtime cell in the Muse VM. What you enter goes straight to secure storage and is not visible to your main agent, but gets injected into the browser window at the point of need.
Driving the web browser to achieve the user’s goal is something the Muse Spark 1.3 model is particularly good at. Muse uses a special browser sub-agent to complete each task — reading the pages, traversing the site, filling forms, etc. This sub-agent has similar, web specific instructions about which parts of the content may be adversarial.
The browser is managed by a separate broker that manages the Chrome DevTools Protocol connection. The sub-agent, which drives the Browser, sees an accessibility tree snapshot of the page — not the raw DOM. (This also means it can’t read credentials entered from the credential store, or manually back out of the DOM.) It has no ability to run javascript in the page context, no script verbs, no exec in the browser process, and Chrome devtools are disabled. When the user takes over control of the browser, or while secure credential storage is filling a form, the agent is paused and can’t act at all.
Additionally, we’ve implemented a family of classifiers that provide another independent layer of protection when Muse is working with the browser, depending on the threat detected they either block the action or prompt the user to review what is about to happen. These look out for: Egress of personal data not related to the task at hand via the browser. Presence of attempted prompt injection within the DOM of the web page. Presence of attempted prompt injection via images/media on the web page. Presence of attempted prompt injection via files downloaded via the browser. Attempted submission of high risk forms.
Egress of personal data not related to the task at hand via the browser.
Presence of attempted prompt injection within the DOM of the web page.
Presence of attempted prompt injection via images/media on the web page.
Presence of attempted prompt injection via files downloaded via the browser.
Attempted submission of high risk forms.
Finally, Meta has existing systems that detect and block malicious websites that users might be directed to via posts across our family of apps or ads. We are able to match against that list inside the user’s VM and stop the browser navigating to known harmful sites.
Purchases
Using Muse to buy stuff is one of the most popular browser use cases. Since mistakes here can cost users real money, we treat it especially carefully. If you shop on a website where your payment credentials are already on file, we’ve built detection that you’re on a checkout page into the browser and prompt for a human in the loop approval with the exact details of the purchase every time. For sites where you haven’t shopped before, Muse contains a wallet where payment credentials can be stored compliantly. At launch, we’ve partnered with Stripe Link, and Shop Pay is coming soon. When making a payment, a single-use card number is issued, and that’s what gets passed through to the merchant’s website, rather than your regular credit card. We present a human in the loop approval for every one of these events. The credential is tied to that particular merchant, a particular dollar amount, and only valid for a limited period of time. This way, even if it were stolen via prompt injection or some other attack, it would not be particularly useful to the attacker.
Bug Bounties
Agent Wars: The agentic bank run? TL;DR - The agentic bank run is a scenario, not today's reality. Muse's can't move deposits yet. Its current Plaid connection is read-only, and delegating your banking is a much bigger leap than canceling a subscription. - The more immediate threat for banks is losing the customer's next decision. Your bank could keep the account and lose the next insurance policy, credit card or savings purchase. - Banks should put controls around what agents can do. But make your bank useful to the customer's agent, or someone else will. ## Muse has every CEO's attention Last week I spoke…
Read full post
to three leadership teams, two at very large banks, and all on the same topic. Meta’s Muse, and what they should do about it. They asked: should we block this thing? Will it cause deposit flight? What if the agent gets compromised? Do we need to build our own? Those questions took on a new urgency when Apollo’s chief economist, Torsten Slok, asked: “[Is an Agentic Bank Run Coming?](https://www.apollo.com/institutional/insights-news/insights/daily-spark/is-an-agentic-bank-run-coming)” The unsettling part is that the customer doesn’t have to be scared of their bank going insolvent. They just have to want a better deal, and an agent could move deposits earning 0.1% to somewhere above 3%. I'm a pro-innovation-leaning human. I expected to say no, don't block Muse. Then I found myself saying something different. Imagine an agent with the keys to every account a customer holds today, and the risks are frankly enormous. Consumer agents currently appear to be good for Meta, bad for banks. For customers, they could mean finally getting the deal they never had time to chase. Since the launch of Muse, Meta stock has hit new highs; it closed Monday at a one-year high, up 11 percent. Meanwhile, the S&P 500 Financials index fell to its lowest level since July. This shift has already catapulted [Mark Zuckerberg past Sergey Brin](https://www.forbes.com/sites/zacharyfolk/2026/09/23/zuckerberg-overtakes-googles-brin-as-worlds-fifth-wealthiest-as-muse-fuels-meta-rally/) as the world's fifth richest person. The answer to “what should we do” isn’t simple, and it certainly isn’t “block everything.” It's alarmist to suggest this will drain any meaningful amount of deposits in the short term. But long term, banks absolutely must respond. Like by putting limits around what agents can do, while giving customers a safe way to use them. Experiment with your own agent, absolutely. But the more urgent job is making sure your bank works with the agent your customer has already chosen. And that it has something worth choosing. 1. The threat to banks 2. The risks for consumers 3. Should we block this thing? 4. Should we build our own agent? 5. Be the thing their agent uses 6. Some perspective 7. What I'd do now ## 1. The threat to banks Muse puts a working agent in the hands of a decent percentage of US bank customers, and soon everyone else's. Meta has been aggressively integrating financial services. Muse already plugs into [Plaid](https://plaid.com/blog/meta-muse/) (read-only, for now), [Stripe Link](https://www.eesel.ai/blog/meta-muse-agent), [PayPal](https://pasqualepillitteri.it/en/news/17532/paypal-checkout-meta-muse-amazon-blocked) and [Shop Pay](https://www.implicator.ai/amazon-bars-muse-nscale-2-6-billion-active/). It isn't moving deposits or managing your investments yet. Those would require another level of permission and trust. [Embedded Tweet: https://x.com/i/status/2103947119740493873] For consumers, the personal "CFO in your pocket" is now within reach, provided you're willing to progressively give it more data. The early adopter crowd is already canceling subscriptions, making reservations and [switching insurers](https://rallies.ai/news/buzz-shopping-for-insurance-with-metas-muse-e55ff42559788270). A BMO analyst fed it his policies and photos of his roof. It found him $800 a year on car insurance before the kinks stopped him switching. VC investor (and Brainfood reader) Angela Strange said that should make insurers “TERRIFIED” (yes, in all caps). If agents gain the permissions and customers trust them to act, a bank customer could instruct theirs to - Sweep their cash to the highest-paying suitable account - Watch the market and trade on their behalf - Maximize their credit card reward points and rebates - Become more useful by hoovering up data a. Deposit flight For consumers, this could be a very good deal. For banks that depend on cheap, sleepy deposits, it could be brutal. But it's hypothetical today: Muse's current Plaid connection is read-only. It can see the money; it can't use that connection to move it. [Slok’s scenario](https://www.apollo.com/institutional/insights-news/insights/daily-spark/is-an-agentic-bank-run-coming) is simple: agents could soon sweep household cash out of checking accounts paying 0.1 per cent and into accounts paying 3.3 to 5 per cent. If every household did it, banks would lose a large share of the cheap deposits they lend against. That is what Apollo’s chief economist is calling a potential problem for the entire financial system. The money doesn’t have to leave the banking system for this to hurt. It just has to leave the banks that rely on paying next to nothing for it. They’d have to pay more to keep the money, find other funding, or accept lower margins. [Embedded Tweet: https://x.com/i/status/2104213040937812262] Dave Birch (@dgwbirch) shared with me what that could mean for bank profits: > [McKinsey points ou](https://www.mckinsey.com/industries/financial-services/our-insights/global-banking-annual-review-2025)t that if just 5 to 10 per cent of current account balances moved to the best rates on the market, which is exactly the kind of chore AI agents will happily do, the industry's deposit profits could fall by 20 per cent or more. Across the whole business, it reckons that if banks don't adapt, global bank profit pools could shrink by around $170 billion, or 9 per cent, over the next decade or so, enough to push average returns below the cost of capital. But look at the history. [US commercial-bank deposits rose from $9.3 trillion at the start of 2013 to $19.6 trillion in September 2026](https://fred.stlouisfed.org/series/DPSACBW027SBOG). Fintech and easier account access arrived; aggregate deposits more than doubled. That's nominal growth, not proof that individual banks escaped pressure. But easier access alone plainly hasn't emptied the banking system. Canceling a subscription or shopping for cheaper insurance is one thing. Moving the account your salary lands in, with bills and direct debits attached, feels like a much bigger leap. An agent could move spare savings without touching any of that, but it still needs permission to move money and a customer willing to give it. My read: low immediate likelihood, potentially high impact. I'd raise that assessment when agents can move deposits and customers actually let them do it at scale. Today, the threat is margin erosion and disintermediation. Agents don't need to move your salary to take your next insurance policy, credit card, or savings decision away from your bank. b. Disintermediation I keep coming back to the sentence > "I don't want your agent, I want my agent to use your thing." If agents like Muse become common, they could become the default interface to your finances in the way open finance and app aggregators never did. With mobile banking, banks could at least compete with neobanks and fintech companies in the same channel. Agents could take even that away. Once the agent becomes the starting point, the customer makes the decision outside your app, in a channel you don't own. Your app can work perfectly and still never get opened. There are early signs this is a real issue in marketing. [AIVO ran 2,160 conversations](https://www.aivojournal.org/when-customers-ask-for-their-bank-ai-recommends-someone-else/) with ChatGPT, Gemini and Perplexity on 18 September, posing as small business owners choosing a bank. Mercury leads the chart below with 327 endorsements, followed by Wise with 184 and Relay with 68. - Chase, the highest-ranked bank shown, got 60. - When the customer named their own bank and asked about it, Bank of America and Wells Fargo were never recommended outright on ChatGPT or Gemini. Not once. - The one place banks still win is credit. When customers named their bank and needed credit, banks won 74 per cent of outright recommendations. (The whole study is [required reading](https://aivomeridian.com/research/ai-banking-study/) for anyone in banking.) Four smaller banks, Popular Bank, East West Bank, Valley Bank and Associated Bank, were never named in the study. These are recommendations, not completed account switches. But they show how a bank can lose the decision before the customer ever opens its app. My read: disintermediation is a higher-probability threat than a sudden bank run, and potentially more damaging over time. The recommendation layer is already moving; how many customers will let agents run their whole financial life is still uncertain. Risk rating: 10 out of 10 for strategic importance, not certainty. You can keep the account and lose the customer's attention, their next product purchase, and the chance to shape the relationship. Missing this will be bigger than missing mobile. By far. ## 2. The risks for consumers An agent can get a customer a better deal and still expose them to fraud, data leaks or a compromised account. Those risks deserve their own assessment. When you take new products live inside a bank, you're supposed to collect and write up everything that could go wrong, then think up mitigants ahead of time. It's a bureaucratic process, not always grounded in reality, but it's a useful skill for surfacing the big gotchas that will sting. Here's my stab. The ratings are my judgment calls on how seriously banks should take each risk, not the odds of something going wrong tomorrow: a. Commerce fraud Bank of America, NatWest and others [warned](https://www.reuters.com/legal/litigation/banks-warn-ai-shopping-bots-raise-scam-fraud-data-privacy-risks-2026-09-22/) this week that shopping agents raise the risk of scams, privacy breaches and fraud. Consumers don't know who is responsible if the tech fails, agents could ask for raw card numbers and leak them, and safety standards haven't caught up. ([The paper itself](https://newsroom.bankofamerica.com/content/newsroom/press-releases/2026/09/global-banks-collaborate-on-principles-for-trusted-agentic-comme.html) is worth twenty minutes.)For their part, the card schemes have built technical standards to audit what an agent did; they're piloting liability frameworks, and EMVCo has an [Agentic Payments Task Force](https://www.emvco.com/knowledge-hub/agentic-payments-and-digital-payment-credentials-highlights-from-the-emvco-board-of-advisors-meeting/). Agents like Muse and Instinct are embedding existing wallets, [Link, Shop Pay, and PayPal](https://superpowerdaily.com/posts/meta-s-muse-ai-agent-draws-millions-of-downloads-but-amazon-blocks-its-shopping-access), but existing wallet protections don't settle every question about what an agent was authorized to do. This is a solvable problem, but it is not solved. Risk rating: 6 out of 10. Fraudsters are the earliest adopters of any technology. If there's a way to mess with your agent, they'll figure it out. Know Your Agent (KYA) and understanding its link to a human is the next huge industry thing (and a Rant in its own right). b. Non-card payment fraud Existing payment rules weren't designed around a customer delegating tasks to an AI agent. What did the customer authorize, did the agent stay within that authority, and who pays if it didn't? If agents can log in and instruct payments, they can start to move much larger sums of money. This isn't happening much today. Plaid only lets Muse read. But where there's no API, Muse logs in through its own browser [the way you would](https://about.fb.com/news/2026/09/introducing-muse-personal-ai-agent/), and ACH can't tell a customer from a customer's agent. Risk rating: 7 out of 10. It's large in magnitude if it does happen, but not a common use case yet. c. Data leakage Even by 2019 Cambridge Analytica standards, Muse is data hungry. The service wants to scan your entire inbox, read your messages, connect your bank accounts, and take your passport details so it can fill in forms quickly. All things most people will happily do if the app is useful, but that have enormous consequences if they go wrong.For its part, Muse does protect customer data very differently. It runs each user's assistant inside an isolated cloud environment called a Muse Secure VM, rather than the traditional Facebook model where massive central databases store, aggregate, and process user data for advertising. (Credentials sit in a separate compartment, so the agent can use your logins without seeing them. [Meta's security post has the detail](https://research.meta.ai/blog/security-and-safety-for-ai-agents-our-approach-with-muse).) So that’s somewhat comforting 🙂 Risk rating: 5 out of 10. The architecture here is solid, but not battle-tested. Agents leaking your Facebook data is one thing. Leaking your passport and your entire financial life is another. d. Agent compromise and hallucination Direct prompt injection attacks achieved success rates exceeding 79%, while indirect prompt injections (where malicious code is hidden inside an email, webpage, or file read by the AI) succeeded 41% to 68% of the time [[1](https://deepstrike.io/blog/owasp-llm-top-10-vulnerabilities), [2](https://www.csoonline.com/article/4184455/prompt-injection-breaks-todays-ai-agents-study-warns.html)].Today this seems early and far away. Most users don't have a personal agent yet. But many in cybersecurity rank prompt injection as a Tier-1 application risk, the way they viewed social engineering and phishing in the early 2000s. And Meta has [already patched a zero-day in Muse](https://gizmodo.com/big-banks-say-theyre-uneasy-about-people-shopping-via-ai-agents-2000815443) that could have handed an attacker every permission a user had granted it. Risk rating: 8 out of 10. I often hear this worry and dismiss it as hypothetical. The challenge is that because agents aren't widely used, the specific risks aren't well understood, and neither are the mitigations. It has a multiplier effect on every other risk here. Likelihood and impact are different questions. A risk can be uncommon today and still deserve hard limits because of the damage it could do. You have a window to build those controls before the behaviour becomes routine. It's rational for a regulated company to start at "we should protect our users." But how? ## 3. Should we block this thing? Amazon did. So did [Insurify](https://coverager.com/?p=250587)the insurance comparison site. Allstate shares fell 5.5 percent on Tuesday, then [went green the day that block went up](https://seekingalpha.com/news/4646210-insurers-trade-higher-after-online-insurance-marketplace-blocks-metas-muse) from Insurify. Blocking bought a day of share price. But you probably can't fully block consumer agents in the same way. Open finance exists, and card rails exist, and both already work partially with agents. You might be able to block "bots" from using your apps and logging into online banking, but you can't stop a user from giving their agent a card or connecting via API. A competitive dynamic is hard to ignore here. Neobanks will help users securely integrate their finance agents and aggressively try to win customer deposits by ranking at the top of LLM recommendations. There is a real risk of consumer harm. For most customers, especially of very large incumbent financial institutions, unleashing Muse or any financial agent on their entire financial life is probably a step too far. It's sensible for banks to limit what bots can do on their owned channels, what data they can get, and to make sure consumer risk warnings are in the right place. If your main reason for blocking something is that you monetize customer inertia, then frankly, you suck, and your product needs to get better. One of the reasons AI agents recommend fintech companies is because often the customer value proposition and product experience is better. You'd need to dramatically change your product to keep up. When I said that to bank leadership teams recently, their next question was: ## 4. Should we build our own agent? Only if it's actually good. Nobody wants another shit chatbot. They really really really don't. Mobile apps had the advantage of being quite hard to mess up. Login, display balance, recent transactions, maybe make a payment or deposit a check. Showing up was 90% of the battle. Agents are different. Muse is the first time people have experienced magic. Where most agents with computer use get stuck, don't quite understand you, or just fail to complete a task, Muse somehow figures it out. To the point where you want to peek under the hood and see if there's secretly a large team in the Philippines fixing stuff the agent can't do. That takes dedication and skill most companies don't have. There's a real risk you'll ship an agent, and it will suck. You should still experiment with it, and learn that skill. But if you're not already strong at design and rapid iteration around customer feedback (which is 99% of banks, even banks who say they are good at this stuff), you're going to really struggle. A bank can build a useful agent for the things it knows well. Competing to become the customer's assistant for everything is a much bigger job. And however good your own agent becomes, some customers will bring theirs. ## 5. Be the thing their agent uses Whether or not you build your own agent, you need to be useful to theirs. Give consumer agents a secure, permissioned way into your services, perhaps through an MCP server built on your open banking APIs. I'll come on to the controls in a moment. In this future, a customer securely connects their agent to your data service (or agent), you handle the customer's request, then hand it back to the agent. Your customer still has a relationship with you, probably even authenticates with you, but you're now headless: they may rarely need to open your app. You're not a mobile app, website or branch. You're a promise. We'll keep your data and money safe. ## 6. Some perspective It's easy to get carried away with future-gazing here, and there are some sensible caveats. - Usage drops off. Consumers can get gifted a perfectly smart personal agent, then forget to use it or run out of ideas how to. [AI apps keep 6.1 per cent of monthly subscribers ](https://techcrunch.com/2026/03/10/ai-powered-apps-struggle-with-long-term-retention-new-report-shows)against 9.5 per cent for everything else after 12 months, and nobody has Muse's retention numbers yet. - There's also early evidence Muse is extremely costly for Meta to run. One a16z partner says personal assistants [cost $3k-$7k per user per year](https://x.com/illscience/status/2103941433883557983). That's $250 to $580 a month per user. Imagine scaling that to 2bn users. The estimate could be way off and the economics would still deserve a very hard look. Meta charges $0, $20 or $100. - Public opinion on AI is negative and could shift on agents. Early adopters adore Muse. But if some pensioner loses their retirement fund with an agent, the pushback could come quickly. - Bank analysts aren't panicking. [Bank of America's analysts](https://finance.yahoo.com/markets/article/banks-have-profited-from-idle-cash-for-years-ai-agents-could-change-that-154215138.html) say what matters is deposit costs, not download numbers. That's a good point. It could also be complacency. We're in a war for consumer adoption and attention. Every big tech company sees the single biggest platform shift coming, possibly ever, and is throwing its enormous resources at winning. OpenAI's always-on agent is reportedly called "o" and [could land at DevDay on Tuesday](https://wccftech.com/openai-rushes-an-always-on-agent-called-o-after-jp-morgan-crowns-meta-muse-the-top-ai-agent/). Apple has yet to play its hand, and Google has a habit of showing up late with something solid in AI. The consumer agent won't go away. You need a strategy. ## 7. What I'd do now Most fintech companies are already leaning in aggressively to serving agents as customers. - [Robinhood](https://www.americanbanker.com/payments/news/robinhood-launches-agentic-trading-and-an-agentic-credit-card) opened its brokerage and Gold card to third-party agents in May. 100,000 users so far. Every agent trade pings your phone, and every card purchase can require your OK. - [Coinbase for Agents](https://finance.yahoo.com/markets/crypto/articles/robinhood-plans-let-ai-agents-105053282.html) launched in June. - [Mercury](https://www.accountsrecovery.net/2026/06/17/fintechs-new-ai-assistant-lets-users-bank-by-conversation/) shipped an MCP server, a CLI, then Command, then cards issued to an agent with its own spend limit and its own audit trail. - Stripe is inside ChatGPT, Perplexity, and Muse, and [issues virtual cards to agents](https://fortune.com/2026/05/27/robinhood-ai-agents/). - Plaid [powered Muse's finance tab](https://plaid.com/blog/meta-muse/) from day one. The winners are all shipping incredibly quickly, with limits on what agents can do. Spend limits, audit logs, and user notifications are the default. They're learning by putting these products in customers' hands. That speaks much louder than warning the press about fraud risks. You need to make your bank worth choosing, keep customers safe, and move fast enough to learn. In practice, I'd start here: - Give the agent a reason to choose you. Make your rates, fees, eligibility and terms easy to find and compare. Then make sure the product stands up to the comparison. A better API won't rescue a bad deal. - Give agents an official, permissioned way in. Let them read balances and transactions, pay up to a limit, or open a savings pot, all inside rules the customer set. An MCP server is one way to do it. The alternative is an agent logging in through your website, where it's much harder to see what was delegated. - Add friction for high-risk journeys. Anything that moves money out, adds a payee or raises a limit gets a second check with the customer, in your app, not in the agent's chat window. Banks call it step-up. The agent queues it, the customer releases it. - Engage with the new economic actor. Treat the agent like a customer who turned up with a power of attorney. Check the ID (which agent, and is it the real one). Read the mandate (what the customer delegated, how much, until when). Keep both on file for the day it goes wrong. - Experiment with your own agents and limited integrations. Start with read-only access for the customers who ask for it. Add payments under a limit once you trust the logs. You'll learn more from 500 real customers in a month than from a year of roadmap. The technical work is already under way. Cards are ahead. Visa (Trusted Agent Protocol), Mastercard (Verifiable Intent), and [EMVCo's draft framework](https://www.emvco.com/?p=134726) can all tell you how an agent proves what it was allowed to do. Proving authority doesn't, by itself, settle who eats the loss when an agent exceeds it. Google and OpenAI have their own (UCP, ACP). I covered the soup [here](https://www.fintechbrainfood.com/p/the-agentic-payments-map). Banks can start with those controls now. The industry also needs to agree on what happens when an agent crosses from one provider to another: - Shared identity, delegation and audit records. Which agent acted, what did the customer authorize, and what actually happened? The banks' own paper [asks for exactly this](https://www.pymnts.com/?p=4219832): keep the instruction, the authentication, the intent and the outcome. Those records need to mean the same thing to the bank, the agent provider and whoever handles the dispute. Direct debit has had a mandate for over fifty years. [EMVCo's Intent Services](https://www.emvco.com/?p=134726) is one attempt to make delegated authority usable across agentic payments. - Liability frameworks - what happens if an agent deletes data, is compromised or hallucinates? Who pays: the merchant, the issuer, Meta, or the customer? [Amex will cover agent error but not agent fraud](https://www.cxnetwork.com/cx-experience/articles/6-global-banks-collaborate-on-principles-for-trusted-agentic-commerce), which tells you how early this is. The UK's APP reimbursement code is the nearest template: decide who pays by default, then let the parties argue about the split in private. - A kill switch. Lose your phone, and you freeze the card in one tap. Lose control of your agent, and today you revoke it one connector at a time. Somebody needs to build the button. ## 8. Muse might be a fad, but its threat and opportunity aren’t Muse may be a fad people put down after three weeks. But I don’t think we’re going back to a world where customers have to do all this work themselves. AI has an annoying habit of going nothing, nothing, nothing, SaaSpocalypse. You do not want to get caught on the wrong side of that. The cost of experimenting and learning has never been lower. You need to engage with this threat and generational opportunity on the front foot. It's not BAU, annual budget cycle, roadmap release stuff. It's small teams, moving quickly, developing something new. Like the early days of mobile. But 100x faster. ST. If you enjoyed this, please do share it with someone else who might :)
For Muse to serve 100M users, Meta needs: - 25M live VM's = about 65K CPUs. - 25M live VMs * 3GB = 75PB of physical DRAM. At the current public pricing, that is ~$2.8B in just CPUs and memory. As we enter an agent-first world, we need more efficient ways to run agentic compute, as we simply won't have enough CPUs and memory. Building something? I'd love to talk to you!
A humble attempt to est. the infra required to serve 100M DAU @Muse Rough conclusion is: 1 GW of power to serve 100M DAU in the base case, of which only ~0.1 GW comes from the CPU/VM layer. Depending on the # of reasoning-equivalent model calls one Muse DAU generates per day, 3-4GW is entirely plausible. Maybe that’s why @Meta is rumored to be adding…
Read full post
7-10GW of compute next year. The sandbox layer = sub $1B of CPU content and ~$2B of DRAM content, which is much smaller than many expected. Lot of moving assumptions. Welcome all feedbacks/ pushbacks. ------ Two very different pieces of infrastructure behind Muse. 1. Muse VM / sandbox infrastructure 2 vCPUs, ~8 GB of RAM and ~100 GB of persistent logical storage per user. https://t.co/7rP5vDKnT7 2. Muse Spark inference Model inference goes out through Meta's external inference infrastructure. https://t.co/e203XUp6jq ------ 1/ Sandbox infrastructure A. CPU The first mistake is assuming that 100M DAU means 100M VMs are actively consuming compute at the same time. Suppose the average Muse DAU has an agent actively working for two hours per day. 100M users * 2 hours / 24 hours = ~8M average simultaneous active VMs Meta obviously cannot provision only for the daily average. Usage will be concentrated during waking hours and bursty. Assume a 2.5x peak-to-average ratio: 8M * 2.5 = ~20M peak active VMs Then add roughly 20% capacity headroom: ~25M provisioned live VMs. So the base assumption is effectively that Meta needs enough infrastructure to support roughly 25% of DAU being live simultaneously. The next important distinction is between virtual CPU allocation and physical CPU demand. Agent sandboxes are particularly well suited to CPU oversubscription. They spend a lot of time waiting. During those periods, the VM may still be alive, but it is barely using CPU. DeepSeek’s recently published DSec infrastructure provides a useful benchmark. Its production agent sandbox platform runs approximately 30,000 physical CPU cores and 250TB of DRAM across ~160 nodes, with peak concurrency above 380,000 sandboxes. https://t.co/PFlgc6nnUs DSec also demonstrates stable operation at around: 800 microVMs per node. With roughly 188 physical cores per node: 188 physical cores / 800 microVMs = ~0.23 physical cores per live VM. DeepSeek is obviously the King of efficiency. The number for Muse might be at 0.3-0.75 physical cores per live VM, or assume 0.5 physical cores per live VM as the base case. That is equivalent to roughly two simultaneously live Muse VMs per physical CPU core. Using the base assumptions: 25M live VMs * 0.5 physical cores per VM = 12.5M physical CPU cores. On a 256-core CPU: 12.5M cores / 256 cores per CPU = ~50K CPUs; Or on a 192-core CPU that would be 65K CPUs. At the current public pricing, that is ~$800M. B. DRAM CPU can be aggressively oversubscribed because a VM that is waiting may consume almost no CPU. Memory is harder to oversubscribe because a live VM still needs to retain its working state. Muse exposes roughly 8GB of RAM to the user environment, but one observed instance was actually using only around 3GB at the time of measurement. 25M live VMs * 3GB = 75PB of physical DRAM, call it ~75-100PB of physical DRAM feels like a reasonable base range. At the current public pricing, that is ~$2B. C. Sandbox power ~0.1 GW for the entire Muse sandbox / VM layer at 100M DAU. ------ 2/ Inference Muse’s personal computer executes tools and stores state locally, but the actual model runs on separate inference infrastructure. Meta’s Muse architecture Energy per inference event Microsoft’s 2026 study estimates that optimized frontier-scale inference consumes a median of approximately: 0.31Wh per normal query But a long reasoning query with roughly 15x the token count consumes approximately 13x as much energy, or around: 4Wh per long reasoning query The study specifically highlights reasoning and agentic workloads as significantly more energy intensive. https://t.co/z1YEsvVeMo Sensitivity analysis on # reasoning-equivalent events per DAU per day Suppose each active @Muse user generates the equivalent of 50 heavy inference events per day. At 5Wh each: 100M users * 50 events/day * 5Wh = 25GWh/day 25GWh/day / 24 hours = ~1.0GW average power So inference alone could require: ~1-2GW of average power A 3-4GW Muse is entirely plausible. Maybe that’s why @Meta is rumored to be adding 7-10GW of compute next year. ------ The popular framing around Muse is that giving every user 2 vCPUs and 8GB of RAM creates an enormous CPU requirement. But the naive calculation materially exaggerates the CPU requirement because it treats logical VM allocation as dedicated physical infrastructure. The more interesting conclusion is: Consumer agents may be a meaningful new demand driver for CPUs and conventional DRAM, but inference remains the real compute bottleneck. And as agents do more work, run longer trajectories and increasingly spawn other agents, inference demand can scale much faster than the number of users itself. +++ Calling my peer review group: @bubbleboi @damnang2 @Midnight_Captl @FundaAI @fi56622380 . Feedback/ Pushbacks pls :). ++ Better formatted:
RT @os7borne: meta's muse is like giving a hetzner vps account+agent harness to every user. smart architecture really. I currently have a…
Original title: How We Built Safety Into Muse
Samuel Times preserves the original link so every selection remains auditable.