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

Agent authorization for payments should be governed by a stakes-and-evidence mental model where the level of cryptographic proof required scales with whether...

By Sean Weldon

Your Agent Just Authorized What?! Toward a Stakes-and-Evidence Model for Agentic Payment Authorization

Abstract

As autonomous agents increasingly initiate financial transactions, a central engineering question emerges: how much cryptographic proof should an authorization mechanism require before an agent's action is trusted? This synthesis, drawing on practitioner analysis from PayPal engineers, presents a stakes-and-evidence framework in which required authorization strength scales along two axes - the stakes of the action (reversibility and magnitude) and the openness of the ecosystem (whether counterparties are mutually vetted). Three graduated case studies are examined: log-based permission scoping in developer tooling (Claude Code), shared credential vaults with OAuth scoping for machine-to-machine commerce (Nevermind/PayPal), and cryptographically verifiable mandates for autonomous payments between unknown parties (AP2, FIDO verifiable intents, PayPal approval tokens). Findings suggest the framework generalizes beyond payments to any high-stakes, hard-to-reverse agent action, offering practical guidance for engineers designing agent authorization systems today.

1. Introduction

The proliferation of agentic systems capable of invoking tools and executing multi-step plans without per-action human confirmation has shifted the central security question from whether a model can perform an action to whether it was permitted to perform it, and whether that permission can be demonstrated after the fact. This concern becomes acute once agents are granted the ability to move money. The practical risk is not speculative catastrophic autonomy but mundane financial harm, as one framing captures:

"The nightmare scenario here though 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."

Three questions organize the authorization problem for any agentic payment system: did the human authorize this action (e.g., via a passkey); is this action currently allowed within a defined scope (time-bound token, amount, merchant or product intent); and can the authorization be proven later if a dispute arises. The central thesis of this analysis is that the answers to these questions are not fixed but contextual, governed by two variables - the stakes involved (low, medium, or high, correlated with reversibility and monetary value) and whether the transaction occurs within a closed ecosystem (mutually vetted, pre-established trust) or an open ecosystem (parties unknown to one another).

This paper formalizes that contextual mapping as a Stakes and Evidence Matrix, examines three reference implementations positioned along its diagonal, and details the cryptographic primitives required at the high-stakes, open-ecosystem end of the spectrum.

2. Background and Related Work

Several emerging industry primitives supply the vocabulary for this analysis. FIDO Verifiable Intents extend the FIDO authentication model so that a cryptographic credential attests not merely to identity but to a specific transactional instruction. The AP2 Mandate encodes delegated authority from a human principal to an agent in a form validatable by downstream parties. The OAuth Scope / Shared Vault Model pairs tokenized credential storage with scoped, delegated API access, a pattern with precedent in card-not-present commerce. The PayPal Approval Token is a provider-specific opaque payload authorizing a bounded transaction. Know Your Agent (KYA) extends counterparty due-diligence obligations from legal persons to autonomous software actors.

An intuition-building device used throughout is the badging-in analogy: an employee badges in once at a building's front desk, and subsequent movement between rooms requires no re-verification because the perimeter check has already established a trusted boundary. Meeting a colleague inside that boundary carries implicit trust because both parties were vetted by the same authority. A high-stakes, open-ecosystem interaction, by contrast, resembles meeting an unvetted stranger on the street - a scenario in which a badge is insufficient and a stronger, independently verifiable form of proof becomes necessary.

3. Core Analysis

3.1 Low-Stakes, Closed-Ecosystem Authorization: Log-Based Evidence

The Claude Code example illustrates authorization at the low-stakes end of the matrix. A human authenticates once when configuring connectors to services such as GitHub, Jira, or Linear. Thereafter, the agent operates under tool permission scopes - allow, deny, or ask - without requiring cryptographic re-verification for each action. Because the ecosystem is closed (the human has already vetted and connected each tool) and the actions are low-stakes and typically reversible, evidentiary requirements are minimal: system logs suffice as the record of what occurred, and erroneous actions can simply be reverted. No cryptographic proof mechanism is deemed necessary in this regime, since the cost of an error is low and the trust boundary is already established at the connector-authorization step.

3.2 Medium-Stakes Commerce: Vaults, OAuth Scope, and Third-Party Enforcement

The medium-stakes case is illustrated by a machine-payments scenario in which a merchant (analogous to a travel-recommendation platform) monetizes data or bookings to buyer-side agents. The partner integration, Nevermind, built on PayPal/Braintree infrastructure, relies on two primitives: a vault, which stores payment credentials on behalf of buyer agents, and OAuth scope access, which grants those agents delegated access to credentials under merchant-defined constraints. Together these primitives constitute a more trusted closed ecosystem linking buyer and seller agents, even though the underlying human principal is once removed from each transaction.

