Open Reader

Your Agent Just Authorized What?! — Jay Mok & Ben Coumes, Paypal

completed 16:07 Sep 01, 2026 Watch on YouTube

Current Status

completed

Video ID

vGn6N4-bxBY

RAG / Chat

Enabled
Your Agent Just Authorized What?! — Jay Mok & Ben Coumes, Paypal
Description

A PayPal order has always been synchronous. You find the item, you open the app, you approve it, it is done. The approval token demonstrated here inverts that: the user approves before the agent has found an item or picked a merchant, and PayPal returns a JSON payload carrying the amount, the expiry, and the merchant the agent is permitted to transact with. It was days from shipping when this was recorded. That inversion is the concrete end of a broader argument about agent authorization, built on three questions any such system has to answer. Did the human authorize this? Is it allowed right now, in this scope? And can we prove it later? The answers, the talk argues, depend entirely on how high the stakes are and on whether the two parties have ever met. The rest maps those questions onto a ladder. At the bottom is a coding agent, where consent happens once when tools are connected, permission is granted per tool as allow, ask or deny, and ordinary logs are proof enough because the actions can be reverted. In the middle is money moving between parties who already know each other through a shared vault and OAuth scopes, where a mandate carries the amount and the scope and existing transaction logs settle disputes. At the top is the case nobody has running in production yet: an agent transacting autonomously with a counterparty it has never met. The proposal there is a layered selective disclosure JWT, so a merchant can verify the checkout and a processor can verify the payment mandate without either knowing the other. Timestamps: 0:00 - Terminator, and the agent that empties your wallet 1:26 - Three questions any agent authorization has to answer 2:49 - Stakes, counterparties, and the badge analogy 4:12 - Low stakes: a coding agent with allow, ask and deny 6:15 - Medium stakes: a shared vault and OAuth scopes 9:45 - High stakes: counterparties who have never met 10:29 - A layered selective disclosure JWT 12:30 - The approval token, and inverting the order flow 14:

Summary

Generated by gpt-5.6-terra

At-a-Glance

  • Verdict: Watch fully
  • Core thesis: Agent authorization should be calibrated to transaction stakes and ecosystem openness: reversible actions in trusted boundaries can rely on permissions and logs, while autonomous high-stakes actions with unknown counterparties require portable cryptographic proof of human intent.
  • Why it matters: This provides a practical authorization model for agent systems that distinguishes ordinary tool access from irreversible actions such as payments, securities trades, medical orders, and e-signatures.
  • Best use: Use it to design an authorization tiering policy for Ken's agents, especially to decide when scoped tokens and audit logs are sufficient versus when signed, verifiable mandates are required.

Executive Summary

PayPal's Jay Mok and Ben Coumes propose three questions for evaluating any agent action: did a human authorize it, is it allowed now and within a defined scope, and can that authorization be proven later? Their central point is that the implementation of those controls must depend on both the stakes of the action and whether the transacting parties operate inside a known, trusted ecosystem.

For low-stakes, reversible work—illustrated by Claude Code acting through authenticated GitHub, Jira, or Linear connectors—the speakers argue that granular tool permissions, ask-before-action controls, system logs, and the ability to revert changes are generally adequate. For medium-stakes payments within a closed ecosystem, they describe using a shared payment vault plus OAuth-scoped access, with the platform serving as the trust boundary and transaction logs supporting disputes.

The strongest recommendation concerns open, high-stakes autonomous transactions. When an agent may transact with unknown, unvetted parties and the outcome is hard to reverse, PayPal believes the industry needs interoperable cryptographic evidence: FIDO verifiable intents and AP2 mandates. These bind a trusted credential, the user's signed instructions, and potentially an agent's subsequent signed action, allowing each participant to verify the transaction component relevant to it.

The talk is strategically useful because it frames authorization as more than identity or API permissions. It is a chain of bounded delegated authority and durable evidence. The presentation is conceptual rather than implementation-complete, but its risk-tiering model is directly reusable for agent control planes.

