The Agent Paid. Now Prove That Payment Was Authorized.

An AI agent can already spend real money without a person clicking confirm on the specific transaction. That capability existed before August. What changed on August 12, 2026 is narrower and, to me, more interesting: a description of what it would take to prove, after the fact, that one specific payment was authorized before it happened, rather than merely logged once it did.

The agent can already pay

Amazon Bedrock AgentCore payments launched in preview on May 7, 2026, built with Coinbase and Stripe. AWS's announcement described a managed payments layer that lets an agent running on AgentCore autonomously pay for the things it needs mid task: a paid API, an MCP server, a data feed, a piece of web content behind a paywall. Payments run over x402, an open protocol built around the HTTP 402 Payment Required status code, with Coinbase and Stripe or Privy providing the embedded stablecoin wallets that actually move value. Coinbase's own announcement confirms the same launch, the same date and the same role for x402. The first version targeted small, frequent transactions, the kind credit card rails were never built to clear economically. AWS has since said it expects the same rails to extend toward larger purchases, such as travel and merchant payments.

That is the capability. It is genuinely new, and it is worth stating plainly once and then moving past: software can now decide, mid task, to spend money, without a person approving that individual transaction first.

Moving money changes the evidence question

A model's bad answer can be corrected. Someone reads it, disagrees, and nothing outside the conversation has changed. A settled payment is different in kind. Value has left one account and reached another. If the transaction should not have happened, reversing it is a separate, harder problem than the decision to make it, and it may not be possible at all.

That difference is what makes an agent that can pay a sharper version of a question Moona Intelligence has been tracking across other domains all month: not whether an agent can technically reach an action, but whether anyone can later show why this specific action was allowed to happen. AgentCore payments answers the reach question. It lets an agent transact. It does not, on its own, answer the harder one.

The decision happens before settlement

That is the gap AWS's August 12 post addresses, in a piece written jointly with Solv Labs, a company building governance for agent payments, and reviewed with ICME Labs, which provides independent policy verification. The post walks through a workflow Solv Labs built on top of AgentCore payments in which a proposed transaction is authorized and evidenced before it is allowed to settle, not audited afterward.

The sequence, at a high level, is this. An agent proposes a payment. Before AgentCore payments will process it, the proposed transaction is evaluated by Solv's policy engine, which AWS and Solv Labs call ORACLE. ORACLE checks the proposed action against the applicable policy and returns one of two outcomes before any value moves: ALLOW, or REVIEW. A separate DENY path exists for proposed transactions that violate configured constraints outright, and it produces a signed refusal record rather than simply dropping the request. ICME Labs' verification layer checks that policy evaluation independently, so the result is not just an internal assertion from Solv's own system. Only once a transaction has cleared that authorization step does settlement proceed.

I am deliberately not walking through the cryptographic mechanics ICME Labs uses to make that check independently verifiable, or the internals of how Solv Labs attests execution inside AWS infrastructure. Those are implementation details, not the point. The point is the ordering: authorization and its supporting evidence are produced as part of the same step that decides whether the transaction goes through, not reconstructed from logs after the fact by someone trying to figure out what happened.

An audit log is not automatically proof of authorization

This is where I think the distinction is easy to blur, so it is worth stating carefully in Moona Intelligence's own words rather than AWS's.

A log entry that says a payment occurred, for a given amount, to a given counterparty, at a given time, is a record of an event. It is valuable. It is also, by itself, silent on the question that actually matters when something goes wrong: was this specific transaction supposed to happen under the rules that applied to it? A log can be reconstructed after the fact from whatever the system happened to write down. It tells you what the system did. It does not, by construction, tell you what authorized it to do that.

What the Solv Labs workflow adds is not more logging. It is a record produced at the moment of authorization itself, binding the specific policy that was evaluated to the specific transaction it was evaluated against, before that transaction was allowed to settle. That is a structurally different kind of evidence than an after the fact trail, and it is worth being precise about why: one answers what happened, the other answers why it was allowed to happen, and a system can have plenty of the first without ever producing the second.

The record does not prove the decision was wise

AWS and Solv Labs are careful not to overclaim what this evidence establishes, and that limitation deserves to be preserved exactly, not rounded up into something bigger.

The evidence record does not establish that the agent's underlying decision to make the payment was a good one. It does not establish that the counterparty receiving the funds is solvent or legitimate. It does not establish that the policy the transaction was checked against was itself a correct or reasonable policy. Those questions remain the operator's responsibility, exactly as they would for any other payment a business makes.

What the record does establish is narrower and more specific: that this particular payment was evaluated against this particular policy, under these particular constraints, and that the result of that evaluation is what authorized it to settle. That is a real and useful claim. It is also a bounded one, and the boundary is the whole point. An evidence record that proved the underlying business decision was wise would not be evidence of authorization anymore. It would be a claim about judgment that no automated check can actually make.

Financial authority needs scope too

AgentCore payments itself, independent of anything Solv Labs built, already constrains what an agent can spend without a person in the loop. A payment session, the scoped context an agent transacts within, carries a configurable spending limit and an expiry. AWS documentation describes these session windows running from as little as fifteen minutes to as long as eight hours. Once either boundary is reached, whichever comes first, further payment attempts within that session are denied before the agent's request is ever signed.

What matters editorially is where that check runs. AWS states these limits are enforced deterministically at the infrastructure layer, outside the agent's own code, specifically so that a prompt injected instruction cannot talk the agent into spending past its cap. That is a scope control, not a wisdom control. It bounds how much authority an agent's payment session carries and for how long. It says nothing about whether any individual payment made inside that boundary was the right one to make. Scope and authorization are two different layers, and AgentCore payments and Solv Labs' workflow sit at different ones: one bounds what is possible, the other evidences what was decided.

Evidence belongs at the decision boundary

None of this is unique to payments, and it is worth placing next to what Moona Intelligence has already written about the same underlying question in other domains this month.

Robinhood already established that agents can be given the authority to move real money, with account isolation, spending caps and an approval gate around the trades and purchases an agent places. That is the authority question: whether software gets to act on an account at all. This is a different question, sitting one step further along: once an agent has that authority, what evidence exists for the individual decision to use it, on this transaction, at this moment.

SAFE, the incident reporting framework proposed by the Open Secure AI Alliance, is about preserving evidence so an agent security incident can be reconstructed afterward: prompts, traces, tool calls, permissions, all gathered once something has already gone wrong. The Solv Labs workflow is not a reconstruction tool. It produces its evidence as part of the authorization step itself, before the transaction executes, whether or not anything ever goes wrong.

AWS's own healthcare architecture separates whether an agent can technically call a submission tool from whether it should be allowed to submit a specific consequential decision, and answers the second question with a human approval step. The payments workflow answers a related but distinct question for a different kind of consequential action: not who has to approve it, but what can be shown afterward about why the automated check let it through.

Put together, those three pieces sketch what a trustworthy answer to a consequential agent action should be able to say: what action was proposed, which authority applied to it, what decision was made, whether a human review was required, and whether execution actually followed that decision. AWS, Solv Labs and ICME Labs never use that framing. It is Moona Intelligence's reading of what their implementation, for one class of action, actually produces.

The agent can spend. It cannot give itself a bigger budget.

On August 17, 2026, AWS published a second post on the same payments service, written as a collaboration with the OpenClaw Foundation, by Daniel Wirjo, Isaac Lin, Madhu Samhitha Vangara, Patrick Erichsen, Chethan Shriyan and Peter Jiang. It walks through connecting OpenClaw, an assistant that runs locally through a gateway, to AgentCore payments using an AWS published plugin. Read as a tutorial it is a configuration walkthrough. Read as a governance document it is something more useful: an account of who holds which piece of financial authority, and where the line between them sits.

AWS describes the split plainly. A human provisions the wallet, creates the payment session, approves recipients and sets the budget through a trusted administrative path, in an interactive terminal where wallet provider credentials are entered and stay. The same human path sets the network and asset scope, a maximum for any single payment, a cumulative budget for the session and an expiry. Administration and runtime use separate IAM roles, and AWS says the runtime role needs only the read operations required for session status plus the payment call itself, and must not carry session write permissions. The signed payment proof is not returned to the model.

What the model facing runtime gets is deliberately small: two tools, one that reports whether the configured session is usable and what remains of its budget, and one that requests an approved paid URL and completes the payment inside the configured policy. AWS is explicit that the runtime can initiate a payment within the approved session but cannot create, extend or replace a session. The plugin documentation in the AWS repository says the same thing in its own words: no setup at runtime, and no replacement sessions. If the session expires or drains, a human uses the trusted administrative path to create a new one.

That distinction is the part I think is being missed in the coverage. Everyone is talking about agents finally being able to pay for things without stopping for a person. What strikes me is the other half: AWS did not give the agent any authority over how much authority it should have. Autonomy and unlimited authority are being treated as separable, and they are separable. A bounded execution envelope can be delegated in advance, the agent can act freely inside it, and the mechanism for enlarging it can sit somewhere the agent cannot reach. Authority to act is not the same thing as authority to grant yourself more authority. That framing is Moona Intelligence's reading, not language AWS or the OpenClaw Foundation use.

AWS is also careful about what this does not solve, and the caveat deserves to survive intact. The design does not prevent prompt injection. AWS states it assumes untrusted input can manipulate the model, and bounds the payment authority available to the runtime by recipient, asset, network, per payment amount, session budget and expiry. Paid content returned to the agent is capped and marked untrusted precisely because a publisher can put instructions in it. The claim is not that the model stays honest. It is that the financial consequence of the model failing is bounded independently of whether it does.

And a bounded envelope still says nothing about whether an individual purchase inside it was a good idea. A payment can sit comfortably under every configured limit and still be the wrong payment to make. That is exactly the gap the Solv Labs workflow addresses at a different layer, by evaluating the specific proposed transaction against policy and binding the result to it. One layer decides how much authority the agent holds. The other decides whether this particular use of it was allowed, and leaves evidence that it was. Neither substitutes for the other.

