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

Read the talk

Your Agent Just Authorized What?!

Jay Mok and Ben Coumes of PayPal build an authorization ladder from reversible coding work to autonomous payments, showing how consent, scope, and evidence must strengthen as actions become harder to undo and counterparties become less familiar.

From a talk by Jay Mok and Ben Coumes

At a glance

Ideas worth remembering

  • Agent authorization must answer three separate questions: whether the human consented, whether the action remains inside its current scope, and whether that authorization can be proved later.

  • Use lightweight permissions and ordinary logs when actions are reversible and participants share a trusted boundary; stronger proof should earn its complexity by addressing higher consequences or unfamiliar counterparties.

  • A shared vault plus OAuth scopes can support machine payments inside a known ecosystem because the common operator enforces mandates and retains transaction history.

  • For autonomous transactions among unfamiliar parties, layered signatures and selective disclosure separate credentialing, human instructions, agent action, checkout verification, and payment verification.

  • PayPal’s approval-token example reverses the usual order: the human approves constrained instructions first, then the agent searches and transacts within the amount, expiry, and merchant limits.

  • The ladder extends beyond payments to any consequential, hard-to-reverse agent action, including medical orders, electronic signatures, and securities trading.

Three questions before an agent acts

The nightmare is smaller than Skynet and much easier to imagine: an agent gets access to your wallet, then buys crypto and Spanx. Jay Mok, a product manager in PayPal agentic payments, and Ben Coumes, a staff software engineer on PayPal Enterprise Payments, use that joke to introduce a serious design problem. Once an agent can act without a person approving each individual step, authorization must describe more than identity. It must say what the agent may do, under which conditions, and what evidence will remain if the action is challenged later. 0:42

Recording frame at 99 seconds
Recording frame at 99 seconds

The framework begins with three questions:

  • Consent — did the human authorize this? In payments, a passkey or similar mechanism can connect the instruction to the person.
  • Authority — is it allowed right now, in this scope? A time-bound token can constrain the amount, merchant, product intent, or some combination of them.
  • Evidence — can we prove it later? If something goes wrong, the system needs enough history to resolve whether the human authorized the disputed transaction.

Those answers depend on two contextual variables: the stakes of the action and whether the parties already know one another. A familiar, closed ecosystem can borrow trust from a shared operator. An open ecosystem cannot assume that an unfamiliar merchant, agent, or processor has already been vetted. “Know Your Agent” is therefore only part of the problem; the topology of the relationship matters too. 2:49

The office-badge analogy makes that distinction tangible. After an employee badges into a building, they usually do not authenticate again at every room. People inside inherit some trust from the shared boundary. Meeting a stranger on the street is different: displaying an unfamiliar badge does not establish who issued it, what it permits, or whether it is still valid. Agent authorization gets more demanding as it moves from the building to the street. 3:19

Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

0:12 · section reference included

Low stakes: permissions and reversible work

A coding agent supplies the first rung of the ladder. A person connects Claude Code to services such as GitHub, Jira, or Linear and authenticates during setup. That initial connection provides human consent for the agent to interact with those applications; tool permissions then narrow what it can do. 4:19

The permission choices are concrete: a tool can be allowed, denied, or configured to ask before use. This is lightweight delegated authority. The user authorizes a relationship once, while the runtime decides whether a particular tool call can proceed automatically, cannot proceed at all, or must return to the human for approval.

Ordinary system logs and version-control rollback can provide enough evidence here because the example assumes a relatively closed environment and reversible coding changes. Cryptographic proof would add machinery without addressing the dominant failure mode: an incorrect edit that can usually be inspected, reverted, or redone. Calling this “low stakes” is contextual rather than universal; it describes the reversible coding example, not every operation a coding agent might be allowed to perform. 5:19

Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

4:19 · section reference included

Medium stakes: borrowing trust from a shared system

The second rung introduces money while retaining a shared system boundary. The example is a travel business with valuable occupancy data or reviews that buyer agents want to purchase through machine payments. PayPal describes partner Nevermind using Braintree or PayPal Enterprise infrastructure to connect buyer and seller agents in a more controlled ecosystem. 6:30

