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.

India's own payments regulator, reported to be building the same thing

On 1 September 2026, Reuters reported, citing three sources familiar with the matter who spoke on condition of anonymity, that India is preparing a framework that would let AI agents make certain low value digital payments on UPI, the Unified Payments Interface, without a fresh human approval for every transaction. Reuters names the framework a Unified Agent Protocol, UAP, and reports it is being prepared at the National Payments Corporation of India, NPCI, the institution that operates UPI. Reuters reports UAP is likely to be unveiled at the Global Fintech Fest, scheduled for 8 to 11 September 2026 at the Jio World Centre in Mumbai, and its own sources describe a rollout on UPI as capable of putting India among the first countries with a national payments infrastructure built for agentic payments, while noting that individual payment companies have already launched comparable frameworks of their own in the United States, Europe, Singapore and Australia. That comparison matters for how this record reads UAP: what would be new here is not agent initiated payment as a category, which Moona Intelligence has already covered in AWS and Solv Labs' governed payments workflow, in Rain's scoped cards and in Alipay's own agent payment products above, but a national fast payment rail's own operator building the authorization layer for it, at the scale UPI already processes for human initiated payments.

What Reuters reports next is the one fact this record treats as more consequential than anything else in its own reporting: NPCI did not confirm the story. Reuters states plainly that NPCI did not immediately respond to its request for comment. This record follows the same discipline as it has applied since its first version, expressed in the Alipay section above: what a company or an institution says, what independent reporting says, and what Moona Intelligence interprets are three different things, and this record does not blur them. Reuters reports what three unnamed sources described to it. NPCI has not confirmed any part of it. Everything that follows in this section is written in that register, using is preparing, is expected and reported architecture rather than NPCI launched, NPCI announced or UPI now allows, because nothing corroborated to this record supports the stronger language.

This is also not the first report of the underlying development. Business Standard reported in July 2026, across two pieces published 8 and 9 July 2026, citing four people aware of the development who also spoke on condition of anonymity, that NPCI was developing a Unified Agent Protocol intended to provide common, trusted infrastructure through which AI agents could be registered, verified and authorized to transact across UPI, without changing UPI's own underlying rails, and reported that UAP would act as a verification layer sitting on top of the existing system. Business Standard's July reporting already named UPI Circle and Reserve Pay as the mechanisms UAP was expected to build on, and reported that major digital payments companies in India had told it they had decided against building a rival protocol of their own, choosing instead to work with the one NPCI was already developing. This record treats Reuters' 1 September 2026 reporting and Business Standard's July 2026 reporting, together with the syndicated and locally rewritten coverage of both that this session's searches surfaced across outlets including Business Recorder, Inc42, Outlook Business, MediaNama and others, as evidence of one underlying NPCI development observed at two points in its maturity, not as two independent developments, exactly as this record already treats the many outlets that covered Alipay's 17 August 2026 launch and China's Payment & Clearing Association's Convention as one underlying artifact each rather than as separately weighted evidence.

On 10 September 2026, NPCI's own chairman confirmed the direction on the record

This record's 1 September 2026 update stated plainly that NPCI had not confirmed Reuters' reporting, that NPCI did not immediately respond to Reuters' request for comment, and that this desk would not describe UAP as launched, announced or specified by NPCI. That source state has since changed, and this update records the change rather than leaving the earlier register standing as the current one. On 10 September 2026, the Economic Times reported, and this desk read directly this session, that Ajay Kumar Choudhary, non-executive chairman and independent director of NPCI, said at the Global Fintech Fest 2026 that NPCI is examining the protocols that may be required to identify and authorise digital agents within the UPI ecosystem while preserving interoperability, auditability and settlement finality. This is an on-record NPCI leadership confirmation of the direction Reuters' three unnamed sources described, and this record reads it as a strengthening of that earlier sources-say reporting rather than as a new or separate development. It does not, however, upgrade what remains unknown to the same degree it upgrades what is now confirmed.

What the chairman said is specific, and this record quotes it as the Economic Times quotes him. NPCI is examining protocols to identify and authorise digital agents within UPI, and is doing so while preserving interoperability, auditability and settlement finality. What the chairman did not say is equally important, and this record keeps each gap explicit. Choudhary did not use the name Unified Agent Protocol, which remains Reuters' and Business Standard's name for the development rather than NPCI's own confirmed term. He framed the work as examining the protocols that may be required, not as a protocol that has been specified, finalised, approved or launched. He did not describe the protocol's authorization binding, whether to a human grant, an agent identity, a device, a transaction amount or a session; did not describe revocation, its propagation, or its handling of an in-flight instruction; did not name the Reserve Bank of India's role or any regulatory approval status; and did not give a launch date or a deployment scope. Each of these remains UNKNOWN, the same posture this record held on 1 September 2026, and a chairman's on-record confirmation of the direction does not by itself settle any of them.