Two more caveats worth stating. This is one implementation pattern for one assistant, not a description of how every OpenClaw agent or every AgentCore payments deployment is configured. And the walkthrough is built around a testnet endpoint, with a production network mentioned as the alternative. What it establishes is that the pattern exists and is documented by the vendor, not that it is universal.

Permission to Act Is Not Evidence of the Decision

On 12 August 2026, the same day AWS and Solv Labs published the payments workflow above, revision 02 of a separate document reached the IETF OAuth Working Group mailing list: Agent Authorization use cases and gap analysis, authored by Meiling Chen, Jia Chen, Jiankang Yao, Yuning Jiang and Chunchi Peter Liu. It is an Internet-Draft, and its own status page states plainly what that means. It is an individual submission, not a document the OAuth Working Group has adopted. It is not an RFC and not an IETF standard. It is a work in progress, and several issues raised against it were still open and deferred to a future revision at the time of this update.

The draft is fair to OAuth, and that is worth stating precisely rather than rounding up into something louder. Its own gap analysis walks through what OAuth scopes, Rich Authorization Requests, DPoP, token exchange, Transaction Tokens and client metadata already do for an agent acting on a person's behalf. Token exchange and client credentials grants, it notes, already let an individual agent obtain a token, and Rich Authorization Requests can express fine grained permissions per request. The draft is not arguing that these mechanisms fail to authorize agents. Its argument is narrower. It says these mechanisms establish what it calls grant layer authority: the permission set created at authorization time, usually expressed as scopes, describing what an agent is allowed to do in principle. A Transaction Token, in the draft's own reading, proves that scope was granted for a task. A DPoP proof shows that the client holding a particular key presented the token. Neither one, the draft argues, carries a record that a person approved the specific parameters of the one action actually taken under that authority.

The draft illustrates the distinction with a personal assistant booking example. A token can establish that an agent has general authority to make bookings on a person's behalf. That is grant layer authority, and the draft credits existing OAuth mechanisms with expressing it reasonably well. What it says is missing is execution layer evidence: a durable, non repudiable record, produced at the moment one specific high risk action executes, binding the exact parameters of that decision, in the draft's own example a particular venue, a specific price and a specific date, to a person's actual consent. A valid token proving general booking authority, on the draft's reading, does not by itself prove a person authorized that specific booking at that specific price.

The draft applies the same distinction to two further scenarios, used here only because they show the pattern is not specific to payments. In a multi agent insurance claims process, where separate agents handle intake, verification, adjudication and payment, the draft argues the final payment action needs execution evidence binding the specific amount and recipient to the full delegation chain and the original claim, not only a token proving the paying agent held authority to pay something. In an automated security incident response scenario, its example is a containment action such as isolating a specific host, it argues that action needs a record binding the agent's identity, the exact action taken, the policy that justified it and a timestamp into one verifiable artifact, not only proof the agent held a valid credential.

The mailing list activity around this revision is contributor discussion, not working group consensus, and should be read that way. In one thread, a contributor suggested folding a related scenario into an existing use case, while the draft's lead author proposed treating it as its own standalone use case and asked for contributed text in that shape. Six issues remained open against the draft at the time of this update, including one bearing directly on execution evidence, and were deferred to a future revision. That is ordinary for an early stage Internet-Draft. It also means the exact wording of grant layer authority and execution layer evidence should be read as a proposal still being argued over, not as settled OAuth Working Group output.

This draft is not the only one working this ground. A separate individual submission, AI Agent Authentication and Authorization, lists contributors affiliated with AWS, Zscaler, Ping Identity, OpenAI and Okta, and proposes applying existing WIMSE and OAuth mechanisms to agent identity rather than defining new protocols. Another, Agent Operation Authorization, proposes a structured token an authorization server issues only after a person confirms a specific proposed operation. None of this is one coordinated standard, and an author's listed employer is not that company's endorsement of a draft it did not itself publish. What the pattern across several independent submissions shows is that more than one group of contributors is now working on what a token proves once an agent, not a browser, is the one presenting it.

Read against the payments workflow above, the draft's distinction lands on ground this piece has already covered, under unfamiliar language. AgentCore payments and the OpenClaw session both describe a grant layer: a spending session, an approved origin list, a budget and an expiry, authority established in advance. Solv Labs' ORACLE evaluation, checked independently by ICME Labs and bound to one proposed transaction before it settles, functions as execution layer evidence in substance, even though AWS and Solv Labs never use that term. The Internet-Draft did not create that pattern. What it adds is a shared name, now being argued over inside the OAuth Working Group, for the boundary this piece has described since 12 August: a valid grant establishes that an agent may act. It does not, by itself, establish that this specific action was the one a person actually authorized.

What remains unknown is worth stating plainly. Whether the OAuth Working Group adopts this draft, whether its terminology survives into a later revision, and whether any vendor builds execution layer evidence the way the draft describes are all open questions. Moona Intelligence is not aware of any implementation, including the ones described above, that claims to satisfy this draft's proposal, and none is claimed here.

Can an approved transaction change before it executes?

Everything above happens off chain, in a payments service or a policy engine. A preprint posted to arXiv on 18 August 2026 asks the same question one layer lower, where the money actually settles, and it asks it in the sharpest possible form: is the thing that was approved still the thing that executes?

The paper is PACE, short for Policy Attested Contract Execution, by Rabimba Karanjai, Yang Lu, Richard Williamson, Hemanth Hm, Prakhar Mehrotra, Lei Xu and Weidong (Larry) Shi. The listed affiliations are the University of Houston and PayPal, with the corresponding author holding both. It is arXiv 2608.17220, version 1, filed under Cryptography and Security, released under a CC BY NC ND 4.0 license. It is a preprint. It is not peer reviewed, it carries no venue in its metadata, and nothing in it claims acceptance. I read the full paper directly rather than relying on the abstract.

What PACE proposes sits between a language model that plans a decentralized finance transaction and the chain that executes it. The paper describes three parts. Every proposed action is reduced to a typed transaction intent: target, value, calldata, approvals, slippage. A deterministic policy verifier evaluates that intent, plus a pre execution simulation of it, against a user defined policy, and the paper is explicit that the verifier never consults the model. The decision is then written into a signed Policy Decision Record, which the authors call a PDR, binding the approved intent, the policy and the simulation report to the exact execution bytes, with nonce based replay protection and an expiry window. A Solidity smart account recovers the signature on chain and re checks the chain identifier, the account, the target, the value, the calldata hash, nonce uniqueness and the validity window before it makes any external call. The authors summarize their own design in one line: the model proposes, the verifier disposes, and the chain enforces.

The evaluation, stated as the paper states it. Forty tasks across four attack categories plus benign utility, six baselines other than PACE, 2,800 trials over 10 seeds, run in the authors' deterministic sandbox. In that sandbox PACE reports a 0.00 unsafe execution rate and a 0.00 false positive rate on benign tasks, against 0.80 unsafe execution for the unguarded baseline. Ablations put the dominant safety factor not in the cryptography but in the policy itself: a permissive policy configuration raises unsafe execution by 57.5 percentage points, and removing the touched contract allowlist adds 12.5. Removing the calldata binding adds 2.5 points, and frees exactly the calldata mutation task. On chain, the authors measure PDR verification at 29,826 to 31,822 gas per transaction, which they note is 91.7 percent relative overhead on an approval and 50.5 percent on a swap. A local EVM case study in Foundry passes 11 of 11 smart account cases, including calldata mutation, target mutation, replay, expiry and wrong verifier rejections. A three model live evaluation over the same task suite, 595 trials in total, reports a guarded attack success rate of 0.000 for all three models, and, unlike the sandbox, benign false positives between 5.0 and 12.8 percent, which the authors attribute to model and parser variance.

Now the limits, because they are the most useful part of the paper and the part most likely to be dropped in summary. The authors write that their evaluation uses a simplified in memory simulator and a regex based mock model, and that results demonstrate logic level safety properties that should not be extrapolated to live chains or adaptive adversaries without further evaluation. They frame their claims, in their own words, as logic level safety within a reproducible benchmark rather than deployment ready decentralized finance security. They state the PDR is not outcome binding: the contract does not replay the simulation on chain, so a transaction approved in one chain state can execute in another with different prices or reserves. They state that soundness depends on the checked fields being reconstructed from decoded calldata by trusted code rather than taken from the model. A mainnet fork harness ships with the artifact, and the paper explicitly makes no fork result claims unless the corresponding result files are generated. And in the adaptive adversary study, PACE blocks 8 of 8 evasion attempts by an attacker who knows the policy, while PACE and every baseline admit 8 of 8 transactions that stay inside the policy and are still economically harmful, among them a five leg drain whose individual legs each sit under the cap. The authors call that a non guarantee by design: the system enforces the declared policy, one transaction at a time, and they leave multi step composition to future work.

Artifact status matters here too, and it is easy to get wrong. The paper says an anonymized artifact accompanies the submission for review, containing source, contracts, task definitions, raw result files, Foundry logs and live model traces, and that the repository will be open sourced upon acceptance. So the design is documented and the results are stated as reproducible by reviewers. There is no public repository to read at the time of writing, no license on code, no deployment and no production adoption. Documented design, review artifact, benchmark demonstration and production use are four different things, and only the first two are established here.

Read against the rest of this article, PACE is the same argument arriving from the opposite end. AWS and Solv Labs govern a payment before it settles and leave a signed record of that governance. The OAuth draft argues that a grant proving general authority is not evidence that one specific action was authorized. PACE takes the narrowest slice of that problem, a single on chain transaction, and asks whether the decision survives contact with execution, then answers with a hash. That is a narrower question than the one sequence level authorization work asks about compositions of individually permitted actions, and the paper says so itself by admitting the multi step case. It is also narrower than the general problem of where agent authority is actually enforced. Moona Intelligence reads it as one specific, evaluated instance of a pattern this publication has been describing in prose: user policy, then an explicit action intent, then a deterministic decision, then signed evidence of that decision, then verification at the moment of execution, then an irreversible financial effect. The authors do not use that framing, and it is not attributed to them.

What I would not take from this paper is a claim that agent payments are now safe. The paper does not say that, and says several times that it is not saying it. What I would take is smaller and harder to argue with: a prior approval, a passing simulation or a valid policy decision is not authorization of whatever eventually executes, unless something binds the two together and re checks the binding at the point of no return.

