Summary
Industry discussion around agentic commerce highlights that autonomous shopping requires more than AI agents connected to product and payment systems. Authorization, identity, accountability and dispute handling remain foundational issues that have not been fully resolved.
The infrastructure question behind agentic commerce
Agentic commerce is often presented as a new way to shop: a user states a goal, and an AI agent searches for products, compares options and eventually completes the purchase. The industry discussion reflected in the source material points to a less visible constraint. The difficult part may not be teaching an agent to navigate a storefront or call a payment endpoint. It may be establishing whether the agent can act for a user in a way that is authorized, verifiable, reversible and accountable.
That distinction matters because conventional online commerce usually places the user at recognizable decision points. The user selects an item, reviews a price, accepts terms and confirms payment. An agentic workflow can distribute those decisions across software. An agent might filter products, choose among alternatives, accept a merchant’s terms or proceed under conditions defined earlier by the user. As more of the process is automated, the line between assistance and representation becomes less clear.
The infrastructure challenge, therefore, is not simply how to make agents more autonomous. It is how to make them autonomous within a clearly defined mandate. That question is likely to shape whether agentic commerce remains a demonstration of AI capability or develops into a reliable part of digital payments.
Payment authorization is more than an API connection
A conventional payment authorization generally relates to a specific transaction: an identified account, a defined amount and a particular merchant or payment flow. Agentic commerce may require a more conditional form of authorization. A user could want an agent to act within a budget, a product category, a set of merchants or a limited time window, without manually approving every individual step.
Such permissions need to express more than a binary yes or no. Can the agent accept a merchant’s terms on the user’s behalf? Can it select a substitute when the preferred item is unavailable? If shipping costs, taxes or exchange rates change the final amount, how much variance is permitted? If the agent performs several connected actions, does the original permission cover all of them, or must the user confirm again at a later stage?
Adding a final confirmation button does not resolve these questions on its own. Payment infrastructure must be able to determine who issued the permission, which actions it covers, when it expires and how it can be revoked. It also needs a record of whether the agent stayed within those limits. For an institutional account or wallet, these controls may have to connect with internal approval processes, spending policies and separation of duties.
Without a structured authorization model, automation can expand the impact of both convenience and mistakes. A mistaken product selection, an excessive charge or an action taken after permission has been withdrawn could become more difficult to investigate when several systems are involved.
Identity must include the agent and its control relationship
Identity in agentic commerce is not limited to authenticating the person who logs in. A transaction may involve the individual or institution that issued the instruction, the AI agent acting on that instruction, the merchant supplying the product or service, the payment provider processing the transaction and, in some cases, a wallet or custody provider controlling the relevant account capability.
Knowing that an account completed a payment may not be enough when a transaction is disputed. Participants may need to establish who initiated the request, what authorization the agent relied on, which account or wallet was used, whether the agent exceeded its mandate and whether the records are sufficient for an audit or a complaint process.
This creates a potentially important requirement for institutional wallet and custody systems. If an agent can call account or wallet functions, security cannot focus only on protecting keys or login credentials. The system must also enforce policies, record each action and identify when a high-risk operation requires additional approval. For a business, agent permissions may need to be tied to employee identity, organizational role and internal policy rather than treated as the broad authority of an independent software account.
The distinction is especially relevant when different agents are given different mandates. An agent allowed to research products should not automatically receive permission to move funds. An agent permitted to complete low-value purchases should not necessarily be able to change account settings or accept new contractual obligations. These boundaries need to be represented in systems, not left to informal assumptions.
Errors and disputes expose the accountability gap
Delegating more decisions to software creates more ways for a transaction to go wrong. An agent may misunderstand a user’s intent, select an unsuitable product, overlook a material term or introduce an error while moving information between services. It may also be affected by misleading product descriptions, malicious instructions, compromised accounts or attempts to manipulate the context it receives.
When a user challenges a transaction, existing refund, chargeback and fraud processes may not always provide an obvious answer. A merchant may argue that the agent completed the required confirmation. The user may argue that the agent acted beyond the authority granted. A payment provider may need to assess whether authentication was valid, while an agent platform or wallet service may be expected to provide authorization records and execution logs.
This does not mean responsibility should automatically be assigned to one participant. A more workable framework would distinguish between an action clearly authorized by the user, an execution error within the agent’s mandate, a platform or infrastructure failure and misleading information supplied by another party. Making those distinctions requires evidence: permission records, timestamps, policy decisions, execution steps and, where relevant, cryptographic or system-level attestations.
Without those records, dispute resolution becomes a debate over intent rather than a review of verifiable events. That is a significant problem for any payment environment, and potentially a larger one when multiple automated systems interact without a common record of authority.
Standards may matter more than isolated product features
Agentic commerce sits at the intersection of AI, identity, payments and merchant infrastructure. If each layer uses a different approach to permissions, identity representation, revocation and error handling, an agent may work in one environment but fail when it moves across providers. Merchants may not know what an agent is permitted to do. Payment providers may not know whether a request reflects a current mandate. Institutions may struggle to apply consistent controls across multiple agents.
The industry may therefore need clearer conventions for identifying agents, expressing and verifying permissions, recording execution history and exchanging the information necessary to handle disputes. These are not purely technical questions. They also touch consumer protection, data use, contractual obligations and compliance responsibilities.
The goal should not be to remove every human decision from commerce. It should be to make automated decisions understandable and bounded. A user may prefer not to confirm routine actions one by one, but that preference still requires a way to define acceptable conditions and stop the agent when circumstances change.
Implications for institutional wallets and custody systems
From an institutional wallet or custody perspective, the issue is not simply whether more account operations can be delegated to software. The question is how automation can be introduced without weakening governance. An agent may help organize information, match transaction conditions or coordinate a workflow. Actions involving asset movement, changes to account permissions or external commitments may require policy checks, tiered approvals and complete auditability.
These controls should cover more than execution speed. Institutions need to know what the agent did, which policy it applied, what the user or organization explicitly approved, which steps were automated and how access can be suspended if behavior becomes abnormal. For organizations with formal compliance or internal-control requirements, these capabilities may be more important than a frictionless interface.
That does not imply that agents cannot have useful roles in institutional workflows. It does suggest that the agent should be treated as a controlled actor with limited permissions, not as an unrestricted substitute for an account owner. The distinction becomes more important as agents are connected to payment systems, wallets and other services capable of producing external consequences.
Building a trust layer before expanding autonomy
The discussion around agentic commerce should not be read as a rejection of autonomous shopping. It is a reminder that broad adoption depends on infrastructure that users and institutions can trust. Authorization boundaries must be clear, identities must be distinguishable, actions must be auditable, mistakes must be correctable and responsibility must be traceable.
Until those conditions become more consistent, the next phase of agentic commerce may be less about giving agents unlimited freedom and more about making every automated action controlled and legible. For payment and wallet providers, that means security models, governance processes and dispute mechanisms need to develop alongside AI capabilities. Adding automation first and attempting to define authority afterward would leave the most consequential questions unresolved.
Source: link