This update narrows one claim this record itself made on 1 September 2026. That update described NPCI's non-confirmation to Reuters as the current, publication-critical source state. As of 10 September 2026 that is no longer the full source state: NPCI's own chairman has now confirmed, on the record and on the same Mumbai stage Reuters itself predicted the unveiling would fall within, that NPCI is examining exactly the kind of protocol Reuters reported it was preparing. This record states that narrowing plainly, in the same register it has used for its own prior corrections on the 2 September 2026 OC 201-B pass, rather than folding it quietly into the existing text. It does not describe UAP as launched, specified, regulatorily approved or deployed, because nothing corroborated to this session, including the chairman's own remarks, supports that stronger language. It also does not claim the chairman confirmed any particular mechanism, scope figure, rail binding or liability allocation, because he did not. What changed is the standing of the development itself: an India national payments rail operator's own leadership has now put its name to the direction this record previously carried only on the strength of unnamed sourcing, with every UAP-specific mechanic the sources described still unconfirmed by NPCI and still kept here as unknown rather than inferred.

Added 12 September 2026, from the same already-captured article, re-read after an Agentic Web Discovery candidate pointed at its AMP mirror: Choudhary went further than confirming that NPCI is examining an authorisation protocol, and stated a specific separation of decisions that architecture would need to enforce. "An agent may interpret intent, but authoriser must verify identity, must verify mandate, must verify limits, and consent," Choudhary said, adding that the architecture should therefore separate intent, authorisation and settlement: an AI system may interpret what a user wants and how to execute it, while the final settlement layer stays rule-based, secure and legally final. This record reads that quote precisely rather than reading more into it than it states. It confirms that NPCI's own chairman treats an agent's interpretation of intent and an authoriser's verification of identity, mandate, limits and consent as distinct decisions, not one collapsing into the other, the same distinction this record's own Authority Provenance methodology has applied to Alipay, Uber, S.5051, China's Convention and MCP's session removal alike. It does not state what a mandate object's own machine-readable form is, what a mandate, a limit or an act of consent is bound to (a session, a device, a specific transaction amount, an expiry window), how a mutation to an already-granted mandate would be revalidated, or what happens on a verification failure at any of those four checks. Each remains exactly as UNKNOWN as this record's 10 September 2026 pass already stated; a chairman naming the checks an authoriser must perform is not the same fact as specifying how those checks bind to an executed transaction, and this record does not treat naming the requirement as satisfying it.

A registry of agents is an identity artifact, not a transaction authority artifact

On the same day, 10 September 2026, Reuters published a second report on the same NPCI development, this one read in full by this desk from the article's own page. Citing three sources involved in the discussions, none of whom could be named because they are not authorised to speak with media, Reuters reports that India's payments authority is building a registry to verify and monitor artificial intelligence agents making transactions on UPI, that the registry will form part of NPCI's planned Unified Agentic Protocol and will vet AI agents that make payments on behalf of users, and that it will initially cover agents paying on UPI and could later cover cards, bill payments and other payment methods, the last attributed to the first source, described as a senior industry executive. Reuters states that NPCI did not immediately respond to a request for comment, so the registry's own details, exactly like UAP's mechanics, remain unconfirmed by NPCI itself. Reuters places the move alongside China's Payment & Clearing Association guidelines this record already carries, and alongside agent registries Amazon, Google and Microsoft have built for agentic commerce, and notes it comes against a backdrop of heightened attention on rogue agent behaviour at leading AI firms.

This record reads the registry as evidence on a different axis from the one it has been tracking, and refuses to let the two collapse. A registry vets, verifies, indexes and monitors an agent. That establishes who an agent is, that it passed some entry assessment, and that its activity can be observed. It does not establish that any individual payment that agent later initiates carried a specific human authorization for that specific amount, that merchant and that moment. Registered identity is a precondition a payments network can reasonably require before an agent transacts at all; it is not itself the transaction-specific authority binding this record has asked about since the Alipay update. The same distinction this record already draws for China's proposed Know Your Agent mechanism, for the FTC registration process in S.5051, and for Uber's attested actor chain applies here without modification: identifying the actor is not the same fact as proving the act was authorised.

Reuters' own reporting keeps the gap open rather than closing it, and this record does not close it either. The third source told Reuters that while the agents would be indexed in the registry, elements like liability for wrong or unauthorised payments will need to be addressed through regulation. That is an explicit, sourced statement that a central question, who bears the loss when an agent pays wrongly or without authority, is unresolved at the time of reporting. It sits directly against the other reported feature of the same programme, that agentic UPI payments would let agents make small, frequent payments without the user approving each transaction, with groceries and other low-value purchases expected first and more complex standing instructions, such as buying at a discount threshold or investing at a price threshold, expected later on the second source's account. A standing grant that removes per-transaction approval and an unresolved liability allocation are the two halves of the propagation problem this record exists to track, reported here in one article.

What remains UNKNOWN after this report is stated rather than inferred. The registry's membership criteria, who may enter it, on what assessment and with what ongoing obligation, are not described. Whether registry membership is bound to a transaction-specific authority at execution, or is only a gate on eligibility to transact, is not described. Revocation mechanics, including how an agent is removed, how quickly removal propagates and what happens to an instruction already in flight, are not described. Liability allocation is explicitly stated as still needing to be addressed through regulation. Whether the registry extends beyond UPI to cards and bill payments is reported only as a possibility by one source. And NPCI has confirmed none of these registry details itself. This record therefore treats the report as strengthening the direction its chairman confirmed on the record the same day, and as adding an identity-layer artifact to the ledger, while leaving every authority binding it has tracked exactly as unknown as it was before.

