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

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

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

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

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.

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