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
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.
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.
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
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.
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.
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.
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.
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
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
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.
Resources
Related talks
- How to Secure Agents using OAuth
Extends the medium-stakes portion into the mechanics of delegated OAuth access, short-lived tokens, consent, scopes, and transactional authorization.
- Full Workshop: Agent Auth Protocol — Paola Estefanía de Campos, Better Auth
Provides a practical companion on distinct agent identities, narrowly scoped capabilities, approvals, revocation, and auditability.
- Building safe Payment Infrastructure for the autonomous economy
Offers a complementary payment-infrastructure view that separates nondeterministic agent discovery from deterministic credentials, checkout, spending controls, and payment execution.
Read the complete timestamped transcript
- 0:01
[music]
- 0:12
>> Hello everybody. How are you doing?
- 0:15
Um
- 0:16
Does anybody remember the movie
- 0:18
Terminator?
- 0:20
Uh anyways, it's one of my favorite uh
- 0:22
movies when I was growing up as a kid.
- 0:24
And it imagines a world where the
- 0:26
machines have taken over, right? And uh
- 0:30
uh the nightmare scenario here though in
- 0:33
in 2026 is not that the machines are or
- 0:37
the agents are launching nukes, but
- 0:38
rather
- 0:39
uh they've uh taken your wallet and
- 0:42
they've gone on a shopping spree.
- 0:44
And they buy like a bunch of crypto and
- 0:47
new bunch of bunch of spanks for you.
- 0:50
Um
- 0:51
but the basically today we're talking
- 0:53
about how we safeguard against that and
- 0:55
uh and uh hopefully we can kind of share
- 0:58
a a mental model that you can use when
- 1:00
you're thinking about agent
- 1:02
authorization.
- 1:04
Uh my name is uh Jay Mock. I'm a product
- 1:06
manager over at PayPal in agentic
- 1:09
payments. And
- 1:11
>> Hi everyone. I'm Ben Cooms. I am a staff
- 1:13
software engineer on the
- 1:15
payment PayPal enterprise payments team.
- 1:18
>> And together we're going to share kind
- 1:20
of like some knowledge with you. Um so
- 1:22
hopefully
- 1:23
uh you find it helpful. Okay.
- 1:26
So uh the the key questions that we kind
- 1:29
of like uh start off with is uh in terms
- 1:32
of like agent authorization is uh did
- 1:34
the human authorize this?
- 1:36
Um is this allowed right now in this
- 1:39
scope and can we prove it later, right?
- 1:42
And we we kind of like try to make it
- 1:44
general, but in our world of payments,
- 1:46
yeah, did the human authorize this? Uh
- 1:48
that could be like a passkey or of of
- 1:51
that nature. Uh is this allowed right
- 1:53
now in this scope? It's generally going
- 1:55
to be a time bound um
- 1:57
you know you know token.
- 1:59
Um and an amount and possibly could be
- 2:02
identified like a merchant or a
- 2:06
the actual product intent. Lastly, can
- 2:10
we prove it later? This is like if
- 2:12
something goes wrong, right? And in our
- 2:14
world of payments it's generally has to
- 2:15
do with like the disputes and
- 2:18
in that case and how do you can you
- 2:19
prove that
- 2:21
you know the the human generally
- 2:23
authorized that transaction. Right? Um
- 2:27
But we think the way that you actually
- 2:29
answer these three questions is really
- 2:32
dependent on the context. You know,
- 2:34
context is a overused term, but in this
- 2:38
case what we what we mean is
- 2:41
um
- 2:41
you know, is it a low stakes or high
- 2:43
stakes kind of
- 2:45
scenario?
- 2:47
Um and
- 2:49
is this a kind of like open ecosystem or
- 2:53
closed ecosystem? Do the parties like
- 2:55
know each other? You know, people use
- 2:56
the term KYA a lot. Know your agent, but
- 3:00
you know, what we think about in this
- 3:02
scenario is is is really about is it
- 3:04
like an open or closed ecosystem, right?
- 3:06
And in a payments context it could be
- 3:08
like, "Hey, you know, ChatGPT or Gemini,
- 3:11
right?" That's like kind of like a more
- 3:12
of like a closed ecosystem because you
- 3:14
know, the those agents know the merchant
- 3:17
generally. Um
- 3:19
I like to use a an analogy.
- 3:23
I like analogies. And the analogy I I
- 3:26
like to use is kind of like the you
- 3:27
know, badging into work. You badge into
- 3:29
work in the front desk. You basically
- 3:33
are are then led into the building or
- 3:35
you know, let's say it's a set of
- 3:36
buildings. You don't need to like badge
- 3:38
in every single time to every other or
- 3:40
for every single room because you're
- 3:42
already within that trusted boundary,
- 3:44
right? So then when you meet someone in
- 3:47
within that within your your office
- 3:49
building, uh, you kind of have some
- 3:51
element of trust, or hopefully you have
- 3:53
some element of trust, uh, because
- 3:55
you're both, uh, employees at the same
- 3:56
company that badged in, right? So, um,
- 4:00
that's kind of like the analogy I may I
- 4:02
may use later in the presentation.
- 4:05
Okay, so based on those key questions,
- 4:07
we kind of think about like, "Hey,
- 4:08
what's the mental model that we can
- 4:09
build off of this, right?" And we have
- 4:11
this like stakes and evidence matrix,
- 4:13
and we're going to talk about, uh, these
- 4:15
three different scenarios.
- 4:17
Um, and so, uh, we're going to first uh,
- 4:20
and you'll see at the top it's kind of
- 4:21
like the stakes and counterparty part
- 4:23
that I was just talking about the
- 4:24
context, right? Counterparty is like the
- 4:26
open or closed ecosystem. And then
- 4:29
authority and like evidence is really
- 4:30
about how you answer those those those
- 4:32
three questions I had shared in in the
- 4:34
prior slide, right? Um, so we'll talk a
- 4:37
little bit first about like cloud code
- 4:38
since that's what most people are very
- 4:40
familiar with, and, uh, basically, you
- 4:43
know, when you as a human you're going,
- 4:45
you know, using your cloud code, uh, you
- 4:47
know, you might be, uh, then setting up,
- 4:49
uh, your your connectors with your
- 4:50
GitHub or or, um, you know, Jira or
- 4:53
whatever, uh, linear or whatever uh,
- 4:55
tool you're using. And, um, you know,
- 4:58
you're as part of that process you're
- 4:59
kind of like authenticating, so that's
- 5:00
how you kind of like get that that human
- 5:02
authorization and consent um, with those
- 5:05
those applications and to for the for
- 5:07
cloud container act with them.
- 5:09
Um, in terms of the, uh,
- 5:11
actual like, uh, scopes, right? The the
- 5:15
example here would be that about, you
- 5:17
know, cloud's like, uh, tool
- 5:18
permissions. Like people are very
- 5:20
familiar probably with, uh, the fact
- 5:21
that you can allow cloud cloud to to use
- 5:24
certain tools, um, uh, deny or ask cloud
- 5:27
to ask you, uh, before for before doing
- 5:30
something, right? And then in terms of,
- 5:33
uh, the action of like a cloud, uh, we
- 5:36
generally think, um, because it's a kind
- 5:38
of closed ecosystem and it's like you're
- 5:39
coding, uh, the stakes are relatively
- 5:42
low here. And so in terms of the
- 5:44
evidence or proof, you don't really need
- 5:46
to have like that cryptographic proof
- 5:48
um, at that point in time. You can kind
- 5:50
of just look at like system logs in
- 5:51
order to to or you have the ability to
- 5:53
just revert revert your changes, right?
- 5:57
So, that's kind of like an example of
- 6:00
applying like this mental model
- 6:03
and using cloud code in terms of that
- 6:05
scenario.
- 6:07
Okay, so the next
- 6:08
example we're going to talk about is
- 6:11
a more medium stakes
- 6:13
scenario and why
- 6:15
why we're calling this medium stakes
- 6:16
even though it's within a known or kind
- 6:19
of closed ecosystem is because it has to
- 6:20
do with money and and payments. And so
- 6:24
that's like the shared vault and OAuth
- 6:25
scope example.
- 6:29
So, in this example where the use case
- 6:33
is is like hey you're like a let's say
- 6:36
a merchant or Trip Advisor, right? And
- 6:38
you have
- 6:40
a travel travel company and you have a
- 6:43
lot of great content that you want to
- 6:44
monetize. It could be occupancy data, it
- 6:46
could be like reviews, what have you.
- 6:48
And you have a new customer now. You
- 6:50
have like a trap like travel agents or
- 6:52
like you know agents that that are buyer
- 6:54
agents that are are coming to you and
- 6:57
you want to be able to monetize
- 7:00
monetize your data, right? Through
- 7:02
machine payments.
- 7:04
So, we work with a partner and Never
- 7:06
mind to be able to enable that that that
- 7:09
use case and leveraging our
- 7:12
they're leveraging our infrastructure.
- 7:15
Right? So, there is two pieces of
- 7:17
infrastructure that they
- 7:19
that I like to kind of to call out or
- 7:21
primitives that they use that
- 7:22
as part of the Braintree or PayPal
- 7:24
enterprise
- 7:26
infrastructure. One is like the vault,
- 7:28
right? And the vault by itself, which is
- 7:30
storing all these like
- 7:33
payment credentials on behalf of the
- 7:35
on behalf of the buyer agents,
- 7:38
on itself doesn't really do much, but in
- 7:40
order to create
- 7:42
what nevermind creates is a a more
- 7:47
eco closed ecosystem, they then off
- 7:49
you're able to um
- 7:52
offer
- 7:53
uh or offer access to those payment
- 7:55
credentials through
- 7:57
OAuth, right? To all those merchants.
- 7:59
So, in our example before we talked
- 8:01
about that that travel travel um travel
- 8:05
company, right? So, by doing so, they're
- 8:07
able to then create like an ecosystem um
- 8:10
of buyer agents and seller agents
- 8:13
uh and have a more trusted
- 8:16
environment, right? So,
- 8:19
um
- 8:19
in the in the just kind of talking more
- 8:21
about the use case, like the human then
- 8:24
is then going to be authorizing
- 8:26
authorizing their their payment.
- 8:28
Usually, this is a commercial card
- 8:30
commercial use case. So, you're using
- 8:32
like a commercial card, they share it
- 8:33
with the buyer agent, travel agent. Um
- 8:37
then that uh it it also has
- 8:41
scopes associated with that mandate. So,
- 8:43
that's how you're able to do controlled
- 8:45
authority, but in terms of like the
- 8:47
actual like dispute handling, we really
- 8:50
uh don't have like a we're not using
- 8:52
like
- 8:54
cryptographic proof that's being sent as
- 8:55
part of that that request, right? At the
- 8:58
end of the day, they can since it's more
- 9:00
of a
- 9:02
closed ecosystem,
- 9:03
they're able to leverage like the just
- 9:05
the existing
- 9:07
transaction logs.
- 9:09
Right? So, that's kind of an example of
- 9:11
like a medium stakes and
- 9:14
use case or scenario, and
- 9:17
we we believe it's medium stakes because
- 9:19
of the fact that it is a more closed
- 9:22
ecosystem and doesn't require all like
- 9:25
the
- 9:27
you know, evidence in terms of
- 9:31
or proof, right? So,
- 9:34
that's kind of like my part. I'll going
- 9:35
to turn it over now to Ben and uh take
- 9:38
it from here.
- 9:40
>> Uh thanks, Jay.
- 9:43
Yeah, so the last slide that Jay talked
- 9:45
about, um
- 9:46
you know, we're kind of going over the
- 9:48
medium stakes example.
- 9:50
Uh um
- 9:51
In that scenario, um
- 9:54
you know, both parties know each other.
- 9:56
Uh they're acting within, you know, the
- 9:58
same system. They they know
- 10:01
you know,
- 10:02
they're borrowing trust from, you know,
- 10:03
Nevermind to
- 10:05
make sure that, you know, the buying
- 10:07
agent is falling within, you know, the
- 10:09
instructions that a human has given it.
- 10:11
Um
- 10:11
and then the selling agent that's also
- 10:13
on Nevermind can feel comfortable taking
- 10:15
a payment um
- 10:17
from another user of of Nevermind. And
- 10:19
And so, what we want to talk about next
- 10:21
is what happens when the parties are are
- 10:23
not known to each other and they're not
- 10:25
vetted. Um
- 10:27
And so, like we think, you know, we
- 10:29
believe that the best option for that,
- 10:31
you know, is actually do these
- 10:33
autonomous payments, um
- 10:36
where, you know,
- 10:37
you know, not everyone's known. Like you
- 10:39
know, the stakes are high. You know, we
- 10:40
think that the industry should converge
- 10:42
on the FIDO verifiable intents and AP2
- 10:46
mandate. Um
- 10:48
You know, the TLDR of that is, you know,
- 10:49
it's a a multi-layered selective
- 10:52
disclosure jot. Uh
- 10:54
The first layer is, you know, created by
- 10:56
a
- 10:57
trustworthy credential provider. You
- 10:59
know, in this case, hopefully it would
- 11:00
be PayPal. Um The second layer, you
- 11:02
know, encapsulates the user's
- 11:04
instructions to the agent. Um
- 11:07
The user signs that with their private
- 11:08
key. And then the third layer, if
- 11:10
there's going to be a third layer, is
- 11:12
when um
- 11:14
we're doing autonomous payments. So,
- 11:15
that case, the agent would, you know,
- 11:17
sign that third layer. And And so, the
- 11:21
where that's powerful is that, you know,
- 11:25
party involved in a transaction can can
- 11:27
verify the part that's, you know,
- 11:29
important to them. So, merchants can
- 11:32
verify that the checkout is correct. Um
- 11:34
Um payment processors can verify that
- 11:36
the payment mandate is correct. Um
- 11:39
And no one has to have any relationship
- 11:40
to each other.
- 11:42
Um
- 11:43
And so, like I think, you know, if
- 11:45
there's going to be a ton of payments,
- 11:47
you know, at scale, we think that that's
- 11:49
going to be the best um way to
- 11:50
accomplish it.
- 11:52
Uh
- 11:53
pictures on the screen are depicting our
- 11:56
PayPal approval token.
- 11:57
Um
- 11:58
This is a new primitive that allows
- 12:01
users of PayPal to
- 12:03
basically start the order process with
- 12:05
an agent um for that agent has actually
- 12:07
found an item at a merchant to transact
- 12:09
with. Uh historically, PayPal orders
- 12:12
have been synchronous.
- 12:14
Um
- 12:15
You know, users on
- 12:16
checkout, they find their item, they go
- 12:19
to their PayPal app, they approve it, um
- 12:21
and it's done. Uh here, it's a little
- 12:23
bit different, you know.
- 12:24
Users on their agent,
- 12:26
um
- 12:27
they get redirected to PayPal to confirm
- 12:29
the instructions that are given to the
- 12:30
agent, and then
- 12:32
uh PayPal hands back this JSON payload.
- 12:35
Um you know, similar to the verifiable
- 12:36
intent, uh includes the
- 12:39
amount, the expiry, uh the merchant that
- 12:42
is supposed to be transacted with. Um
- 12:45
Similar concept, but not quite the same.
- 12:47
Um
- 12:48
it's an opaque string that only PayPal
- 12:50
can approve right now.
- 12:51
Um
- 12:52
But we're about to ship this into
- 12:53
production, um
- 12:55
and users of Jet and I that pick PayPal
- 12:57
as a payment method will will use this.
- 13:02
Um so, going to our last slide, um
- 13:05
you know, we showed this slide earlier.
- 13:07
It we didn't have the two columns filled
- 13:08
out on the right-hand side. Um
- 13:11
You know, we wanted to reinforce this
- 13:12
mental model where,
- 13:14
you know, starting at the top, we have,
- 13:15
you know, the low-stakes scenario, you
- 13:17
know, you're you're using Claude, you've
- 13:19
given it access to connectors, you know,
- 13:21
granular permissions to do things on
- 13:22
your behalf.
- 13:24
Um you feel comfortable doing that
- 13:25
because the stakes are low. You know,
- 13:27
you can reverse those actions or redo
- 13:29
them. It's not a big deal if Claude
- 13:30
produces, you know, the wrong output.
- 13:33
Uh going down a level, we have the
- 13:35
medium stakes scenario. You have
- 13:37
two parties that know each other that
- 13:39
are acting within the same system's
- 13:40
boundary. Um
- 13:42
you know, the
- 13:43
the actions are a little bit higher
- 13:44
stakes. You know, there is money
- 13:45
movement here, but both parties can can
- 13:48
feel comfortable, you know, transacting
- 13:49
with each other because they're relying
- 13:51
on this this third party to enforce uh
- 13:54
the payment mandate.
- 13:56
And then the third level, you know, the
- 13:58
highest stakes one um that we haven't
- 14:00
actually really seen in production yet,
- 14:01
it's, you know, the user's giving an
- 14:03
agent some
- 14:05
instructions to do something on their
- 14:06
behalf autonomously, and you don't know
- 14:08
who they're going to interact with, who
- 14:09
they're going to transact with. Um and
- 14:11
those parties need some verifiable proof
- 14:14
that the agent has permission to do the
- 14:16
transaction. And so, we believe that
- 14:18
that will be um
- 14:20
either verifiable dents and and AP2
- 14:23
mandates.
- 14:24
Um
- 14:25
I think the interesting thing is
- 14:27
it's also our belief that, you know,
- 14:28
this is a model that can't won't just be
- 14:31
used for payments, but we think it could
- 14:33
be for any sort of high-stakes action
- 14:35
that's hard to reverse. So, medical
- 14:37
orders, e-signatures, securities
- 14:39
trading, um you know, basically any
- 14:41
hard-to-reverse agent action.
- 14:45
That's all I have.
- 14:46
>> Yeah, I mean, I think um if we could
- 14:47
just go back to analogies, uh
- 14:50
you know, like in the low stakes is kind
- 14:51
of like, "Hey, you're within the the
- 14:53
building. You've uh put a badge in and
- 14:55
you're within the building." Whereas in
- 14:57
the um high stakes is kind of like, "You
- 15:00
are on the street and you meet
- 15:01
somebody." And uh you know, you need a
- 15:04
way to be able to uh get comfort that
- 15:07
that's someone you can trust, right? Um
- 15:09
is a badge is them showing you their
- 15:12
badge good enough? Uh probably not. You
- 15:14
need to have something that's a little
- 15:15
bit more um you know, verify verifiable.
- 15:19
Or I guess at a verifiable standard. So,
- 15:21
um you know, just kind of like using
- 15:23
that analogy and like how to think about
- 15:25
like the you know, what you need to do
- 15:28
in order to
- 15:30
prove the that the human authorized the
- 15:33
agent. Hopefully that that helps and now
- 15:36
you have kind of like a tool set to use.
- 15:39
So you can kind of prevent Skynet from
- 15:41
taking over your wallet. So, thank you
- 15:43
very much for your for listening. Hope
- 15:46
that helps.
- 15:49
>> [applause]
- 16:04
[music]