Letting Agents Pay for You: What's Still Missing? (Product Side)

This is the product side: what’s still missing for users, product design and the payments ecosystem. An engineering post will follow, going deeper into layer 1: how an agent system actually works out what an action will cost, and how the policy check is built.

AI agents can already pay for users. But when it comes to the payment itself, most users still won’t let the agent complete it: in a survey for Visa, only 23% of Americans trusted AI to make payments for them.

TL;DR

This post answers one question: agents can already pay for users, so why do most users still not let them, and what has to be fixed before users will let agents pay for them?

The examples are three products that already pay for users: Google’s Agentic Checkout, Meta’s Muse, and Instinct, from a startup.

The answer: the payment step itself already works; users still don’t let them because the risk isn’t under control at any of the three layers: an agent can’t see clearly what an action will cost, and doesn’t stop when it can’t tell; payment systems’ fraud models can’t yet price the risk of an agent’s transaction, so the loss gets pushed onto the user; and users haven’t built up trust in agents yet, with no ladder for widening what they consent to step by step.

I split the question into three layers, each answering a smaller question:

• Layer 1, the model: will the agent do something the user never agreed to? Yes. Models take orders from the wrong source, misread intent, overreach and make facts up. The three products have each published part of the same structure: the user’s consent is kept where the model can’t change it; before any action flagged as having consequences runs, code checks that it matches a consent; the model only judges what an action is, and can only stop an action, never let one through. What’s missing comes in two halves. One is seeing the consequences: web pages don’t tell an agent what a step will cost or whether it can be undone, so the agent has to infer it from the page’s DOM (the page’s underlying structure), the text next to a button and the cancellation terms, and inference is probabilistic; the steadier route is for pages or APIs to state the consequences outright. The other is not acting before the consequences are confirmed: in the $258 case (see the top), the cancellation ran before the fee was shown.
• Layer 2, payment systems: can merchants and banks recognize and accept a payment an agent makes for a user? The payment itself already goes through: agents get payment credentials with a limited scope and never see the user’s real card number. What’s really missing is risk control: the fraud models at card networks, issuers and merchants were trained on human behavior, and can’t yet tell which transactions an agent started or price their risk. When the risk can’t be priced, the rules push the loss onto the user first (an agent’s wrong purchase within the user’s consent fits no chargeback reason), and big merchants simply keep agents out.
• Layer 3, users: what do users need before they’ll let an agent pay for them? Users trust Alipay and Apple Pay because of three things: before paying, they know what they’re agreeing to; if something goes wrong, they know in advance the most they can lose; if they’re charged wrongly, they can get the money back. When an agent pays, the user isn’t there, so all three have to be redesigned, and not all at once: Alipay’s password-free limits and the credit limits of Huabei (Alipay’s credit-payment service) both grew step by step with a track record. Trust in agents will work the same way: start with a small scope and widen it as the agent proves itself. Today that ladder doesn’t exist yet.

The problem: from “can buy” to “may buy”

By “agent” I mean an AI that can open web pages, click buttons, fill in forms and finish a task for the user, not a chatbot that only answers questions.

Several agents can already spend money. I’ll use three as examples:

• Agentic Checkout (Google). The user tracks a product’s price in Google Shopping and sets a budget. When it drops into range, the user confirms the purchase and shipping details and taps “buy for me,” and the agent checks out on the merchant’s site with Google Pay. Announced at I/O, Google’s annual developer conference (May 2025), rolled out in the US in November 2025.
• Muse (Meta). A personal agent with its own cloud computer and browser, launched in September 2026. It shops, books, calls businesses and runs errands in the background.
• Instinct. A personal agent that is just a contact in the user’s iMessage or WhatsApp. It has its own email address and computer, and according to its founder, more than half of its transactions are travel.

Agents can do this already. The problem lies somewhere else. This exchange comes from a screenshot a user posted on X. They texted Instinct: “Can u cancel my sf flight sorry.” Instinct replied that the free 24-hour window had closed, so it would check the cancellation terms “before I touch anything.” The user wrote back: “Yea can u see if possible.”

Instinct cancelled the flight before it had shown the fee: $258, in exchange for a $31.96 travel credit and no cash back.

When a chatbot gives a wrong answer, the user can ignore it. When an agent buys or cancels the wrong thing, the money’s gone. So the question users ask isn’t “can it do this?” It’s “will it do this when I haven’t agreed?”

