Agent authorization has to establish that a human approved an action, that the action is currently allowed within its scope, and that the approval can be proven later.
2
The required authority and evidence depend on the stakes and on whether the parties operate inside a trusted ecosystem.
3
For autonomous payments with unknown counterparties, layered selective-disclosure credentials can let merchants and processors verify only the part relevant to them.
Summary
Jay Mok and Ben Coumes present a framework for deciding how agents should be authorized. Every system needs to answer three questions: did a human authorize the action, is it allowed now within the stated scope, and can the authorization be proven later? Their answer depends on the stakes and on whether the parties know each other. A coding agent can use connector authentication, per-tool allow, ask, or deny settings, and ordinary logs because its actions are usually reversible. Money movement inside a shared ecosystem needs stronger scopes and mandates, while existing transaction logs may still be enough for disputes. The hardest case is an agent paying an unknown merchant. The speakers propose a layered selective-disclosure JWT linked to FIDO verifiable intents and AP2 mandates. They also show PayPal's approval token, which lets a user approve an amount, expiry, and merchant before the agent has found an item. The same pattern could apply to medical orders, e-signatures, and securities trading.
Jay Mok frames agent authorization around three questions: did the human authorize this, is it allowed right now in this scope, and can the system prove it later? In payments, human approval could use a passkey. Current permission could be expressed with a time-bound token, an amount, a merchant, or a product intent. Proof matters when something goes wrong, especially during a payment dispute. The system must show that the human authorized the transaction. These questions apply across agent systems, but their answers change with the setting.
Stakes and trust boundaries determine the evidence required
The speakers classify situations by two factors: how serious the action is and whether the parties know each other. They compare a trusted ecosystem to badging into an office building. Once someone has entered through the front desk, they do not badge into every room, and employees inside share some trust because they crossed the same boundary. An open ecosystem is different because the agent may meet an unknown party. The resulting stakes-and-evidence matrix connects the context to the way authority and proof should work.
Coding agents can use permissions and ordinary logs
For a coding agent such as Claude, the user authenticates connectors to services such as GitHub, Jira, or Linear. Tool permissions can be set to allow, ask before acting, or deny. The speakers place this in a relatively low-stakes, closed ecosystem because the user can inspect the result and revert changes. System logs are therefore sufficient evidence for this case. Cryptographic proof is not needed for every coding action when the consequences are easy to undo and the tools operate within a familiar boundary.
The medium-stakes example involves a travel company monetizing data for buyer agents through machine payments. A shared vault stores payment credentials, while OAuth controls access to them for the participating merchants and agents. The human authorizes a commercial card for a buyer or travel agent, and the resulting mandate includes scopes that limit how it can be used. Because buyer and seller agents belong to the same ecosystem, existing transaction logs can handle disputes. The system does not attach cryptographic proof to every request in this example.
The highest-stakes case begins when the agent and the party it wants to pay have never met and neither has been vetted by the other. Ben Coumes says the industry should converge on FIDO verifiable intents and AP2 mandates for this situation. He describes a multi-layered selective-disclosure JWT. A trusted credential provider creates the first layer, the user signs instructions to the agent in the second, and the agent can sign a third layer for an autonomous payment. Each participant can verify the part that matters to its role.
PayPal's approval token moves approval before product selection
PayPal's approval token changes the usual order flow. Traditionally, the user finds an item, reaches checkout, opens PayPal, approves the order, and finishes. In the demonstrated flow, the user starts with the agent and confirms its instructions before the agent has found an item or selected a merchant. PayPal then returns a JSON payload containing the amount, expiry, and permitted merchant. Ben says the token is currently an opaque string that PayPal can approve, and that it is about to ship into production for users who choose PayPal through Jet and I.
The same authorization ladder applies to other hard-to-reverse actions
The speakers extend the framework beyond payments. Their highest-stakes model applies whenever an agent can take an action that is difficult to reverse and the counterparty may be unknown. They name medical orders, e-signatures, and securities trading as examples. Jay returns to the street analogy: a badge may be enough inside a trusted building, but showing a badge to someone encountered outside does not provide enough assurance. That setting needs stronger, verifiable evidence that the human authorized the agent.
"Users on their agent, they get redirected to PayPal to confirm the instructions that are given to the agent, and then PayPal hands back this JSON payload."12:30
Who should watch
You are building an agent that can call tools, spend money, or act without a person approving every individual request.
Your system operates across company or trust boundaries, and you need to decide what evidence a merchant, processor, or other counterparty should receive.
You are designing authorization for actions such as payments, medical orders, e-signatures, or securities trading that are hard to reverse.