Key Takeaways

  • Claim: Every agent authorization design should answer three distinct questions: whether a human authorized the action, whether the action is currently permitted within scope, and whether the authorization can later be proven. | Evidence: In the payments example, human authorization may be a passkey; active permission is represented by a time-bound token constrained by amount, merchant, or product intent; later proof is needed for disputes. | Implication: Ken should treat identity/consent, runtime policy enforcement, and non-repudiable audit evidence as separate control-plane capabilities rather than assuming one access token solves all three.
  • Claim: The appropriate authorization mechanism depends on a two-axis context: action stakes and whether counterparties are in an open or closed ecosystem. | Evidence: The speakers use a matrix contrasting low-, medium-, and high-stakes scenarios with known/closed versus unknown/open counterparties; their building-badge analogy describes trust inherited inside a bounded environment. | Implication: Ken should classify agent workflows before choosing controls: reversibility, financial/legal impact, and counterparty trust should determine escalation requirements. | Caveat: A closed ecosystem reduces counterparty uncertainty but does not itself eliminate the need to constrain delegated authority, particularly when money or other consequential actions are involved.
  • Claim: Low-stakes, reversible agent work can rely on authenticated connectors, granular permissions, confirmation prompts, logs, and rollback rather than cryptographic transaction proof. | Evidence: Claude Code is presented as the example: a user authenticates connectors such as GitHub, Jira, or Linear; Claude can be allowed, denied, or required to ask before using specific tools; mistakes can be inspected in system logs or reverted. | Implication: For internal coding and operational agents, Ken can prioritize least-privilege tool scopes, approval-on-sensitive-tools, and reliable rollback/auditability over heavyweight signing infrastructure. | Caveat: This approach is appropriate only where errors are genuinely low impact and remediable; it should not be extended unchanged to irreversible external actions.
  • Claim: Medium-stakes agent payments inside a controlled network can be managed through shared credential infrastructure and OAuth-scoped delegation, with the platform acting as the trust intermediary. | Evidence: PayPal describes partner Nevermind using Braintree/PayPal Enterprise primitives: a vault holds buyer-agent payment credentials, while OAuth grants merchants controlled access. The example is a travel-content provider monetizing occupancy data or reviews to buyer/travel agents, often using commercial cards. | Implication: Where Ken operates a brokered agent network, a shared trust boundary can simplify payments and authorization—but only if the intermediary can enforce mandates, retain evidence, and vet participants. | Caveat: The described arrangement does not attach cryptographic proof to each payment request; dispute handling instead depends on the closed ecosystem and existing transaction logs.
  • Claim: Open-network autonomous payments require portable, verifiable evidence that the user authorized the agent's specific action because transacting parties cannot rely on an existing relationship. | Evidence: The proposed standard stack is FIDO verifiable intents and AP2 mandates, described as a multi-layer selective-disclosure JOT: 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. | Implication: For agents that can discover and transact with arbitrary third parties, Ken should avoid relying solely on bearer tokens or platform-local logs and instead track interoperable signed-intent and delegated-mandate standards. | Caveat: The speakers present this as the preferred industry direction, not a broadly established production standard; they explicitly say the highest-stakes scenario has not yet been seen in production.
  • Claim: Selective disclosure makes a layered authorization artifact useful across multiple transaction participants without requiring every party to trust or know every other party. | Evidence: The speakers say a merchant can verify checkout details, a payment processor can verify the payment mandate, and each party can validate the portion important to it without a pre-existing relationship. | Implication: Ken's agent protocols should separate and minimize disclosures by verifier role—for example, merchant-facing order constraints, processor-facing payment authority, and internal agent execution attestations.
  • Claim: The high-stakes authorization model should generalize beyond payments to any difficult-to-reverse agent action. | Evidence: The speakers name medical orders, e-signatures, and securities trading as examples of actions that should require stronger proof of delegated human authority. | Implication: Ken should establish a cross-domain 'irreversibility threshold' that automatically upgrades authorization requirements for financial, legal, clinical, and external-commitment workflows. | Caveat: The talk provides payment-oriented examples and does not specify the sector-specific compliance, liability, or revocation rules needed for these other domains.

Detailed Brief