For an agent that spends money, “usually right” isn’t a selling point. What people remember is the one time it’s wrong.

For users to let agents pay, I think three layers of questions have to be answered, bottom to top:

1. The model: will the agent do something the user never agreed to?
2. Payment systems: can merchants and banks recognize and accept a payment an agent makes for a user?
3. Users: what do users need before they’ll let an agent pay for them?

Layer 1, the model: will the agent do something the user never agreed to?

What it is

When people talk about agents going wrong, they say “hallucination.” But there’s more than one way to go wrong, and the failures share one structure.

Every time a user authorizes an agent to do something, four questions are implied: who’s giving the order, what did they agree to, how far may the agent go, and what facts is it acting on. The model can get each one wrong, and each mistake is a different failure:

The question	What the model gets wrong	Example
Who’s giving the order	Takes orders from someone else. A web page or email hides instructions posing as the user, and the model follows them (this is called prompt injection)	A tester emailed Instinct instructions from a fresh Gmail account. It followed them and sent out his to-do summary
What they agreed to	Misreads intent. Drops a condition the user set	The flight above: the user did ask it to cancel, but only after seeing the fee; the agent dropped that condition and cancelled
How far it may go	Overreaches. Does things outside the task	Instinct pulled a sign-in code from a user’s inbox and logged into their restaurant-booking account. Nobody had asked it to log in
What facts it’s acting on	Makes facts up, or misreads a page	A user saw Instinct describe what looked like a stranger’s insurance claim; the founder said the model had “fabricated a proper noun.” Muse once quoted a discount that had already expired and only found out at checkout

Seen this way, the four failures are one: the model’s action no longer matches what the user actually authorized. They just break the match in different places.

That’s also why a better prompt (the instructions given to the model) doesn’t fix it: the user’s instructions and the web page’s content land in the same context, and the model can’t reliably tell who’s in charge. So the checking has to go to things the model can’t change: code, plus independent models that can only stop an action, never let one through.

What needs checking isn’t what the model says. It’s whether what it’s about to do matches what the user authorized.

Before agents

Before agents, nobody had to ask these four questions. Who’s giving the order? The user. What did the user agree to? The amount on the screen. How far can it go? Exactly the one tap the user makes. What facts is it acting on? The ones in front of the user’s eyes.

Software that handled money used to be deterministic, too: the same input always gave the same result. A checkout button does one thing. An auto-buy script is brittle, and it breaks when the page changes, but it never improvises. The failure engineers planned for was “it didn’t work.” With agents, it’s “it did something else,” and it may not happen the same way twice.

For the first time, something that handles money improvises: the model.

What’s changing

If all four failures are “the action doesn’t match the authorization,” the fix is direct: write the authorization down, keep it where the model can’t touch it, and check every action with consequences against it before it runs. Each of the three products has published part of this structure; none has published all of it. Put the public parts together and it looks roughly like this:

Walking through it:

• The consent screen is drawn by the app, not a line in chat, and the user’s answer goes straight into the consent record without passing through the model. That answers “who’s giving the order”: only what comes from here counts as the user.
• The consent record holds what the user agreed to, how far the agent may go, and the price cap.
• The policy check is code, and it sees every action. An action flagged as having consequences (it costs money or can’t be undone) runs only if the consent record holds a matching user consent: the amount is under the cap, the merchant matches, and the action type is within the scope the user agreed to. Price and order details are read by code from the checkout page and the wallet, never taken from the model’s description.
• Outside content (web pages, emails) is marked untrusted before the model sees it. That only lowers the odds that the model follows instructions inside it; it can’t guarantee the model won’t. The real guarantee is the policy check: an action with consequences has to match the user’s consent.
• Recognition models take a look before an action runs: what is this action, really, and does the content carry injected instructions or made-up facts?
• Only when the check passes does a wallet pay or the action run. Otherwise the agent stops and tells the user why, with no blind retries. The wallet here is Google Pay, Link (Stripe’s wallet) or Shop Pay (Shopify’s wallet).

Here’s an example. The user agreed to “these running shoes, under $120.” The model gets to checkout and is about to place the order. The policy check reads the total from the checkout page, sees $135, which is over the cap in the consent record, so the payment doesn’t go through and the agent stops to ask the user. Even if the model says in chat that “the price is fine,” it makes no difference: the policy check never looks at what the model says.