The limits are written into the card itself

On June 9, 2026, Rain, a stablecoin payments infrastructure company that issues cards as a principal member of Visa and Mastercard, announced something it calls the Agent Control Layer: controls, embedded across its APIs, over how AI agents spend on cards and move money on behalf of users. That announcement is two months older than the update you are reading. What put it in this article is August 18, when Rain launched a coalition around the same questions, covered in the next section. The product evidence deserves to be read first, and read precisely, because Rain's own material is unusually specific about where its controls sit, and because everything in this section is Rain's own description unless stated otherwise.

The dimensions Rain describes will look familiar from everything above. Through its APIs, a partner configures acceptable merchant category codes, approved merchants or payment recipients, transaction amounts, transaction frequency, the number of agent cards active at any one time, and card expiry. At the level of an individual agent, a user defines what the agent can do before it acts: transaction amounts, merchant and category allowlists, spend intervals, expiry. At the program level, a platform caps the number of active cards and sets aggregate spend limits across its whole user base. And because Rain's platform also moves money outside cards, through virtual accounts, onramps, offramps and fiat and stablecoin payments, Rain states the same category of parameters applies to those flows too: approved counterparties, amounts, frequency and timing, defined before an agent is permitted to act.

The mechanism for agent spending is the scoped virtual card: a card issued for a purpose, which Rain describes as locked to a specific merchant, amount and task. Its worked example is an agent issued a card for a single booking, limited to approved airlines or hotels, capped at a set amount and restricted to a defined window. Outside those parameters, Rain states, the card does not transact.

Now the precision about what has actually been established, because this section would be worthless without it. All of the above is Rain's account, in its announcement and product pages. I could not inspect Rain's API documentation directly for this update, so which parameters the API actually exposes, and what a rejected transaction returns, is recorded as the vendor's description rather than as independently confirmed technical behavior. No public artifact demonstrates a transaction being declined. And one piece of product language deserves particular care: Rain says agent cards are retired the moment the task is complete. Whether that retirement is an enforced lifecycle event or an operator practice, what triggers it, and whether a retired card can be reused, is not described in anything public I could reach. The claim is recorded here, and so is the gap.

Rain is also explicit about the human boundary, in one sentence that maps directly onto the OpenClaw pattern above: changes to those payment terms require explicit action by a human administrator. Its example is a business that lets agents pay vendors, restricted to approved vendors, on a defined schedule, for a defined amount. The same reading discipline applies here as everywhere else in this piece. That sentence describes configuration authority, not per transaction approval: inside the configured limits the agent pays without a person confirming each transaction, and nothing in Rain's public material says otherwise. Who qualifies as an administrator, how that person authenticates, and whether an agent can request a change that a human then approves are not publicly documented. What the sentence does establish, as a stated design commitment, is the separation this article keeps finding: the agent spends inside an envelope, and the envelope is changed somewhere the agent is not.

Then the status question, because Rain's announcement holds two claims side by side and they should not be collapsed. The Agent Control Layer is, in Rain's own words, available in beta. The same announcement calls it production ready infrastructure, and states that agents have already been transacting on Rain's rails in production for months, booking travel, subscribing to software, running procurement workflows and moving money. Read carefully, the two claims describe different layers. The card issuing and money movement rails are Rain's existing business and predate the agent framing. The Agent Control Layer, the branded control surface over those rails for agents, is the part in beta. The production claim about agents is vendor reported. Rain names one partner, Sponge, a Y Combinator backed company issuing agent usable virtual cards against a user's stablecoin balance, and Sponge's own site confirms the relationship from its side, describing its card as issued by Rain. Beyond that, I found no named customers, case studies, transaction figures or independent reporting of agent activity on Rain's infrastructure. Months of production agent transactions is Rain's statement, corroborated only to the extent that Sponge exists as a live partner, and nothing more is claimed here.

What Rain's public material does not describe is the other half of this article. Scope, configuration and expiry, the grant layer in the OAuth draft's vocabulary, are specified in unusual commercial detail. What is absent is execution layer evidence: a record, produced when a permitted transaction goes through, of which configured constraints it was evaluated against and why it was allowed. Visibility and monitoring appear in Rain's material. A signed record of the authorization decision does not. That is not a verdict on a product I could not fully inspect. It is a map reference: as publicly described, the Agent Control Layer is the most specific commercial statement this article has covered of authority scoped into the payment credential itself, and it sits on the scope side of the line this piece has been drawing, not the evidence side.

More than twenty five companies, and no standard yet

On August 18, 2026, Rain announced the Agentic Payments Alliance, and that announcement is the reason this update exists. The founding membership is not small: more than 25 companies, including Visa, Mastercard, Fiserv, Circle, Solana and Remitly, alongside payments, fraud and issuing infrastructure firms such as Chainalysis, Fireblocks, Lithic, Sardine, Shift4, Turnkey and Uniswap Labs. American Banker and PYMNTS both covered the launch the same day, which matters here: unlike the June product announcement, whose trail is mostly the press release itself, the Alliance has independent reporting behind it.

What the Alliance is should be stated exactly, because the temptation to round it up is strong. Rain describes it as a working coalition, run collectively by its founding members, who will set its charter and mission together rather than have one company own it. American Banker reports that the member firms joined to work toward standardizing authorization and other risk management functions for agentic commerce, and that the group's early work is expected to involve shared research and frameworks, experimenting with emerging standards for agent identity and authorization, and advocacy on the regulatory questions agentic commerce raises. Rain's co founder and chief executive, Farooq Malik, put the motivation in one sentence: no single company should get to decide how agents transact on someone's behalf.

Now the list of things the Alliance is not, as of this update. It is not a standards body. It has published no standard, no technical specification, no repository and no interoperability test. Its charter, by Rain's own description, does not exist yet: the members will write it. Agent authorization is a named focus area, which is exactly why the Alliance belongs in this article, and a named focus area is a statement of intent, not an artifact. One inference should be refused outright: Visa, Mastercard, Fiserv and Circle joining a coalition Rain convened establishes nothing about whether any of them use, or ever will use, Rain's Agent Control Layer. Membership is not adoption, and Rain's materials do not claim it is.

Read against the rest of this piece, the Alliance belongs to the same pattern as the Internet-Drafts a few sections up: the authorization question has reached the stage where organizations that do not otherwise coordinate are creating venues to argue about it. Several unrelated draft author groups at the IETF, a governed payments implementation, a research preprint, and now a payments coalition whose stated early work includes authorization. None of these artifacts is a standard. What they establish together, and this is Moona Intelligence's reading rather than anything Rain says, is that the market has stopped treating an agent's access to a payment rail as the end of the design, and started treating the boundaries of the agent's authority on that rail, which counterparty, what amount, what task, what window, how often, as infrastructure to be built before the transaction happens and argued over in public. Who ends up owning that boundary, the card issuer, the network, a protocol or the operator, is precisely what a coalition like this exists to contest.

Four roles, and which one can enlarge its own authority

On 18 August 2026, AWS announced that AgentCore payments is generally available, six days after the Solv Labs implementation above and one day after the OpenClaw walkthrough. The underlying capability does not change at general availability: agents still pay over x402 for APIs, MCP servers and paid content, still through Coinbase and Stripe Privy embedded wallets. What AWS adds at this stage is documented support for the Machine Payment Protocol and an upto payment scheme alongside x402, a Quick Create flow for Coinbase credential provisioning inside the AgentCore console, a curated Bazar MCP server of pay per use x402 endpoints, and, per AWS's Regions documentation, availability in four Regions: US East (N. Virginia), US West (Oregon), Europe (Frankfurt) and Asia Pacific (Sydney). None of that changes the authority architecture described above. It is the same service the May preview and the two August implementations were built on, now out of preview.

What general availability does add is AWS's own name for the architecture the OpenClaw walkthrough showed in practice without labeling it. AWS's IAM documentation for AgentCore payments describes four roles. A ControlPlaneRole administers the service at the account level. A ManagementRole configures payment managers, instruments and sessions, the identity a developer or a deterministic setup pipeline uses to provision the wallet and create a session, and in AWS's own example policy it carries an explicit Deny statement on the ProcessPayment action. A ProcessPaymentRole, scoped to the payment execution path, is the identity that actually calls ProcessPayment against a session's resources. A ResourceRetrievalRole is what the service itself assumes, not a customer identity, to read session and credential state at runtime. AWS states the reason for the split directly: separating management from execution means a single compromised identity cannot both create a session with an unbounded budget and execute payments against it.

Two things about that architecture are worth stating precisely, because each is easy to round up into something stronger than the documentation supports.

First, nothing in what AWS documents shows the ProcessPaymentRole able to create, update or delete a PaymentSession, create a payment instrument, change a limit, or replace a credential provider. Its documented scope is the ProcessPayment action plus the read operations needed to check a session's status. On the IAM actions AWS's own examples grant it, a role limited to that set cannot expand the budget it executes against. It can spend what a separate identity already authorized, and nothing beyond that.

Second, that separation is IAM the customer configures, not a constraint AgentCore applies to every account regardless of setup. The explicit Deny on ProcessPayment that keeps the ManagementRole from also executing payments is a statement in AWS's example policy, not a restriction the service enforces by default. A customer who attached ProcessPayment permission to the same role that manages sessions, or who granted one identity every permission across all four roles, would not be stopped by AgentCore itself from doing so. They would simply have configured the two functions AWS recommends keeping apart back into a single identity. AWS's documentation, and the OpenClaw walkthrough built on top of it, describe a genuine, well reasoned architecture for keeping authority to create a grant separate from authority to exercise it. Whether that separation exists in a given deployment depends on whether whoever configured IAM followed it. AWS recommends the architecture. It does not, on the evidence reviewed here, force it.

