The Agent Did Not Make the Payment Alone. It Passed Your Authority Down a Chain.

Everyone is talking about agents becoming able to buy things. What I think actually matters is what happens after agentic commerce stops being a demo, when one human instruction can travel through several agents, services and execution systems before producing a real transaction.

That is the reason the Alipay announcement on 17 August 2026 is worth reading closely, and it is not the reason most coverage gives.

What Alipay announced today

At its AI Ecosystem Partner Conference in Hangzhou on 17 August 2026, Alipay launched what it describes as China's first full stack agentic commerce platform. Alipay says the platform lets merchants turn existing pages, products and service workflows into Skills and MCP tools that an agent can call, and lets merchants that already have AI capability handle agent creation, skill orchestration, task execution and operations management.

Alongside it, Alipay released a protocol system it calls AHA, short for Agent Hub Access, described as China's first multi agent cross device interconnection protocol system. Chinese reporting on the conference describes the system as containing three parts: an interaction standard (Skills Interface Standards), the agent interconnection protocol itself (Agent Hub Access), and a device perception and execution protocol (X User Interface). Alipay also announced an ecosystem plan with more than 20 partners spanning device makers, automakers and foundation model companies, including Qwen, Huawei, OPPO, vivo, Xiaomi, Honor, BYD, Geely, Li Auto, NIO and StepFun.

Ant Group CEO Cyril Han framed the timing directly: "Agentic commerce is poised for rapid growth over the next 6 to 12 months. AI agents will become a new interface connecting hundreds of millions of users with tens of millions of merchants, unlocking a new intent-driven commercial ecosystem."

What is new today, and what is not

This distinction matters more than the headline numbers, so I want to be exact about it.

New on 17 August 2026: the full stack agentic commerce platform for merchants, the formal release of the AHA protocol system, the multi partner interconnection plan, and an incentive programme for developers and merchants.

Already in place before today: Ah Bao, Alipay's super service agent, which Alipay says launched in June 2026 and gives consumers access to more than 10,000 AI powered everyday services. Alipay's AI payment products, launched in May 2026 according to contemporaneous reporting on its AI strategy. The AI Open Platform, opened in July 2026. The cross agent integrations themselves, including OPPO's Breeno calling Ah Bao, announced in July 2026, and a system level partnership with StepFun demonstrated at WAIC in July 2026. Alipay states that as of August 2026, Ah Bao has connected with 5 leading smartphone brands accounting for over 70% of the market, and 16 leading automakers.

So AHA as a named capability is not something that appeared this morning and immediately started routing payments. Integrations built on it were running publicly in July. What Alipay did today was publish it as a protocol system and recruit an ecosystem around it. That is a governance event more than a technical one, and it is the correct thing to focus on.

The scale is real, and it is vendor reported

Alipay's own AI payment platform documentation states its platform scale as more than 300 million agent payments, more than 100 million service users, and coverage of 12 mainstream commercial scenarios across phones, cars, smart glasses, AI earphones and speakers. Its marketing site adds a claim worth quoting because it is unusually specific: the payments achieved through AI pay have exceeded 300 million, and these are "not a demo, not a sandbox, but transaction volume in real commercial scenarios."

Two things follow. First, that 300 million figure was already reached before today. It appears in Alipay's platform documentation as a current cumulative total, not as something announced at the conference. Nothing in the material dates the crossing of that threshold to 17 August. Second, these are metrics Alipay supplies about its own platform. They have not been independently audited, and I have seen no third party verification of them.

I also want to be careful about what 300 million agent payments does not mean. It does not mean 300 million fully autonomous transactions with no human in the loop. Alipay's own documentation describes multiple authorization modes, at least one of which requires the user to confirm every single payment. The number counts payments made through agent payment products. It does not tell you the split between confirmed and unconfirmed.

What Alipay says about authorization

Alipay's public product material is more precise than the coverage around it, and it deserves to be represented fairly.

Alipay's Agent payment product documentation lists several distinct capabilities under one product. Agent identity authentication, which establishes an identity and risk profile for the agent itself. User authorization, offered in multiple modes including per transaction confirmation and a confirmation free mode within a user set limit. Payment intent verification, described as checking whether the agent's behaviour matches the user's original intent. Trusted evidence recording of key nodes in the delegated payment for dispute handling. Liability determination for abnormal transactions. And authorization management after the fact, including aggregating orders by task, alerting on abnormal bills, and suggesting that authorization be stopped.

Alipay's agent to agent payment page states that every transaction requires user authorization and that the agent does not act on its own initiative. Its Skill monetisation product page says the same, adding that Alipay risk control identifies intent to ensure the transaction matches what the user expected, and that the agent completes product selection, ordering, payment and receipt return under user authorization.

Read carefully, that is not one control. It is at least six: agent identity, authorization grant, per transaction confirmation or a limit, intent checking, evidence recording, and revocation. Collapsing them into "Alipay requires authorization" loses the part that matters, because those mechanisms answer different questions and fail in different ways.

Where the chain actually runs

Take the workflow Alipay itself demonstrated publicly, described in the same announcement. At WAIC in July 2026, a user asked an agent named Amoo, running on StepFun's device, to find the nearest EV charger and order a coffee to their home. Amoo interpreted the intent, planned an approach based on route and price, then activated charging and coffee agents on Ah Bao, which recommended options and generated an order the user could confirm.

Or the OPPO integration, live since July: a user tells Breeno to buy a cinema ticket while watching a short video, and Ah Bao handles theatre selection, showtime and booking.

Count the actors in the first one. A human. A device assistant from one company. A super service agent from another. At least two merchant service agents. A payment system. Then a real order.

Notice also that in the described demonstration, the chain terminates in a ready to confirm order. The human is still there at the end. That is the design working as documented, and it is worth saying plainly rather than implying that money moves silently through five hops.

Connectivity is not authorization

Here is the interpretation, and it is mine, not Alipay's.

A protocol that connects agents solves a routing problem. It establishes that agent A can reach agent B, that B can understand what A is asking for, and that a service can be discovered and invoked across a company boundary. That is genuinely hard and Alipay has clearly done real work on it.

But routing and authority are different substances. When the coffee agent receives a request, what it has received is a message from another agent. The interesting question is what accompanies that message. Does the downstream agent receive an independently scoped authorization, bounded to this task, this amount, this merchant, traceable back to a specific human grant? Or does it receive a request that is trusted because of who sent it?

Those two designs look identical when everything works. They diverge completely the first time something upstream is wrong: a misread intent, an agent that expands a task beyond what was asked, an instruction that entered through content rather than from the user.

I do not know which design AHA implements at the authorization layer. Alipay's public material does not say, at the level of detail that would settle it, how authorization is represented as it crosses agents, which party retains the user account and payment relationship at each hop, or whether a downstream agent inherits authority or is issued its own. That is an unknown and I am leaving it as one.