Two existing UPI mechanisms, verified independently rather than taken on Reuters' shorthand

Reuters reports that UAP is expected to build on two existing UPI mechanisms, UPI Circle and Reserve Pay. This record does not take that description on faith. What follows is independently verified against NPCI's own documented terms and payment processors' technical documentation describing NPCI's own circulars, because direct access to npci.org.in was blocked in this session's tooling environment for every destination this session attempted, including NPCI's own published circular on Reserve Pay enhancements.

UPI Circle, launched by NPCI in 2024, lets a primary account holder link a trusted secondary user to their own UPI linked bank account for delegated payments, in one of two modes. Full delegation authorizes the secondary user to both initiate and complete a UPI transaction from the primary user's account inside a defined spending limit, with no further action from the primary user on that specific transaction. Partial delegation authorizes the secondary user only to initiate a payment request; the transaction completes only once the primary user separately approves it and enters their own UPI PIN. Corroborated technical documentation describes full delegation as currently capped at a monthly limit on the order of ₹15,000 per delegation and a per transaction limit on the order of ₹5,000, with a primary user free to set a lower limit, while partial delegation carries no separate cap of its own beyond UPI's existing transaction limits. A primary user may link up to five secondary users, and NPCI's own guidelines are reported to require app passcode or biometric authentication for a secondary user's own access. This record does not treat the specific limit figures as certain to the rupee, because this session could not read NPCI's own circular directly, and reports it as the consistently corroborated order of magnitude rather than an exact, primary sourced figure.

Reserve Pay, which NPCI's own documentation names UPI Single Block Multiple Debits, lets a payer block a set amount of funds in their account at the time of an initial transaction, against which a merchant may then debit multiple times without requiring a fresh authentication from the payer on each individual debit, until the blocked amount is exhausted or the mandate expires. Corroborated technical documentation, cross checked against NPCI's own circular title even though this session could not read the circular's full text directly, states the maximum blockable amount at ₹10,000 and the maximum validity at 90 days, extended by NPCI to draw on savings accounts, current accounts, overdrafts, RuPay credit cards and pre sanctioned credit lines as funding sources for merchant transactions. Any portion of the blocked amount that is not debited before the mandate expires, or if the underlying transaction is not completed, is reported to release back to the payer automatically. This record states these as Reserve Pay's current limits under NPCI's existing rules, not as a UAP specific figure, because Reuters itself reports that these limits, among other UPI Circle and Reserve Pay parameters, are ones a future UAP may revisit for agentic use rather than adopt unchanged, and this record does not attribute today's ₹10,000 and 90 day figures to UAP itself.

A delegation model built for a person, and, since October 2025, for devices and software too

This is the question this record's own instructions for this update treat as the sharpest one available, and it is answerable from UPI Circle's own documented terms rather than from Reuters' description of UAP: can a software agent already act as a UPI Circle secondary user under today's rules, or is UAP reported to adapt the same delegation model for agents rather than to activate a capability that already exists.

This record's own 1 September 2026 pass answered that question by describing UPI Circle as a strictly human to human delegation feature, with nothing corroborated to that session's searches showing NPCI extending secondary user status to a software agent. Further primary source location undertaken specifically for this 2 September 2026 update narrows that answer rather than confirming it as stated. NPCI's own operating circular, NPCI/UPI/2024-25/OC 201-B, an addendum to NPCI/UPI/2024-25/OC 201 titled Introduction of IoT devices/software on UPI Circle, dated 8 October 2025, already extends UPI Circle's Full Delegation architecture to a Device and a Software category of secondary user, published at NPCI's own site and consistently corroborated across multiple independent legal analyses (a Lexology client alert, its Mondaq republication, a Khaitan & Co briefing dated 20 November 2025, an AMLEGALS analysis, a Complinity compliance summary and a Bar & Bench opinion piece), months before either Reuters' or Business Standard's reporting on UAP. This record states that correction plainly, in the same register it has used for every other revision to its own prior claims, rather than folding it quietly into the existing text: the 1 September 2026 statement that nothing corroborated to that session showed a software delegation precedent was itself incomplete, not because the underlying research was careless, but because this narrower circular had not yet been located.

Corroborated detail from those independent analyses describes OC 201-B as authorizing a Primary User's UPI app to link, as an additional Secondary User category alongside the individual human secondary user UPI Circle already supported since 2024, an IoT Device or a Software profile capable of initiating a payment instruction, with reported examples including smart wearables, smart televisions and, in one corroborating account, artificial intelligence based software profiles. This record treats that last phrase as the closest primary-adjacent language this session could locate for what Reuters' UAP reporting a year later calls an AI agent, and it is the reason this record now states that NPCI's own current rules, not only its reported future protocol, already contemplate a software rather than only a human secondary user. Nothing corroborated to this session, however, shows OC 201-B itself using the phrase AI agent, Unified Agent Protocol or UAP, and this record does not backdate UAP's own name to October 2025 or describe OC 201-B as an earlier version of UAP; it treats OC 201-B as an existing, narrower regulatory precedent UAP may build on, distinct from UAP itself.