The same distinction between what the platform provides natively and what a deployment layers on top of it applies to PaymentSession itself. AWS's core concepts documentation for AgentCore payments describes a PaymentSession as carrying a maxSpendAmount, a currency and an expiry, and that budget is cumulative across the session's lifetime rather than a per payment allowance: each ProcessPayment call checks the remaining balance before a transaction is signed, and a failed signing attempt does not consume it. What the core service does not document is a native per payment ceiling, a recipient allowlist, or a network or asset restriction as fields of the PaymentSession object itself. Those constraints appear in the OpenClaw walkthrough and its aws-agents-pay plugin, which validate the requested resource's origin and path, the network, the asset, the recipient and the amount against an operator configured policy before it calls ProcessPayment. That check runs in the plugin, layered on top of the session budget and expiry AgentCore payments enforces natively. Crediting a recipient or network restriction to AgentCore payments itself, rather than to the policy an integration builds around it, would attribute the control to the wrong layer.

What happens to a session after it exists is also narrower than it might sound. DeletePaymentSession removes the session record, and AWS documents that further payment requests against a deleted session are denied, the same outcome as an exhausted budget or an expired session. Nothing in AWS's public documentation for AgentCore payments reviewed for this update describes what happens to a ProcessPayment call already in flight when a session is deleted, or whether a payment already signed and settled can be reversed. Settlement over x402 moves stablecoin value between wallets, and nothing in the documentation reviewed here claims that step is reversible once it clears. Where AWS's material is silent on revocation reaching an in flight or completed payment, this piece leaves the question undocumented rather than assuming an answer in either direction.

Read against everything above this section, general availability does not add a new authority question. It gives the question this article has been asking since 17 August a name AWS itself uses, and it narrows exactly one thing: whether the separation between creating a payment session and spending against it is something AWS's platform guarantees, or something AWS's platform makes easy to build and easy to get wrong. The documentation available says the second. The runtime cannot enlarge its own budget only if whoever set up its IAM roles built it that way.

A payment ends. A loan does not.

MoonPay, a crypto payments company, launched PayBox on 29 July 2026: a payment vault that connects to Claude and ChatGPT and lets either assistant prepare a payment or an onchain transaction on a user's behalf without receiving the user's private key or other raw credentials. The permission model is one this article has now traced across several unrelated vendors under different names. PayBox exposes two modes. Always Ask requires passkey approval before every transaction. Autonomous lets the connected assistant act within limits the user sets in advance, without a person confirming each eligible transaction separately.

On 27 August 2026, MoonPay added Kamino, one of Solana's largest lending protocols, as a plugin inside PayBox. MoonPay's own framing is that eligible users can now supply supported assets to Kamino's lending markets or borrow against supported collateral, from inside a Claude or ChatGPT conversation, with worked examples given as asking the assistant to supply 500 USDC on Kamino, or to borrow USDC against SOL. MoonPay states the same PayBox permission rules that govern every other transaction, Always Ask or Autonomous, apply to Kamino as well; nothing reached for this update describes a separate, stricter mode reserved for borrowing specifically. The plugin is live inside PayBox, not merely announced, and MoonPay states it is not currently available to users in the United States, the United Kingdom, the EU or Australia. That is a fact about eligibility, not evidence this article treats as bearing on the authority architecture, and it is recorded here only for completeness.

Supplying an asset to Kamino for yield and borrowing against collateral are not the same consequence, and this article keeps them distinct rather than folding both into a general description of DeFi activity. Supplying moves an asset into a lending market in exchange for yield; the supplier can withdraw it, subject to the market's own liquidity. Borrowing creates debt secured by the collateral posted for it. That debt carries interest, a collateral dependency and, if the value of the collateral falls far enough relative to what is owed, a state in which Kamino's own protocol rules permit a third party to liquidate the position, whether or not the AI agent, MoonPay, or the user does anything further after the borrowing transaction settles.

Transaction authority is not position authority

Everything this article has examined until now answers one question: may the agent submit this specific transaction. A payment session's budget, a scoped card's merchant lock, a passkey approval bound to one action, all of them gate a discrete, self contained event. Once it settles, the authority that permitted it has been spent, and nothing about the agent's standing changes as a result.

A Kamino borrow does not fit that shape, and MoonPay's own material does not claim it does. The transaction that creates the loan is gated the same way every other PayBox transaction is, by a passkey under Always Ask or by a standing limit under Autonomous. But what that gate authorizes is not only the transfer of value at the moment of borrowing. It is the creation of a financial position, debt against posted collateral, that persists after the transaction, exposes the user to interest and liquidation risk, and will, at some point, require further decisions, add collateral, repay some or all of the debt, or do nothing and accept the risk, that the original borrowing transaction did not itself make.

Moona Intelligence reads that as two different questions sharing one approval mechanism, not as a single question MoonPay has already answered. Call the first transaction authority: may the agent submit this individual, self contained action. Call the second position authority: may the agent create a continuing financial exposure that outlives the transaction that opened it. Neither term appears in MoonPay's material, and this distinction is Moona Intelligence's reading of the consequence Kamino support introduces, not a framework MoonPay itself states. What MoonPay's public material establishes is that PayBox gates transaction authority, thoroughly and by the same mechanism regardless of what the transaction does. What it does not establish, because nothing found for this update addresses it, is whether the Always Ask or Autonomous decision a user makes about individual Kamino transactions is understood, by the product, its documentation, or the user granting it, as also being a decision about the standing position that results.

What PayBox persists, and what the prompt does not grant

The natural language instruction, supply 500 USDC on Kamino, is not by itself the authority grant. MoonPay's help documentation describes a separate persisted object: an agent client, the identity PayBox uses to authenticate and authorize a specific connected assistant, carrying its own grant, its own approval mode and its own audit trail, distinct from any one conversation held with it. The grant, not the prompt, is what PayBox checks on every request, and MoonPay's guidance to users is to start an agent client with a narrowly scoped grant, one wallet, one approval mode, a low spend limit, and expand it only as trust in the agent's behavior builds. That is a real separation between the standing authority a user has configured and the specific instruction a conversation happens to contain, and it means a user typing borrow USDC against my SOL is invoking a grant that already exists rather than creating one in that moment.

What that grant is understood to cover semantically is a narrower claim. Under Always Ask, the individual requested action, this transaction, this amount, this asset, is what the passkey approves, and that mandate is about as strong as a mandate gets: a human looked at one specific thing and approved it. Under Autonomous, what is delegated in advance is described publicly only as limits chosen by the user, and this article preserves that exact level of specificity rather than filling it in. No public MoonPay material reached for this update itemizes which fields an Autonomous grant can constrain for a Kamino transaction specifically, whether that is a maximum transaction amount, a maximum outstanding debt, a specific collateral asset, a loan to value ceiling, a health factor floor, a permitted protocol, or something else. Whether a user setting Autonomous limits for their PayBox agent is understood, by the product or by the user, to have authorized standing borrowing exposure up to some ceiling, or only individual transactions up to some ceiling with no aggregate view of outstanding debt, is not established by anything reached for this update. This article records that gap rather than resolving it in either direction, consistent with how it has treated undocumented limit dimensions everywhere else above.

Signing capability is not authority to use it

MoonPay states that PayBox wallet keys are protected using threshold cryptography and secure enclaves, key material split by multi party computation across hardware isolated environments such that no single party, not the user's device alone, not MoonPay, and not the connected AI assistant, ever holds a complete signing key or can sign independently. Corroborating detail describes this as built on infrastructure from Sodot, a key management company MoonPay acquired, with a signing operation requiring a quorum of key fragments held in physically separate, hardware protected enclaves.

That architecture answers a narrower question than authorization does, and this article keeps the two apart the same way it did for AgentCore's IAM roles and for Rain's card issuance above. Threshold signing determines whether a signature can be produced at all without any single party, including a manipulated AI assistant, being able to forge one alone. It says nothing about whether producing that signature for this specific transaction, or for a transaction that opens a Kamino borrowing position at all, was something the user had actually authorized. Signing capability is a control plane property: it constrains what can be signed regardless of intent. Authority to use that capability is a permission plane property: it is what Always Ask and Autonomous are supposed to express. MoonPay's own passkey requirement, sitting in front of the signing step rather than being the signing step itself, is consistent with treating the two as separate layers. Nothing reached for this update suggests MoonPay conflates them, and this article does not either.

One action, not a standing key

MoonPay states that every passkey approval under Always Ask is scoped to a single action, cannot be reused, and expires once it is exercised, language that reads as a direct answer to the replay problem this article raised in the PACE section above: an approval that cannot be reused cannot be widened into standing access, and a captured approval is worthless a second time. That claim is corroborated across independent reporting of MoonPay's own material with consistent wording.

What is not established, because no source reached for this update specifies it, is exactly which fields a single action approval binds. PACE's answer to the same question, discussed above, is explicit: the chain identifier, the account, the target contract, the value, the calldata hash, a nonce and a validity window, re-checked on chain at the moment of execution. Whether a PayBox passkey approval binds an equivalent set for a Kamino transaction, the specific contract called, the method, the asset, the amount, the recipient, the calldata, or binds something looser that a downstream step could still mutate before execution, is not publicly documented anywhere this article could reach. This article records that as MoonPay's first party claim about scope and reuse, with the exact technical binding undocumented, rather than assuming PACE's binding model applies here because the two solve an adjacent problem.

MoonPay also states that changing permissions, presumably including switching Always Ask to Autonomous, raising a limit, or adding a new asset or protocol to a grant, always requires a new human passkey approval. That is the same separation this article drew from the OpenClaw walkthrough above, authority to act is not authority to grant yourself more authority, appearing again in a second, unrelated implementation. If accurate as described, an agent operating inside a PayBox grant cannot expand that grant's own limits, including any limits that govern Kamino borrowing, without a human passkey approval outside the agent's reach. No source reached for this update describes an exception, and none is claimed here.

Revoking the agent is not closing the loan

MoonPay states PayBox access can be revoked at any time, either by revoking one agent client's grant from the dashboard, which MoonPay says immediately prevents that client from making further requests, or by a kill switch that revokes every connected agent at once. That is authority revocation: it stops new requests from an agent from being honored going forward.