Delegated authority is not concurrent authority

Moona Intelligence has covered adjacent versions of this before. When Robinhood authorized software to move money, the chain was short: one user, one agent, one account, contained by a spending cap and a disconnect. When AWS and Solv Labs published a governed payments workflow, the question was whether you could later prove why one payment was allowed. When Claude Code began forking subagents by default, the question was which permissions came with the new agent.

Agentic commerce at consumer scale is a different shape from all three. It is not one agent acting with delegated authority, and it is not several agents holding concurrent authority over the same environment, which is the failure mode Anthropic's researchers produced when three agents with conflicting goals started revoking each other's access.

It is a chain. Authority is handed forward, hop by hop, across parties that have no shared operator, no shared policy engine, and often no commercial relationship with each other beyond a protocol. Each hop is individually reasonable. The composition is the thing nobody owns.

The provenance question

Alipay is not being careless here. The evidence recording, the intent verification, the liability determination and the stop authorization mechanisms all exist precisely because Alipay knows disputes are coming. Building dispute machinery into the product before scale arrives is more foresight than most agent products have shown.

But dispute resolution is a reconstruction exercise. It answers the question afterwards. The question I keep returning to is whether it can be answered at the moment the action executes.

When a payment finally settles at the end of a chain that crossed a phone maker, a super agent, a merchant agent and a payment platform, can anyone establish, at that instant, which human authorization legitimately reached it, and that the action being executed is inside the scope of what that human actually granted?

Agentic commerce will be judged on that question long before it is judged on transaction volume. Three hundred million payments is a demonstration that the plumbing works. Authorization propagation is what determines whether the next three billion are defensible.

A separate development, verified now: Uber's actor chain

On 21 May 2026, Uber Engineering published Solving the Identity Crisis for AI Agents, a technical account of an internal architecture built during 2025 and extended through Uber's 2026 platform work. It has no connection to Alipay's 17 August launch above and did not appear today. Moona Intelligence is verifying it and adding it to this record on 23 August 2026 because it speaks directly, with production implementation detail, to the propagation question this record has asked since the Alipay chain: when a human's instruction has already crossed several agents, does the system at the far end see the whole chain, or only the last hop.

Uber's own framing of the problem, corroborated through this session's search passes because automated fetching of uber.com is blocked in Moona's tooling environment, uses a multi agent workflow to motivate the design rather than describing a disclosed production incident. An on call engineer asks an Oncall Agent to investigate an alert. The Oncall Agent delegates to an Investigation Agent, which finds the alert itself misconfigured and hands the fix to a Monitoring Agent, which opens a pull request adjusting the threshold. The resulting pull request is attributed to the Monitoring Agent. The identity of the on call engineer who actually asked for the change does not travel with it. This record treats that scenario as Uber's own illustrative example of the problem its architecture addresses, not as a reported incident, and does not manufacture one where Uber describes none.

Workload identity is not agent identity, and Uber keeps the two separate

Uber's architecture, as corroborated through multiple independent search passes against this session's blocked direct access to uber.com, starts each workload with a cryptographically signed workload SVID obtained from SPIRE, the reference implementation of the SPIFFE workload identity standard. That credential establishes that the compute environment is legitimate, a Kubernetes hosted workload with a real identity inside Uber's infrastructure. It does not, on Uber's own account, establish which agent is entitled to run inside it. Uber's material names Michelangelo, Uber's machine learning platform, as the system that associates a specific agent with the workload hosting it, with an Agent Registry recorded as the source of truth for that association. When a workload requests a token, the Security Token Service checks the requested agent identifier against the Agent Registry to confirm that specific agent is authorized to run on that specific workload, closing the gap a workload identity alone leaves open. A legitimate workload is not, by itself, proof of which agent is entitled to act from inside it.

Uber states the Security Token Service is the only system permitted to mint a JWT for an AI agent. When an agent needs to call the next hop, it presents its workload's SVID together with the inbound context to the STS and requests a token scoped to the next hop's audience. What comes back is scoped to that one destination and short lived, with a time to live corroborated across multiple independent secondary sources as being on the order of minutes. A token issued so an Oncall Agent can call an Investigation Agent is not, on this design, reusable to call a database or a different service directly, because its audience claim names the intended destination and nothing else. This record preserves that as Uber's documented architecture rather than inferring stronger cryptographic guarantees than a short lived, signed, audience scoped JWT actually carries.

The actor chain, MCP Gateway, and what carrying identity does not do

Each token exchange, on Uber's account, carries forward a fully attested actor chain: a claim recording the human user and every intermediate agent involved in the request so far, for example a chain naming the originating user, the Oncall Agent and the Investigation Agent, extended again as the token reaches MCP Gateway. What that chain proves is exactly what it carries: identities that were present in the request path, cryptographically attested hop by hop, with the STS as the only party permitted to write a new hop into it. What it does not prove is that every participant recorded in that chain legitimately possessed the business authority the resulting action implies.

Uber describes MCP Gateway as a central policy enforcement point for MCP tool invocations, applying tool level authorization policy once a caller's token is authenticated and before a request is proxied to a downstream microservice or datastore, with policies mandated for systems Uber's internal risk classification treats as high risk. Nothing corroborated to this session establishes that this tool level enforcement runs uniformly across every tool Uber's agents can reach, only that it is mandated where that internal classification requires it. The load bearing claim in Uber's material is narrower and more precise than an authorization claim: preserving the full actor chain lets a policy evaluate the personnel identity behind a request and the agent identity acting on it at the same time, rather than one standing in for the other. That is a claim about the context a policy decision can draw on. It is not a claim that the chain itself authorizes anything, and this record does not collapse the two. The policy decision at MCP Gateway is what authorizes or refuses a call. The actor chain is what that decision is allowed to see.

Uber describes its per hop mechanism as conceptually based on OAuth 2.0 Token Exchange, RFC 8693, customized to carry agent identity and provenance in a form suited to its own internal auditing and performance requirements. This record does not describe Uber's mechanism as standard OAuth Token Exchange, because Uber's own account is that it diverges from the standard rather than implementing it unmodified, and does not describe it as a new public standard, because Uber has not published it as one. Uber also states it initially considered an external gateway for agent to agent calls and found that fully closing the attribution gap required support at the agent application layer itself, the layer where execution context is actually created and propagated end to end, which is why the mechanism is built into Uber's own SDK rather than left entirely to a proxy sitting between agents. This record preserves that as an architectural observation about what Uber's own attribution problem required. It is not evidence that an external gateway cannot enforce authority elsewhere, and this record does not read it that way.

What is documented as running today, and what is documented as next