If code already runs the policy check, why is a model still needed?

Because code can only check structured things: whether the amount is under the cap, whether the merchant is right, whether a tool is on the allowed list. Many of an agent’s actions happen on open-ended surfaces, where code only sees the surface:

• In a browser, code sees “click element 42.” Whether that click means “add to cart,” “place order” or “cancel booking” depends on understanding the page. When Muse reaches a checkout page, it stops and asks: “Looks like your agent is on a checkout page.” That only works because something recognized the page as a checkout page first.
• An email or a reply is, to code, just text. Whether it contains the user’s home address, hides instructions posing as the user, or includes a made-up name is something code can’t judge.

That kind of understanding needs a model. So both companies that have described their architecture run more than one. Muse runs a set of separately trained classifiers (small models that each judge whether something belongs to one category) outside the agent’s environment, checking for prompt injection, personal data leaking out for no task reason, and high-risk form submissions; when a classifier flags an action as one of these, it blocks the action or sends it to the user for review, and Meta says “attackers cannot disable these protections.” Instinct’s founder has described three layers. Incoming content first passes a “firewall” that keeps suspicious content out. Then an action monitor, a model that supervises actions, reviews each one; he stresses that it’s “decoupled from the same incentive system” as the agent, meaning it doesn’t share the agent’s goal and won’t excuse the agent just to get the task done. Last come the hallucination detectors added after the stranger-document incident.

My read on the division of labor: models recognize, code decides. A recognition model’s verdict can only make the system stricter (stop the action, or ask the user first). It can never make it looser by letting through something the user never agreed to. When a recognition model mistakes an ordinary click for one that needs confirmation, the cost is one extra question to the user. The other mistake is the dangerous one: if it treats a “cancel booking” click as an ordinary click, the cancellation runs without confirmation. That’s exactly the open problem below.

Each company has published engineering detail at a different point on this diagram:

• Muse published the policy check and the classifiers above. Meta’s security write-up says: “Muse proposes actions, but only Sentinel can grant permission.” Sentinel is a separate permission service the agent can’t override, and the design starts from the assumption that the agent “may be under attack.”
• Instinct published the recognition layer: the firewall, the action monitor, and the hallucination detection it shipped within 48 hours of the stranger-document scare.
• Google published the user-facing rule in the consent record: it buys only if the final price is “the same as, or lower than” the total the user confirmed, charges nothing if the price rises, and notifies the user with the reason when a purchase fails.

What’s still open

What this layer hasn’t done yet comes in two halves.

The first half is seeing the consequences. Payments are easy to flag. But in the public incidents, what went wrong were actions nobody flagged: a cancellation with a fee, a booking with a cancellation charge, an email that can’t be unsent. My read is that web pages don’t tell an agent what an action will cost. A payment goes through a checkout page or a wallet, so its type is easy to recognize; cancelling a flight, to code, is just an ordinary click on the airline’s site, and the fee lives in the airline’s terms. There are two ways to see the consequences. One is for the agent to infer them: read from the page’s DOM, the text next to a button and the cancellation terms what this step will cost and whether it can be undone. That relies on recognition models, so it’s probabilistic, and it gets better as models do. The other is for the environment to state the consequences: tools labeled when they’re built (Muse’s guidelines for third-party developers say never to hide a send, share, publish or payment action inside a tool described as read-only), or a merchant’s checkout API that returns the cancellation fee. That route is certain, but it only covers merchants who have connected.

The second half is not acting before the consequences are confirmed. The flight at the top is the example: Instinct already knew the free cancellation window had closed, yet the cancellation ran before the fee was shown. What was missing wasn’t understanding but a gate: no action before its consequences are confirmed, and any action whose consequences can’t be inferred asks the user first. Many products today let it run by default.

Every action that costs money or can’t be undone should have its consequences seen and confirmed by the user before it runs.

Layer 2, payment systems: can merchants and banks recognize and accept a payment an agent makes for a user?

What it is

If a user hands an agent their card number today, the payment system sees the user. There’s nowhere to say “this is my agent, at this store only, up to $120, until Friday.” The card is all or nothing.

