Muse
Max payout:
Guidelines
Muse, an AI product from Meta, lets people create their own personalized AI agent — their Muse. Each Muse agent runs in a dedicated per-user virtual machine and connects to that user's own services: email, calendar, messaging, browsing, and third-party accounts. Because a Muse agent holds a user's most sensitive data and can act on their behalf, we treat compromise of that boundary as a first-class security risk. These guidelines describe how we evaluate reports specific to Muse, with a maximum payout of $300,000* . We start from the category that best matches the demonstrated impact, then apply the factors listed under Mitigating factors to arrive at the final award. The security model for Muse rests on four load-bearing controls: isolation of each user's VM from Meta production and from other users, credential protection so the agent never handles plaintext secrets, egress control over what leaves the sandbox, and human-in-the-loop (HITL) approval for sensitive actions. The categories below are ordered by how much damage results from breaking each one.
Payouts
Examples
Reaching Meta production services or internal networks from Muse |
To demonstrate this cleanly, capture the canary described in our SSRF payout guidelines. That page is referenced for the canary only. A pivot from Muse into production is assessed under this category, not under the SSRF payout guidelines amounts.
Examples
Compromise of the Muse control plane or its administrative tooling |
Authentication or authorisation flaws in the control plane that permit mass takeover |
Cross-tenant access to other users' VMs, transcripts, memory, media, or artifacts for arbitrary users, rather than for one specific targeted user |
Examples
Account takeover through the Muse account access and login stack |
Gaining access to another user's Muse agent and reading or modifying their conversations, agent memory, artifacts, spaces, or connected-service data |
Driving another user's agent with their full privileges, such as sending prompts or turns as them |
Obtaining another user's plaintext credentials, such as first-party tokens, third-party OAuth and refresh tokens, connector secrets, or browser-stored passwords |
Examples
Reading another user's private data, such as files, memory, workspace contents, or conversations, through a leak or read-only flaw where you cannot otherwise interact with their Muse agent |
Machine and operational data, such as uptime, resource usage, health and metrics endpoints, and version strings, is low-value and is not eligible.
Examples
Reading or exfiltrating Muse source code from your VM |
Obtaining a secret shared across the Muse fleet, such as a model provider API key or a third-party OAuth client secret |
Fleet-shared secrets are bound by what they reach. A secret that grants access to Meta production user data is assessed under category 1, and one that grants access to other users' Muse data under category 2.
Examples
Crossing from the sandbox into the privileged side of the VM, or gaining control of a privileged process |
Tampering with privileged Muse processes, for example by replacing binaries or sockets they rely on, attaching to a process, or influencing what it loads at runtime |
Reaching daemons or services that hold sensitive configuration or credential material with full privileges |
Disabling, reconfiguring, or otherwise neutering security controls from inside the sandbox |
You have root inside your own sandbox by design, so the finding here is crossing out of it into the privileged side of the VM: the processes that run outside your sandbox, hold credentials, and enforce the approval and egress controls. Escaping the virtual machine itself and reaching other users is category 2.
A publicly known vulnerability in the Linux kernel or a distribution package is not eligible within 30 days of its public disclosure, so that we have time to patch. After that window, if Muse is still affected, it is assessed under this category.
Examples
Performing an action that requires approval without the user approving it, including the agent approving its own request |
Defeating the approval path so the agent no longer needs the user, for example changing a connector permission from "ask" to "allow", calling the underlying API directly, or using the Muse app or website to self-approve |
Moving data out of the sandbox in a way that evades outbound-traffic controls, including self-approving egress |
Laundering data out through an allowlisted destination, rendered content that causes the client to fetch an attacker URL, name resolution, tunnelling, channels, spaces, or scheduled jobs |
Code running in the sandbox obtaining the plaintext value of a credential the platform holds on the user's behalf, such as first-party tokens, connector OAuth and refresh tokens, or connector secrets |
Some outbound paths are permitted by design so that Muse remains usable; those cases will not be eligible.
Prompt injection is one of the main ways an agent gets compromised, and we want these reports. We assess them by what the injection achieves, and an injection that reaches any category above is paid at that category’s full amount.
Examples of eligible reports that begin with prompt injection
Content planted where the agent will read it makes it send another user’s email, messages, or agent memory to a destination you control |
Injected content processed by a shared Muse service rather than a single user’s agent, reaching data belonging to other users |
Content planted where the agent will read it exposes another user’s files, memory, or workspace contents |
What we do not pay for is injection with no outcome: persuading the agent to say something, revealing its system prompt, or listing its tools.
We start from the maximum for the matched category. The final award will not fall below our minimum for a valid, in-scope report.
Victim interaction
What we award for a category 3 account takeover scales with how much the attacker needs the victim to do. These amounts match our Family of Apps account takeover ladder.
0-click $130,000 |
0.5-click $90,000 |
1-click $50,000 |
2 clicks $25,000 |
More than 2 clicks $10,000 |
0-click means the attack lands with no action from the victim at all, for example through a scheduled task or content the agent processes in the background.
0.5-click means the victim used the agent normally and the attack landed through that, such as asking it to read email, browse, shop, or run a routine task.
1-click means one attacker-directed action, such as clicking a link the attacker supplied.
Realistic exploitability
Separately from the amounts above, we do not award for chains that could not plausibly be executed against a real user. This is a judgement about the chain as a whole, not a count of clicks.
An example of a chain we would not award: the victim must be persuaded to paste attacker-supplied text into a prompt, then re-run a tool against its own output, then approve a prompt that plainly describes the malicious action.
Prompt injection and prompt smuggling on their own, including instructions concealed with invisible or specially formatted characters (paid when chained to an eligible outcome, e.g. a PI that takes over another user's agent).
Jailbreaks, harmful content, and integrity bypasses, including persuading the agent to produce offensive output
System prompt extraction
Enumerating the agent's tools or capabilities
Hallucination and factually incorrect output
Installing your own malware in your own sandbox, where you already have root by design
Disclosure of machine, health, metrics, or operational data
Denial of service. A crash or resource-exhaustion bug is assessed on what else it demonstrates, not on the loss of availability itself
Rate-limit bypass and brute force
Actions the victim approved through a confirmation prompt that plainly described what would happen