Uber's material, corroborated through this session's search passes, distinguishes what it describes as its current internal architecture and controlled production environments from capabilities it names as a future direction. Identity issuance through the Agent Registry and SPIRE, per hop token minting through the STS, actor chain propagation, and MCP Gateway policy enforcement for systems classified as high risk are each described as part of the deployed architecture. A further, explicitly forward looking direction, described across corroborating secondary sources as risk adaptive access control and a unified policy enforcement plane spanning tools, sessions and protocols, is named as where Uber intends to take the design next, not as something already running. The token format itself is described as extensible, with session identifiers and request intent named as claims a future revision could add. This record does not treat those future claims as present in the tokens Uber describes issuing today.

One limitation is worth preserving exactly because it cuts against the strongest reading of the architecture rather than for it. Corroborating secondary material describes a specific, acknowledged gap in revocation: because each token is a self contained, signed JWT, a service several hops deep into a chain has no built in way to learn that the grant its chain descends from was withdrawn upstream, and revocation in that account reaches no further than the token's own short expiry. A short lived token limits how long an already issued grant can be misused. It is not, by itself, a system for revoking a delegation still inside its own validity window.

The Authority Provenance ledger

Uber's own account, corroborated through this session's search passes because direct access to uber.com is blocked, establishes some of the layers below and leaves others undocumented. This record separates them rather than letting cryptographic identity propagation stand in for proof of legitimate authority.

Authority grantor. The proximate root actor is the human user whose identity opens the chain, recorded in it at the first token exchange. Nothing corroborated to this session shows Uber modeling a separate, formal authority grant object distinct from that user's own identity and context. This record does not infer that the user context passed into the first exchange constitutes a delegated authority grant in its own right, only that it is the identity the chain traces back to.

Mandate or basis. Undocumented. Uber's architecture can establish which employee initiated a request and which agents acted on it. Nothing corroborated to this session, in Uber's own material or in adjacent first party identity documentation, establishes that the initiating employee held the organizational, operational or resource owner authority the resulting action implied, for example that an on call engineer was actually entitled to approve a monitoring threshold change through an agent rather than only to request an investigation of one. Authenticated employee identity is not treated here as evidence of organizational mandate.

Delegated scope. Documented at the transport layer, undocumented beyond it. Each per hop token is scoped to a single destination through its audience claim and carries the actor chain. Tool calls are separately authorized at MCP Gateway. Nothing corroborated to this session shows a current token carrying an action specific scope, a resource scope or a stated intent beyond audience and the chain of identities. Uber's own material describes the token format as extensible enough to carry a session or intent claim in the future, which this record treats as not yet present rather than already carried.

Explicit limits. Documented directly: single hop validity, an audience claim binding a token to its intended destination, a time to live corroborated as being on the order of minutes, and MCP Gateway policy enforcement mandated for systems Uber classifies as high risk. No numeric delegation budget or spending style ceiling is documented anywhere corroborated to this session.

Inherited permissions and assumptions. A raw human credential is not passed downstream. Each agent exchanges what it received for a freshly minted, next hop scoped token through the STS. What is not documented, corroborated to this session, is a rule for how effective permission changes hop to hop: whether it is intersected against each new agent's own access the way GitLab's composite identity documents, attenuated by some other rule, or left entirely to MCP Gateway's tool level policy to decide fresh at each call with no attenuation rule carried in the token itself. This record does not assume the chain shrinks authority monotonically as it grows, because nothing corroborated to this session states that it does.

Revocation or modification. Partially documented, and the documented part is a limitation. Token expiry, on the order of minutes, bounds how long an issued grant can be misused. Corroborating secondary material describes revocation as reaching only the first hop: a self contained JWT several hops downstream has no mechanism to learn that the grant it descends from was withdrawn upstream before its own expiry. This record preserves that as a documented gap rather than treating short lived tokens as a substitute for a working revocation system.

Challenge authority. Undocumented. MCP Gateway deciding, for one specific call, whether policy permits it is a real time authorization decision, not a channel by which a human principal, a resource owner or an administrator can later challenge or invalidate the authority an already running workflow is exercising. Nothing corroborated to this session names such a channel.

Recovery. Undocumented. Nothing corroborated to this session describes a rollback, compensation or reversal mechanism for an action a downstream system already executed under a chain later found to rest on illegitimate mandate. Audit attribution through the actor chain explains what happened and who was involved. It is not, by itself, a recovery mechanism for what already ran.

Provenance evidence quality. Layered, not uniform. Human identity propagation is real: the originating user's identity is carried in the chain from the first exchange. Workload identity is real and cryptographically attested through SPIRE. Agent identity is real where the Agent Registry check runs, closing the specific gap Uber's own material names, that a legitimate workload does not by itself prove which agent is entitled to act from inside it. Actor chain integrity is real as far as the STS being the sole minting authority makes it: each hop is a fresh, attested addition, not a client supplied claim. Per hop token scoping is real and directly documented. Tool authorization at MCP Gateway is real where Uber's internal risk classification mandates it, not established as universal to every tool the architecture can reach. Organizational mandate behind the originating human's authority, challenge authority and recovery are each undocumented by anything corroborated to this session. This record does not collapse those layers into a single claim that Uber's architecture proves authority. It proves that identity and provenance moved through the chain intact. Whether the person at the start of that chain was entitled to set it in motion is a different question, and Uber's material does not answer it.

What this adds to the propagation question

Alipay's launch above asks whether one human's authorization travels intact once several agents, with no shared operator, pass a request between them. Uber's architecture is a different shape: one operator's own internal chain, built and run inside a single company's infrastructure, answering a narrower, adjacent question with production implementation detail that Alipay's public material does not supply. It shows that identity and provenance can be deliberately carried hop by hop, cryptographically attested at each step, rather than left to disappear behind a generic service identity once a request crosses an internal boundary. GitLab's composite identity already shows two identities, a human and a service account, evaluated together inside one product. Uber's actor chain is a related idea carried across an arbitrary number of hops rather than fixed at two, inside one company's own systems rather than across companies the way Alipay's chain runs. x401 and BIND ask a related but distinct question: whether a portable proof of delegation can travel with an agent across systems that share no operator at all. Uber's contribution belongs here, next to Alipay, because both are read against the same question this record opened with, not whether an agent is authorized in isolation, but how far a human's authority is shown to travel once several agents stand between a request and its execution. What Uber adds is production evidence that the answer can be engineered rather than left to chance, and a clear demonstration of the limit of doing so. A system that can cryptographically prove every identity in a chain has not, by itself, proven that the human at the head of that chain was entitled to set it in motion. That is a different claim than authorization propagation solving itself, and it is the more precise one.

A Senate bill names the same distinction, in statutory language