The distinction matters more for a Kamino borrow than for a discrete payment, because a discrete payment leaves no ongoing relationship between the user and the counterparty once it settles, while a borrowing position does. A user who revokes their agent's access still holds whatever debt and collateral exposure that agent's prior, authorized borrowing created, and still needs to manage it, add collateral, repay debt, or accept liquidation risk, through some other path, since revocation closed the door the agent used to act, not the position the agent already opened.

Maintaining a position is a further authority question

Kamino's own protocol mechanics mean an open borrowing position is not static. Its collateral value moves with the market, its debt accrues interest, and its standing relative to Kamino's liquidation threshold changes without anyone taking any action at all. Managing that position, adding collateral to improve its standing, repaying debt to reduce it, refinancing, or withdrawing supplied collateral once a loan is closed, are each further onchain actions, and nothing reached for this update establishes that a user's original grant, under either Always Ask or Autonomous, is understood by PayBox or by MoonPay's documentation to extend automatically to those follow on actions. Under Always Ask, each one would presumably require its own passkey approval, consistent with the single action model described above. Under Autonomous, whether ongoing position management falls inside whatever limits a user configured, or requires a separate, explicit grant of its own, is not documented anywhere this article could reach, and this article does not assume an answer.

Liquidation itself is not an action the agent, MoonPay, or even the user takes. It is a consequence Kamino's own protocol rules apply to a position once collateral falls far enough relative to debt, executed by a third party liquidator the borrowing position never selected and does not control. The user authorized borrowing action can place collateral into a state where third party protocol liquidation later becomes possible under Kamino's rules; describing the agent as authorizing the liquidation itself would misstate where that decision actually sits.

One authority grantor, at the end of a delegated chain

The immediate authority grantor throughout is the PayBox user, not Claude or ChatGPT and not Kamino. Connecting an assistant to a PayBox agent client does not, by itself, create financial authority; the grant configured on that client does, and MoonPay's documentation describes that grant as something a user sets up and narrows or widens deliberately, separately from any one conversation. That puts PayBox alongside the multi agent payment chain this article has already examined, where authority passed from a human through more than one agent before a payment executed: here, a user's PayBox grant is exercised by Claude or ChatGPT, checked and enforced by PayBox's own policy and signing layer, and finally executed against Kamino's smart contracts, three distinct systems none of which independently originates the authority the transaction runs on. It also sits beside two records this article has not yet linked to directly. Robinhood's account isolation and spending caps and Binance's per trade approval against a predelegated subaccount both scope what an agent can do to an account holding real value, without addressing what happens once the account's exposure can outlive any single approved action, which is exactly the gap a collateralized loan opens. And BNB Chain's Altana integration, which keeps a connected agent from ever holding the wallet's own keys while still letting it transact, is the same signing capability separation MoonPay describes for PayBox, arrived at through a different cryptographic mechanism, session keys rather than threshold signatures, for the same underlying reason: the party executing a transaction and the party who can authorize it should not be reducible to the same holder of one secret.

What none of those four records, or MoonPay's own material, currently states outright is whether a decision to delegate standing authority for discrete transactions was ever meant to cover, or was understood by anyone granting it to cover, the decision to hold a continuing, market exposed financial position. That is not a defect specific to MoonPay. It is the same gap this article opened in May, whether an evidence trail exists for why a consequential action was authorized, arriving at a sharper edge: for a payment, the consequential action and its authorization are the same size. For a loan, they are not, and nothing reviewed for this update, from MoonPay, from Kamino, or from any implementation this article has covered, currently draws that boundary explicitly.

A third assistant, not a new product

On 31 August 2026, MoonPay stated that PayBox is now live inside Grok, X's native chatbot, a month after the 29 July 2026 launch that connected PayBox only to Claude and ChatGPT and four days after the Kamino addition above. Reporting attributes the announcement to MoonPay directly, dated the same day, and describes Grok users able to request the same kind of transactions this article has already covered under Claude and ChatGPT: buying stablecoins, swapping tokens, bridging assets between chains, interacting with decentralized finance protocols including Kamino, and preparing traditional purchases, in each case with Grok assembling the request and a human approving it through a passkey before anything moves. That sequence, prepare then approve, is the same Always Ask shaped flow this article has already traced through Claude and ChatGPT; nothing found for this update describes Grok as running under different authority mechanics from the rest of PayBox.

This article keeps three dates that are easy to blur apart. PayBox itself launched 29 July 2026. Kamino was added as a plugin on 27 August 2026. Grok is a third assistant connecting to that same underlying vault on 31 August 2026. None of the three is the others, and treating the Grok integration as a second product launch, rather than a new client of an existing one, would misstate what actually changed: the agent client and grant architecture below is unchanged by which assistant is issuing requests against it.

Two modes became three

The 29 July 2026 launch, and this article's own earlier sections above, describe PayBox's authority model as two approval modes: Always Ask, where every transaction requires passkey approval, and Autonomous, where the connected assistant acts within limits the user sets in advance. MoonPay's current help documentation, read for this update, names three: Always approve, where every operation pauses for explicit sign off before PayBox executes it; Approve above limit, where small, pre scoped operations run automatically and anything larger or outside the defined scope requires approval; and Autonomous within policy, where the agent acts without per operation approval inside a tightly defined grant the user has configured.

This article treats that as a documented product evolution, not a correction of what the launch said. Always Ask maps onto Always approve. Autonomous maps onto Autonomous within policy. Approve above limit is new: a middle mode that was not named at launch, sitting between full per transaction confirmation and full pre configured autonomy, gating only what falls outside a pre set limit rather than every operation or none. Whether Approve above limit existed as unnamed launch behaviour or was added afterward is not established by anything reached for this update, and this article does not assume either. What it does note is that Fortune's 31 August 2026 coverage of the Grok integration still describes the two mode version, Always Ask and Autonomous, rather than the three mode names MoonPay's own current help documentation uses, which this article reads as secondary reporting lagging a documentation change rather than evidence the three mode model is not yet in effect. This update treats MoonPay's current help documentation as authoritative for current behaviour, consistent with how it has treated documentation versus launch material everywhere else in this piece.

What a changed field forces

MoonPay's current help documentation describes the object PayBox actually checks in more structural detail than the launch material did. An agent client is the identity PayBox uses to authenticate and authorize a specific connected assistant, and two things make it functional: a grant, which defines what the agent client is allowed to do, and a client key, the secret the agent presents to authenticate as that client. MoonPay is explicit that these are different layers. The client key proves a request comes from the agent client it claims to come from; it does not itself expand what that client may do. Anyone holding a valid client key can make requests as that client, but the grant, not the key, is what PayBox checks against every request, and MoonPay's guidance is to start a new agent client with a narrowly scoped grant, one credential, one approval mode, a low limit, and widen it deliberately as trust in the agent's behaviour builds.

The grant itself, per current documentation, names which credentials the agent client may request, what operations are allowed, what scope limits apply, and which of the three approval modes above the client runs under. Every approval request PayBox generates shows a human the full context before a decision is made: the requesting agent client, the credential being accessed, the merchant or destination, the amount and currency for a payment, the chain and contract for a wallet operation, the secret name for a secret request, and the request's own expiration time.

Two further behaviours current documentation states plainly. If a human does not respond to an approval request, it times out; the timeout is itself logged as an audit event alongside approvals and denials, and the agent cannot proceed with that operation, which this article reads as the same principle stated everywhere else in this piece in different vendors' words: an unresolved approval is not executable, silence is not consent, and a request that expires unanswered does not default to permission. And every individual passkey approval, per current documentation, is scoped to one action and expires once exercised, consistent with, and now more precisely sourced than, the single use claim this article already recorded from the July 29 launch material above. Changing a grant's own limits, not just an individual operation's parameters, is stated separately as always requiring a new human passkey approval; nothing reached for this update describes an agent requesting a change that a human then grants as a distinct, named flow, so this article records only that the agent cannot enlarge its own grant unilaterally, not whether a request-then-grant pattern exists alongside that constraint.

What comes back is not always the same shape

MoonPay's current documentation is explicit that PayBox does not return the same thing for every credential type, and this article preserves that distinction rather than describing a single universal output. For a payment operation, what an agent receives is a scoped payment token or a one time virtual card, restricted by merchant, amount, currency, expiration and use count. For a wallet operation, it is a signature, a signed message or a transaction hash; private keys, seed phrases and MPC key shares are never returned. For a secret an agent has been granted access to, the raw secret is returned as stored, according to the grant's own rules, which current documentation states without qualification. That third case matters because it is the one place this article's own earlier claim, that PayBox never exposes an underlying credential, does not hold without exception: cards and wallets are tokenized so an agent never sees the underlying material, but a secret, by the nature of what a secret is for, passes through as itself once a grant permits it.

MoonPay's current material also describes what PayBox is not, in terms this article has been building toward since the AgentCore sections above without a vendor stating it this directly: PayBox is a control plane, not a custodian, money transmitter, payment processor or party to the transfer itself. Funds move directly between the user's funding source and the merchant or recipient; MoonPay states PayBox does not hold, transmit or move money or digital assets on a user's behalf, and that on chain value never passes through PayBox. What PayBox gates is who may authorize a payment and under what conditions, not the settlement of the payment itself. That separates authority control from payment settlement the same way this article has separated authority from evidence throughout: a control plane that decides whether a transfer is allowed to happen is a different system from the rails that carry it once it is. Card transactions are described as routing through Visa's agentic commerce protocol as the external settlement rail; nothing reached for this update states that Visa's protocol, x402, or any other settlement rail inherits PayBox's own grant and approval evidence, and this article does not assume that propagation without a source stating it, consistent with how it has treated authorization propagation across systems everywhere else above.

A card that the FAQ says is not there yet

Here this article records a conflict it cannot resolve rather than smoothing it over. Coverage of the 29 July 2026 launch describes card payments as functioning through Visa's agentic commerce protocol at launch: a verified agent passing the payment details a merchant expects, with one time virtual card numbers scoped to a single merchant and amount, so that a raw card number is never stored by or visible to the agent. MoonPay's current PayBox FAQ, read for this update, states instead that payment card support is coming in a future phase, described in reporting on that current documentation as Phase 2. Those two statements describe card functionality in PayBox in different states, live at launch against not yet shipped now, and nothing reached for this update explains the difference: whether the launch described a capability that was subsequently delayed, whether the launch overstated what shipped on 29 July, whether availability differs by region or account, or whether the current FAQ language is itself stale. This article does not guess. It records card status inside PayBox as unresolved, and narrows what it treats as established PayBox capability to wallet, chain and secret credential operations, the categories current documentation confirms without contradiction.