Corroborated provisions bound that extension tightly rather than opening it broadly. A Primary User may authorize up to five Devices. Delegated payments initiated through a Device are reported as limited to domestic person to merchant transactions, with cross border payments and peer to peer transfers reported as outside the addendum's scope. Before any Device or Software profile is authorized to link as a secondary user, explicit user consent is reported as required through a two factor authentication process. A newly created delegation is reported to carry a 24 hour cooling off period, during which cumulative transactions are capped at roughly ₹5,000. Issuer banks are reported to be required to validate both the linked Device ID and the associated user ID before permitting any debit against the primary account, and Secondary PSP banks together with the linked device app or software are reported to carry data-localisation and security-reporting obligations of their own. This record states each of these as reported provisions of OC 201-B, corroborated across independent secondary legal analyses rather than read from NPCI's own circular text directly, because direct fetch of npci.org.in was blocked to this session's tooling on every attempt, the same discipline it has applied to Reserve Pay's own circular above.

What this session could not settle with confidence is the exact form "explicit user action" takes at the moment of an individual debit under this Device or Software path, as distinct from the explicit consent NPCI's own reported rules require once, when a Device or Software profile is first authorized to link. One secondary analysis available to this session describes the addendum's overall effect as shifting payment initiation away from a per-instance, user-driven action toward delegated, automated, context based triggers operating inside limits the primary user has already set, while other corroborating accounts state only that issuer banks validate device and user identifiers before permitting a debit, without describing a live confirmation gesture, such as a PIN entry or a biometric prompt, at each individual debit. This record does not resolve that ambiguity by assuming either reading. It states plainly that NPCI's own October 2025 rules already permit a linked Device or Software profile to initiate person to merchant debits inside a primary user's pre-set rules, with explicit, authenticated user consent documented as a requirement at the point a Device or Software profile is first authorized to link rather than necessarily confirmed on this evidence as a fresh, per-transaction human gesture at each individual debit thereafter. That is a materially closer existing precedent for Reuters' reported UAP architecture than this record's 1 September 2026 pass credited NPCI's existing rules with holding. It is still not the same claim as Reuters' own reporting about UAP: NPCI's October 2025 addendum operates through UPI Circle's existing delegation architecture and its existing, human oriented spending caps, addressed above, not through a new rule based instruction layer, a new agent identity check, a new audit trail requirement or a new liability framework, each of which Reuters reports as a UAP specific addition still unbuilt and unconfirmed by NPCI.

Independently locating primary evidence for UPI Circle's own existing Full Delegation feature, as distinct from OC 201-B's IoT and software extension, also surfaced NPCI subsidiary NPCI BHIM Services Limited's own press release, BHIM Goes Live with UPI Circle Full Delegation, Enabling Authorised UPI Payments within Set Limits, published at NPCI's own site and dated 25 November 2025, confirming BHIM's own rollout of the human secondary user feature this record already described above. Corroborated consistently across that release and independent coverage of it (Business Standard, Business Today, IANS), a primary user may set a Full Delegation validity period of up to five years for a given secondary user, a detail this record had not previously stated, alongside the monthly and per transaction caps already carried in this record's 1 September 2026 update. This record cites NBSL's own press release here as a further primary-adjacent anchor for figures already in this record, not as new substantive evidence about UAP itself.

What Reuters and Business Standard both report remains narrower and more precise than either existing mechanism read alone: UAP is expected to extend, or adapt, UPI Circle's existing delegation architecture (now including its October 2025 Device and Software extension), and Reserve Pay's existing fund reservation architecture, into a rule based, agent-identity-checked, audit-trailed protocol with its own liability framework, none of which OC 201-B itself establishes. That distinction, an existing regulatory precedent for software and device secondary users against a reported future protocol layering agent identity, audit and liability on top of it, is exactly the one this record's Authority Provenance ledger below is built to hold apart, and this record does not collapse it in either direction.

What UAP is reported to add, and what stays unknown

Reuters reports several specific features NPCI is expected to build into UAP, and this record states each one exactly as reported rather than sharpened into something more concrete than the sourcing supports. Customers would be able to set rule based instructions governing when an agent may pay and how much it may pay, described consistently across corroborating coverage as spending limits set in advance rather than approved per transaction. NPCI is expected to build agent identity verification into the protocol, checking that a given AI agent is the one entitled to act, though nothing corroborated to this session describes the mechanics of that verification, whether it issues a credential, a certificate or a registration record, or how it binds a verified agent identity to a specific user's own delegation the way UPI Circle's own passcode or biometric check binds a secondary user to a primary one today. Audit trails are reported as an expected feature, without detail on what a trail would record, at what stage of a transaction, or whether it would bind a payment instruction to the specific rule based instruction that authorized it the way this record's own Authority Provenance ledger methodology, developed across Alipay, Uber, S.5051 and China's Convention, has looked for throughout. NPCI is expected to offer merchant integration infrastructure, letting merchants connect directly to agent initiated payments, though nothing corroborated to this session describes what that infrastructure would expose, to whom, or under what verification. And NPCI reportedly plans a liability framework, with Reuters reporting no further detail about what it would cover, who it would assign responsibility to when an agent initiated payment goes wrong, or how it would relate to UPI's existing dispute and chargeback mechanisms. This record does not credit ordinary UPI dispute resolution, chargebacks or bank fraud processes as an Agent Authority recovery mechanism for UAP, because nothing corroborated to this session states that UAP's own liability framework integrates them, or how.

