Who controls agentic finance?

AP2 distrusts the agent, and we’d put the last no outside it

AP2 v0.2, Google’s Agentic Payment Protocol, says “the Agent itself is a potential attacker” whenever either side of a message is an agent. It requires consent on a trusted surface no language model may drive, and every validation and processing step it defines in deterministic code, even inside a role an agent plays [6]. We call the last meaningful chance to refuse a payment the last no, and we think it belongs outside the agent.

A bank teller holds the last no until the money leaves the drawer. In an agent payment it passes from party to party, as a made-up purchase shows. Say you ask an AI assistant to buy a train ticket under $200.

It picks a route, and you approve the limits on a consent screen. The merchant creates a checkout, and a credential provider, which holds your payment details, issues a payment capability, a right to pay, for it. A payment processor, card network or card-issuing bank then accepts the payment, and settlement and fulfillment follow.

Each step can refuse the request, change it or pass it on. The assistant might find a pricier ticket, the merchant might swap in another item, you might withdraw permission, or the same request might arrive twice. Each time, the question is who can still reject the next step.

An agent payment bundles seven decisions a broad yes can’t carry

The ticket purchase bundles seven decisions. Two are about you: who proved their identity, and what you or your organization meant to buy or allow. Two decide what the agent gets: which app or agent may assemble the request, and whether a payment capability may be issued. Three come later: whether the merchant’s order still matches your approval, whether a payment network accepts and completes it, and what others can check afterward.

A broad OAuth scope is too coarse to carry them. RFC 9396, Rich Authorization Requests (RAR), lets a request carry structured details instead. Its worked payment example names the amount and currency, the party being paid and its account, the actions requested and the payment service’s address. Cancel is one of those actions, beside initiate and status, so in the RFC’s own example the app asks for permission to cancel [1].

Where integrity is a concern, the RFC says apps must protect the details from tampering and swapping on their way to the authorization server. That server must then pass them to the API, for example in a JWT access token or through introspection [1].

RAR is clear about where it stops. The authorization server decides what each detail means, and the protected API decides which values it allows. Nor does RAR itself turn the details into a mandate, a signed instruction from you that sets what the agent may do [1].

Writing that mandate is a separate job, and so is settling substitutions, shipping, tax, currency conversion, recurrence, partial fulfillment and cancellation. So is matching the merchant’s system ID to the brand you saw. We propose that an agent mandate name the following, as our essay on agent trust does for other actions:

• the principal the agent acts for;
• the agent, by delegate or client key;
• the action;
• the counterparty;
• the cart or object, by reference;
• the spending cap and currency;
• the expiry and any recurrence rule;
• the policy version;
• the verifier responsible for rejecting a mismatch.

DPoP and FAPI 2.0 harden the token, not what the purchase means

Your instruction for the ticket becomes the agent’s plan, then a checkout, a credential request and a message to a merchant or processor. Each handoff can lose meaning. Sender binding, which ties a token to its holder, protects one link in that chain.

One form, RFC 9449’s DPoP, ties an access token to a key the sender holds and lets a server spot a replayed proof. On its own, the RFC says, the proof shows possession of a key and neither proves identity nor decides access. The RFC’s sections 4.2 and 11.7 limit the proof to the HTTP method and URI, leaving out the request body and general headers [3]. So DPoP alone leaves the cart and the amount to other checks.

OAuth’s current security advice recommends audience-restricted and sender-constrained tokens, which make stolen or leaked tokens harder to misuse [4]. FAPI 2.0 is a high-security OAuth profile for high-value APIs. It requires services to check that each token is sender-bound, valid, intact, unexpired and not revoked, and that it grants enough access [5].

FAPI’s authors say formal analysis showed it meets a stated attacker model. A note in its rules for authorization servers adds that, at publication, detailed security analysis covered only the authorization-code and CIBA flows. The profile requires a revocation check but doesn’t say how fresh: it doesn’t prescribe an RFC 7662 introspection call before every change of state, or promise zero-cache revocation [5].

Four questions sit outside the profile: whether the consent screen described the final purchase, and whether the merchant swapped an item. The other two are whether a compromised agent made an allowed but unwanted purchase, and whether a completed payment must be reversed.

OAuth revocation is instant at the issuing server and can reach others late

Say you change your mind about the ticket and press revoke. Under RFC 7009, systems must support revoking refresh tokens and should support revoking access tokens. Revocation takes effect at once at the authorization server, but in practice the news could take time to spread, so some servers may know while others don’t [2]. The ticket’s token can be dead at one service while its payment is still moving.

RFC 7009 also notes that access tokens may be self-contained, so a service can check one without asking the authorization server. To revoke such tokens at once, the RFC points to back-channel communication between servers, which had no standard when it was written. Another option it names is short-lived access tokens, which limit how long a revoked token stays in use [2].