Two primitives divide storage from delegated access:

  • The vault stores payment credentials on behalf of buyer agents. Storage alone does not determine which seller may use those credentials or for what purpose.
  • OAuth access exposes those stored credentials to participating merchants under defined authorization, creating a known ecosystem around the vault.

Follow the travel example through one purchase. A business user shares a commercial card with a buyer or travel agent. The associated mandate carries scopes that limit the agent’s authority. A seller agent inside the same Nevermind environment accepts payment because both sides rely on the platform to enforce that mandate. The observable change is money moving between buyer and seller agents; the causal chain is human authorization, scoped delegated access, platform enforcement, and a transaction recorded by the shared system.

Disputes in this model rely on existing transaction logs rather than cryptographic proof attached to every request. That is why the example sits in the middle of the ladder: money makes mistakes consequential, but the shared operator can identify participants, enforce the payment mandate, and reconstruct events. The parties are “borrowing trust” from the system they both use. 8:30

How it fits togetherHow a shared payment system lends trust

Authorizes a commercial payment credential for the buyer agent.

The vault stores credentials, OAuth scopes delegated access, and the shared operator supplies enforcement and transaction history for both agents.

Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

6:30 · section reference included

High stakes: proof between strangers

The top rung removes the shared boundary. A user gives an agent instructions, but neither the user nor the agent necessarily knows which counterparty will eventually fulfill them. PayPal’s proposed direction is FIDO verifiable intents and AP2 mandates, described here as a multilayer selective-disclosure JWT. The goal is to let each participant verify the authorization relevant to its role without requiring every participant to maintain a prior relationship with every other one. 10:43

Recording frame at 658 seconds
Recording frame at 658 seconds

The layers carry different claims. A trustworthy credential provider creates the first layer. A second layer encapsulates the human’s instructions to the agent and is signed with the user’s private key. For an autonomous payment, the agent can sign a third layer representing its action under those instructions. Selective disclosure then lets a merchant verify the checkout while a payment processor verifies the payment mandate, without forcing either party to inspect everything in the authorization package.

What question does this layering answer? It shows how trust can cross an open ecosystem without collapsing all participants into one shared database or exposing every claim to everyone. Identity, human intent, and agent action remain distinguishable, while signatures connect them into evidence that unfamiliar parties can verify.

How it fits togetherLayered authorization for an autonomous payment

Established by a trustworthy credential provider.

Each signed layer contributes a different part of the authorization story, and each participant verifies only the portion relevant to its role.

Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

10:43 · section reference included

The approval token inverts the order flow

The PayPal approval token turns the abstract ladder into a concrete order flow. A conventional PayPal purchase is synchronous: the user finds an item, enters checkout, opens PayPal, approves the order, and finishes. The approval token changes the sequence by allowing authorization to begin before the agent has found the final item and merchant. 11:43

The user starts with an agent and is redirected to PayPal to confirm the instructions being delegated. PayPal then returns a JSON payload carrying constraints such as the amount, expiry, and merchant. The agent can continue its search and transact only within those approved limits. Authorization becomes an input to discovery rather than a final click after discovery.

The token resembles a verifiable intent in purpose but not in implementation. Coumes describes it as an opaque string that only PayPal can approve, rather than the interoperable multilayer proof proposed for unknown parties. At the time of the recording, PayPal said the token was about to enter production for users selecting PayPal as a payment method in Gemini; that statement establishes the recorded plan, not its later deployment status. 12:43

What changed visibly? The approval screen moved ahead of product selection. Causally, the human first confirms bounded instructions; PayPal encodes those instructions in a constrained token; the agent searches under that delegated authority; and a later transaction must satisfy the amount, expiry, and merchant restrictions. The system avoids asking for unrestricted wallet access while still letting the agent continue after the human leaves the loop.

Compare the ideasSynchronous checkout versus approval before discovery

The user has already selected the transaction.