Merchants have the opposite problem: they can’t tell who’s arriving. Their bot defenses were built to stop scalpers and fraud, and an agent looks exactly like one: it trips captchas (the “click the traffic lights” tests that prove a visitor is human) and gets flagged as credential stuffing (trying leaked usernames and passwords in bulk). From the merchant’s side, a helpful agent and a fraud bot send the same traffic.

Before agents

Several parties sit behind an online payment: the merchant; the payment gateway, the technical service that takes the payment details and sends the transaction on; the acquiring bank, which connects the merchant to the card network and, when a cardholder files a chargeback (disputes a charge with the bank to get the money back), recovers the money from the merchant; the card network, such as Visa or Mastercard, which carries the transaction between banks; and the issuing bank, which gave the user the card and decides whether to approve the transaction.

Take buying a pair of $120 running shoes:

Grouped into five layers, each one answers a question:

1. Identity: who is this person? KYC (Know Your Customer): when a user opens an account, the bank verifies who they really are.
2. Credential: what do they pay with? A card number. Whoever has the number can charge it.
3. Front door: is this a human? Captchas and fraud checks block anything automated.
4. User consent: is the cardholder the one paying? The issuing bank scores each transaction’s risk and asks for an SMS code only when the risk is high (this is called 3DS verification); most transactions pass without one. The security code on the card only proves someone has the card details, not that the cardholder is the one paying.
5. Checkout: how is the order placed? A person fills in the merchant’s pages, one click at a time.

All five share one assumption: the person is the one acting. Paying on someone’s behalf did exist, but only in narrow forms, like a subscription where a user authorizes one merchant to charge them every month. That doesn’t help software that shops across many sites for the user.

What’s changing

Why now? In October 2025, Visa cited Adobe data showing AI-driven traffic to US retail sites up more than 4,700% over the previous year. Merchants can no longer treat all automated traffic as an attack, and payment companies don’t want users handing full card numbers to a model. So each of the five layers is adding a version for someone acting on the user’s behalf. At the identity layer, for example, it used to be enough to prove who the user is; now it also has to be possible to prove which agent is acting for the user. The same shoes, bought by an agent:

For each layer below, the verdict comes first, then the reasons.

1. Identity (KYA): approving a payment doesn’t need it; a dispute does

KYA is Know Your Agent: proof of which agent this is and whom it works for. Mastercard launched Agent Pay in April 2025, with agent registration and verification; in June 2025 the startup Skyfire launched KYAPay, where an agent carries an identity token with a cryptographic signature, so nobody else can forge it.

Why approving a payment doesn’t need it: an agent pays with a token, a stand-in for the user’s real card number. That token is backed by a card that has already been through KYC, so the issuing bank knows whose money it is and doesn’t require KYA. Transactions made with agent-specific tokens carry a marker; but if the user hands the card number straight to an agent that types it into a web page, the payment network can’t tell an agent paid. Only in September 2026 did Mastercard start testing a “probability score” estimating whether a transaction was started by an agent. There’s no public example yet of an issuer or merchant that requires KYA before accepting a payment.

But KYC answers “whose money is this?”, not “did the user really send this agent?” Day to day, that doesn’t affect approval. Once there’s a dispute, or someone poses as an agent, proving it takes KYA plus a record of the user’s consent. That’s the first open question at the end of the post.

Where identity does matter is the front door. In October 2026, the fraud-prevention company Forter and Skyfire reported a pilot in which a retailer’s bot defenses had been blocking most of its agent traffic; with KYA signals, they say, agent checkout success rose to nearly 100% with no rise in chargebacks (the companies’ own numbers).

2. Credentials: already live

Visa Intelligent Commerce, Mastercard’s agentic tokens, Stripe’s Shared Payment Tokens and Link for agents are all live. Their mechanisms differ. Visa’s and Mastercard’s agent tokens are bound to a specific agent and can carry rules like amount or merchant limits, but aren’t necessarily single-use. Stripe Link issues a one-time virtual card each time, good at one store, for one amount. A Shared Payment Token is a credential usable only with one merchant, within a set amount and time. What they share: the agent never sees the user’s real card number, and what it can spend has limits. According to media reports of Mastercard’s April 2026 earnings call, “nearly all” Mastercard cards are now enabled for Agent Pay. Muse has paid with Link one-time cards since it launched in September 2026.

The only cost is by design: Link requires the user to confirm every purchase, so the most widely used agent wallet isn’t autonomous at all. Stripe says budget rules are coming.

