The integration has run clean for a month. A customer's procurement assistant, connected through your OAuth flow, files supply orders inside your product, and the account is one of your best. Then a dispute lands: the customer says the largest order of the quarter, several times their usual volume, was never approved. You pull the records. The token was valid, and it covered everything, because your integration offers a single scope. Nothing recorded what the person asked the assistant to do, no ceiling was ever set, and no confirmation was ever given. You cannot prove the order was authorized, the customer cannot prove it was not, and the card network rules for the cardholder. The refund is yours to absorb, and so is the new doubt about every other order that assistant has filed.
In Identity: whose keys your AI holds, the question was what your own agent could reach with the credentials you handed it. This chapter turns that question around: an agent someone else equipped now works inside your product, and you are the one checking its keys. Whose authority it carries, and how much of it you can verify, decides whether that dispute is a minor write-off or costs you the account.
The delegation chain: verify every hop
Every operator agent working inside your product stands at the end of a chain. A person grants the agent a slice of their authority, the agent presents that authority to your product, and your product checks what was presented before any action runs. Each hop is a separate claim, and each one is either verified or assumed.
The delegation chain runs person grants, agent presents, product verifies, and a hop you cannot verify leaves two outcomes: you block a paying customer, or you hand their account to a stranger.
If you refuse everything you cannot verify, your best customers' assistants finish their jobs with a competitor; if you accept anything that carries a valid token, you will eventually replay the opening scene. The way out is a chain where every hop leaves evidence, and the rest of this chapter builds it.
Scopes that name actions, not access
The first hop is the grant, and a grant that reads "full access" is unverifiable from the moment it is created, because it records nothing about what the person actually delegated. Agent-facing scopes have to name actions the way your customers describe work, not the way your database is organized.
- Name actions, not areas. "Read order history", "create orders", and "issue refunds" are grants a check can enforce and a customer can read; "manage account" is neither.
- Split read, act, and spend into separate grants. An assistant that reports on spending needs none of the authority of an assistant that spends, so keep the dangerous grant rare and deliberate.
- Give every grant an expiry and a visible exit. The customer gets one page listing which agents hold grants on the account, what each grant allows, and a control that revokes any of them immediately.
Mandates: authorization you can prove later
Scopes bound what an agent may ever do; a mandate records what its principal authorized this time. The agent-payment protocols that card networks and commerce platforms shipped over the past two years converge on that record. When a person delegates a purchase, the delegation is captured as a signed record naming what may be bought, up to what amount, and until when. The agent presents the record at checkout, the merchant verifies it before charging and stores it, and if the purchase is disputed later, the merchant can prove exactly what the principal authorized. The designers started from the dispute and worked backward, and that is the order to copy.
Apply mandate-thinking to every consequential action, not just purchases: what was authorized, by whom, within what limits, until when, provable later.
A customer's agent deleting records, messaging that customer's clients, or changing a production configuration deserves the same treatment we just described for a purchase: record the grant it acted under, the limits that applied, and the check your product ran, and keep all three where a dispute can reach them. Individual protocols will keep changing; the signed, checkable, storable grant is the pattern that holds.
Human checkpoints: when the agent goes back to ask
Some actions should not run on any standing grant, so decide which ones before an agent ever requests them.
- Irreversible actions. Anything without a compensating undo goes back to the person, because a record of the mistake does not bring the data back.
- Above-threshold actions. A request inside the scope but past a cap, like an order at several times the usual volume, goes back for confirmation; that checkpoint would have saved the account in the opening scene.
- Out-of-scope requests. When the agent requests something no grant covers, the right response is a refusal that states which grant would cover it.
The design question is what the checkpoint returns. A redirect into your web login flow is a dead end, because the agent has no way to pass a login page to its principal, so the task dies quietly and the customer reads it as your product failing. Return a structured needs-confirmation response instead: what the agent requested, why it stopped, what an approval would allow, and how the approval comes back. The assistant can then put the decision in front of its principal, and the answer either extends the mandate or ends the attempt. The payment protocols draw the same line between actions a present person approves and actions that run under conditions signed in advance.
Receipts settle the dispute
When a visiting agent oversteps, the argument that follows is settled by records, not recollections. For each consequential action, log the grant that was presented, the check your product ran, and the action that resulted, tied together as one entry. This is the guest edition of the run ledger from Receipts and recovery: design for the failed run, and it earns its keep the first time the customer, the assistant's vendor, and you disagree about who authorized what, because the answer becomes a lookup rather than a negotiation.
The grant screen is your consent flow
The screen a customer sees when they connect an assistant is now the consent flow for everything the agent will ever do on their behalf. Treat it as product design with an owner.
- Plain-language scopes. Each grant reads as an action the customer recognizes, and the risky grants look different from the safe ones.
- Caps the person sets. The spending ceiling and the validity window are entered or confirmed by the customer, not buried defaults nobody saw.
- One place to look afterward. The customer can watch what their agent did under each grant, with revocation one step away.
A customer who can see what they delegated, watch how it was used, and end it in one motion will trust your product with an assistant sooner.
Try it now
This drill takes twenty to thirty minutes on paper and produces a verification map for one real action in your product.
Get your specimen. Pick one published agent-payment or agent-checkout protocol and open its specification; the dated Interop Ledger lists the current ones.
Map the chain. Draw the hops from person to agent to merchant and label each one: who signs what, what the merchant can verify at execution time, where the spend ceiling lives, and what record exists if the purchase is disputed. Scale it down: the spec's overview and its mandate or token definitions are enough, because you are mapping the chain, not implementing it.
Sketch your own chain. Choose one consequential action in your product that a customer's agent could plausibly take, placing an order, deleting a project, messaging the customer's clients, and draw the same hops as they exist today.
Mark the unverifiable hops. Circle every hop where you could not prove what was granted: a scope that covers everything, a cap that does not exist, a confirmation only a browser session can give. Each circle is a backlog item, and the circles closest to money come first.
Chapter Summary
- An operator agent stands at the end of a delegation chain: a person grants scoped authority, the agent presents it, and your product verifies each hop before acting.
- A hop you cannot verify forces a bad choice: block a paying customer's assistant or hand the account to a stranger.
- A valid token proves the agent may connect; it records nothing about what the person authorized.
- Offer scopes that name actions, with read, act, and spend as separate grants, each carrying an expiry and a revocation control the customer can see and use.
- The shipping payment protocols carry mandates, signed records of what the principal authorized, with limits and a validity window, so the merchant can prove authorization in a dispute.
- Apply mandate-thinking to every consequential action: what was authorized, by whom, within what limits, until when, provable later.
- Route irreversible, above-threshold, and out-of-scope actions to a human checkpoint, returned as a structured needs-confirmation response the agent can relay, never a login wall.
- Log the grant presented, the check run, and the action taken as one entry, because disputes are settled by records.
- The grant screen a customer sees when connecting an assistant is your consent flow: plain-language scopes, caps the person sets, one place to watch and revoke.
- A verified chain covers the agents acting in good faith, and Guardrails for guests: rate limits, abuse, and the malicious agent covers everyone else.
Sources
- Google (2025). Agent Payments Protocol announcement and specification, including intent and cart mandates (last verified July 2026).
- OpenAI and Stripe (2025). Agentic Commerce Protocol specification and delegated payment documentation (last verified July 2026).
- Visa (2025). Trusted Agent Protocol announcement and developer documentation (last verified July 2026).
- Mastercard (2025). Agent Pay announcement and agentic token documentation (last verified July 2026).
- Anthropic (2025). Model Context Protocol authorization specification, built on OAuth 2.1 (last verified July 2026).