A wallet daemon reaches for a merchant network

On September 3, 2026, Korean trade and crypto press reported a memorandum of understanding between Infinisoft, a Seoul based payment gateway founded in 2011, and IOTRUST, a Korean digital asset security company founded in 2017, to jointly pursue what the announcement calls WAIaaS based agentic payment. Every outlet this article could locate, TokenPost, Edaily, HelloT, FinTech Times Korea and DevTimes, carries near identical text describing the same role split and the same stablecoin plan, which is the pattern of a single press release distributed to multiple outlets rather than several outlets independently reporting the story. This article treats that convergent coverage as one evidence event, not five, consistent with how it has treated syndicated coverage of MoonPay's own announcements above. Direct access to tokenpost.kr, edaily.co.kr, hellot.net, fintechtimes.co.kr and devtimes.co.kr was blocked by the network egress proxy in this environment on every attempt; what is reported here about the announcement's own text is corroborated through multiple independently phrased search passes returning consistent, matching Korean language detail, not read directly from a rendered page. No first party post specific to this announcement could be located on either company's own site or blog channels, which is common for Korean MOU announcements distributed through press wires rather than separately published, and is recorded here as a limitation rather than assumed to mean no such post exists.

The announcement's own role split, corroborated consistently across every outlet found, is this. IOTRUST is responsible for agentic commerce WAIaaS technical support and building the AI technology environment. Infinisoft is responsible for the InnoPay merchant network, building the payment system side, and operating merchant payout and settlement processes. The stated aim is joint development and verification of stablecoin based AI payment and settlement services using assets such as USDT and USDC, described in one fuller summary as covering: applying agent payment technology inside InnoPay's existing merchants, connecting WAIaaS to online and offline payment networks, reviewing stablecoin based settlement structures, developing scenarios for an agent paying for content, APIs, products and services, reviewing payment authority and limit policy, and running joint proof of concept work.

The two companies are not a generic pairing of a fintech and a wallet vendor. Infinisoft operates InnoPay, an integrated online and offline payment system, holds PCI DSS 4.0 Level 1 certification, the top tier of the global payment card data security standard, and is itself a registered electronic financial institution that can settle directly or route through nine partner payment gateways including NICE, KICC and KSNET. IOTRUST is best known for D'CENT, a biometric hardware wallet it has sold since 2018, and its public GitHub organization is the canonical home of the WAIaaS project itself, with the account behind the bulk of its commit history identified in the repository as IOTRUST's own. That matters for how this development should be read: this is not a payment gateway adopting a third party's wallet product. It is WAIaaS's own maker bringing its wallet daemon to a payment gateway's merchant network, which is exactly the adoption direction the durable question below asks about.

What WAIaaS's own source establishes

WAIaaS is a self hosted wallet daemon for AI agent transactions, and this article inspected its current public source directly, at github.com/waiaas/WAIaaS, rather than relying on the partnership announcement's own description of it. The repository's documentation carries dated front matter placing its security architecture at least as far back as February 9, 2026, and commit and version history well past that by April 2026, establishing the project predates this partnership by months, consistent with what this article's own guidance for this update asked it to determine rather than assume.

Three authorization roles run through the whole design, and the names matter because they name three different actors, not three settings on one account. masterAuth is the daemon operator: a master password authenticates administrative actions, wallet creation, policy configuration, session management and system settings. ownerAuth is the fund owner: a per request wallet signature, corroborated by WalletConnect and Telegram channels described below, authorizes transaction approval and kill switch recovery. sessionAuth is the AI agent: a scoped bearer token, issued per wallet, authorizes wallet queries and transaction requests. That is a real technical separation, three different credential types serving three different functions, and this article preserves the distinction the way it has for every other role architecture above: a daemon operator is not a fund owner is not an agent. What the separation does not establish, because nothing in the documentation or the authorization code this article reviewed addresses it, is whether the same human is prevented from holding all three credentials at once. The roles are cryptographically and functionally distinct. Nothing found here shows they are tied to distinct verified identities, so technical role separation is recorded here as established, and organizational separation of duties is recorded as not established, the same distinction this article has drawn for every other role architecture it has examined.

Four tiers, and what NOTIFY actually is

WAIaaS routes every transaction through one of four policy tiers, each with a documented default dollar threshold, configurable per deployment. INSTANT, at or below ten dollars by default, executes with no gate at all. NOTIFY, at or below one hundred dollars, executes and then tells the owner; this article confirmed directly in the pipeline source that INSTANT and NOTIFY both proceed through the wait stage with no pause, which means NOTIFY is exactly what its name says and nothing more, a notification about a transaction that has already happened, not a checkpoint before it happens. That distinction matters because it is easy to misread NOTIFY as a light weight approval mode; it is not one, and this article does not call it one.

DELAY, at or below five hundred dollars by default, queues the transaction for a configurable window, five minutes by default, and auto executes once the window passes unless it is cancelled first. APPROVAL, above five hundred dollars, halts entirely until the owner signs. Here this article records a discrepancy rather than resolving it in the vendor's favor: WAIaaS's own documentation states the owner can cancel a queued DELAY transaction, but the cancellation endpoint this article located in current source is gated by sessionAuth, the agent's own credential, checked against wallet access, not by a separate ownerAuth check. Whether a distinct owner only cancellation path exists elsewhere in the codebase was not established by what this article could review, and it records the documented claim and the code it could locate as not fully reconciled, rather than assuming the documentation is accurate about who holds the cancel authority.

Default deny, and what an unpriced asset does

Twelve policy dimensions govern what a transaction is allowed to do at all, independent of which tier it falls into: an amount tier, a daily limit, a rate limit, an allowed token list, a contract whitelist, approved spenders, a recipient whitelist, a time window, a maximum gas figure, a cumulative dollar limit with rolling daily and monthly caps, an allowed domain list for x402 payments, and an environment type flag. WAIaaS's own documentation states the token and contract lists are default deny, and this article confirmed that in source: an operation whose type cannot be determined is mapped to a contract call for whitelist evaluation, so an unrecognized action is denied by default rather than passed through for lack of a matching rule. Where a policy evaluation returns a denial, this article confirmed the pipeline halts immediately with no override path found that converts a denial into an execution; denial wins unconditionally in the source reviewed. And where an asset's price cannot be determined by whatever oracle the policy check consults, this article confirmed the code escalates that transaction's tier upward, to at least NOTIFY, rather than leaving it at whatever tier it would otherwise have qualified for. An unpriced asset is treated as more consequential, not silently passed through at face value.

Where the key lives

WAIaaS's pipeline runs six stages: validate, authenticate, apply policy, wait for delay or approval where the tier requires it, execute, and confirm. This article confirmed directly in the execution stage's source that the wallet's private key is decrypted from the daemon's local keystore only for the duration of signing, inside a code block that explicitly releases the key in a cleanup handler immediately afterward. The same decrypt, sign, release pattern governs smart account signing for account abstraction transactions. What that means for this article's recurring distinction between signing capability and payment authority is direct: the session credential, the one an AI agent actually holds, never receives the raw key at any point in this pipeline. It can request a transaction. It cannot itself produce a signature. That is the same separation this article has already found in AgentCore's IAM roles, Rain's card issuance and MoonPay's threshold signing, arrived at here through a fourth distinct mechanism, a daemon held key rather than a distributed one.

What an owner's approval actually binds

WAIaaS exposes an approval route keyed to a transaction identifier, gated by ownerAuth. This article confirmed in source what that identifier resolves to: a row in a transactions table, linked to a pending approval row carrying an expiry, an approval type and, where applicable, EIP 712 typed data describing what is being signed. While a transaction awaits approval its status is queued; approving flips it to executing and clears the amount WAIaaS had reserved against the relevant limits; rejecting cancels it; an unanswered request expires on a configurable timeout, falling back through a policy specific window, a global default, and a one hour hard default in that order. The approval and rejection endpoints both run inside an atomic database transaction that only matches a pending row that has not already been approved or rejected, which this article confirmed makes a second approval or rejection attempt fail outright: the approval is one shot and replay safe at the database level.

A kill switch with two settings, and what neither one undoes

WAIaaS's kill switch has two states above normal operation, SUSPENDED and LOCKED, transitioned atomically at the database level. SUSPENDED blocks every new transaction at the API layer but leaves existing sessions alive, and recovery requires only the daemon operator's masterAuth. LOCKED blocks transactions and freezes sessions, and recovery requires both masterAuth and ownerAuth together, a dual authority requirement neither role can satisfy alone. Activation, per WAIaaS's own account of the mechanism, cascades through revoking active sessions, cancelling pending transactions, suspending active wallets, returning a service locked response to new requests, sending notifications and writing audit log entries, each step attempted independently so one failure does not stop the rest.

Two boundaries matter here, and this article keeps them distinct the way it has kept revocation and reversal distinct for AgentCore, Rain and PayBox above. First, exactly what happens to a transaction already queued for DELAY or APPROVAL at the moment the kill switch activates was not established by what this article could verify; the cascade is described as cancelling pending transactions, but the precise mechanism was not confirmed in source this article could read directly, and this article records that as undocumented rather than assumed to work as described. Second, and with more confidence: nothing in WAIaaS's design claims to reach a transaction that has already been broadcast to a blockchain. Revocation stops the daemon from initiating anything further. It does not, and by the nature of a settled onchain transaction cannot, undo value that has already moved. That is the same distinction this article has drawn for AgentCore's session deletion and for PayBox's Kamino revocation: authority revocation is not the same operation as reversing an already produced financial effect, and WAIaaS's kill switch, however forceful within the daemon, is no exception to that rule.

Is every path gated the same way