3. Front door: lots of small and mid-size merchants are open; big merchants chose to close.

The open side: Shopify turns agent checkout on by default for eligible stores, and merchants who don’t want it have to switch it off. Some Shopify stores already publish a checkout profile meant for agents on their public pages.

The closed side is big companies with their own reasons:

• Amazon has blocked Muse since September 20, 2026. Its block page says continued access by an unauthorized AI agent violates Amazon’s conditions of use. Amazon’s reported reasons are that Muse doesn’t identify itself and stores users’ login credentials. Many reports also point to Amazon’s large ad business, and agents don’t look at ads.
• Banks are the firmest. According to The Verge, Schwab’s CEO said, “We don’t want someone just giving their password to Muse.”
• Delta and United don’t let third-party agents book, citing their terms or the lack of a partnership.

The law isn’t settled either. Amazon sued Perplexity over its browser agent, and the lower court ordered the agent off Amazon; in August 2026 the US Court of Appeals for the Ninth Circuit vacated that order, but the dispute over Amazon’s terms of use continues.

Visa’s Trusted Agent Protocol already has every request from a trusted agent carry a signature, so a merchant can check who it is. Recognizing an agent isn’t the same as letting it in.

4. Records of user consent: the protocol is still a draft, but it isn’t the bottleneck today

AP2 is Google’s agent payment protocol from September 2025. At its core is the mandate, best thought of as a signed authorization letter: a record, which can’t be altered, of what the user agreed to. There are two kinds: an intent mandate for when the user isn’t there (signed in advance with a price limit and conditions, so the agent can order when they’re met), and a cart mandate for when the user is there and agrees to the exact items and price. In April 2026 Google handed AP2 to the FIDO Alliance (the industry group behind login standards like passkeys), and the new version adds “human not present” payments.

Why it isn’t the bottleneck today: in the products that are live, the user is present, and consent is a tap on “confirm” for every purchase, so there’s no use for an intent mandate yet. It becomes a bottleneck once people let agents buy while they’re away.

One more thing belongs here: who’s liable when something goes wrong has been written down already, and it’s the user. Rule 4.1.24.10 of Visa’s April 2026 Core Rules says the cardholder is responsible for a transaction an agent makes on their behalf, as if they had made it themselves, and the agent provider has to get the cardholder to acknowledge that. The Link confirmation page in Instinct’s demo says the same in its footer: approving means taking responsibility for the agent’s purchases. Today’s chargeback rules cover two situations: the merchant didn’t deliver (nothing arrived, or the item isn’t as described), and the cardholder wasn’t involved (fraud). For example: a user agreed to “these running shoes, under $120,” and the agent bought them in a color the user doesn’t like. Neither situation applies; it’s the same as buyer’s remorse, and the user can only use the merchant’s return policy.

5. Checkout APIs: they exist, but merchants and shoppers both chose the merchant’s own checkout.

ACP (Agentic Commerce Protocol, from OpenAI and Stripe, September 2025) and UCP (Universal Commerce Protocol, from Google and Shopify, January 2026) are two protocols for agents to place orders: once a merchant connects, an agent orders through an API instead of clicking through pages. But the most visible attempt has been pulled back: in March 2026, OpenAI stopped pushing Instant Checkout (buying directly inside a ChatGPT conversation) as a standalone feature, saying the first version “did not offer the level of flexibility that we aspire to provide,” and moved merchants to their own checkout while OpenAI focuses on product discovery.

Why haven’t most merchants joined? The reasons reported are concrete:

• Shoppers didn’t take to it. A Walmart executive told WIRED that conversion (the share of shoppers who end up buying) for purchases made inside ChatGPT was a third of the rate for click-outs to Walmart.com; shoppers worried that checking out after every item would leave them with several separate deliveries.
• Checkout is more than payment. Real-time inventory, coupons, loyalty points, multi-item carts, store pickup and sales tax were all missing from the first versions.
• Merchants give up too much. OpenAI reportedly charged a fee of about 4%, and merchants lose the direct customer relationship along with the recommendations and add-ons on their own pages.