The conventional flow authorizes a known order. The approval-token flow authorizes constrained instructions first, then lets the agent search within them.

Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

11:43 · section reference included

Match evidence to consequence and distance

The completed ladder connects four design choices: reversibility, financial consequence, counterparty familiarity, and strength of evidence. A reversible coding change inside a familiar toolchain can use connector consent, granular tool permissions, logs, and rollback. Money moving inside a shared platform needs a scoped mandate and transaction history. An irreversible autonomous action involving unknown parties needs portable, verifiable proof that the agent had permission to act. 13:02

Recording frame at 835 seconds
Recording frame at 835 seconds

The highest rung remained prospective in the talk: Coumes says they had not yet seen fully autonomous transactions between unknown parties running in production. That limitation matters because the layered intent model is presented as the direction the industry should adopt, not as a demonstrated production result at scale.

Payments are only the motivating case. The same reasoning applies to medical orders, electronic signatures, securities trading, and other agent actions that are difficult to reverse. As consequences rise, “the model said so” and an ordinary activity log stop being sufficient. The system must bind human intent to a limited action and preserve evidence another party can verify later. 14:31

The badge analogy returns with a sharper conclusion. Inside the building, a shared boundary can make a familiar badge good enough. On the street, an unfamiliar badge is only a claim until its issuer, validity, and permitted scope can be checked. Preventing “Skynet from taking over your wallet” therefore does not require maximum cryptography for every agent action. It requires evidence proportionate to the damage, reversibility, and distance between the parties. 14:46

Compare the ideasThe authorization ladder

Connector consent; allow, ask, or deny; system logs and rollback.

As actions become harder to reverse and counterparties less familiar, authority narrows and evidence becomes more portable and verifiable.

Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

13:02 · section reference included

Resources