On 21 July 2026, Senator Mark Warner introduced the Artificial Intelligence Access, Gatekeeper Exchange, and Nondiscriminatory Transfer Act of 2026, known as the AI AGENT Act, in the United States Senate as S.5051. It was read twice and referred to the Committee on Commerce, Science, and Transportation, where it remains, with no cosponsor and no further recorded legislative action as of 26 August 2026, reconfirmed on that date. This follows a discussion draft of the same bill Senator Warner released on 29 June 2026 for public and industry comment before formal introduction. Both facts matter for the same reason they mattered for Alipay's launch above: the bill is a proposal working its way through one committee of one chamber. It is introduced legislation, not enacted law, and nothing in it currently binds any platform, provider or user. Congress.gov's own indexed record describes S.5051, in its own short official language, as a bill to promote competition and reduce consumer switching costs in the provision of online services, and for other purposes. That framing matters for what this record does not claim: the custodial user agent provisions read closely below sit inside a broader platform interoperability and competition bill, not a standalone AI agent statute, and this record does not treat S.5051 as though agent delegation were its only subject.

What makes it relevant to this record is not that a senator introduced an AI bill. Most such bills touch this desk's beat only glancingly. This one is different because its central definition writes the same distinction this record has argued since the Uber update directly into statutory language. The bill defines a custodial user agent as a software based agent expressly authorized by a user to interact with a large online platform on that user's behalf in a manner that is transparent, documented, scope limited and revocable, consistently corroborated across multiple independent legal analyses of the bill text. Each end user of a covered large online platform, reported across those same analyses as one crossing a threshold near 50 million United States customers or subscribers, though sources differ slightly on the exact measurement window, would have the right to designate one or more custodial user agents as an authorized representative for online interactions, electronic commerce decisions, user generated content and account settings, on the same terms as a user. Covered platforms would have to maintain an interoperable, nondiscriminatory interface letting an authorized agent act through it, and providers of custodial user agents would have to register with the Federal Trade Commission, which the bill directs to develop or certify security and identity standards, before accessing that interface.

What the bill requires directly, and what it hands to future rulemaking

This desk could not read the introduced bill text directly. Congress.gov, GovInfo, GovTrack and Senator Warner's own site are each blocked to this session's fetch tooling, and what follows is drawn from repeated, independently phrased searches that returned consistent detail across Congress.gov's own indexed bill status page, Senator Warner's own section by section summary of the bill, and several independent legal and trade analyses of the introduced text (DLA Piper, Davis Wright Tremaine, CyberScoop, Biometric Update, CIO, Paubox). An editor with unblocked access should read the bill directly before treating any claim below as settled beyond what is stated here.

With that limitation stated plainly, several provisions are corroborated closely enough, in near identical language across independent sources, to state with reasonable confidence, and this desk's 26 August 2026 reverification pass narrows a few of them further. First, redelegation: the bill is consistently described as barring a custodial user agent or its provider from delegating, assigning or transferring a user's granted authority to another company, agent or AI system operated by another entity, without the user's express, specific and revocable authorization for that further delegation. That wording is specific about the trigger: it is transfer to another entity's agent or system that the bill conditions on a fresh grant, and this record found no corroborated statement of an equivalent statutory bar on a provider routing a task to its own sub-agents internally. Sources also corroborate, closely and consistently enough to state directly, that a permitted downstream delegate remains subject to the same duties the bill establishes for a custodial user agent, to the same extent as the custodial user agent itself. Read together, that is the same principle this record's Authority Provenance ledger named after the Uber update, that authority to act is not automatically authority to delegate that authority onward, now appearing as a proposed legal requirement with its own downstream compliance obligation attached, rather than only as an architectural choice a company happened to make. Second, revocation on the user's side: providers are consistently described as required to give users a transparent, readily usable way to clearly grant or revoke an agent's permission to act on their behalf, and to promptly communicate a revocation to the relevant large online platform. Revocation on the platform's side is a separate, corroborated provision: a large online platform may restrict or deny a custodial user agent's access on its own authority where the agent's provider has not met registration requirements, where a user's consent has been revoked, or where the agent is associated with a pattern of harmful activity. This record keeps those two revocation paths, a user revoking their own delegation and a platform revoking or denying an agent's access, distinct rather than treating either as a stand in for the other. Third, records: providers are consistently described as required to keep real time records of the actions taken for a user and make them available to the user on request, subject to the bill's own deletion exception, which this record found named but not detailed in the sources available to it. None of the sources available to this record quote the bill specifying exactly how immediate a user's revocation must take effect, whether it must propagate to any authority already redelegated downstream, or exactly what a compliant action record must contain beyond the action itself. Those are the harder technical questions, and the bill's own approach, as corroborated here, is to direct the National Institute of Standards and Technology to identify open protocols, or develop and publish technical standards where no adequate protocol already exists, for four specific capabilities: scope limited and revocable delegation credentials, verification of a custodial user agent's identity and registration status, real time communication and effectuation of revocation, and auditable records of the actions an agent takes on a user's behalf. NIST is named across corroborating sources as free to consult existing work from bodies including the Internet Engineering Task Force, the Internet Identity Workshop and IEEE rather than starting from nothing. That is a rulemaking and standards development mandate aimed at a future NIST process, not a technical requirement already in force, and this record does not treat it as one, nor does it treat NIST's own separate, already announced AI Agent Standards Initiative as the fulfillment of this specific statutory directive, since nothing corroborated to this record ties that initiative to S.5051 by name.

One further provision is corroborated on the platform and provider side rather than the user side: the Federal Trade Commission is described as able to set uniform registration terms built on a provider's own self attestation, with the Commission or a recognized independent certification body then evaluating that submission within 180 days, and certification by a recognized body creating a rebuttable presumption, not a conclusive proof, that a provider is meeting the bill's duties. The Commission is separately corroborated as able to set more specialized terms for custodial user agents operating in particular commercial settings, weighing privacy, financial security and personal safety implications of the delegated access involved. Both are proposed rulemaking authority a future FTC would exercise if the bill becomes law. Neither is a standard the Commission has already set, and this record does not describe either as currently operative.

The Authority Provenance ledger, for S.5051

Read as a proposed framework rather than as deployed infrastructure, S.5051 sits differently on this record's ledger than Alipay's product or Uber's architecture do, because a bill's obligations are legal commitments a regulator could eventually enforce, not a system a user's request is already flowing through.

Authority grantor. The end user of the large online platform, on the bill's own framework as corroborated here: the individual designates the custodial user agent. Nothing corroborated to this session addresses a user acting on a shared, employer owned or otherwise organizational account, so whether that user's designation is treated as sufficient authority over resources belonging to another principal is undocumented in the material available to this record.