Skipping the API and working directly in web pages often fails at the steps right before payment. In a 2025 benchmark of web agents by the AI company Halluminate (Web Bench, 452 sites), the best fully automated agent succeeded on just 46.6% of “write” tasks such as filling forms, logging in and checking out, against mostly above 70% on read-only tasks. A concrete case: Walmart is a Muse partner, but according to TechCrunch, Walmart’s “verify you’re human” check throws Muse out if the session is interrupted, which Walmart says wasn’t intentional.

Where the bottleneck is

The payment itself already goes through. Users still don’t use it, for two kinds of reasons: products aren’t good enough yet, and payment systems can’t yet price the risk of an agent’s transaction.

Users really aren’t using it. Visa’s CEO put it plainly in September 2026: “We are seeing adoption for shopping, but not yet for autonomous payments.” Asked what the barrier was, he answered with one word: trust. The 23% figure at the top comes from a Harris Poll survey for Visa (May 2026, 2,065 US consumers); it measures attitudes, and most respondents hadn’t used such an agent yet.

The first kind of reason is that products aren’t good enough yet. Walmart’s conversion gap and the web-agent benchmark in section 5 above are both this kind.

The second kind is that the risk can’t be priced. The fraud models at card networks, issuers and merchants were trained on human behavior: the device, the rhythm of how someone uses a site, whether the cardholder is present. For a transaction an agent starts, those signals are either missing or look like a bot. The impostor problem in section 1, big merchants closing their doors in section 3 and the chargeback rules in section 4 all follow from the same thing: when the risk can’t be priced, the rules push the loss onto the user first, and big merchants close first. For that to change, fraud models have to learn to judge transactions agents start, and the rules will follow.

What a product writes when there are no rules is shown plainly by xAI’s Grok Bot, an agent that places orders for users. Section 2.4 of its terms (updated October 12, 2026) says that for the charges, commitments, communications and other consequences of the agent’s actions, “Customer is solely responsible.” Section 2.3 says approval and automated-review controls are “provided as aids only,” with no promise that they’ll stop the agent from doing the wrong thing, and the terms also say xAI isn’t responsible for the agent’s actions. In other words, users may use it this way, but when the agent gets it wrong, xAI isn’t on the hook.

Layer 3, users: what do users need before they’ll let an agent pay for them?

What it is

Layer 2 covered how payment systems judge the risk of agents. This layer is about users: what do users need to see before they’ll let an agent pay for them?

When a user pays with Apple Pay or Alipay, the user is the one who wants the thing, sees the price and presses confirm, all in the same second. With an agent, it’s different. The user asks “is a refund possible?” and a little later the agent clicks a button for them on a page the user never sees. Between what the user said and what the agent did, there’s time, and a page the user wasn’t looking at.

That creates a dilemma, and Instinct shows it best. An investor https://x.com/pitdesi/status/2090579987778937159">praised it on X because other AIs “will often stop for confirmation, which kills the vibe,” and Instinct doesn’t. But what people complain about is exactly the same thing: it did it without asking. The $258 flight. A €375 hotel charged without asking. An email sent before the user had finished writing it. The fans and the critics are describing one thing: it doesn’t ask the user.

Ask too often and nobody wants to use it. Ask too rarely and something will go wrong.

We’re a long way from “just right.” Instinct’s founder says it takes “several weeks” for users to trust it, and by his own numbers, only about 40% hand over their credit card after roughly three weeks. Most people haven’t.

Before agents: how Alipay and Apple Pay earned trust

Think about why users trust Alipay or Apple Pay. It’s not that they never go wrong. It’s three things:

1. Before paying, the user knows what they’re agreeing to. Apple Pay pops up a sheet that says how much and to whom. It only counts when the user double-clicks and glances for Face ID.
2. If something goes wrong, the user knows in advance the most they can lose. Alipay’s password-free payments only work up to a limit the user sets, usually a small one. Apple Pay never gives the merchant the user’s real card number, so the merchant can’t use it for any other charge.
3. If the charge is wrong, the user can get the money back. Alipay started as escrow. When Taobao launched in 2003, strangers didn’t trust each other enough to trade online, so the platform held the money, and the seller only got paid when the buyer tapped “confirm receipt.” If the item was wrong, the buyer’s money hadn’t gone anywhere yet.

Nobody had to design these three things on purpose, because the user was there when paying. When an agent pays for the user, the user isn’t there, so each of the three has to be built back in, one at a time.

What’s changing

1. Before paying: the user knows what they’re agreeing to