RFC 7662 introspection, the live alternative, lets a service ask whether a token is active and what it covers. The RFC warns that a cached answer leaves a window in which a revoked token could still be used. Highly sensitive systems can turn caching off, at a cost in network traffic and server load [9].

A stricter design may stop more requests in time, though that still has to be measured. In it, every high-value check asks for current status and skips a stale cache. It rejects an inactive or mismatched request before the commit, the point after which stopping the payment takes a separate cancellation or recovery process. Even then, much can happen after the token decision, so the status you see should read as a series of observations:

• the grant was invalidated;
• the credential was refused;
• the merchant rejected the request;
• the processor rejected the request;
• queued work was canceled;
• settlement status is known;
• fulfillment status is known.

A control that only stops new credentials is still worth having. But it shouldn’t imply that a merchant canceled a request it had already accepted.

Card checks may rest on risk scores; AP2 names each checking role

Online, your bank may check it’s you through EMV 3-D Secure, which EMVCo manages, using purchase, card and device data it swaps with the merchant. EMVCo says the check avoids unnecessary friction, which it says often leads to abandoned purchases. For many purchases, it says, consumers “simply click ‘Buy’ and the payment is approved” [7].

EMVCo’s 2025 white paper describes a frictionless path, in which a real-time risk check confirms you without asking you anything. In its challenge path, you face an extra step when that check can’t confirm you or the purchase looks high-risk [10].

So a passed check may rest on a risk score no person looked at. On its own, it doesn’t show that you freshly approved the agent’s final cart, and 3-D Secure leaves agent spending limits, cancellation and disputes to other systems.

AP2 names each checking role. It has five, each with its own duties: the shopping agent, the credential provider, the merchant, the merchant payment processor and the trusted surface. In one of its two modes, you’re present at checkout and approve the final cart [6].

In its autonomous mode, you approve open checkout and payment mandates in advance on the trusted surface, which set limits on a later checkout and payment [6]. For the ticket, that means one ticket under $200.

Once the merchant has signed a checkout, the agent signs closed checkout and payment mandates for it with its own key. The merchant must check the closed checkout against each limit disclosed to it. The credential provider, with the network where one takes part, must check the closed payment mandate the same way [6]. So in that mode, the checks against your limits sit with the merchant and the credential provider, not the agent.

One party may play several roles, or all five, and any role may hand its duties to someone else, so role names alone can’t promise separate checks. One agent handing its mandate to another is outside the current spec, and so are the details of dispute resolution [6].

AP2 also says the agent must not reuse an open mandate for a second checkout without a rejection receipt for the first. It recommends that open mandates expire at the earliest point that still lets the agent finish its task. The pinned version we reviewed doesn’t describe revoking a mandate [6]. As we read it, a short expiry does the work a revoke button would.

A record its own subject signed proves little about what happened

Say the ticket arrives at the wrong price, and you dispute it. You’ll need to see what each party received, checked, released and observed.

AP2 says its checkout and payment mandates, brought together with receipts, give a picture no party can later deny. Once checked, it says, they can be used as evidence of what you and each party saw. It leaves the retention and retrieval of those records outside its spec [6].

A receipt lets you inspect a statement, but it doesn’t make the statement complete or current, or show that anyone independent collected it. A record signed only by the party whose conduct is disputed shows who signed it and that it hasn’t changed since, but little about what happened.

We learned this with our first receipt draft, Lugano’s Attested Agent Receipt v0.1, which proposed a signed, logged record of an agent’s run. Nothing in it was deployed, and its offline checker tested the supplied signatures, log material and a stated field about kept data. It never watched the run or confirmed that anything was deleted [8]. We’ve since archived it, and our receipt spec essay describes what replaced it.

Good payment evidence would need independently authenticated trust roots, rules for keeping and finding records, and status tied to a source of truth. It would also need locks on sensitive payment data and a way to settle disagreements among all the parties. Our essay on agent trust covers receipts in general.

Name who holds the last no; we’d have it ask for fresh status

If you put an agent into a checkout flow, name the party that holds the last no, and make sure it isn’t the agent. AP2’s autonomous mode puts the checks against your limits at the merchant and the credential provider, and that’s where we’d put the last no too. Whoever holds it should hold the approved mandate and see the actual merchant, cart, amount, timing and credential. It should be able to refuse before the commit.

Next, decide how that party hears about a revocation. A self-contained token is checked locally. A cached introspection answer can let a revoked token through until the cache expires [9].

Our bet is that the check closest to the commit should ask for fresh status. For high-value purchases, we think the extra traffic and load are worth paying. We hold that view on the texts alone, not on measured behavior, and a simpler design could beat it.

A simulation would walk one purchase through every order in which a revocation can meet it, with stated network delays and faults. It would compare three designs: a local token check, fresh status at each check, and fresh status plus sender binding.

The simpler rival is short-lived credentials. They might stop late commits, payments that go through after a revocation, as well as a fresh check does, with fewer lost purchases and less load. If so, the online check isn’t worth its cost. The design is on our proposed-studies page.