Mandate or basis. The bill's own custodial user agent definition, as corroborated, requires the grant itself to be transparent and documented. It does not, on the material available here, specify the evidentiary form that documentation must take, an activity log, a signed record or something else, leaving that to the NIST directed standards process described above.

Delegated scope. Documented at a functional, domain level: online interactions, electronic commerce decisions, user generated content and account settings on a given platform, described as on the same terms as a user. Nothing corroborated to this session shows a finer, action level scope, a per merchant limit, a spending ceiling or a time bound authorization, as a requirement the statute itself defines, distinct from whatever a platform or provider chooses to build. A further, corroborated but not yet exercised dimension sits with the FTC rather than in the statute's own domain list: the Commission is described as able to set more specialized scope terms for custodial user agents operating in particular commercial settings, weighing privacy, financial security and personal safety implications. That is proposed rulemaking authority to narrow or specify scope further in specific settings, not a scope boundary the statute itself already draws, and this record does not treat it as one.

Explicit limits. Documented directly, and it remains the bill's clearest contribution: the custodial user agent definition itself requires the grant to be transparent, documented, scope limited and revocable. That four part requirement is the same set of properties this record has tracked as the core of legitimate delegated authority since the Uber update, now proposed as a statutory definition rather than observed as one company's engineering choice. A fifth, separately corroborated limit sits specifically on redelegation rather than on the initial grant: a custodial user agent or its provider may not delegate, assign or transfer the user's granted authority to another company, agent or AI system operated by another entity without the user's express, specific and revocable authorization for that further delegation, and any delegate a user does authorize this way remains bound by the same duties as the custodial user agent itself. This record treats that as a distinct, second authorization event layered on top of the initial delegation, not as an automatic extension of it, and notes that the corroborated wording conditions the requirement on transfer to another entity, not on a provider's own internal use of multiple agents.

Inherited permissions and assumptions. Documented as a ceiling, undocumented as a floor. The bill's own repeated framing, that a custodial user agent acts on the same terms as a user, reads on the material available here as an access ceiling: an agent is not described anywhere corroborated to this record as reaching more of a platform than the user who designated it could reach directly. This record treats same terms as a user as establishing that ceiling rather than as a separate, stronger grant of platform access in its own right, and it does not read the ceiling language as guaranteeing the agent everything the user could reach either, since whether an agent can exercise the full extent of what a human session could do, or only a platform defined operational subset of it, through the required interoperable interface is left, on the material available here, to platform and FTC implementation rather than settled in the bill's own text.

Revocation or modification. Documented on two distinct paths, each still partial. On the user's side, providers are consistently described as required to give users a transparent, readily usable way to clearly revoke a prior delegation and to promptly communicate that revocation to the relevant large online platform. On the platform's side, a large online platform is separately corroborated as able to restrict or deny a custodial user agent's access where its provider has not met registration requirements, where a user's own consent has been revoked, or where the agent is associated with a pattern of harmful activity, an institutional check distinct from the user's own act of revoking. Neither path, on the material available to this record, specifies how immediately a revocation must take effect, whether a provider must stop honoring credentials already issued under a revoked grant, or what becomes of a request already in flight or an action already completed at the moment revocation is communicated. The NIST directed standards process described above is aimed at exactly the real time communication and effectuation gap this paragraph leaves open, which is why this record treats that gap as a subject for a future technical standard rather than as a defect in the statute's own drafting. This record also does not infer that revoking a user's initial delegation automatically terminates authority already redelegated downstream to another entity, since nothing corroborated to this session states a cascading rule, though a downstream delegate does remain bound, corroborated above, by the same duties as the custodial user agent it received authority from for as long as that redelegated authority stands.

Challenge authority. Documented at the provider level, in more procedural detail than previously stated here, and still undocumented at the level of a single disputed action. Federal Trade Commission registration, built on a provider's self attestation and evaluated by the Commission or a recognized independent certification body within 180 days, with certification creating a rebuttable presumption of compliance and deregistration described as a consequence of violations, is a real enforcement channel against a provider's ongoing standing, and a rebuttable presumption is, by its own nature, capable of being challenged rather than treated as conclusive. Nothing corroborated to this session describes a distinct mechanism by which a user or a downstream party can dispute, after the fact, whether one already executed action fell inside one specific task's authorization, separate from a provider's registration being challenged or an agent losing its access going forward.

Recovery. Undocumented. Nothing corroborated to this session describes a mechanism for reversing a purchase, transfer, account change or content change a custodial user agent already completed under a mandate later found invalid or exceeded. Recordkeeping and FTC enforcement explain what happened and can end a provider's registration. Neither reverses an action that already ran.

Provenance evidence quality. Real at the level of legal attention and largely unbuilt at the level of technical proof, and this desk's 26 August 2026 reverification pass changes that assessment only by making it more precise, not by revising it. The bill's own definition treats delegated authority as something that must be attributable to a specific user, bounded in scope, documented and revocable, that redelegation to another entity is its own distinct authorization event carrying the original duties forward, and that a platform, not only a user, has a corroborated basis to cut off an agent's access, which is a genuine advance in naming the problem precisely at the statutory level, more precisely stated here than in this record's first pass at it. What it does not yet supply, on everything corroborated to this session, is a specified mechanism by which a platform, a merchant or a payment processor, none of which necessarily shares an operator with the custodial user agent provider, could independently verify that one already executed action was inside that documented grant, or a settled answer for what happens to a credential already issued, or a request already in flight, at the instant a revocation is communicated. That is exactly the gap the bill hands to a future NIST standards process, and exactly the gap the next section takes up from the consumer's side rather than the statute's.

The same gap, without a bill or a multi agent chain

Alipay's chain above involves a phone assistant, a super agent and merchant agents. Uber's architecture involves an on call engineer, an investigation agent and a monitoring agent. Both are elaborate. Aashis Luitel's analysis, published in The Conversation on 13 August 2026 and reported to have been republished by Fortune on 24 August 2026, makes the same underlying point without either kind of complexity, using one user, one agent and one purchase.

The scenario Luitel uses is illustrative, not a reported incident, and this record treats it that way: a user tells an agent to find a shirt under 30 dollars but not to buy it, and the agent buys it anyway. What happens next is the part worth reading closely. The agent provider retains the task instruction it received. The merchant retains the resulting order. The payment provider retains the resulting charge. Each of those three records can be entirely accurate on its own terms and still fail, together, to answer the only question that matters afterward: did the user authorize this specific action as part of this specific task. The retailer may recognize the agent provider without identifying which specific agent acted. The payment service may label the same underlying customer differently than the merchant does. None of that is a data quality failure inside any one system. It is a binding failure across three systems that were never designed to agree on a shared reference for the same event.