Three things are being done now:

• Make what the user agrees to specific. With Agentic Checkout, the user arrives from a price-drop alert: which item, which color and size, and how much they’ll pay are already chosen, and the rule is spelled out: it buys only at the same price or lower. The more an entry point tries to do everything, the vaguer the user’s agreement gets. Reviewers found that Muse takes on anything, yet for online shopping or booking an Airbnb, users are better off opening the app themselves. A better starting point is a ready-made task, like “watch this and buy it under $X,” instead of a blank chat box.
• Don’t say yes in chat. An agent can misread a line in chat, as the flight at the top shows. That’s why Muse’s confirm button, though it looks like it’s in the chat, is drawn by the app itself; Meta says it appears “within the client UI — not via their conversation with Muse.” Instinct is more direct: when it’s time to pay, it sends the user to the wallet’s own page.
• Decide when to ask. One way is to ask in advance: Agentic Checkout has the user set a limit up front, so if the price drops in the middle of the night, it can still buy. The other is to ask at the end: Muse and Instinct get the cart ready and wait for the user’s OK before paying. That suits tasks where the user can’t say in advance exactly what they’ll buy, but the user has to be around. These are the two kinds of mandate from layer 2.

Not there yet: things other than paying don’t get a page like this. As layer 1 covered, actions like cancelling a flight or booking a non-refundable table often aren’t flagged; and even when they are, no wallet page shows the amount for the user to confirm before they run, so the user never gets to press confirm.

2. While it acts: the user knows in advance the most they can lose

The payment step already has a limit: the one-time card an agent gets works at one store, for one amount, and Muse asks for the user’s OK on every payment, with no way to set it to “Always allow.”

The trouble is everything other than paying. Muse has five levels of permission: just this once, this conversation, this task, a period of time, or forever. For things that don’t involve paying, the user can pick “Always allow.” The YouTuber Matt Robb did. He had Muse sell a keyboard for him on Facebook Marketplace, Facebook’s secondhand marketplace, and assumed it would still check with him before agreeing to a deal. According to news reports, Muse’s auto-replies sent his pickup address to everyone who asked about it, and it agreed to a lowball price.

When he said yes, nothing on the screen told him which actions “Always” covered: “reply to buyers,” “share the pickup address” and “accept offers” are three different things. Alipay’s password-free payments feel safe because the limit is spelled out, and it’s small.

What the user agrees to should never be wider than what the agent is about to do.

Not there yet: it either asks every time or never asks, with nothing in between. If it asks every time, the agent barely saves the user any effort, and after enough prompts users stop reading and just tap yes; Muse’s design team says it has to guard against exactly this “banner blindness.” If it never asks, the user ends up like Robb. The in-between option should work like Alipay’s password-free limit: “this kind of thing, this month, under this amount, don’t ask me.” The budget rules Stripe plans (layer 2, section 2) point this way, but they haven’t shipped.

3. After it’s done: if the charge is wrong, the user can get the money back

What’s working today is mostly about being clear:

• Before acting, say what happens if it fails. Booking a hotel for an investor, Instinct first said: “If it declines I’ll hand you the direct link instead of retrying.” In other words, if the card is declined, it hands the user the link instead of trying again and again on its own. Getting quietly charged several times is exactly what people fear most.
• If it didn’t buy anything, say so clearly. When a reviewer hit “deny” at an Airbnb checkout, Muse immediately said nothing had been booked and nothing paid, and pointed out that with taxes, the total was about $380 more than it had quoted. When an Agentic Checkout purchase fails, the user gets a notification or email saying why: out of stock, the price went up, or the card was declined.

Not there yet: a clear explanation doesn’t get the user’s money back. With the $258 flight, Instinct owned up quickly and offered to “try to get the flight reinstated within the hour,” but the fee had already been charged. Alipay’s escrow earned trust because, when something went wrong, the platform was still holding the money. With an agent, the charge or cancellation usually takes effect the moment it acts. I think agents need their own version of escrow: hold anything that can’t be undone for a few minutes, like Gmail’s “undo send,” so the user still has time to change their mind. Who pays when it does go wrong is the rules question from layer 2.

What’s still open

Of the three, I think the second is furthest behind, and more precisely, consent given per action and scope.