This article looked specifically for a route that could sign or broadcast a transaction without passing through policy evaluation, because a bounded pipeline is only as strong as its least gated path. It found, and read directly, a second, separate signing pipeline behind a sign only endpoint intended for externally constructed transactions; that pipeline independently runs its own policy evaluation before signing, rejects the request outright if policy denies it, and, notably, refuses DELAY and APPROVAL tier requests altogether, directing higher tier transactions back to the ordinary six stage pipeline rather than allowing a second, less supervised path to reach them. Administrative credential endpoints this article reviewed return metadata only and never a decrypted secret value. No raw signing or key export endpoint was found in what was reviewed.

That is meaningful evidence against an obvious bypass, and it is not a claim of complete mediation. WAIaaS's daemon exposes more than forty route handlers, including integrations this article did not individually read for x402 payments, ERC 8004 and ERC 8128 agent identity standards, account abstraction user operations, and several DeFi and NFT specific endpoints. The two signing paths this article did verify both enforce policy before a key is ever touched. Whether every one of the remaining routes does the same was not established, and this article does not claim it, consistent with the instruction that complete mediation is never assumed without direct evidence for every path. Separately, and worth recording precisely: WAIaaS's own documentation names a genuine Model Context Protocol server package and a genuine x402 payment endpoint with its own allowed domain policy, both real implementations rather than passing mentions of either standard. Neither is a claim this article extends into a protocol interoperability finding beyond what WAIaaS itself documents, and neither changes anything about the authority architecture described above.

Authorization continuity is not yet established publicly

Put the two halves of this update together and a specific, narrower question emerges than production deployment or general capability. WAIaaS, on the evidence reviewed here, produces a bounded, evidenced authorization decision before a transaction executes: a policy evaluation, an owner approval where the tier requires one, and a signature the session that requested the transaction never holds. Infinisoft operates the payment gateway and merchant settlement infrastructure the announcement says WAIaaS is now reaching toward. What connects the two, on everything this article could find, is a stated intent to develop and validate, not a described mechanism.

Specifically: this article found no evidence, in the MOU coverage or in WAIaaS's own material, of any portable authorization artifact, a transaction identifier, a policy decision record, an approval signature, an agent identity, an owner identity, a settlement reference or a merchant identity, stated to travel from WAIaaS's authorization decision into Infinisoft's payment and settlement systems. A WAIaaS policy decision may be exactly as sound as this article's own inspection of its source suggests. Whether a merchant, a settlement processor, or Infinisoft's own systems downstream of WAIaaS would have any way to verify why that decision was correct, once the transaction reaches their side of the boundary, is not answered by anything reached for this update. This article does not read that gap as evidence of a vulnerability; nothing found here suggests the two companies have built and then failed to connect an authorization trail. It reads as the plainer fact that end to end continuity from a wallet's authorization boundary through a payment gateway to merchant settlement has not yet been publicly described by either party, for this integration or, on the evidence this article has gathered across every implementation above, for any agent payment implementation examined so far. That is the same question this article opened in May about whether evidence for a consequential financial action can be produced at the boundary where it is authorized. What this update adds is a second boundary, downstream of the first, where the same question now has to be asked again.

A second Korean architecture aimed at the same boundary

On the same day as the WAIaaS material above, a separate and unrelated Korean company put out a separate announcement addressed to the same open question this article has been circling since 12 August. Seoul Labs Inc., a Korean digital identity company already building a consumer identity and wallet product it calls Super Wallet, announced that it is developing an architecture it calls SeoulLabs Pay, described as designed to verify an AI agent's identity and delegated authority before a purchase and preserve the resulting authorization evidence through settlement. The announcement is company authored and distributed through EIN Presswire, and Seoul Labs' own domain names the same product. This article treats Infinisoft and IOTRUST's WAIaaS work and Seoul Labs' SeoulLabs Pay work as two independent developments rather than one, because they are: different companies, different starting points, no stated relationship between them, and nothing found for this update connects one to the other beyond both being announced the same week by Korean companies working on a version of the same problem.

What earns SeoulLabs Pay a place in this article specifically, rather than a separate one, is that its proposed sequence describes the exact gap the WAIaaS section above just left open. WAIaaS produces a bounded, evidenced authorization decision at a wallet's own boundary, and this article found no description of any portable artifact carrying that decision into a payment gateway's settlement systems. SeoulLabs Pay proposes, as a design, a principal identity, an agent identity, a signed mandate, a pre execution policy decision and an evidence envelope, in that order, aimed at exactly the property that gap is missing: authorization evidence that travels with a payment's effect rather than stopping at the boundary where the decision was made. That is why this update reads as an addition to this article's running question rather than a new one.

What Seoul Labs says it is building

The company's own description, read as a design rather than a shipped product, is specific. A principal completes KYC verification, and the resulting identity is linked to an AI agent credential the company states is compatible with W3C decentralized identifier and verifiable credential standards. Delegated spending authority is encoded into a mandate the company describes as signed and revocable, and names example dimensions the mandate can carry: approved merchants, approved assets, spending limits, an expiration, and triggers that require a human approval step. Before a proposed transaction executes, the company states a deterministic policy engine evaluates it against the mandate. An approved transaction is then bound into what the announcement calls a secure evidence envelope, carrying a principal reference, the agent's DID, a hash of the mandate, and settlement details, with the company stating raw personal data is kept off chain while evidence references link to an auditable ledger. The stated aim is a consistent authorization record across cards, bank transfers, stablecoins and on chain settlement, delivered through planned APIs, SDKs and white label modules.

Every sentence in that paragraph describes a claimed design, and this article records it that way throughout rather than upgrading any part of it once the description is specific. Direct access to Seoul Labs' own technical material was blocked by this environment's network egress controls on every attempt made for this update, the same limitation this article has recorded against dozens of other sources above, and repeated independent search passes, including in Korean, for SeoulLabs Pay, Know Your Agent, agent DID, mandate hash, signed mandate and payment evidence envelope returned no independent reporting, no technical documentation, no public API or SDK, no repository and no production demonstration. What those searches did return is corroboration that Seoul Labs is a real, active company with an existing, separately documented identity and credit scoring product, Super Wallet, unveiled at CES 2026 and covered by trade press months before this announcement. That corroborates the company. It does not corroborate SeoulLabs Pay as a shipped or independently verified architecture, and this update does not treat it as though it does. Per this article's own rule for a company announcement carrying no independent verification, that is an acceptable basis for recording a developing, claimed architecture, and not a basis for describing SeoulLabs Pay as built, interoperable or in production.

A KYC verified identity is not the same claim as delegation authority

The architecture's first step deserves the same scrutiny this article has applied to every other identity claim above. KYC verification establishes who a principal is and that they control the credential presented. It does not, by itself, establish that the principal is organizationally entitled to delegate the specific purchase authority a mandate would encode. A verified individual inside a company, for instance, is not automatically the person with standing to authorize that company's agent to spend against a given budget; that is a separate, internal entitlement question KYC does not reach. Seoul Labs' announcement does not address this distinction, and nothing found for this update describes a mechanism inside SeoulLabs Pay that checks organizational entitlement to delegate rather than mere identity. This article keeps the two apart rather than assuming the stronger claim, consistent with how it has treated grantor legitimacy everywhere else: identity verified is not the same fact as authority to grant.

The same discipline applies one layer up. An agent credential the company describes as W3C DID and VC compatible establishes, at most, that the credential conforms to a data format those standards define. It is a description of compatibility with a credential shape, not a claim that the W3C has certified the product or that any protocol interoperability has been demonstrated, and this article does not use either of those stronger phrases here. Whether the credential format on its own establishes only the agent's identity, or also carries the delegation itself, is not stated with enough specificity in anything reached for this update to say, and this article keeps agent identity and the mandate that grants it authority as two separate, unresolved questions rather than treating a valid credential as proof of a currently valid delegation.

A signed mandate with undocumented mechanics

Seoul Labs states the mandate is signed and revocable, and names the dimensions it can encode: merchants, assets, spending limits, expiration and human approval triggers. What the announcement does not state, in anything reached for this update, is the credential format the mandate uses, its signature scheme, its issuer, its subject, a version scheme, or the mechanism by which revocation actually propagates, whether that is a status list, a ledger entry, an API call or something else. This article does not infer any of those mechanics from the word signed or the word revocable. Each is recorded here as unknown. The same applies to the scope of what a mandate can name: this article records only the dimensions Seoul Labs itself lists, merchants, assets, spending limits, expiration and human approval triggers, and does not add merchant category, geography, purpose, transaction frequency or a cumulative budget as mandate dimensions, because nothing found for this update documents any of those as part of the design.

The distinction this article has drawn everywhere above between revoking authority and undoing a payment's effect applies here with the same force, because the announcement's own language, revocable mandate, invites exactly the conflation this article has been careful to avoid elsewhere. A revoked mandate is not described anywhere in what was reached for this update as reaching an in flight payment, let alone a settled one. Whether revocation is immediate, whether it is checked against a cache with its own lifetime, and what happens to a transaction already inside the policy engine's evaluation when the mandate underneath it is revoked, are not addressed in the company's own material, and this update records all three as unknown rather than assuming the more reassuring answer.

A policy engine and an envelope, both claimed

The pre execution policy check Seoul Labs describes is the same shape of claim this article has evaluated for AWS and Solv Labs, for Rain, and for WAIaaS above, and it gets the same treatment. Nothing reached for this update establishes a real, inspectable policy engine, its exact enforcement point, or its behavior when the engine itself is unavailable, fail open or fail closed. Absent that evidence, this article records the pre execution check as a claimed design, not a demonstrated one, and does not credit it with the kind of independently verified enforcement this article was able to establish directly from WAIaaS's own published source above.