PayPal approval token: a near-term product implementation

  • Claims: PayPal is introducing an approval-token primitive that lets a user authorize an agent-led purchase before the agent has located the exact product or merchant.; This changes PayPal's conventional synchronous checkout flow into a delegated purchasing flow with authorization established earlier in the agent journey.
  • Evidence: Historically, the user finds an item, enters PayPal checkout, approves the purchase in PayPal, and completes the transaction synchronously.; In the proposed flow, the user is redirected from their agent to PayPal to confirm instructions; PayPal returns a JSON payload containing constraints including amount, expiry, and intended merchant.; The speakers say the payload is a PayPal-signed string that currently only PayPal can approve, and that it was about to ship in production for Gemini users selecting PayPal.
  • Caveats: The approval token is presented as similar to, but not equivalent to, the proposed verifiable-intent model.; Because approval is currently PayPal-specific, it does not yet provide the cross-party interoperability envisioned for open ecosystems.
  • Implications: A practical migration path is to deploy platform-native constrained approval objects now while designing interfaces that can later accommodate interoperable signed mandates.; Pre-authorization must bind meaningful constraints—at minimum validity period, monetary limit, and target merchant—to avoid converting user approval into an unrestricted spending credential.

Notable Concepts & Terms

  • Stakes and evidence matrix: The presentation's core decision framework: choose authorization and proof requirements based on action impact and whether counterparties are known within a trusted boundary.
  • Closed ecosystem: A network where participants know or are vetted by a shared platform, allowing them to borrow trust from that intermediary and often rely on its logs and enforcement.
  • FIDO verifiable intents: The proposed cryptographically verifiable expression of a user's instructions to an agent for high-stakes, open-network transactions.
  • AP2 mandate: The payment-authorization mandate paired with verifiable intent in the speakers' proposed model for autonomous payments.
  • Selective-disclosure JOT: Described in the talk as a layered signed artifact in which each transaction participant can verify only the authorization component relevant to its role.
  • Vault plus OAuth scopes: The medium-stakes pattern in which payment credentials are stored centrally and access is delegated through constrained OAuth permissions.
  • PayPal approval token: A PayPal-native constrained authorization payload intended to permit an agent to begin an order process before it has identified the final item or merchant.

Operator Notes / Why Ken Should Care

  • Create a workflow authorization matrix with mandatory fields for reversibility, financial/legal/clinical impact, counterparty trust status, maximum delegated scope, expiration, and required evidence retention.
  • Define a hard escalation policy: unknown external counterparties plus irreversible or high-value actions must require signed, narrowly scoped mandates rather than ordinary OAuth or reusable API credentials.
  • Audit current agent permissions for unconstrained delegation; require explicit caps on amount, merchant/vendor, product category or intent, tool operation, and expiry where agents can create external commitments.
  • Separate the architecture for user consent, runtime authorization, and post-event proof so that revocation, policy checks, and dispute/audit records can evolve independently.
  • Monitor FIDO verifiable-intent and AP2-mandate adoption, but avoid making product plans dependent on interoperability that the speakers acknowledge is not yet deployed for the highest-stakes use case.

Source/Metadata

  • Title: Your Agent Just Authorized What?! — Jay Mok & Ben Coumes, Paypal
  • Transcript words: 2247
  • Duration seconds: 967
  • Timestamp note: No usable timestamps or chapters were present in the supplied transcript.

Transcript

2246 words en Processed in 93.6s

