An AI agent that can initiate payments needs a spending mandate that another system can enforce. A natural-language instruction such as buy what we need is useful context for a model, but it leaves unresolved who may receive funds, how much can be committed and when authority ends. Institutional deployment starts with those boundaries.
The issue is more specific than agentic commerce as a category. It concerns the authority granted to one software process acting for an organisation. A successful checkout does not establish that the purchase was permitted. The record needs to connect the mandate, the proposed purchase, the execution decision and the resulting payment.
Separate intent from execution authority
An agent may interpret a business goal and propose a purchase. A payment system should make a separate decision about whether the purchase fits the granted authority. That separation allows a model to reason about options while a more constrained component enforces a budget, destination rule or expiry. The institution needs to describe where each check occurs.
ERC-7715 provides a concrete wallet interface specification for requesting execution permissions, including permission types and rules such as expiry. It also describes discovering supported permission types. The document is evidence of a specified interface, not evidence that a particular wallet supports every rule or that the specification settles an institution's procurement policy.
A buyer should ask what the deployed implementation actually enforces. A user interface might display a spending limit while the underlying authority is broader. Conversely, a wallet may support a narrow token allowance while the business mandate needs supplier and product restrictions. The gap between displayed intent and executable authority belongs in the review.
Define the commitment being limited
A spending limit needs a unit, period and event that consumes it. Does the budget count submitted orders, accepted orders, settled payments or all outstanding commitments? The choice matters when a supplier accepts an order before payment completes. A mandate that counts only settled transfers may leave room for several obligations that collectively exceed the intended budget.
A hypothetical compute-buying agent illustrates the point. It places several short leases with separate suppliers. Each lease is under the per-purchase cap, yet the combined commitments exceed the team's period budget. The error is not solved by asking the model to be more careful. The execution layer needs a shared view of reserved, committed and released amounts.
Currency and asset definitions also need precision. A token amount is not automatically a fixed purchasing budget in another currency. The institution should specify the measurement method and permitted conversion conditions if its mandate uses both. This is an operating specification, not a forecast about token prices or a recommendation to use any particular payment asset.
Concurrent agents need shared reservations
Multiple agents can spend against the same budget. Even one agent may submit requests concurrently or retry after an ambiguous response. A check performed separately by each process can approve several payments against the same remaining amount. The institution therefore needs a budget reservation process with defined treatment of incomplete purchases.
Reservation creates another state to manage. When does it expire, and what evidence allows it to be released? If an order might already have been accepted, a timeout alone does not prove the organisation has no obligation. The system should reconcile the supplier's order state before restoring spending room. Otherwise a retry can create a duplicate commitment while appearing to remain within budget.
The general payment lifecycle appears in Machine-to-machine payments. Agent spending adds a specific authority question at every transition: which mandate covered this commitment, and how much remaining authority did the system have when it accepted it? That question must be answerable across concurrent processes.
Credentials carry claims, not judgment
W3C's Verifiable Credentials Data Model 2.0 describes a model for expressing claims made by issuers and presented for verification. A signed credential can support an evidence chain about a party or an authority. Its presence does not establish that the claim is true in every business context or that the verifier should accept the issuer.
An institution needs its own policy for trusted issuers, relevant claims and current validity. It also needs to bind evidence to the correct actor and action. A credential identifying an agent is different from a permission for that agent to spend a specified asset. Treating identity and transaction authority as interchangeable leaves a gap even when both artefacts are cryptographically valid.
The agent's purchase record should retain the evidence that the execution component evaluated. Later review needs to know why the permission was considered valid at the time. Keeping only a link to a mutable profile or an overwritten configuration makes that conclusion difficult to reconstruct.
Protocol examples do not settle the mandate
The Agent Payments Protocol repository contains code samples and demonstrations for agent payment flows. As read on 7 October 2026, its README explicitly presents those materials as samples and points to protocol and scenario documentation. That makes it a useful implementation reference, not proof that an institutional spending design has been deployed or accepted across all payment providers.
A procurement team can use a demonstration to examine the evidence carried between agent, merchant and payment components. The team should then test its own mandate: allowed supplier, purchase amount, expiry and response to changes. A sample that completes checkout with a human present does not by itself answer what happens when an unattended agent acts under a previously granted authority.
The difference is operationally important. Institutions often need approval for a category of purchases rather than one fixed cart. That flexibility must be represented within the enforceable permission or handled through another approval. A protocol's ability to transmit objects cannot resolve an ambiguity the organisation left in the mandate.
Revocation needs an effective point
A mandate needs a way to end before its normal expiry. The institution must identify who can revoke authority, how the execution layer learns of the change and which pending actions remain possible. Revocation is not a single label. Its effect depends on where a purchase sits in the commitment and payment lifecycle.
An exercise can revoke an agent's permission while it has a reserved budget and an uncompleted order. Reviewers can then establish whether new purchases stop, whether reservations are released correctly and whether the existing order requires explicit cancellation. The test should examine the system's state after revocation, rather than relying on a success message in the administration screen.
Human escalation also needs a boundary. An agent asking a reviewer to approve an exception should present the actual purchase and the rule it exceeds. If a reviewer grants broader ongoing authority while intending to approve one purchase, the exception process has changed the mandate. The evidence should make that distinction visible.
Keep the mandate explainable
The operating record can connect mandate identifier, issuing authority, policy version, proposed purchase, budget reservation, execution outcome and final receipt. It can also preserve rejected attempts. Rejections show whether controls are functioning and reveal repeated misunderstandings between the agent's instruction and its executable limits. They should not disappear merely because no money moved.
Treat supplier substitutions as mandate decisions
An agent may discover that an approved supplier is unavailable and propose another offering. A cheaper price does not establish equivalent authority to buy. The substitute can have different data handling, service terms or delivery conditions. The mandate should say which substitutions can be accepted automatically and which require a new decision by the organisation.
A useful test gives the agent an attractive offer outside the permitted supplier or product scope. The payment component should evaluate the actual proposed purchase rather than the model's explanation that it meets the original goal. If the proposal goes to a reviewer, the record should expose the changed conditions and the precise exception requested. That preserves useful agent flexibility while making the organisation's authority decision visible at the moment a commitment is created.
Agentic commerce when the buyer is software covers the wider market question. A spending mandate makes the institutional question concrete. The organisation is not approving a model's personality or broad intention. It is granting an actor a bounded capability and retaining evidence of how that capability was used.
The meaningful deployment milestone is therefore a demonstrated purchase within authority and a demonstrated refusal outside it. The same system should explain expiry, revocation, concurrent spending and ambiguous supplier responses. Until those outcomes are observable, the payment capability is ahead of the institution's ability to govern it.