In this model, the human typically authorizes payment upstream by sharing a commercial card with a buyer or travel agent, and mandates specify scopes that bound the agent's authority (e.g., category, amount ceiling, or merchant set). Critically, dispute handling in this regime does not require cryptographic proof; it relies on existing transaction logs and the contractual/technical enforcement already embedded in the closed vault-and-OAuth relationship. This reflects a design principle: when the ecosystem is closed and parties are already bound by commercial agreements and existing dispute infrastructure (e.g., card network chargebacks), the marginal value of cryptographic verifiability is lower than the cost of introducing it.

3.3 High-Stakes, Open-Ecosystem Authorization: Verifiable Mandates and Multi-Layer JWTs

The high-stakes case applies when transacting parties are not known to each other and have not been mutually vetted - the "stranger on the street" condition. Here, the source material argues that the industry should converge on FIDO verifiable intents and AP2 mandates, both of which are implemented via a multi-layered selective disclosure JWT structure comprising up to three layers.

Layer 1 is created by a trustworthy credential provider, such as PayPal, establishing a root of trust. Layer 2 encapsulates the user's actual instructions to the agent and is signed with the user's private key, cryptographically binding the human principal to a specific, bounded instruction. Layer 3, present specifically in autonomous payment scenarios, is signed by the agent itself, attesting that the agent executed within the bounds delegated to it. This layered structure enables selective disclosure: each party in the transaction chain can verify only the portion of the JWT relevant to its role, without requiring a pre-existing bilateral relationship with the other parties.

A concrete instantiation of this pattern is the PayPal approval token, a new primitive enabling an agent-initiated order confirmation flow. The token is an opaque JSON payload - approvable only by PayPal - that encodes amount, expiry, and merchant, functioning similarly to a verifiable intent but remaining PayPal-specific rather than an open standard. Historically, PayPal order flows were synchronous, requiring in-app user approval at the moment of purchase; the new mechanism redirects users to confirm agent instructions asynchronously, decoupling the agent's initiation of a transaction from the human's approval step while preserving an auditable, cryptographically-anchored trail. This mechanism is reported to be nearing production deployment as a PayPal payment method.

4. Technical Insights

Several implementation-relevant observations follow from the three cases. First, the evidentiary requirement is not monotonic with transaction value alone - it depends jointly on reversibility and ecosystem openness, meaning a high-value transaction within a well-vetted closed loop (3.2) may require less cryptographic overhead than a low-value transaction between unknown open-ecosystem parties. Second, the multi-layer JWT design enables incremental adoption: a credential provider (Layer 1) can be deployed before user-signed instructions (Layer 2) or agent-signed execution (Layer 3) are fully standardized, since each layer is independently verifiable. Third, opaque provider-specific tokens (e.g., the PayPal approval token) represent a pragmatic bridge - offering bounded, auditable authorization without requiring immediate industry-wide standardization on AP2 or FIDO verifiable intents. A trade-off is that opaque tokens lack interoperability across providers, whereas standardized verifiable intents aim for cross-provider verifiability at the cost of slower convergence. Fourth, the vault-plus-OAuth-scope pattern (3.2) reuses established card-network dispute infrastructure rather than inventing new cryptographic dispute mechanisms, reducing integration cost for merchants already familiar with tokenized credential storage.

5. Discussion

The stakes-and-evidence framework reframes agentic payment authorization as a design problem rather than a binary security question. Rather than asking "is this action cryptographically verifiable," the more productive question is "given the stakes and ecosystem openness, what is the minimum sufficient evidentiary structure." This reframing has implications beyond payments: the source material explicitly proposes that the same matrix applies to any high-stakes, hard-to-reverse agent action, including medical orders, e-signatures, and securities trading, wherever an agent's action must later be defensible in a dispute.

An open question is how Know Your Agent (KYA) obligations will be operationalized alongside these cryptographic layers - particularly in open ecosystems where an agent's provenance and behavioral history may need to be attested independently of the transaction-specific mandate. Additionally, the coexistence of provider-specific opaque tokens (PayPal approval tokens) and open standards (AP2, FIDO verifiable intents) suggests a transitional period in which interoperability across payment providers remains incomplete, a gap likely to shape near-term agentic commerce infrastructure.

6. Conclusion

This analysis presents a stakes-and-evidence matrix for agentic payment authorization, demonstrating through three graduated cases - log-based scoping, vault-and-OAuth commerce, and cryptographically verifiable mandates - that authorization strength should scale with reversibility, value, and ecosystem openness rather than be uniformly maximized. Practically, engineers designing agent authorization systems should first classify the stakes and ecosystem openness of a given action before selecting an evidentiary mechanism, reserving costly cryptographic constructs like multi-layer selective disclosure JWTs for genuinely high-stakes, open-ecosystem scenarios. The framework's proposed generalizability to non-payment domains suggests its principles merit further investigation as agentic systems expand into medical, legal, and securities contexts.

Sources

About the Author

Sean Weldon is an AI engineer and systems architect specializing in autonomous systems, agentic workflows, and applied machine learning. He builds production AI systems that automate complex business operations.

LinkedIn | Website | GitHub