Luitel draws a related distinction worth preserving precisely, because it generalizes past this one scenario. A standing authorization, the kind an OAuth style connection grants once when a user first links an agent to an account, can remain technically valid at the exact moment an agent takes an action that exceeds what the user's current, narrower task actually asked for. Credential validity is not evidence that this particular action belonged to the current delegated mandate. That is the same standing access versus task specific authority distinction this record has kept separate throughout, applied here to the single most common case in consumer agent products: an agent that is allowed to act, in general, taking an action nobody currently authorized, in particular.

Luitel proposes, as his own suggestion for a stronger system rather than as a description of what any law or protocol currently requires, that an agent provider bind the user's account, the agent and the task into a single record before execution, convert the user's original request into limits other systems can check, and that every party in the chain keep a tamper evident record so a later dispute has something firmer than three separately truthful logs to reconcile. This record represents that proposal as exactly that: an analyst's proposed architecture. Nothing in the AI AGENT Act, the NIST concept paper or AP2's published material independently requires verifiable cross system binding of this kind today, and this record does not attribute the requirement to any of them.

Where AP2 and NIST already sit, and where neither reaches

Moona Intelligence has already verified Google's Agent Payments Protocol directly against its own primary material, in the record covering Robinhood's agentic trading launch: a purchase is represented as a chain of signed Mandates, an Intent Mandate describing what the user wants, a Cart Mandate the merchant assembles and signs, and a Payment Mandate authorizing a specific charge, each a cryptographically signed object rather than a plain log entry. That chain is one existing technical shape of the cross system binding Luitel calls for, built and available today for participants who adopt it. It is not evidence that the binding problem is solved generally. AP2 only binds the systems that implement it, and Luitel's scenario, an ordinary agent, an ordinary merchant and an ordinary payment processor connected through whatever each already runs, is precisely the case where nothing requires any of the three to have adopted AP2, or any comparable protocol, at all. This record does not describe AP2 as defining a distinct task reference primitive beyond the mandate chain itself, because nothing corroborated to either this record or the Robinhood record establishes one.

Moona Intelligence has also verified NIST's own concept paper on software and AI agent identity and authorization directly, and one detail from that record bears directly on the gap S.5051 hands to NIST above: the concept paper's own initial scope, as verified there, is enterprise agents an organization already controls and can observe, with external agents from untrusted sources explicitly placed outside that initial effort. A consumer's custodial user agent reaching a merchant's systems and a payment provider's systems, none of which share an operator with the agent provider or with each other, is closer to the external, cross organization case that paper's own stated scope does not yet cover than to the internal enterprise case it does. That is not a criticism of NIST's project. It is a precise statement of why directing NIST toward this exact problem, as S.5051 is corroborated to do, would be asking that initial project to grow into ground it has not yet stood on, not asking it to apply work it has already scoped to cover.

China's payments industry writes its own authorization boundary

On 24 August 2026 the Payment & Clearing Association of China (中国支付清算协会) issued 《智能体支付应用自律公约》, the Self-Regulatory Convention on Agent Payment Applications, developed under People's Bank of China guidance. That status is the first thing to get exactly right, because it is easy to round up into something stronger than it is. This is an industry self-regulatory convention. It is not a statute, not an administrative regulation, not a PBOC regulation and not a national mandatory technical standard. Moona Intelligence's preferred language for what it actually is, is this: China's payments industry has adopted an active self-regulatory convention under PBOC guidance. On the Convention's own reported scope, it applies to Association member institutions that provide account management, transaction processing, acquiring or switching and clearing services in agent payment applications, not to every payment provider operating in China and not to every AI agent that happens to touch money. This session could not read the Association's own primary text or the reproduced full-text copy indexed at mpaypass.com.cn directly; both destinations were blocked by this session's network egress tooling. What follows is drawn from repeated, independently phrased searches that converged on consistent Chinese-language detail across a search-indexed Xinhua report and multiple independent Chinese financial and technology outlets, and it is narrowed everywhere that convergence ran out.

The Convention's own definition of an agent payment application is worth quoting in substance because it is itself Agent Authority evidence: a member institution's use of large-model or AI agent technology, under user authorization and according to the user's genuine intent, to have an agent interact with e-commerce or other digital services and initiate or execute payment instructions. Read that definition closely and two words matter more than the rest. User authorization and the user's genuine intent are named as two separate preconditions of a legitimate agent payment, not folded into one general requirement that a user be involved somehow. This record has kept authentication, agent identity, authorization and intent apart as four different questions since its own first version, and the Convention's own definition draws exactly that line between authorization and intent without this record having to argue for it.

An authorization boundary, a KYA direction, and a scope-attenuating limit

Reported provisions ask a member institution to clarify the authorization boundary of its agent payment application, to sign an authorization agreement with the user that clearly allocates responsibility, and to strengthen verification of the user's transaction intent, alongside protecting the user's right to revoke authorization. That is four distinct mechanisms, not one: a defined boundary, a signed agreement, an intent check, and a revocation right, and collapsing them into a single phrase like "requires authorization" would lose exactly what this record has argued matters since Alipay's own launch, that these mechanisms answer different questions and fail in different ways.

On agent management, the Convention is reported to ask member institutions to explore establishing, on top of Know Your Customer, a "Know Your Agent," or KYA, mechanism (在"了解你的客户（KYC）"基础上进一步探索建立"了解你的智能体（KYA）"机制). The verb matters. This is an exploratory direction, not a specification of a credential format, a certificate type or an interoperable identity protocol, and nothing corroborated to this session describes KYA as a defined technical standard any member institution must implement in one particular way. What KYA names, at the policy level, is a requirement direction: identify and verify the agent acting, and establish, through an agreement or a registered correspondence, which user that agent is actually acting for. This record does not invent a formal KYA protocol where the Convention itself, on the evidence available here, specifies a policy direction instead.

On standing authority, the Convention is reported to require member institutions to build a graded, tiered management mechanism and strengthen fund-safety management including through transaction limits, aimed at preventing excess withdrawals and unauthorized transfers of a user's funds, with more cautious risk warnings, permission controls and transaction protections called for specifically where the user is elderly or a minor. That is a scope-attenuating control on standing authority, the same category this record has tracked in Rain's scoped cards and in S.5051's own custodial user agent definition, not a general AI-safety measure, and this record does not invent specific limit values, thresholds or merchant-category rules the material available here does not state.

A rule that names the result, not the mechanism