Robb’s incident and the $258 flight were both missing exactly this: in the first, “Always” never said which actions it covered; in the second, “cancel the flight” wasn’t treated as an action that needed confirmation at all. What users need is the limit setting described in part 2, with a scope that covers which actions, not just how much money.

That setting won’t arrive all at once; it’s more likely to evolve step by step, the way Alipay’s did. Alipay has climbed two ladders that point in opposite directions. Password-free payments are the user trusting the platform: the user starts with a small limit and raises it once things go smoothly. Huabei, Alipay’s credit line, is the platform trusting the user: it starts with a small credit limit based on the user’s spending and repayment record, and raises it as the record improves. Agents are closer to the first ladder but will borrow the second’s method: the user gives an agent a very small scope, every task it gets right adds to its record, and the scope grows with it. Today that ladder doesn’t exist yet. Without it, an agent either interrupts the user for every purchase or spends the user’s money without confirmation, which is the one thing Instinct’s fans and critics are both talking about.

Muse and Instinct already do the other two: put confirmation on an app-drawn button or a wallet page, and explain failures clearly.

Users don’t need an agent that never makes mistakes. They need to know what it’s going to do before it pays, the most they can lose if it goes wrong, and that they can get the money back if it’s wrong.

What’s still unsolved

Broken down, that’s three open questions.

1. How can a payment system confirm a payment was really authorized by the user?

There are three cases to tell apart: the user authorized it, the agent improvised, or someone is posing as an agent.

• Layer 1 covered how to separate the first two: the user’s consent lives outside the model, and code checks actions against it.
• Payment systems can’t catch the third case yet (layer 2, section 1). Fed Governor Waller said in a September 2026 speech that fraud systems are calibrated to human behavior, and that standards for agents to carry identity, consent records and payment credentials are still missing. Mastercard, Visa and Skyfire each have their own identity scheme, and merchants rarely check.
• The warning signs are growing. Visa’s risk team reportedly saw posts mentioning “AI Agent” on the dark web rise more than 450% in the first half of 2026, and a bot-defense company found that most agents don’t say they’re agents when they visit a site. But there’s no public loss data yet.

2. When something goes wrong, who pays?

• If someone steals a card or token and uses it, the rule is clear: the cardholder has zero liability and pays nothing. The issuing bank usually files a chargeback, and the loss passes through the acquiring bank back to the merchant; only when the transaction went through strong verification such as 3DS does the liability move to the issuing bank. A stolen agent token only works with a set merchant or device, so it’s worth little to begin with.
• When an agent buys the wrong thing within the user’s consent, there’s a rule too, but it works against the user: as layer 2, section 4 covered, the purchase counts as the user’s own and fits no chargeback reason. What’s missing is a way to dispute “the agent bought the wrong thing.”
• That directly affects whether people will use agents at all. In a survey by the payments company Checkout.com, 25% of consumers said they’d stop using an agent if a purchase was hard to dispute (the company’s own survey).

3. How can users hand over only part of the control?

This is the gap layer 3 ended on: users have no setting for giving consent per action and scope, and no ladder for widening that scope as the agent builds a record.

The other two obstacles from layer 2, big merchants keeping agents out and incomplete checkout APIs, shrink the number of places an agent can buy; but even if both were fixed, the three questions above would remain.

Changes worth watching

Each of these is an answer to one of the questions above:

• Card networks are starting to write rules for agents (question 2). Visa’s rules now define an “agentic transaction” for the first time, and Mastercard and Google are reportedly building Verifiable Intent, a way to show in a dispute what the user actually authorized.
• Fraud companies are starting to recognize agent identity (question 1). Forter now accepts Skyfire’s KYA (the pilot in layer 2, section 1).
• For the first time, a standard can express “approved in advance” (questions 1 and 3). AP2’s new version added payments with the user not present (layer 2, section 4).
• The first limit setting is on its way (question 3). The budget rules Stripe plans for agents (layer 2, section 2) would be the first usable limit setting.
• Platforms are splitting. Shopify opens checkout to agents by default; Amazon chose to close its doors. Whichever side becomes the norm decides how many places an agent can shop.

The payment step works now, but that’s far from the whole story. Whether a user lets an agent pay comes down to two sides: how much time and money the agent saves them, and how much they could lose if it goes wrong. A smarter agent with a better experience makes the first side bigger; getting the risk under control at all three layers makes the second side smaller.