Two further facts bound how far any of this has actually progressed. Corroborating coverage reports that UAP would require regulatory approval from the Reserve Bank of India before it could launch, which this record treats as a real, additional gate beyond NPCI's own development and beyond whatever NPCI unveils at the Global Fintech Fest, not a formality. And Reuters reports that low value, high frequency use cases such as grocery orders and other routine digital purchases are expected to be the initial rollout target, with Business Standard's earlier July reporting describing a similar progression from low consideration purchases toward more sophisticated use cases over time; this record treats both as reported, expected use cases rather than as protocol fields UAP itself is confirmed to define, consistent with this record's own instruction not to convert an illustrative example into a specification. Separately, and outside NPCI's own UPI rail, Reuters reports that Mastercard and Visa are each separately building comparable agentic payment capabilities for the Indian market, with Mastercard reported to have completed its first authenticated agentic transaction in New Delhi in June 2026; this record notes that development only to record that India's agentic payments landscape already has a private card network track running in parallel to NPCI's own national UPI rail, the same coexistence this record has already documented between Rain's Agent Control Layer and the Agentic Payments Alliance on one side and Alipay's own product architecture on the other, and does not merge the two tracks or attribute either's specifics to the other.

The Authority Provenance ledger, for India's Unified Agent Protocol

Read as reported, pre launch architecture rather than as deployed infrastructure, UAP sits on this record's ledger closer to S.5051 and to China's Convention than to Uber's own shipped system: a framework three and four unnamed sources have described to two news organizations, not yet confirmed by the institution building it, let alone specified in a public document this record could verify directly.

Authority grantor. The reported immediate grantor is the primary UPI account holder, the same role UPI Circle already assigns to a human delegating to a secondary user. Nothing corroborated to this session addresses a business, merchant or enterprise UPI account, so whether a person configuring an agent's authority under UAP necessarily holds the organizational authority to bind an employer's or a business's funds is undocumented here, the same gap this record has already left open for S.5051's individual user designation model and for the Convention's own user authorization requirement.

Mandate or basis. Reported as rule based instructions a customer sets governing when and how much an agent may pay. Nothing corroborated to this session describes the machine readable form that mandate would take, whether as a UPI Circle style preset limit, a new UAP specific instruction object, or something else, and this record keeps the exact representation unknown rather than inferring one from adjacent protocols this record has verified elsewhere, such as AP2's signed Mandate chain.

Delegated scope. Reported along two dimensions Reuters names directly: when an agent may pay and how much it may pay. This record does not add merchant, merchant category, payee, product, frequency, schedule, transaction count, cumulative budget or expiry as additional UAP dimensions, because nothing corroborated to this session states that UAP itself defines any of them as a distinct, required field, even though Business Standard's own reporting names low consideration purchases and, later, more sophisticated use cases as expected applications of whatever scope UAP ends up defining. Reported use cases are not protocol fields, and this record does not convert one into the other.

Explicit limits. Reported as spending limits set in advance by the customer, reportedly built on Reserve Pay's existing fund blocking mechanism, itself currently capped, under today's rules, at ₹10,000 for up to 90 days, and on UPI Circle's existing full delegation caps, currently on the order of ₹15,000 monthly and ₹5,000 per transaction. A narrower existing precedent, independently located for this 2 September 2026 update, sits below even those figures: NPCI's own OC 201-B addendum caps a newly created Device or Software delegation at roughly ₹5,000 cumulative during its first 24 hours and restricts Device initiated payments to domestic person to merchant transactions only. This record does not attribute any of these current figures to UAP itself; Reuters reports UPI Circle's and Reserve Pay's existing limits as ones a future UAP may revisit for agentic use, and this record keeps UAP's own eventual limit, whatever it turns out to be, distinct from Reserve Pay's, UPI Circle's and OC 201-B's current limits until NPCI or the RBI publishes one.

Inherited permissions and assumptions. This is the ground this record's own instructions for this update identify as most consequential, and the evidence here cuts against, not for, an inference that broad account access would follow from UAP. UPI Circle's and Reserve Pay's existing architecture already establishes, for human secondary users and merchants respectively, that holding a payment relationship with an account does not mean holding unbounded authority over its funds: full delegation is capped and revocable, and Reserve Pay blocks a bounded amount rather than exposing the whole account. NPCI's own OC 201-B addendum, independently located for this update, shows the same discipline already applied to a Device or Software secondary user rather than only a human one: a capped cooling-off period, a person to merchant restriction, and issuer bank validation of device and user identifiers before any debit. Nothing corroborated to this session suggests UAP would depart from that inherited discipline by handing an agent broader account reach than a human secondary user, or NPCI's own existing Device and Software secondary user category, already has today. What remains genuinely unresolved is the different question this record has asked since the Uber update: an agent's identity being verified under UAP's own reported identity checks is not, on anything corroborated to this session, the same claim as that specific payment being authorized under the customer's own rule based instruction, and this record does not equate agent verification with payment authorization anywhere in this ledger.