The reported provision on execution discipline is the sharpest sentence in the material available to this record, and it deserves the same care given to S.5051's own definition above: member institutions must execute payment instructions according to the user's authorization, strictly prevent unauthorized or over-authority payments (越权支付), and ensure the integrity, authenticity and traceability of the payment. Read against the three-part distinction this record has kept throughout, authentication of who the user is, agent identity of which software is acting, and authorization of what the agent may do, that sentence sits squarely in the third category. It specifies a required result: an executed instruction must stay inside what the user authorized. It does not, on anything corroborated to this session, specify how that boundary must be mechanically enforced, at what layer, or through what runtime architecture. This record treats it exactly the way it treated AgentCore payments' own scope controls and Rain's own scoped cards elsewhere in this desk's coverage: a rule that names the required outcome, leaving the engineering of it to the institution.

Revocation is reported on two separate provisions rather than one, and this record keeps them apart the way it kept S.5051's two revocation paths apart above. One protects the user's underlying right to revoke a granted authorization. A second, distinct provision requires member institutions to provide convenient channels for disabling an agent payment application and for querying related information. Neither reported provision, on the material available here, states how quickly a revocation must propagate, whether it reaches a payment instruction already issued, whether an in-flight transaction is halted, or whether authority already redelegated to a downstream agent or service is recursively withdrawn. This record leaves each of those as unknown rather than assuming an answer in either direction, the same discipline it applied to Uber's own documented revocation gap and to S.5051's own silence on real-time effectuation.

Trusted evidence across four stages, and the verb that bounds the claim

The most significant reported provision for this record's own Authority Provenance thesis asks member institutions to explore establishing a trusted evidence mechanism at key stages of a transaction, reported as covering user authorization, model decision, payment instruction and risk control, producing an evidence chain that is verifiable, traceable and tamper-resistant, and that can support later dispute resolution and responsibility determination. That is a direct, four-stage articulation of exactly the lineage this record's own ledger methodology has been reconstructing piecemeal from Alipay's product pages, Uber's actor chain and S.5051's recordkeeping language: authorization, a model's decision, the resulting instruction, and a risk check, held apart as separate evidentiary events rather than compressed into one audit log entry.

Model decision sitting inside that evidence chain is worth one further sentence of care. Its presence as a named stage is evidence that the Convention treats a model's decision as a distinct event worth preserving proof of, alongside the authorization that preceded it and the instruction that followed it. It is not, on anything corroborated to this session, a claim that the model's decision itself constitutes authority, and this record does not read it that way. Authorization is what a user granted. A model's decision is what the agent's reasoning produced inside that grant. A payment instruction is what was executed. A risk decision is a separate check applied to it. Keeping those four events distinct, rather than letting a model's decision stand in for a user's authorization, is the same discipline this record applied when it separated Uber's actor chain, which proves identity moved through a chain intact, from proof that the identity at the head of that chain held legitimate authority to set it moving.

Separately, reported provisions describe risk monitoring aimed at prompt or injection attacks, tampering with a transaction instruction, over-authority interaction, suspicious transactions and execution anomalies. This record connects that monitoring requirement only to the authorization and payment-execution lifecycle it is reported to cover, not to a general claim about AI security, consistent with how this record has treated adjacent monitoring requirements throughout.

Reporting before autonomous launch, and what rollback is not

For an agent payment application where the agent autonomously initiates the payment, without a person confirming that specific transaction, the Convention is reported to require a member institution to report the application to the Association before public launch and to complete business-effectiveness, technical-safety and ethical-conformance assessment, alongside supporting measures including human service, risk monitoring, public-sentiment monitoring, emergency response and a rollback mechanism (回退机制). This record does not describe that reporting process as regulatory licensing, because nothing corroborated to this session states that the Association's role here is a licensing gate rather than an industry self-regulatory filing and review step, and it does not read 回退机制 as a guarantee that a settled financial transfer can be reversed. The more precise reading, consistent with how this record has treated Rain's own emergency and recovery language, is an operational fallback or recovery capability for the deployment itself, kept separate from settlement reversibility, which nothing corroborated to this session establishes.

The significance of a reported reporting requirement specifically for autonomous initiation is what it implies about human confirmation. Chinese industry discussion around the Convention describes agent payment maturing across stages, from agent-assisted payment requiring a user's per-transaction confirmation, to autonomous payment executed within conditions a user preset in advance, to autonomous payment under broader, less narrowly preset conditions. This record attributes that staged description to industry and expert commentary surrounding the Convention, including discussion at the industry forum where Vice Governor Lu Lei spoke, not to the Convention's own text, because this session could not confirm the taxonomy appears in the Convention itself. What the reporting requirement for autonomous launch does establish, independent of that taxonomy, is that the Convention itself contemplates payments an agent initiates without a human confirming each one. Human confirmation is not a precondition of every agent payment under this framework. It is exactly where that precondition disappears that an authorization boundary, a transaction limit, a revocation right and a trusted evidence chain stop being nice-to-haves and start being the entire basis for later showing a payment was legitimate.

Responsibility is reported to rest on a stated principle, whoever provides the payment service is responsible for it (谁提供支付服务谁负责), with core payment activity, account management, transaction processing and clearing or settlement among it, reported as carried out by licensed institutions. Read against everything above, that principle is the reason the rest of the Convention reads as coherent rather than contradictory: an agent may be permitted to decide and to execute autonomously, but the institution behind it, not the model, remains the party a user, a counterparty or the Association can hold to account. This record does not turn that principle into a general legal-liability conclusion beyond the Convention's own stated scope.

Central-bank reinforcement, not a new regulation

On 27 August 2026, PBOC Vice Governor Lu Lei spoke at the 15th China Payment and Clearing Forum. Reported coverage of his remarks describes him calling on market participants to actively implement the Convention, to strengthen consumer protection, and to strengthen risk prevention. This record does not read that speech as a new rule. Lu Lei did not, on anything corroborated to this session, announce a mandated technical protocol or issue a PBOC regulation from the podium. What the speech establishes is public central-bank reinforcement of an industry framework the Payment & Clearing Association of China had already issued three days earlier under the same institution's guidance, the difference between a regulator endorsing a standard the industry set for itself and a regulator setting one itself.

The Authority Provenance ledger, for the Convention

Read as reported industry policy rather than as a deployed technical system, the Convention sits on this record's ledger closer to S.5051 than to Uber's own architecture: a stated framework of obligations, not yet demonstrated as engineered into any specific member institution's runtime.

Authority grantor. The immediate grantor is the user, on the Convention's own definition of an agent payment application as acting under user authorization and according to the user's genuine intent. Nothing corroborated to this session addresses an enterprise, corporate-treasury or employee-user scenario, so whether an authenticated user was organizationally entitled to delegate a company's funds through an agent payment application is undocumented here, the same gap this record left open for S.5051's own user-designation model above.

Mandate or basis. The Convention's own definition requires that a payment reflect the user's genuine intent, reported as a distinct check from authorization itself, stronger than mere account authentication. Nothing corroborated to this session describes a structured, machine-readable format for that intent, a natural-language mandate standard, or a purpose-binding schema the Convention itself defines; this record does not invent one where the material available states a requirement without a specified form.

