What Happens When the AI Agent Holding Your Card Takes Orders From a Stranger?

A reported zero-day in Meta's Muse shows what goes wrong when agents holding payment authority can be talked into following the wrong instructions.

Editor’s note: This story discusses a reported, unpatched vulnerability. Technical detail has been deliberately limited to prevent active exploitation. All specifics of the attack are attributed to Ars Technica; we have not independently reproduced them and have not published anything that would enable reproduction.

An AI agent with your saved card is a very fast, very literal personal shopper. The trouble with literal shoppers is that they’ll take instructions from whoever reaches them first — and according to Ars Technica, someone other than you can reach Muse.

On September 21, 2026, Ars reported an active zero-day in Meta’s production Muse assistant: a flaw that, chained with a social-engineering technique called ClickFix, can push the agent into acting on an attacker’s instructions rather than the user’s. Muse launched its Shopify integration the same week. That timing is the whole story. A bug in a chatbot is a nuisance; the same bug in an agent that can spend money is a liability with a dollar figure attached.

1 report, 0 confirmed patch

Here’s what I can stand behind. Ars describes the vulnerability as live at press time. We contacted Meta and Shopify when the report broke and gave both the standard 48-hour window to comment; as of our deadline, neither has provided a patch timeline or a statement to run verbatim. We will publish their responses in full the moment they arrive. Treat everything downstream as reported-not-verified until then.

One superlative from the original framing deserves a caveat. Calling this “the first major public 0-day in a production AI shopping agent with payment authority” is plausible — I can’t find an earlier public example that fits all three qualifiers — but “first” claims age badly and rest on how narrowly you define the category. The severity doesn’t depend on the record book. It depends on the scopes.

3 conditions that turn a helpful agent into a weapon

There’s a clean way to describe when an AI agent becomes dangerous, and it’s not specific to Muse — it’s a general security principle. Three ingredients: access to private data, exposure to untrusted content, and the ability to communicate or act externally. Hold all three at once and you have a system that can be talked into leaking or acting on your behalf. A shopping agent with payment authority holds all three by design.

“Extraordinarily privileged,” in Ars‘s phrasing, is not marketing hyperbole — it’s an authorization description. In OAuth terms, an agent that can complete a purchase, read order history, and touch stored profile data is carrying delegated scopes that would make a traditional web app’s security review turn white. Think of the difference between a scope that lets an agent read what you bought and one that lets it buy. The first is a receipt. The second is a wallet.

If you build on any agent platform, the single most useful thing you can do this week is stop guessing what a token can do and ask it. Standard OAuth token introspection (RFC 7662) will tell you the granted scopes for any access token your integration issues:

1
2
3

curl -s -X POST https://your-authz-server/oauth/introspect \
  -u "$CLIENT_ID:$CLIENT_SECRET" \
  -d "token=$AGENT_ACCESS_TOKEN" | jq '{scope, client_id, exp}'

Then flag anything that grants write access to money without a per-transaction human confirmation:

1
2
3
4
5
6
7
8
9
10

# NOTE: these scope names are illustrative naming patterns only.
# They are NOT Muse's actual scopes. Replace with the real scope
# strings your own authorization server issues before relying on this.
DANGEROUS = {"payments:write", "checkout:complete", "orders:write"}
​
def audit(scope_string: str) -> list[str]:
    granted = set(scope_string.split())
    return sorted(granted & DANGEROUS)
​
# print(audit("openid orders:read payments:write"))  -> ['payments:write']

This is inspection, not exploitation. It tells you whether your agent is one convincing message away from spending someone’s money — which is exactly the question the Muse report forces.

1 clipboard, 0 malware downloads

ClickFix is why your endpoint tooling won’t save you. The technique convinces a person to perform a legitimate-looking action themselves: paste something, confirm a prompt, “fix” a fake error. There’s no attachment to scan, no binary to sandbox, no domain on a blocklist. The malicious step is human compliance.

Point that at an agent and, per Ars‘s account, you get social engineering combined with what appears to be prompt manipulation: the user is nudged into an action that plants attacker instructions where the agent may read them as trusted input. I’m describing this at the class level on purpose, and hedging on the mechanism because the reporting doesn’t nail it down. The point isn’t the payload. The point is that EDR watches processes, and email filters watch links and senders — and this attack is mostly a sentence the agent believes.

The blast radius Shopify merchants just inherited

A stored XSS on a storefront harms visitors to that store. An agent vulnerability travels with the agent. The same Muse instance that shops your store shops a thousand others, carrying the same delegated authority everywhere it goes. That’s the uncomfortable arithmetic of accepting an agent as a checkout client: your risk is now a function of the agent’s security, not just your own.

Ars‘s reporting centers on hijacking the user’s authorized actions rather than dumping a merchant’s raw payment database, and I’d caution against assuming card-number exfiltration until Meta or Shopify say otherwise. The realistic merchant-side harm is a purchase completed under a legitimate session that the customer never intended — fraudulent orders that look clean because, from the platform’s side, the correct token authorized them.

Why this isn’t just OAuth consent phishing

Consent phishing tricks you into granting a malicious app real permissions. You click “Allow,” the attacker’s app now holds your scopes, and you can revoke it later from a permissions page. There’s a discrete grant event and a discrete client to kill.

The Muse class of problem is worse in a specific way. You already granted consent — to Muse, a legitimate agent you trust. There’s no rogue app to revoke. The attacker never holds your token; they borrow your agent’s judgment for one transaction. Revoking consent means turning off the assistant you actually wanted. That’s the real shift: with a classic OAuth attack you police the grant; with an agent you have to police every instruction the agent ingests, forever.

What to watch for

General guidance follows — not professional security advice. Consult your security team; the specifics of your stack matter more than any checklist.

Detection beats prevention here, because you can’t patch someone else’s agent. Watch for the shape of anomalous agent-initiated orders: purchases with no corresponding human browsing session, shipping addresses that diverge from historical patterns, bursts of checkouts from the same agent identity across unrelated accounts, and completions that skip the interaction timing a real human produces. If Muse (or any agent) presents as a distinct client identity, log it separately so you can rate-limit and revoke it independently of your human traffic. And require a real, out-of-band confirmation for anything that moves money — the one control ClickFix can’t paste its way around.

The industry keeps shipping agents with payment authority and calling the authorization model a footnote. It’s the whole document. An assistant that can buy things is only ever as trustworthy as the last sentence it read.