Revocation or modification. UPI Circle's and Reserve Pay's own existing architecture each documents a revocation path in general terms, a primary user's control over a secondary user's delegation and a payer's own reserved balance releasing automatically on expiry or an incomplete transaction, and this record does not doubt that a UAP built on top of them would inherit some working notion of stopping future payments. What is specifically undocumented, on everything corroborated to this session, is UAP's own revocation and modification mechanics: how immediately a revocation would take effect once UAP is layered on top of UPI Circle and Reserve Pay, whether it would reach an already issued reserved block or an in flight merchant debit, and whether a rule based instruction, once set, could be narrowed only by the same customer who set it or by some other party. This record keeps each of those unknown rather than assuming UPI Circle's own general revocation language answers a UAP specific question it has not yet been asked to answer.

Challenge authority. Undocumented. Nothing corroborated to this session describes whether a transaction that would exceed a customer's rule based limit, fall outside whatever reserved authority Reserve Pay's block establishes, or trip an unspecified risk check returns to a human approval flow, is simply declined outright, or is handled some other way. This record leaves that path unknown rather than assuming UPI's existing per transaction PIN flow would apply by default to a case UAP itself is specifically built to route around.

Recovery. Undocumented beyond a single reported fact: NPCI reportedly plans a liability framework, with no further detail reported about what it would cover or how. This record does not credit UPI's existing dispute resolution, chargeback or bank fraud processes as UAP's own recovery mechanism absent a reported statement that UAP's liability framework integrates them, the same discipline this record has applied to Rain's, AWS's and the Convention's own recovery and rollback language throughout its coverage of agent payments.

Provenance evidence quality. Layered, and earlier stage than any other entry on this ledger. UPI Circle's and Reserve Pay's own existing mechanics are independently verified here against corroborated technical documentation, even though this session could not read NPCI's own primary circulars directly, and that verification is real: a bounded delegation architecture and a bounded fund reservation architecture both already exist and already operate for human actors at national scale. What UAP itself would add on top of them, agent identity verification, audit trails, merchant integration infrastructure and a liability framework, is reported by three and four unnamed sources respectively to two news organizations, not confirmed by NPCI, not specified in any document this session could read, and not yet subject to the Reserve Bank of India approval Reuters reports UAP would need before launch. This record does not treat that reporting as weaker evidence than it is, three and four independent sources across two established news organizations describing a consistent underlying development over nearly two months is meaningful corroboration, but it also does not treat it as stronger than it is: a national infrastructure protocol that exists today only as sourced reporting about a regulator's internal development process, unconfirmed by that regulator, ahead of a possible unveiling this record has not yet observed.

A seventh development: MCP removes sessions, and states the propagation question as protocol text

The sixth development above is reported, unconfirmed infrastructure. This seventh one is the opposite: a final, shipped specification revision to the Model Context Protocol, the connectivity layer a large share of the agent products this record already covers, Alipay's own Skills and MCP tools among them, are themselves built on. It happened earlier than this record is publishing it. The Model Context Protocol's own 2026-07-28 specification revision, and the two Standards Enhancement Proposals behind its authority-relevant sections, SEP-2567 (created 11 March 2026) and SEP-2663 (created 27 April 2026), predate this update by weeks to months. This record is adding it on 6 September 2026 because it was only surfaced to this desk now, not because anything about it is new today, and because it states, in a widely adopted protocol's own normative text, the same distinction every development on this ledger has approached from a different angle: connectivity and reference are not authority.

Before SEP-2567, MCP carried an initialize and initialized handshake and an Mcp-Session-Id header identifying a connection as a stateful session; a server could let context accumulate implicitly across the requests riding that connection. The 2026-07-28 revision removes that entirely. Fetched directly from the specification's own repository, the current base protocol text states that MCP is a stateless protocol, that servers must process each request independently, and that servers must not rely on prior requests over the same connection to establish context. There is no session identifier left in the wire protocol at all.

Removing sessions does not remove state. SEP-2567's own text is explicit that a server needing state to span multiple requests should expose a tool that mints an opaque identifier, an explicit state handle, such as a shopping basket or a workflow id, and have the client pass that identifier back as an ordinary tool argument on every later call. A handle is not a protocol construct. SEP-2567 states plainly that there is no handles method, no handle type in the schema and no wire-level concept of a handle at all; it is indistinguishable, to MCP itself, from any other string a tool returns or accepts. That is precisely why this record reads SEP-2567 as validating its own propagation thesis rather than merely resembling it: the specification's authors reached, from a completely different problem, the exact place this record's Authority Provenance ledger has been built to stand since Alipay's launch. A reference to state can now travel anywhere a chat transcript, a subagent prompt or a copy paste buffer can carry a string. Whether the party presenting that reference is actually entitled to use it is a separate question the reference itself never answers.

Possession of a handle is not authorization, where authorization exists