The evidence envelope is the part of the announcement doing the most work for this article's own authorization continuity question, and it is also the part where the announcement's language most invites overreading. Seoul Labs names four fields the envelope carries: a principal reference, an agent DID, a mandate hash, and settlement details. What the announcement does not state is whether that envelope is a signed object, a hash chained record, data embedded directly in the transaction itself, sidecar metadata stored separately, a ledger entry, a database row inside Seoul Labs' own systems, a portable verifiable credential, or an API payload a counterparty could independently request and check. The phrase secure envelope, on its own, is not evidence of any one of those specific technical shapes, and this article does not select one. Most importantly, a mandate hash inside that envelope is not, on anything published, the same claim as a binding between the mandate and the exact final payment effect. The paper's own worked precedent for what that binding would need to look like is PACE, described earlier in this article, where a smart account recovers a signature and re checks the chain identifier, the target, the value and a calldata hash against the approved intent before executing. Nothing in Seoul Labs' announcement describes an equivalent re check at the point a card, bank transfer, stablecoin or on chain transaction actually settles. Whether the envelope binds the exact final payment effect to the authorized mandate is, on the evidence available for this update, unknown, and this article states that plainly rather than crediting the architecture with exact action binding it has not documented.

Cross rail continuity is a stated aim, not a demonstrated property

Seoul Labs states the architecture aims to preserve a consistent authorization record across cards, bank transfers, stablecoins and on chain settlement. That is a design intention, stated in exactly those terms, and this article preserves it as one rather than restating it as an accomplished fact. Whether a downstream card network, a bank transfer rail, a stablecoin issuer or an on chain settlement layer actually receives the agent's DID, the mandate, the mandate hash or the evidence envelope itself, and whether any of them can independently validate what they receive rather than merely store it, is not addressed anywhere in what was reached for this update. Nor is it established whether the envelope is one portable object that moves with the transaction or a set of separate evidence references Seoul Labs' own systems retain and reconcile only after the fact. The correct summary, on the evidence gathered here, is that Seoul Labs proposes an architecture intended to preserve consistent authorization evidence across multiple payment rails. It is not that authorization continuity has been solved, by Seoul Labs or by anyone else this article has examined, and this update does not claim SeoulLabs Pay is the first company attempting it, only that it is the first this article has found describing the full principal to envelope sequence in one proposed design.

Read next to the WAIaaS material immediately above, the two updates say different things about the same open question, and this article keeps that difference explicit rather than collapsing it. For WAIaaS and Infinisoft, this article found a wallet daemon's own authorization boundary independently verified against source, and no publicly described mechanism carrying that boundary's evidence into a payment gateway's settlement systems; that gap remains correct for that architecture and is not rewritten here. For SeoulLabs Pay, the full principal through settlement sequence is part of the stated design from the outset, but no technical documentation, API, SDK, repository or independent production demonstration exists yet to verify any part of it against source the way this article was able to verify WAIaaS. Two different distances from the same unresolved question, not one resolved and one not.

What this does, and does not, establish about human approval

Human approval triggers are named as one of the mandate's dimensions, and nothing beyond that phrase is documented in what this update could reach: not who approves, not what surface an approval happens on, not whether approval and mandate configuration are held by different parties, and not how long an approval, once given, remains valid. Consistent with how this article has treated every other claimed approval step above, that is recorded as claimed design pending an implementation this article has not been able to inspect, not as a demonstrated control.

A paper this update could not read

On 2 September 2026, a paper titled Agentic Settlement Protocol, An Application Profile for Refundable, Delayed Fulfilment Agent Commerce on Stablecoin Rails, was submitted to arXiv by Behnam (Beny) Mohammadkhani, Atul Khekade and Ritesh Kakkad, filed as arXiv 2609.02208, version 1. This update tried to fetch the abstract and full text directly, from arxiv.org itself, from ar5iv, from Hugging Face's paper index, from Semantic Scholar and from a general purpose reader proxy. Every one of those, and every secondary outlet this update tried to reach for a fuller account of the paper's substance, was blocked by this session's own network egress policy on every attempt, the same class of limitation this article has recorded against dozens of individual sources above, applied here to the primary source itself. What follows is bounded accordingly.

What multiple independently phrased search passes consistently corroborate, without ever surfacing the paper's own abstract or body text, is its indexed structural description: the paper runs thirty two pages, includes a seventeen case conformance suite in an appendix, specifies normative interfaces across four further appendices, and states that a companion document, an ASP-Lite Implementation Specification, is available from the authors on request. It is filed under cs.CR, cryptography and security. This update also independently corroborated that two of the three authors, Khekade and Kakkad, are the co founders of XDC Network, and that the third, Mohammadkhani, is described in a professional networking listing as a web3 developer at XinFin, XDC Network's founding organization; this update treats that listing as a weaker source than a first party statement and does not upgrade it further.

One distinction this update can state without reading the paper, because it follows from the title alone and from a distinction this article has already drawn for x402 above: an atomic, pay per request settlement, quote a price, pay it, receive the resource in the same exchange, is a reasonable fit for a metered resource a payer can inspect and consume immediately, an API call, a data feed, a piece of web content. It is not, by construction, a model of a purchase where the thing being paid for, a flight, a booking, a physical order, is only confirmed, delivered or fulfilled after the payment has already been authorized. That is not a claim that atomic settlement is defective; it is a claim that a single settlement event cannot represent two different moments in time that have not yet both occurred. Whatever Agentic Settlement Protocol's own paper actually specifies to close that gap remains unread and unknown; what its title states is only that it is aimed at that gap.

The layer underneath the claim, read directly

The paper's own title places its design on stablecoin rails, and the closest already implemented, open source authorize and capture layer for onchain commerce this article could independently verify is Commerce Payments Protocol, published by Coinbase and Shopify and developed in the open at github.com/base/commerce-payments. This update read the protocol's own documentation and its core contract directly rather than relying on the companies' announcement posts, and nothing reached for this update states that Agentic Settlement Protocol's own paper builds on, cites or requires Commerce Payments Protocol specifically; the two are recorded here as separate pieces of evidence about the same underlying question, not as one implementing the other.

Commerce Payments Protocol's own documentation describes an escrow contract, AuthCaptureEscrow, built around exactly the separation this article's title has been asking about since 12 August. An authorize call moves a payer's funds into escrow and marks them capturable, guaranteeing a merchant that payment is available without yet giving the merchant that payment. A capture call, restricted to the payment's designated operator, moves some or all of the capturable amount to the receiver, and can be called more than once against a single authorization for partial settlement. A charge call collects both steps into one transaction for purchases with no delay between authorization and settlement. Separately, a void call lets the operator cancel a still capturable authorization and return the funds to the payer outright, and a reclaim call lets the payer, and only the payer, recover whatever remains capturable once the authorization's own expiry has passed and the operator has done neither. A refund call, bounded to what was actually captured, lets the operator return already settled funds afterward. Each of these six functions is documented as a distinct, separately gated operation in the protocol's own docs, read directly for this update.

The protocol's own PaymentInfo structure, read directly from its Solidity source, is what a payer's own signature actually binds: the operator address responsible for driving the payment forward, the payer, the receiver, the token, a maximum authorizable amount, a minimum and maximum fee rate, a fee receiver, and three separate timestamps, a preApprovalExpiry after which the payer's signed authorization can no longer be exercised at all, an authorizationExpiry after which a still capturable amount can no longer be captured and instead becomes the payer's to reclaim, and a refundExpiry after which a captured amount can no longer be refunded. That is three distinct deadlines bound into one payer signed object, not one generic expiry, and it means the protocol's own contract already encodes, at the level of a smart contract's access control rather than as prose, the exact distinction this article's title states: a payer's authorization at one point in time does not by itself establish that the same funds remain capturable at a later one. Whatever additional deadlines or invariants Agentic Settlement Protocol's own paper specifies on top of this, for issuance, for inventory or for submission and finality margins, remain unread and unknown; this paragraph describes Commerce Payments Protocol's own three expiries, verified directly, not the separate paper's.

Two further properties, read directly from the protocol's own audit documentation and security notes, bound what an operator can actually do. Funds sit in a separate TokenStore contract per operator rather than one shared pool, so one operator's escrowed funds are not exposed to another operator's compromise. And the documentation states plainly that an operator drives which of these state transitions happens and when, but does not custody funds and cannot direct them anywhere the protocol's own rules do not already permit; a compromised operator can, on the protocol's own account of its threat model, misdirect fees or decline to act, not steal escrowed principal outright. The protocol reached this state through six recorded audits, three by Coinbase's own Protocol Security team and three by Spearbit, the most recent addressing a rounding and billing change in version 1.1.0. It is deployed identically to Base Mainnet and Base Sepolia through a deterministic factory, and its source is published under the MIT license. This update treats Commerce Payments Protocol's own authorize, capture, void, reclaim, refund and charge model as independently verified, implemented, audited infrastructure, distinct in evidence weight from the Agentic Settlement Protocol paper this update could not read, and does not credit the paper with any of it.

What this update did not find, for either artifact, deserves the same precision this article applies everywhere above to a claimed but unread instantiation. A search for independent evidence that Agentic Settlement Protocol's own paper has actually been built and run on XDC Network, the network the paper is reported to name, returned only XDC Network's own broader, separately announced agentic payments marketing: an x402 based payment marketplace, XDC AI, that XDC Network's co founders have publicly demonstrated using stablecoin settlement for API level purchases. Nothing this update could reach ties a specific repository, a deployed contract, or an on chain transaction to Agentic Settlement Protocol by name, as distinct from XDC Network's own general purpose agentic payments work. This update therefore keeps four things separate rather than treating any one as evidence for the others: a design paper, whose own text remains unread here; a reference implementation, for which no repository this update could reach was found; a public deployment, for which no contract address or transaction history was found; and production adoption, for which nothing beyond the authors' own reported affiliation with an already operating payments network was found. Until this session, or an editor with unblocked network access, can read the paper directly, this article records Agentic Settlement Protocol as an unread design submission whose stated aim, closing the gap between a payment being authorized and a payment remaining capturable once whatever it was paying for has actually happened, sits squarely inside the question this article has been asking since 12 August, without this article being able to say anything about how the paper itself proposes to close it.

End with the transaction

Everyone currently writing about AI agents is focused on the fact that they can now spend money. That fact is genuinely new, and it deserves the attention it is getting. What I think actually matters more is narrower and will outlast this particular product announcement: for a consequential agent action, the important question is not only what did it do. It is why was this specific action authorized to happen, and can anyone show that answer after the money has already moved.