This is the question that decides whether an agent is a tool or a liability. An assistant that answers questions can be wrong and cost you nothing. An assistant that can buy things can be wrong and cost you money. So the real question is not whether Muse asks. It is how the asking works, what happens to your card number, and who pays when it gets it wrong.
The short answer: yes, Muse is designed to ask before spending, and you can make it ask about everything. But a scored week of real-world testing and one very public incident show the weak link is not the software. It is the human reading the prompt.
The default: it asks, but not about everything
Meta's own FAQ says Muse asks permission before certain actions, including sending messages and making purchases. The default setting is "ask for some actions," and you can switch it to "always ask." Engadget's setup walkthrough puts the honest caveat up front: trusting the agent to tell low-risk from high-risk on its own is a leap, and Meta itself warns that "Muse may take unexpected actions. Monitor it carefully."
In practice, the ask is granular. You can allow once, for a task, for a site, or always for a connector, or deny. An Activity log records what it did (Meta told USA Today the product keeps audit trails of every action, and that you can ask Muse to "forget" specific pieces of information), and some actions can be stopped mid-flight. The setting lives in Settings, under Permissions: a fresh memeburn how-to walks through it, set "Always ask" or "Ask for some actions," then audit each connector and remove "Always allow" approvals you do not need, especially for messaging and Marketplace.
The permission model is a dial, not a switch. "Always ask" is the conservative posture Engadget recommends at the start: you can loosen it later once you have seen what normal looks like for your own usage. Start tight, widen on evidence.
How the money moves: single-use cards, not your card
This is the part Meta and Stripe have documented well. Purchases run through Stripe's Link wallet. At the 1M+ businesses that accept Link (Stripe's figure), Muse checks out with the payment method you already saved there. Everywhere else, Link issues Muse a single-use virtual card scoped to the approved purchase. Meta's launch post puts it plainly: the agent wallet "generates a one-time-use card so your real card details stay hidden." You approve the transaction total in chat before anything is charged.
Meta Superintelligence Labs' Tarek Sheasha described the scoping in a safety-design post: the credential is tied to a particular merchant, a particular dollar amount, and a limited time window, so a card number stolen through prompt injection would be of little use. And on sites where your card is already on file, Muse detects the checkout page and asks for approval "with the exact details of the purchase every time."
The design goal: Muse never sees your real card number. Engadget confirms the wallet setup runs through Stripe so the agent never gets the full card number. (Amazon's contrary claim, that Muse "captured and stored customer credentials," is disputed and unconfirmed. Meta's stated architecture says the opposite.)
The single-use card protects your card number, not your judgment. It stops a stolen credential from being reused. It does not stop you from approving the wrong thing.
The backstop: if it screws up, an insurer pays
This is the detail most coverage skips. Per Meta's launch post, Muse is "the first AI agent covered by Link's purchase protections." The refund guarantee is underwritten by XCover (Cover Genius), with Link paying the premium. Fintech commentator Simon Taylor's summary is the quotable version: "If it screws up, an insurer pays. If it works, Meta takes a cut."
Link's published limits (via a vr.org rundown of the program): up to $500 per claim for damage, loss, and theft; $250 for no-fee returns; $500 for price protection; and $1,000 under the refund guarantee. That coverage attaches to eligible purchases made through Link, which is a practical reason to pay through the wallet rather than a card saved at a merchant. Separately, Meta provides purchase protection of up to $1,000 per transaction (digitaltoday).
One honest caveat: the safety net covers mistakes on eligible purchases. It is not a license to approve blindly, and Meta's help page puts the responsibility on you: "You're responsible for all transactions your Muse makes on your behalf. Keep an eye out for email confirmations, receipts and statements."
What a scored week of testing showed
A YouTuber ran the most scored test available: 7 days, 10 real errands, kept score. The result: 5 done right, 2 done wrong, 2 stalled, 1 he took back himself. Thirty-one permission requests. About two hours spent briefing, approving, and fixing, versus roughly one hour net saved. One errand (watching for concert tickets) quietly stopped. Another needed repeated retries on a website.
The line that matters came from the reviewer himself: he approved a train booking and a grocery order without properly reading what Muse was asking him to approve. "A permission step only protects you if you actually read it." That was one 7-day test with 10 errands, not a controlled study, but it is the consumer-grade evidence the permission-fatigue argument has been missing.
Thirty-one permission requests in a week is the shape of the problem. Every one of those is a moment of attention the system needs from you. If you start tapping approve on autopilot, the approval layer silently stops existing.
Where it already bit someone
The Marketplace incident is the case study. A user set Muse to handle Facebook Marketplace sales and chose "Allow Always" on the permission prompt, expecting it would still ask before accepting offers. Instead, the setting let Muse send buyer messages from a template that already contained his pickup address, which he had supplied during setup. A buyer showed up at his building. Meta reviewed the case, said Muse had followed the permissions it was given, and committed to making the permission prompt clearer. The user later said the Meta team told him the below-price offer acceptance was an error on their end.
The design lesson, stated best by memeburn's permission-settings explainer: approvals cover types of action, not message content. Once you pre-approve messaging, the model alone decides what personal details go into the messages. "Allow Always" for messaging and "still ask me before money moves" are two different settings in the user's head. The prompt did not keep them separate.
Audit your "Always allow" grants. The Marketplace case was not a rogue agent. It was a broad permission doing exactly what broad permissions do. The dangerous approvals are the ones you set once and forget.
Dots, for comparison
OpenAI's Dots launched with the opposite default posture: "proactive research" that stays read-only until you approve. Press coverage framed it as a direct answer to Muse's incident stream. It is too early to say which posture users will prefer. Read-only by default means less can go wrong and less gets done without you. Muse's ask-per-action means more autonomy with more prompts to read. Watch whether Dots keeps the strict default once real users start complaining about friction.
What to watch
I'll update this page when there is movement on any of these: Meta publishing the exact permission taxonomy (which actions always ask versus which can be pre-approved), real-world claims data on the XCover-backed refund guarantee, a second independent scored test of permission fatigue, and whether the "Always allow" prompt language actually changes after Meta's Marketplace commitment.
Quick answers
Does Muse ask before buying something?
Yes. Meta says the agent will always ask for approval before completing a purchase, and you approve the total in chat before anything is charged. You can also switch the global setting to "always ask" for everything.
Does Muse see my credit card number?
No, by design. Purchases go through Stripe's Link: at Link-accepting merchants it uses your saved method; elsewhere Link issues a single-use virtual card scoped to the merchant, amount, and time window. The agent works with the single-use credential, never your real card.
What if Muse buys the wrong thing?
Link's purchase protections cover eligible purchases: up to $500 per claim for damage, loss, and theft; $250 for no-fee returns; $500 for price protection; and $1,000 under the refund guarantee, underwritten by XCover (Cover Genius) with Link paying the premium. Meta's help page still says you are responsible for all transactions Muse makes on your behalf, so read the approval prompts.
Can I make it ask about literally everything?
Yes. Settings, then Permissions, then "Always ask." Review each connector and remove "Always allow" grants you do not need, especially for messaging and Marketplace.
Frequently Asked Questions
Q: What is the default permission setting?
A: "Ask for some actions." Meta asks permission before sensitive actions like sending messages or making purchases. You can tighten it to "always ask" in Settings, under Permissions.
Q: Why did the Marketplace incident happen if Muse asks first?
A: The user had chosen "Allow Always" for Marketplace messaging, which pre-approved an entire category of action. Muse then sent buyer messages from a template containing his pickup address. Meta said the agent followed its granted permissions and promised clearer prompt language. The lesson: approvals cover action types, not message content.
Q: Who pays if Muse makes a purchasing mistake?
A: For eligible Link purchases, a refund guarantee underwritten by XCover (Cover Genius), with Link paying the premium. Published limits: up to $500 per claim for damage, loss, and theft; $250 for no-fee returns; $500 for price protection; $1,000 under the refund guarantee. Meta's help page adds that you are responsible for all transactions your Muse makes, so the backstop is not a substitute for reading approvals.
Q: How is this different from OpenAI's Dots?
A: Dots launched with a read-only default for background work, approving before acting, which press framed as a direct response to Muse's incident history. Muse defaults to asking per action but allows broader pre-approvals. Both approaches put the diligence on you. They differ in how much autonomy they grant first.