Delegated scope. Documented as a named concept, the authorization boundary, and as a required deliverable, a signed authorization agreement allocating responsibility, but undocumented as an enumerated set of dimensions. Nothing corroborated to this session shows the Convention itself specifying that a boundary must include amount, recipient, merchant, service, time window, transaction type or agent identity as discrete, required fields, the way S.5051's own domain list or Rain's own scoped-card parameters are each documented elsewhere in this record. This record does not construct a machine-readable scope schema the Convention does not itself specify.

Explicit limits. Documented at the policy level: transaction limits aimed at preventing excess withdrawals and unauthorized transfers, with more cautious controls called for specifically where a user is elderly or a minor. No numeric threshold, merchant-category restriction or time-window value is corroborated to this session, and this record does not invent one. The elderly and minor protections are recorded here as consumer-protection controls layered onto the same standing-authority attenuation, not generalized into a separate Agent Authority primitive beyond what they actually change.

Inherited permissions and assumptions. The Convention's own definition and its authorization-boundary requirement together undermine, rather than assume, any inference that holding a payment account gives an agent payment application unrestricted spending authority. An agent payment application is required to stay inside user authorization and verified transaction intent, the same discipline this record found in S.5051's "same terms as a user" ceiling and in Rain's own scoped-card design: standing account access is not, on this framework, standing agent authority.

Revocation or modification. Documented on two separate paths. A user's underlying right to revoke authorization is protected as a matter of policy. A separate, required channel lets a user conveniently disable an agent payment application and query related information. Neither reported provision, on the material available here, specifies how immediately a revocation takes effect, whether it reaches a payment instruction already issued, whether an in-flight transaction is halted, or whether authority already redelegated to a downstream agent or service provider is recursively withdrawn. This record leaves each of those open rather than assuming a technical revocation-finality guarantee the Convention's own reported text does not state, the same treatment this record gave Uber's documented revocation gap and S.5051's own silence on real-time effectuation.

Challenge authority. The Convention does not, on anything corroborated to this session, require a human to confirm every individual agent payment; it explicitly contemplates autonomous initiation and conditions it on a pre-launch reporting and assessment process instead. Human intervention, on this framework, belongs at authorization establishment, at the pre-launch assessment for autonomous deployment, at the required human-service channel, and wherever a specific provider's own policy places it, not as a universal per-transaction gate this record should manufacture where the Convention does not impose one.

Challenge integrity. Undocumented. Nothing corroborated to this session describes an action-bound approval token, a nonce, an expiry, single-use enforcement or replay resistance as a technical mechanism the Convention itself defines. This record keeps those unknown rather than borrowing PACE's or AP2's own cryptographic vocabulary, verified elsewhere in this desk's coverage, and attributing it to a document that does not itself specify a mechanism at that level.

Recovery. Documented as an operational requirement for autonomous-payment deployment, an emergency-response and rollback mechanism among the assessments and safeguards a member institution must have in place before public launch, and undocumented as a guarantee of settlement reversal. This record reads 回退机制 as operational fallback and recovery for the deployment, not as evidence that a settled financial transfer can be undone, the same separation it has kept between recovery mechanisms and guaranteed reversal throughout its coverage of AgentCore payments, Rain and Uber.

Provenance evidence quality. High for policy recognition: the Convention's own definition, its authorization-boundary requirement, its KYA direction and its four-stage trusted-evidence provision together name a user-to-agent-to-authorization-to-payment-decision lineage as the thing that should be provable, explicitly holding a model's decision apart as its own evidentiary stage rather than folding it into the instruction it produced. That is a genuine advance in naming the problem precisely, at the level of an industry-wide convention rather than one company's product. What remains unknown, on everything corroborated to this session, is whether any member institution has actually built the cross-stage evidence chain the Convention only asks its members to explore, whether such a chain, once built, would be interoperable and independently verifiable across more than one participant in a transaction, and whether the user at the head of an authorization was themselves entitled to grant it, the same ultimate-legitimacy gap this record has left open for Alipay, Uber and S.5051 alike.

What this adds to the propagation question

Alipay's own product documentation already gestured at several of these mechanisms, agent identity authentication, user authorization, intent verification, trusted evidence recording, liability determination, without a shared industry requirement compelling every other Chinese payment provider to build the same six things the same way. The Convention is the difference between one company's own product choices and an industry's own governing rule: it takes the authorization boundary, the KYA direction, the revocation right and the trusted evidence chain this record already found described in Alipay's own material, and states them as an expectation for every Association member institution running an agent payment application, not one company's competitive feature. Read next to the execution-layer evidence this desk verified in AWS and Solv Labs' governed payments workflow and next to the Agentic Payments Alliance's own admission that agent payment authorization remains an open, unsolved coordination problem among the companies that would have to answer it, the Convention is a fifth kind of artifact this record has now gathered evidence on: not a technical implementation, not a coalition of competitors still deciding what to build, but a national industry's own self-regulatory rule stating, in advance of any one company's engineering choices, what an authorization boundary, a revocation right and a cross-stage evidence chain are expected to look like. It does not, on the evidence available to this record, close the gap between that expectation and a deployed, interoperable, independently verifiable system. It is the clearest evidence yet that more than one country's payments industry now treats that gap as something to be governed, not merely engineered.

Five developments, one distinction

Alipay's chain, Uber's actor chain architecture, a proposed statute, a consumer scale analysis, and now an industry-wide self-regulatory convention from China's own payments industry, are five separate artifacts answering to the same underlying claim this record has made since its first version. A connection between systems is not authority. A record of an event is not proof that the event was authorized. And authority to act, however well documented at its origin, is not automatically authority to hand onward to another agent, another provider or another system, without a fresh, explicit decision that only the original principal, or someone the principal has actually entitled to decide, can make. Alipay showed the propagation question at commercial scale. Uber showed that identity, at least, can be engineered to survive the trip. S.5051 shows a legislature naming the same requirement, attributable, limited, documented, revocable, as a definition rather than an implementation. Luitel shows that even without any of that complexity, an ordinary purchase already exposes the same gap between what a record proves and what a record is assumed to prove. The Payment & Clearing Association of China's Convention shows an entire national industry, under central-bank guidance, naming an authorization boundary, a Know Your Agent direction and a cross-stage evidence chain as the expected shape of a legitimate agent payment, before any one member institution's implementation of it can be checked. None of the five, read on its own primary terms, closes the gap between naming the requirement and proving it was met. Together they are the clearest evidence this record has gathered that the market, the standards bodies, a legislature and now a national payments industry have converged on naming it precisely, which is a different and earlier thing than any of them having solved it.