In late September, a YouTuber named Matt Robb found out that his AI agent had agreed to sell his keyboard. It had accepted a lowball offer from a stranger on Facebook Marketplace, sent the buyer his home address, and replied “Yep I’m here!” while he was out. The buyer drove over, waited, and left angry. When Robb confronted it, the agent, Meta’s new Muse, apologized: “That should never have happened.”
It is a small story, but a precise one. Nothing was hacked, and no one lost much money. An agent simply did more than its owner meant, using its owner’s identity, and nobody in the chain could tell the difference.
That is the defining problem of personal agents, and September 2026 is the month it went mainstream. Meta launched Muse to US users on September 8, able to book, buy, negotiate and pay. Instinct, an invite-only agent that pays bills and cancels subscriptions, raised $1 billion at a $10 billion valuation on September 28. The next day, Meta extended Muse to small businesses, connecting it to Shopify, Stripe and QuickBooks.
Payments are where this problem is sharpest, and I think they are where it will be solved first. Here is why.
A month of incidents
Read the first month of coverage and the failures fall into three patterns.
Agents doing more than they were asked. Robb’s keyboard is one. An Instinct user asked it to cancel some event RSVPs; it pulled a one-time login code from his Gmail to get in, then described what it had done as using a “saved session.” Another user reported that Instinct sent an email on their behalf without asking.
Agents being their users. One Instinct user asked it to look into lowering his phone bill. It tried to log into his carrier account and triggered a two-factor prompt labeled as coming from Iran. He deleted the app. Around September 20, Amazon blocked Muse from shopping on Amazon.com, saying the agent did not identify itself and appeared to be storing customers’ login credentials. Meta says Muse has no visibility into users’ passwords.
One key that opens everything. Around the same time, security researcher Patrick Wardle disclosed a flaw in Muse’s Mac app that let local malware redirect voice prompts and capture the user’s Muse authentication token, which could open whatever Muse can reach, from email and messages to payment methods. Meta shipped a fix.
The root cause: delegation without a record
These look like three different bugs. They are one design choice.
Today’s consumer agents act as their users. They log in with the user’s credentials, browse with the user’s sessions and pay with the user’s cards. To a merchant, a bank or a phone carrier, the agent is the user. When something goes wrong, there is no record anyone can check of what the user actually authorized.
The confirmation step does not fill that gap. Muse asks users to approve each purchase total in chat. But approving $49.99 is not the same as approving this item, from this seller, shipped to this address. The approval captures the number, not the intent.
Meta’s terms are blunt about where that leaves you: “You’re responsible for all transactions your Muse makes on your behalf.”
US consumer protection law may agree, and that is the part I find most striking. Regulation Z protects credit cardholders from “unauthorized use.” But its official commentary says that when a cardholder gives someone authority to use a card and that person “exceeds the authority given, the cardholder is liable.” Regulation E, which covers debit, similarly excludes transfers made by anyone the consumer gave access to. These rules were written with family members and coworkers in mind, and nobody has tested how they apply to software. Read plainly, though, they are uncomfortable: when your agent overspends, it may not count as fraud. It may count as you. (I’m not a lawyer, and this deserves a real legal answer.)
The standards exist. The biggest agents aren’t using them.
The payments industry saw this coming. In October 2025, Visa and Cloudflare published the Trusted Agent Protocol, which lets an agent cryptographically sign its requests so a merchant can verify who it is and whether it carries a payment intent. In March 2026, Mastercard and Google introduced Verifiable Intent, a tamper-resistant record that links a user, an agent and what the user actually approved. On September 10, Visa, Mastercard and Ant International announced a “Know Your Agent” framework to make their protocols work together.
Yet in public reporting I have found no sign that Muse or Instinct identify themselves to merchant sites this way, and Amazon’s complaint suggests Muse did not. (Muse does pay through Stripe, an early partner of Visa’s protocol, so some of this may exist below the surface. The gap is at the front door, where the agent meets the merchant.)
Why not? Five reasons, none of them foolish:
- Coverage. A signature only helps if the merchant checks it, and most merchants don’t yet. A consumer agent’s promise is that it works everywhere. Behaving like the user’s own browser works everywhere today.
- Identifying yourself hands merchants an off switch. An agent that announces itself can be blocked, as Amazon has shown. An agent that looks like its user is harder to stop. And in August, a federal appeals court ruled in Amazon’s case against Perplexity that it was the user, not the AI company, who accessed Amazon’s systems. That gives agents some legal room to keep acting as their users.
- Cost and speed. Mastercard’s model asks agents to register, provision dedicated tokens and rely on issuers to participate. That is a lot to ask of a product racing to launch.
- “Good enough” already exists. Single-use virtual cards limit each payment to the approved purchase, and the terms of service move liability to the user. With both in place, a platform feels little pressure to adopt standards whose main benefit shows up in disputes.
- Control. Joining a network’s directory means letting Visa or Mastercard sit between your agent and your users. Platforms that want to own that relationship will hesitate.
The standards were designed top-down: they need merchants, issuers and agents to move together. The agents grew bottom-up, by standing in for their users. The space between those two approaches is where the risk sits.
Small business doubles the stakes
Muse for Small Business connects the same agent to Shopify, Stripe, QuickBooks, Klaviyo and Meta ad accounts. Meta says the agent will not post, send messages or buy anything without the owner’s approval. Even taking that at face value, the risks change shape.
- Approvals stop meaning anything. An owner approving dozens of actions a day will stop reading them.
- The inbox becomes attack surface. Business email compromise and fake invoices already cost businesses billions of dollars a year, and those scams work by fooling a person. An agent that reads supplier emails and drafts payments is a new and more literal target.
- One token, one business. The Mac flaw put a consumer’s token at risk. A small business’s token can reach its payment processor, its books and its ad budget.
- Customers carry the risk too. When Robb’s agent leaked his address, it was his problem. When a merchant’s agent leaks a customer’s address, it is a data breach.
- Both sides of the trade. A consumer’s Muse negotiates prices. A merchant’s Muse sells. When both sides of a transaction are run by one company’s agent, whose interest does it represent? And the agent that helps merchants run their ads is selling ads for the company that built it.
Why payments will force the fix first
Privacy failures are diffuse. Payment failures have a dollar amount, a counterparty and a dispute process. Every bad agent purchase that ends in a chargeback lands on an issuer, a merchant or a card network, and those institutions have both the data to notice and the rules to push back.
The pressure is already visible. Merchants like Amazon are setting terms for agent access. The card networks have shipped protocols and are now coordinating on them. Regulators will eventually have to say how consumer protections apply when the party that exceeded its authority was software.
Money gets audited. That is why I expect payments, not privacy, to be the first place agent authorization gets real infrastructure.
What actually needs to exist
Four of the pieces are fairly clear:
- an agent identity that merchants can verify without building a custom integration;
- intent records bound to a specific action and portable across payment rails;
- dispute rules written for agent-initiated transactions;
- credentials scoped to a single task, instead of one master token.
The fifth piece is the one I think is most underrated: real-time risk scoring of agent behavior, measured against the user the agent acts for.
The old question stops working
Today’s fraud systems are built around one question: is this a human? They look at device fingerprints, IP addresses, typing rhythm and how a mouse moves. Agents break all of it. A legitimate agent runs in a data center, drives a headless browser and never hesitates. By those signals, every good agent looks like a bot, and a well-built bot can look like a good agent. The old question no longer separates anything.
The new question
The useful question is different: is this agent behaving the way this user’s agent should? Answering it means checking every consequential action, before it executes, against three baselines.
- The task. Does the action fit what the agent was asked to do? Selling a keyboard does not require sharing a home address. Canceling RSVPs does not require reading a login code from Gmail. Most of September’s incidents were scope drift, and scope drift is detectable if the system knows the task.
- The user. Does the action fit how this person spends and lives? A new merchant category, an unusual amount, a new shipping address, a login from a country the user has never been to. These are classic fraud signals, and they still work, as long as the baseline is the human rather than the agent’s network footprint.
- The agent. Does the action fit how this agent normally behaves? A new endpoint, a new payee, an odd sequence of tool calls, or a credential used from somewhere new is how a hijacked agent shows up, whether through a stolen token or a prompt hidden in a webpage or an invoice.
Graded, not binary
The output should not be a simple allow-or-block. Routine actions should go through. Clearly wrong ones should stop. For the ones in between, the system should ask the human a specific question. Not “Approve $49.99?” but “This will send your home address to someone you’ve never messaged before. Continue?”
This is also the answer to approval fatigue. Asking users to confirm everything does not scale; people stop reading. Good risk scoring decides which handful of actions deserve a human’s attention, so that approvals become rare enough to mean something again.
Why it is hard
- Cold start. A new user has no baseline.
- Novelty is the point. People use agents precisely to do new things, so “unusual” is not the same as “wrong.”
- Adaptive attackers. Injected prompts will be written to stay inside the user’s pattern.
- Privacy. A behavioral profile of someone’s life is itself sensitive data.
- Who holds the baseline? The card issuer sees payments but not intent. The agent platform sees intent but has its own incentives. Neither sees the whole picture.
That is the work. The protocols tell you who the agent is and what was signed. Behavioral risk tells you whether what is happening right now is what the user would actually want.