SEP-2567 draws the line precisely rather than leaving it to inference. For an authenticated server, its own text states that the server should validate the pair, a handle together with the caller's current authenticated identity, on every call, not the handle alone, because handles will end up in chat logs, copy paste buffers and subagent prompts. The specification's own analogy is a Google Doc id sitting in a URL or a browser history: reachability is not what protects the document, an access control list checked against the requester is. Moona Intelligence states this precisely rather than inflating it into a protocol-level guarantee: MCP itself has no handle type and enforces nothing about how any given server treats a handle it mints. This is guidance for how a server implementing its own application logic on top of MCP should behave, not a wire-level authorization mechanism MCP itself carries out. The specification's own security best practices page, fetched directly, states the corrective as a should, not a protocol invariant, but states it in the clearest terms this record has found anywhere in the six developments on this ledger: MCP servers must not treat possession of a state handle as authentication, and a server that implements authorization must verify all inbound requests rather than trusting whoever happens to present a valid looking identifier. For a server with no authentication layer at all, SEP-2567 is equally direct about the tradeoff it is naming rather than hiding: the handle is then necessarily a bearer capability, and the specification's corrective is generation with at least 128 bits of cryptographically secure entropy and a bounded lifetime, the same design already standard for a password reset link or an anyone with the link share, not a claim that such a handle is somehow still gated by identity once none exists to check against.

Read against Alipay's own architecture above, this sharpens rather than answers the open question this record left there. Alipay's public material does not state, at the level of detail that would settle it, whether a downstream agent in its AHA chain receives an independently scoped authorization traceable to a specific human grant or a request trusted because of who forwarded it. MCP's own 2026-07-28 revision does not resolve that for Alipay's own architecture either. What it does is state, as the connectivity layer's own normative guidance rather than as one company's product design, exactly which of those two designs a server implementing state across MCP tool calls should be building, and exactly which failure mode results from building the other one.

Tasks make the same requirement mandatory, and remove the one operation that could not be scoped safely

Where SEP-2567's handle guidance is a should, the redesigned Tasks extension, SEP-2663, states a must. Long running work that used to sit inside MCP's own core specification as an experimental capability now lives in a formal io.modelcontextprotocol/tasks extension, through which a server may respond to a tool call with a durable taskId instead of an immediate result, and a client polls tasks/get, sends tasks/update when the task needs further input, and sends tasks/cancel to signal that it no longer wants the work continued. The current Tasks specification, fetched directly, states its own authorization requirement without qualification: servers must perform authentication and authorization checks on each task-related request to ensure that the client has permission to access a task. That applies to tasks/get, tasks/update and tasks/cancel alike. A taskId, on this record's own reading of the specification's text, functions as a bearer style reference sufficient to locate the task, exactly the same shape of risk SEP-2567 names for a state handle, but the specification does not leave locating the task equivalent to being authorized to act on it: the per-request check is required regardless of whether the caller can produce the identifier.

The extension also removes a capability its predecessor's experimental version had: tasks/list. The specification states the reason directly rather than as an implementation detail: because there is no tasks/list, a server cannot inadvertently leak the existence of one caller's tasks to another. In a sessionless protocol with no connection-scoped identity to filter a listing by, an enumeration endpoint is exactly the kind of surface this record has already named, in Uber's own architecture above, as the harder problem underneath a propagation question: not only whether a request presenting a reference is authorized, but whether the existence of other principals' references is itself something the protocol should ever expose. MCP's own answer, for this one operation, is not to build a scoping mechanism and hope every implementation gets it right; it is to remove the operation.

One further limit this record states precisely because two other developments on this ledger already turn on exactly this kind of gap. The Tasks specification describes cancellation as cooperative: a tasks/cancel request signals intent, and the server decides whether and when to honor it, with no guarantee that the task's eventual terminal state is cancelled rather than a status the work reached on its own before the signal was acted on. A client that sends tasks/cancel and stops polling has signaled a withdrawal of interest. It has not confirmed the work stopped. This record does not treat that limitation as unique to MCP; it is the same distinction between a revocation signal and a revocation's actual effect this record has already left open, undocumented, for UPI Circle's, Reserve Pay's, S.5051's and the Convention's own revocation mechanisms above. MCP's own specification simply states the limitation as normative text rather than leaving a reader to discover it by testing an implementation.

The Authority Provenance ledger, for MCP's 2026-07-28 revision

This ledger reads differently from every other entry on it. Alipay, Uber, S.5051, the Convention and UAP each describe one organization's own delegation architecture, human to agent or agent to agent, inside one product or one proposed law. MCP's own revision describes the wire protocol several of those products, Alipay's own Skills and MCP tools among them, are themselves carried on. There is no single grantor here because the specification does not grant anything; it states what a conforming server should and, for Tasks, must do about a grant an application layer above it makes.

Authority grantor. Not modeled by the protocol. MCP's core specification carries no identity, authorization or grant concept of its own; a state handle is an opaque string a server's own application logic mints, and whoever grants access to what that handle refers to is a decision the server implementing it makes, entirely outside MCP's own wire format. This record does not read SEP-2567 as naming a grantor, because it explicitly declines to.

