.
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.