. Hello, everybody. How are you doing? Does anybody remember the movie Terminator? Anyway, it's one of my favorite movies from when I was growing up as a kid. It imagines a world where the machines have taken over, right? And the nightmare scenario here, in 2026, is not that the machines or the agents are launching nukes, but rather they've taken your wallet and they've gone on a shopping spree and they buy a bunch of crypto and a new bunch of Spanx for you. But today we're talking about how we safeguard against that and hopefully we can share a mental model that you can use when you're thinking about agent authorization. My name is Jay Mock. I'm a product manager over at PayPal in Agentic Payments. And? Hi, everyone. I'm Ben Coombs. I am a staff software engineer on the PayPal Enterprise Payments team. And together we're going to share some knowledge with you. So hopefully you find it helpful. Okay. So the key questions that we start off with in terms of agent authorization are, did the human authorize this? Is this allowed right now in this scope? And can we prove it later? Right? And we try to make it general. But in our world of payments, did the human authorize this? That could be a passkey or something of that nature. Is this allowed right now in this scope? It's generally going to be a time-bound token. And an amount. And possibly could be identifying a merchant or an actual product intent. And then lastly, can we prove it later? This is if something goes wrong, right? And in our world of payments, this generally has to do with disputes in that case and how you can prove that the human generally authorized that transaction. Right? But we think the way that you actually answer these three questions is really dependent on the context. I know context is an overused term. But in this case, what we mean is, is it a low-stakes or high-stakes scenario? And is this an open ecosystem or a closed ecosystem? Do the parties know each other? People use the term KYA a lot. Know your agent. But what we think about in this scenario is really about an open or closed ecosystem, right? And in a payments context, it could be, hey, ChatGPT or Gemini, right? That's more of a closed ecosystem because those agents know the merchant generally. I like to use an analogy. I like analogies. And the analogy I like to use is badging into work. You badge into work at the front desk. You then are led into the building or, let's say, it's a set of buildings. You don't need to badge in every single time to every other building or for every single room because you're already within that trusted boundary. Right? So then when you meet someone within your office building, you have some element of trust, or hopefully you have some element of trust, because you're both employees of the same company that badged in. Right? So that's the analogy I may use later in the presentation. Okay. So, based on those key questions, we think about, hey, what's the mental model that we can build off of this? Right? And we have this stakes and evidence matrix, and we're going to talk about these three different scenarios. And so we're going to first, and you'll see at the top, it's the stakes and counterparty part that I was just talking about, the context. Right? Counterparty is the open or closed ecosystem. And then authority and evidence is really about how you answer those three questions I had shared in the prior slide. Right? So we'll talk a little bit first about cloud code, since that's what most people are very familiar with. And when you, as a human, are using your cloud code, you might be setting up your connectors with your GitHub or Jira or whatever, Linear or whatever tool you're using. And as part of that process, you're authenticated. So that's how you get that human authorization and consent with those applications and for cloud to interact with them. In terms of the actual scopes, right, the example here would be about cloud's tool permissions. People are probably very familiar with the fact that you can allow cloud to use certain tools, deny, or ask cloud to ask you before doing something. Right? And then in terms of the action of cloud, we generally think, because it's a closed ecosystem and it's your coding, the stakes are relatively low here. And so, in terms of evidence or proof, you don't really need to have that cryptographic proof at that point in time. You can just look at system logs, or you have the ability to just revert your changes. Right? So that's an example of applying this mental model and using cloud code in terms of that scenario. Okay, so the next example we're going to talk about is a more medium-stakes scenario. And why we're calling this medium stakes, even though it's within a known or closed ecosystem, is because it has to do with money and payments. And so that's the shared vault and OAuth scope example. In this example, where the use case is, hey, you're a merchant or a TripAdvisor, right? And you have a travel company and you have a lot of great content that you want to monetize. It could be occupancy data, it could be reviews, what have you. And you have a new customer now, you have travel agents or agents that are buyer agents that are coming to you. And you want to be able to monetize your data, right, through machine payments. So we work with a partner, Nevermind, to be able to enable that use case, and they're leveraging our infrastructure, right? So there are two pieces of infrastructure, or primitives, that they use as part of the Braintree or PayPal Enterprise infrastructure. One is the vault, right? And the vault by itself, which is storing all these payment credentials on behalf of the buyer agents, by itself doesn't really do much. But in order to create what Nevermind creates, which is a more closed ecosystem, you're then able to offer access to those payment credentials through OAuth, right, to all those merchants. So in our example before, we talked about that travel company, right? So by doing so, they're able to then create an ecosystem of buyer agents and seller agents and have a more trusted environment, right? So, just talking more about the use case, the human is going to be authorizing their payment. Usually this is a commercial card use case. So you're using a commercial card and they share it with the buyer agent, travel agent. Then it also has scopes associated with that mandate. So that's how you're able to do controlled authority. But in terms of the actual dispute handling, we really don't have cryptographic proof that's being sent as part of that request. Right? At the end of the day, since it's more of a closed ecosystem, they're able to leverage the existing transaction logs. Right? So that's an example of a medium-stakes use case or scenario. And we believe it's medium stakes because of the fact that it is a more closed ecosystem and doesn't require all the evidence in terms of proof. Right? So that's my part. I'm going to turn it over now to Ben and take it from here. Thanks, Jay. Yeah. So the last slide that Jay talked about, we're going over the medium-stakes example. In that scenario, both parties know each other. They're acting within the same system. They're borrowing trust from Nevermind to make sure that the buying agent is following the instructions that a human has given it. And then the selling agent that's also on Nevermind can feel comfortable taking a payment from another user of Nevermind. And so what we want to talk about next is what happens when the parties are not known to each other and they're not vetted. And so we believe that the best option for that, to actually do these autonomous payments where not everyone is known, the stakes are high. We think that the industry should converge on the FIDO verifiable intents and AP2 mandate. The TLDR of that is it's a multi-layer selective disclosure JOT. The first layer is created by a trustworthy credential provider. In this case, hopefully it would be PayPal. The second layer encapsulates the user's instructions to the agent. The user signs that with their private key. And then the third layer, if there's going to be a third layer, is when we're doing autonomous payments. So in that case, the agent would sign that third layer. And where that's powerful is that every party involved in a transaction can verify the part that's important to them. So merchants can verify that the checkout is correct. Payment processors can verify that the payment mandate is correct. And no one has to have any relationship to each other. And so I think if there's going to be autonomous payments at scale, we think that that's going to be the best way to accomplish it. The pictures on the screen are depicting our PayPal approval token. This is a new primitive that allows users of PayPal to basically start the order process with an agent before that agent's actually found an item and a merchant to transact with. Historically, PayPal orders have been synchronous. Users are on checkout, they find their item, they go to their PayPal app, they approve it, and it's done. Here, it's a little bit different. Users on their agent get redirected to PayPal to confirm the instructions that are given to the agent. And then PayPal hands back this JSON payload, similar to the verifiable intent. It includes the amount, the expiry, the merchant that it's supposed to be transacted with. Similar concept, but not quite the same. It's in a page string that only PayPal can approve right now. We're about to ship this in production, and users of Gemini that pick PayPal as their payment method will use this. So going to our last slide, we showed this slide earlier. We didn't have the two columns filled out on the right-hand side. We want to reinforce this mental model where, starting at the top, we have the low-stakes scenario. You're using Claude. You've given it access to connectors, granular permissions to do things on your behalf. You feel comfortable doing that because the stakes are low. You can reverse those actions or redo them. It's not a big deal if Claude produces the wrong output. Going down a level, we have the medium-stakes scenario. You have two parties that know each other that are acting within the same system's boundary. The actions are a little bit higher stakes. There is money movement here, but both parties can feel comfortable transacting with each other because they're relying on this third party to enforce the payment mandate. And then the third level, the highest-stakes one, that we haven't actually seen in production yet, is the user's given an agent some instructions to do something on their behalf autonomously, and you don't know who they're going to interact with, who they're going to transact with. And those parties need some verifiable proof that the agent has permission to do the transaction. And so we believe that that will be FIDO verifiable intents and AP2 mandates. I think the interesting thing is it's also our belief that this is a model that won't just be used for payments, but we think it could be for any sort of high-stakes action that's hard to reverse. So medical orders, e-signatures, securities trading, basically any hard-to-reverse agent action. That's all I have. Yeah, I think if we could just go back to analogies, in the lowest stakes, it's, hey, you're within the building, you've badged in, you're within the building. Whereas in the high stakes, it's you are on the street and you meet somebody. And you need a way to be able to get comfort that that's someone you can trust, right? Is a badge, is them showing you their badge good enough? Probably not. You need to have something that's a little bit more verifiable, right? I guess at a verifiable standard. So, just using that analogy and how to think about what you need to do in order to prove that the human authorized the agent, hopefully that helps. And now you have a tool set to use so you can prevent Skynet from taking over your wallet. So, thank you very much for listening. I hope that helps. Thank you. So, um, you know, just kind of like using that analogy and like how to think about like the, uh, you know, what you need to do in order to, uh, um, um, prove the, that the human authorized the agent. Uh, hopefully that, that helps. Uh, and, uh, now you have kind of like a tool set to use, um, so you can kind of prevent Skynet from, uh, taking over your wallet. So, thank you very much for your, for listening. I hope that helps. Thank you.