Read the complete timestamped transcript
  1. 0:01

    [music]

  2. 0:12

    >> Hello everybody. How are you doing?

  3. 0:15

    Um

  4. 0:16

    Does anybody remember the movie

  5. 0:18

    Terminator?

  6. 0:20

    Uh anyways, it's one of my favorite uh

  7. 0:22

    movies when I was growing up as a kid.

  8. 0:24

    And it imagines a world where the

  9. 0:26

    machines have taken over, right? And uh

  10. 0:30

    uh the nightmare scenario here though in

  11. 0:33

    in 2026 is not that the machines are or

  12. 0:37

    the agents are launching nukes, but

  13. 0:38

    rather

  14. 0:39

    uh they've uh taken your wallet and

  15. 0:42

    they've gone on a shopping spree.

  16. 0:44

    And they buy like a bunch of crypto and

  17. 0:47

    new bunch of bunch of spanks for you.

  18. 0:50

    Um

  19. 0:51

    but the basically today we're talking

  20. 0:53

    about how we safeguard against that and

  21. 0:55

    uh and uh hopefully we can kind of share

  22. 0:58

    a a mental model that you can use when

  23. 1:00

    you're thinking about agent

  24. 1:02

    authorization.

  25. 1:04

    Uh my name is uh Jay Mock. I'm a product

  26. 1:06

    manager over at PayPal in agentic

  27. 1:09

    payments. And

  28. 1:11

    >> Hi everyone. I'm Ben Cooms. I am a staff

  29. 1:13

    software engineer on the

  30. 1:15

    payment PayPal enterprise payments team.

  31. 1:18

    >> And together we're going to share kind

  32. 1:20

    of like some knowledge with you. Um so

  33. 1:22

    hopefully

  34. 1:23

    uh you find it helpful. Okay.

  35. 1:26

    So uh the the key questions that we kind

  36. 1:29

    of like uh start off with is uh in terms

  37. 1:32

    of like agent authorization is uh did

  38. 1:34

    the human authorize this?

  39. 1:36

    Um is this allowed right now in this

  40. 1:39

    scope and can we prove it later, right?

  41. 1:42

    And we we kind of like try to make it

  42. 1:44

    general, but in our world of payments,

  43. 1:46

    yeah, did the human authorize this? Uh

  44. 1:48

    that could be like a passkey or of of

  45. 1:51

    that nature. Uh is this allowed right

  46. 1:53

    now in this scope? It's generally going

  47. 1:55

    to be a time bound um

  48. 1:57

    you know you know token.

  49. 1:59

    Um and an amount and possibly could be

  50. 2:02

    identified like a merchant or a

  51. 2:06

    the actual product intent. Lastly, can

  52. 2:10

    we prove it later? This is like if

  53. 2:12

    something goes wrong, right? And in our

  54. 2:14

    world of payments it's generally has to

  55. 2:15

    do with like the disputes and

  56. 2:18

    in that case and how do you can you

  57. 2:19

    prove that

  58. 2:21

    you know the the human generally

  59. 2:23

    authorized that transaction. Right? Um

  60. 2:27

    But we think the way that you actually

  61. 2:29

    answer these three questions is really

  62. 2:32

    dependent on the context. You know,

  63. 2:34

    context is a overused term, but in this

  64. 2:38

    case what we what we mean is

  65. 2:41

    um

  66. 2:41

    you know, is it a low stakes or high

  67. 2:43

    stakes kind of

  68. 2:45

    scenario?

  69. 2:47

    Um and

  70. 2:49

    is this a kind of like open ecosystem or

  71. 2:53

    closed ecosystem? Do the parties like

  72. 2:55

    know each other? You know, people use

  73. 2:56

    the term KYA a lot. Know your agent, but

  74. 3:00

    you know, what we think about in this

  75. 3:02

    scenario is is is really about is it

  76. 3:04

    like an open or closed ecosystem, right?

  77. 3:06

    And in a payments context it could be

  78. 3:08

    like, "Hey, you know, ChatGPT or Gemini,

  79. 3:11

    right?" That's like kind of like a more

  80. 3:12

    of like a closed ecosystem because you

  81. 3:14

    know, the those agents know the merchant

  82. 3:17

    generally. Um

  83. 3:19

    I like to use a an analogy.

  84. 3:23

    I like analogies. And the analogy I I

  85. 3:26

    like to use is kind of like the you

  86. 3:27

    know, badging into work. You badge into

  87. 3:29

    work in the front desk. You basically

  88. 3:33

    are are then led into the building or

  89. 3:35

    you know, let's say it's a set of

  90. 3:36

    buildings. You don't need to like badge

  91. 3:38

    in every single time to every other or

  92. 3:40

    for every single room because you're

  93. 3:42

    already within that trusted boundary,

  94. 3:44

    right? So then when you meet someone in

  95. 3:47

    within that within your your office

  96. 3:49

    building, uh, you kind of have some

  97. 3:51

    element of trust, or hopefully you have

  98. 3:53

    some element of trust, uh, because

  99. 3:55

    you're both, uh, employees at the same

  100. 3:56

    company that badged in, right? So, um,

  101. 4:00

    that's kind of like the analogy I may I

  102. 4:02

    may use later in the presentation.

  103. 4:05

    Okay, so based on those key questions,

  104. 4:07

    we kind of think about like, "Hey,

  105. 4:08

    what's the mental model that we can

  106. 4:09

    build off of this, right?" And we have

  107. 4:11

    this like stakes and evidence matrix,

  108. 4:13

    and we're going to talk about, uh, these

  109. 4:15

    three different scenarios.

  110. 4:17

    Um, and so, uh, we're going to first uh,

  111. 4:20

    and you'll see at the top it's kind of

  112. 4:21

    like the stakes and counterparty part

  113. 4:23

    that I was just talking about the

  114. 4:24

    context, right? Counterparty is like the

  115. 4:26

    open or closed ecosystem. And then

  116. 4:29

    authority and like evidence is really

  117. 4:30

    about how you answer those those those

  118. 4:32

    three questions I had shared in in the

  119. 4:34

    prior slide, right? Um, so we'll talk a

  120. 4:37

    little bit first about like cloud code

  121. 4:38

    since that's what most people are very

  122. 4:40

    familiar with, and, uh, basically, you

  123. 4:43

    know, when you as a human you're going,

  124. 4:45

    you know, using your cloud code, uh, you

  125. 4:47

    know, you might be, uh, then setting up,

  126. 4:49

    uh, your your connectors with your

  127. 4:50

    GitHub or or, um, you know, Jira or

  128. 4:53

    whatever, uh, linear or whatever uh,

  129. 4:55

    tool you're using. And, um, you know,

  130. 4:58

    you're as part of that process you're

  131. 4:59

    kind of like authenticating, so that's

  132. 5:00

    how you kind of like get that that human

  133. 5:02

    authorization and consent um, with those

  134. 5:05

    those applications and to for the for

  135. 5:07

    cloud container act with them.

  136. 5:09

    Um, in terms of the, uh,

  137. 5:11

    actual like, uh, scopes, right? The the

  138. 5:15

    example here would be that about, you

  139. 5:17

    know, cloud's like, uh, tool

  140. 5:18

    permissions. Like people are very

  141. 5:20

    familiar probably with, uh, the fact

  142. 5:21

    that you can allow cloud cloud to to use

  143. 5:24

    certain tools, um, uh, deny or ask cloud

  144. 5:27

    to ask you, uh, before for before doing

  145. 5:30

    something, right? And then in terms of,

  146. 5:33

    uh, the action of like a cloud, uh, we

  147. 5:36

    generally think, um, because it's a kind

  148. 5:38

    of closed ecosystem and it's like you're

  149. 5:39

    coding, uh, the stakes are relatively

  150. 5:42

    low here. And so in terms of the

  151. 5:44

    evidence or proof, you don't really need

  152. 5:46

    to have like that cryptographic proof

  153. 5:48

    um, at that point in time. You can kind

  154. 5:50

    of just look at like system logs in

  155. 5:51

    order to to or you have the ability to

  156. 5:53

    just revert revert your changes, right?

  157. 5:57

    So, that's kind of like an example of

  158. 6:00

    applying like this mental model

  159. 6:03

    and using cloud code in terms of that

  160. 6:05

    scenario.

  161. 6:07

    Okay, so the next

  162. 6:08

    example we're going to talk about is

  163. 6:11

    a more medium stakes

  164. 6:13

    scenario and why

  165. 6:15

    why we're calling this medium stakes

  166. 6:16

    even though it's within a known or kind

  167. 6:19

    of closed ecosystem is because it has to

  168. 6:20

    do with money and and payments. And so

  169. 6:24

    that's like the shared vault and OAuth

  170. 6:25

    scope example.

  171. 6:29

    So, in this example where the use case

  172. 6:33

    is is like hey you're like a let's say

  173. 6:36

    a merchant or Trip Advisor, right? And

  174. 6:38

    you have

  175. 6:40

    a travel travel company and you have a

  176. 6:43

    lot of great content that you want to

  177. 6:44

    monetize. It could be occupancy data, it

  178. 6:46

    could be like reviews, what have you.

  179. 6:48

    And you have a new customer now. You

  180. 6:50

    have like a trap like travel agents or

  181. 6:52

    like you know agents that that are buyer

  182. 6:54

    agents that are are coming to you and

  183. 6:57

    you want to be able to monetize

  184. 7:00

    monetize your data, right? Through

  185. 7:02

    machine payments.

  186. 7:04

    So, we work with a partner and Never

  187. 7:06

    mind to be able to enable that that that

  188. 7:09

    use case and leveraging our

  189. 7:12

    they're leveraging our infrastructure.

  190. 7:15

    Right? So, there is two pieces of

  191. 7:17

    infrastructure that they

  192. 7:19

    that I like to kind of to call out or

  193. 7:21

    primitives that they use that

  194. 7:22

    as part of the Braintree or PayPal

  195. 7:24

    enterprise

  196. 7:26

    infrastructure. One is like the vault,

  197. 7:28

    right? And the vault by itself, which is

  198. 7:30

    storing all these like

  199. 7:33

    payment credentials on behalf of the

  200. 7:35

    on behalf of the buyer agents,

  201. 7:38

    on itself doesn't really do much, but in

  202. 7:40

    order to create

  203. 7:42

    what nevermind creates is a a more

  204. 7:47

    eco closed ecosystem, they then off

  205. 7:49

    you're able to um

  206. 7:52

    offer

  207. 7:53

    uh or offer access to those payment

  208. 7:55

    credentials through

  209. 7:57

    OAuth, right? To all those merchants.

  210. 7:59

    So, in our example before we talked

  211. 8:01

    about that that travel travel um travel

  212. 8:05

    company, right? So, by doing so, they're

  213. 8:07

    able to then create like an ecosystem um

  214. 8:10

    of buyer agents and seller agents

  215. 8:13

    uh and have a more trusted

  216. 8:16

    environment, right? So,

  217. 8:19

    um

  218. 8:19

    in the in the just kind of talking more

  219. 8:21

    about the use case, like the human then

  220. 8:24

    is then going to be authorizing

  221. 8:26

    authorizing their their payment.

  222. 8:28

    Usually, this is a commercial card

  223. 8:30

    commercial use case. So, you're using

  224. 8:32

    like a commercial card, they share it

  225. 8:33

    with the buyer agent, travel agent. Um

  226. 8:37

    then that uh it it also has

  227. 8:41

    scopes associated with that mandate. So,

  228. 8:43

    that's how you're able to do controlled

  229. 8:45

    authority, but in terms of like the

  230. 8:47

    actual like dispute handling, we really

  231. 8:50

    uh don't have like a we're not using

  232. 8:52

    like

  233. 8:54

    cryptographic proof that's being sent as

  234. 8:55

    part of that that request, right? At the

  235. 8:58

    end of the day, they can since it's more

  236. 9:00

    of a

  237. 9:02

    closed ecosystem,

  238. 9:03

    they're able to leverage like the just

  239. 9:05

    the existing

  240. 9:07

    transaction logs.

  241. 9:09

    Right? So, that's kind of an example of

  242. 9:11

    like a medium stakes and

  243. 9:14

    use case or scenario, and

  244. 9:17

    we we believe it's medium stakes because

  245. 9:19

    of the fact that it is a more closed

  246. 9:22

    ecosystem and doesn't require all like

  247. 9:25

    the

  248. 9:27

    you know, evidence in terms of

  249. 9:31

    or proof, right? So,

  250. 9:34

    that's kind of like my part. I'll going

  251. 9:35

    to turn it over now to Ben and uh take

  252. 9:38

    it from here.

  253. 9:40

    >> Uh thanks, Jay.

  254. 9:43

    Yeah, so the last slide that Jay talked

  255. 9:45

    about, um

  256. 9:46

    you know, we're kind of going over the

  257. 9:48

    medium stakes example.

  258. 9:50

    Uh um

  259. 9:51

    In that scenario, um

  260. 9:54

    you know, both parties know each other.

  261. 9:56

    Uh they're acting within, you know, the

  262. 9:58

    same system. They they know

  263. 10:01

    you know,

  264. 10:02

    they're borrowing trust from, you know,

  265. 10:03

    Nevermind to

  266. 10:05

    make sure that, you know, the buying

  267. 10:07

    agent is falling within, you know, the

  268. 10:09

    instructions that a human has given it.

  269. 10:11

    Um

  270. 10:11

    and then the selling agent that's also

  271. 10:13

    on Nevermind can feel comfortable taking

  272. 10:15

    a payment um

  273. 10:17

    from another user of of Nevermind. And

  274. 10:19

    And so, what we want to talk about next

  275. 10:21

    is what happens when the parties are are

  276. 10:23

    not known to each other and they're not

  277. 10:25

    vetted. Um

  278. 10:27

    And so, like we think, you know, we

  279. 10:29

    believe that the best option for that,

  280. 10:31

    you know, is actually do these

  281. 10:33

    autonomous payments, um

  282. 10:36

    where, you know,

  283. 10:37

    you know, not everyone's known. Like you

  284. 10:39

    know, the stakes are high. You know, we

  285. 10:40

    think that the industry should converge

  286. 10:42

    on the FIDO verifiable intents and AP2

  287. 10:46

    mandate. Um

  288. 10:48

    You know, the TLDR of that is, you know,

  289. 10:49

    it's a a multi-layered selective

  290. 10:52

    disclosure jot. Uh

  291. 10:54

    The first layer is, you know, created by

  292. 10:56

    a

  293. 10:57

    trustworthy credential provider. You

  294. 10:59

    know, in this case, hopefully it would

  295. 11:00

    be PayPal. Um The second layer, you

  296. 11:02

    know, encapsulates the user's

  297. 11:04

    instructions to the agent. Um

  298. 11:07

    The user signs that with their private

  299. 11:08

    key. And then the third layer, if

  300. 11:10

    there's going to be a third layer, is

  301. 11:12

    when um

  302. 11:14

    we're doing autonomous payments. So,

  303. 11:15

    that case, the agent would, you know,

  304. 11:17

    sign that third layer. And And so, the

  305. 11:21

    where that's powerful is that, you know,

  306. 11:25

    party involved in a transaction can can

  307. 11:27

    verify the part that's, you know,

  308. 11:29

    important to them. So, merchants can

  309. 11:32

    verify that the checkout is correct. Um

  310. 11:34

    Um payment processors can verify that

  311. 11:36

    the payment mandate is correct. Um

  312. 11:39

    And no one has to have any relationship

  313. 11:40

    to each other.

  314. 11:42

    Um

  315. 11:43

    And so, like I think, you know, if

  316. 11:45

    there's going to be a ton of payments,

  317. 11:47

    you know, at scale, we think that that's

  318. 11:49

    going to be the best um way to

  319. 11:50

    accomplish it.

  320. 11:52

    Uh

  321. 11:53

    pictures on the screen are depicting our

  322. 11:56

    PayPal approval token.

  323. 11:57

    Um

  324. 11:58

    This is a new primitive that allows

  325. 12:01

    users of PayPal to

  326. 12:03

    basically start the order process with

  327. 12:05

    an agent um for that agent has actually

  328. 12:07

    found an item at a merchant to transact

  329. 12:09

    with. Uh historically, PayPal orders

  330. 12:12

    have been synchronous.

  331. 12:14

    Um

  332. 12:15

    You know, users on

  333. 12:16

    checkout, they find their item, they go

  334. 12:19

    to their PayPal app, they approve it, um

  335. 12:21

    and it's done. Uh here, it's a little

  336. 12:23

    bit different, you know.

  337. 12:24

    Users on their agent,

  338. 12:26

    um

  339. 12:27

    they get redirected to PayPal to confirm

  340. 12:29

    the instructions that are given to the

  341. 12:30

    agent, and then

  342. 12:32

    uh PayPal hands back this JSON payload.

  343. 12:35

    Um you know, similar to the verifiable

  344. 12:36

    intent, uh includes the

  345. 12:39

    amount, the expiry, uh the merchant that

  346. 12:42

    is supposed to be transacted with. Um

  347. 12:45

    Similar concept, but not quite the same.

  348. 12:47

    Um

  349. 12:48

    it's an opaque string that only PayPal

  350. 12:50

    can approve right now.

  351. 12:51

    Um

  352. 12:52

    But we're about to ship this into

  353. 12:53

    production, um

  354. 12:55

    and users of Jet and I that pick PayPal

  355. 12:57

    as a payment method will will use this.

  356. 13:02

    Um so, going to our last slide, um

  357. 13:05

    you know, we showed this slide earlier.

  358. 13:07

    It we didn't have the two columns filled

  359. 13:08

    out on the right-hand side. Um

  360. 13:11

    You know, we wanted to reinforce this

  361. 13:12

    mental model where,

  362. 13:14

    you know, starting at the top, we have,

  363. 13:15

    you know, the low-stakes scenario, you

  364. 13:17

    know, you're you're using Claude, you've

  365. 13:19

    given it access to connectors, you know,

  366. 13:21

    granular permissions to do things on

  367. 13:22

    your behalf.

  368. 13:24

    Um you feel comfortable doing that

  369. 13:25

    because the stakes are low. You know,

  370. 13:27

    you can reverse those actions or redo

  371. 13:29

    them. It's not a big deal if Claude

  372. 13:30

    produces, you know, the wrong output.

  373. 13:33

    Uh going down a level, we have the

  374. 13:35

    medium stakes scenario. You have

  375. 13:37

    two parties that know each other that

  376. 13:39

    are acting within the same system's

  377. 13:40

    boundary. Um

  378. 13:42

    you know, the

  379. 13:43

    the actions are a little bit higher

  380. 13:44

    stakes. You know, there is money

  381. 13:45

    movement here, but both parties can can

  382. 13:48

    feel comfortable, you know, transacting

  383. 13:49

    with each other because they're relying

  384. 13:51

    on this this third party to enforce uh

  385. 13:54

    the payment mandate.

  386. 13:56

    And then the third level, you know, the

  387. 13:58

    highest stakes one um that we haven't

  388. 14:00

    actually really seen in production yet,

  389. 14:01

    it's, you know, the user's giving an

  390. 14:03

    agent some

  391. 14:05

    instructions to do something on their

  392. 14:06

    behalf autonomously, and you don't know

  393. 14:08

    who they're going to interact with, who

  394. 14:09

    they're going to transact with. Um and

  395. 14:11

    those parties need some verifiable proof

  396. 14:14

    that the agent has permission to do the

  397. 14:16

    transaction. And so, we believe that

  398. 14:18

    that will be um

  399. 14:20

    either verifiable dents and and AP2

  400. 14:23

    mandates.

  401. 14:24

    Um

  402. 14:25

    I think the interesting thing is

  403. 14:27

    it's also our belief that, you know,

  404. 14:28

    this is a model that can't won't just be

  405. 14:31

    used for payments, but we think it could

  406. 14:33

    be for any sort of high-stakes action

  407. 14:35

    that's hard to reverse. So, medical

  408. 14:37

    orders, e-signatures, securities

  409. 14:39

    trading, um you know, basically any

  410. 14:41

    hard-to-reverse agent action.

  411. 14:45

    That's all I have.

  412. 14:46

    >> Yeah, I mean, I think um if we could

  413. 14:47

    just go back to analogies, uh

  414. 14:50

    you know, like in the low stakes is kind

  415. 14:51

    of like, "Hey, you're within the the

  416. 14:53

    building. You've uh put a badge in and

  417. 14:55

    you're within the building." Whereas in

  418. 14:57

    the um high stakes is kind of like, "You

  419. 15:00

    are on the street and you meet

  420. 15:01

    somebody." And uh you know, you need a

  421. 15:04

    way to be able to uh get comfort that

  422. 15:07

    that's someone you can trust, right? Um

  423. 15:09

    is a badge is them showing you their

  424. 15:12

    badge good enough? Uh probably not. You

  425. 15:14

    need to have something that's a little

  426. 15:15

    bit more um you know, verify verifiable.

  427. 15:19

    Or I guess at a verifiable standard. So,

  428. 15:21

    um you know, just kind of like using

  429. 15:23

    that analogy and like how to think about

  430. 15:25

    like the you know, what you need to do

  431. 15:28

    in order to

  432. 15:30

    prove the that the human authorized the

  433. 15:33

    agent. Hopefully that that helps and now

  434. 15:36

    you have kind of like a tool set to use.

  435. 15:39

    So you can kind of prevent Skynet from

  436. 15:41

    taking over your wallet. So, thank you

  437. 15:43

    very much for your for listening. Hope

  438. 15:46

    that helps.

  439. 15:49

    >> [applause]

  440. 16:04

    [music]