Mandate or basis. For an authenticated MCP server, the specification's own stated basis is an auth_context established by whatever authorization mechanism the server has deployed, most commonly the protocol's own separate OAuth-based authorization specification, hardened in this same 2026-07-28 revision with mandatory issuer validation under RFC 9207. For an unauthenticated server, there is no mandate beyond possession of a sufficiently high-entropy, bounded-lifetime bearer string, which SEP-2567 states as a deliberate, named tradeoff rather than an oversight.

Delegated scope. Undocumented at the protocol level, and deliberately so. A handle's scope, one basket, one workflow, one document, is whatever the server minting it decides to bind it to; MCP's own schema carries no scope field for a handle because a handle carries no protocol-recognized type at all. For a task, scope is bounded to the single unit of work the taskId was issued for, since the extension provides no mechanism to address more than one task by reference.

Explicit limits. A task carries an explicit, protocol-defined limit the current specification states directly: a ttlMs field giving the task's time to live from creation, after which a server may mark it failed and later delete it, with the value itself allowed to change over the task's own lifetime. A state handle carries no protocol-defined limit at all; SEP-2567's own guidance that an unauthenticated server's bearer-style handle should carry a bounded lifetime is a recommendation to implementers, not a field MCP itself defines or enforces.

Inherited permissions and assumptions. This is the field every other development on this record's ledger has turned on, and MCP's own revision states the corrective as directly as this record has found anywhere in its coverage. Nothing about knowing a handle, or being able to reach a server that will accept it, establishes that the caller presenting it holds the authority the handle's underlying state represents. SEP-2567 names the exposure surface this creates precisely, handles will end up in chat logs, copy paste buffers and subagent prompts, and states the corrective precisely too, validate the handle together with the caller's current authenticated identity, not the handle in isolation. This record's own recurring distinction, that a reference passed to a subagent lets the subagent attempt access, not that the subagent has thereby been delegated authority, is the same distinction SEP-2567 draws for a handle passed anywhere a string can travel, stated now as the connectivity layer's own guidance rather than as this record's own interpretation of one vendor's product.

Revocation or modification. For a state handle, entirely application-defined; MCP's own specification states nothing about revoking one, because it does not model handles as a first-class concept to revoke. For a task, the specification provides tasks/cancel as a signal a server is not obligated to honor immediately or at all, only obligated to acknowledge, with eventual transition to a cancelled state explicitly not guaranteed. This record states that limitation as the specification's own normative text, not as a gap this record has inferred.

Challenge authority. For an authenticated server, whatever authorization server issues and validates the auth_context, entirely outside MCP's own core specification. For Tasks specifically, the current specification states an unqualified requirement rather than leaving challenge authority to implementer discretion: a server must perform authentication and authorization checks on each of tasks/get, tasks/update and tasks/cancel, which this record reads as the clearest must-level statement, anywhere on this ledger, that current authorization has to be re-established on the request that is actually being made rather than inherited from whichever request created the resource being acted on.

Recovery. Application and task specific. A task's own ttlMs functions as a backstop a client may treat as an eventual expiry when the task's observable status stops updating, on the current specification's own stated language, but recovery from a task that never reaches a clean terminal state is otherwise undocumented at the protocol level, and recovery from a compromised or leaked state handle is entirely a question for whichever server minted it.

Provenance evidence quality. High for the normative text itself: the 2026-07-28 revision is a final, shipped specification, SEP-2567 and SEP-2663 are both final Standards Enhancement Proposals, and this record read the base protocol text, both SEPs, the current Tasks specification, the 2026-07-28 changelog and the specification's own security best practices page directly, at the primary source rather than through search corroboration, notwithstanding that modelcontextprotocol.io itself was blocked to this session's direct fetch and the identical text was instead read from the specification's own source repository. What that provenance does not establish, and this record does not claim it does, is how any individual MCP server implementation actually behaves. SEP-2567's own handle authorization guidance is a should for an authenticated server implementer to follow correctly; this record has already covered, in Grafana's own CVE-2026-19516 disclosure elsewhere in this corpus, a real MCP server whose session check accepted a caller supplied identifier the server itself had never issued. The specification's own text and one deployed server's own failure to meet an equivalent standard are two separate facts, and this record keeps them separate rather than letting the first stand in for the second.

Seven developments, one distinction

Alipay's chain, Uber's actor chain architecture, a proposed statute, a consumer scale analysis, an industry-wide self-regulatory convention from China's own payments industry, reported, unconfirmed work toward a national protocol on India's own UPI rail, and now the Model Context Protocol's own 2026-07-28 specification revision, are seven 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. India's reported Unified Agent Protocol, exactly because NPCI has not confirmed it, shows the earliest possible stage of the same pattern. And MCP's own specification revision shows the pattern stated as the connectivity layer's own normative text: state can now propagate across requests explicitly, through a handle or a task id, and the specification's own authors state, in the clearest terms this ledger has gathered, that authority does not propagate with it automatically, that possession of a reference is not authorization where authorization exists, and, for a task specifically, that authorization must be checked again on the current request rather than assumed from whichever request created the resource being acted on. None of the seven, read on its own primary terms, closes the gap between naming the requirement and proving it was met everywhere it matters. Together they are the clearest evidence this record has gathered that the market, the standards bodies, a legislature, two national payments industries and now the agent connectivity protocol itself have converged on naming it precisely, which is a different and earlier thing than any of them having solved it.