Agentic commerce needs authority boundaries, not just a wallet

Commerce is a sequence, not a payment button. An agent may discover suppliers, compare offers, select an item, negotiate terms, create an order, present payment, observe settlement, and track fulfilment. Each step uses different evidence and carries different consequences. A system that moves directly from a model recommendation to a wallet signature combines these stages into one opaque decision. It becomes difficult to determine whether the purchase was intended, merely plausible, or manipulated.

The distinction is straightforward: capability describes what the system can do, while authority describes what it is permitted to do for a particular principal. Funding a wallet gives the system capability. Authority still needs a defined purpose, scope, value, counterparty, duration, and route for exceptions. Those constraints should survive changes to the prompt and model because they belong to the operating agreement, not to the agent's interpretation of it.

A commerce workflow can start with a machine-readable purchase envelope. It identifies the goods or service sought, acceptable suppliers, maximum total cost, currency or token, delivery conditions, refund requirements, timing, recurrence, and applicable jurisdictional or data-handling constraints. Natural-language instructions can express the goal, but consequential limits need structured fields that another component can validate without inferring what the user meant.

This separates proposal, authorisation, and execution. The agent can search and prepare candidate orders without holding spending authority. A deterministic policy service can approve candidates that fit the envelope, reject those that do not, and route ambiguous cases to a person. Human review can then focus on defined exceptions while routine purchases proceed within policy.

The model should request a commercial action through a narrow tool; it should not receive a raw private key or an unrestricted signing interface. Between that request and the signer, a policy layer can enforce approved merchants or contract addresses, permitted assets and networks, and exact operations. It can also apply per-transaction and rolling spend limits, expiry times, and rate limits. A smart-contract account, delegated permission, or short-lived session key can enforce some controls close to the asset. The policy must operate independently of the model's instructions.

Approval also needs to be legible. A person asked to approve an opaque hexadecimal payload is not providing meaningful oversight. The system should resolve the network and counterparty, decode the contract call, normalise token units, show expected balance changes and fees, and identify any continuing permission being granted. The signed bytes remain the final source of truth, but the reviewer needs a faithful explanation of those bytes rather than a separate description generated from the agent's intent.

Smart contracts can make commercial rules deterministic. They can hold funds in escrow, release payment against an event, enforce a limit, split proceeds, or restrict which calls an account can make. That makes them valuable execution boundaries for agentic commerce. It does not make the surrounding decision safe by default. The agent can still select the wrong contract, accept unfavourable terms, misunderstand token units, grant an excessive allowance, or execute on the wrong network with perfect cryptographic validity.

Before signing, the system should verify addresses and chain identifiers from trusted configuration, inspect whether code is upgradeable, constrain function selectors and arguments, and simulate the transaction against current state. Simulation can expose reverts, unexpected asset movements, and unrealistic fee or slippage assumptions, but it cannot prove that an off-chain seller will fulfil an order or that the state will remain unchanged before inclusion. Persistent approvals deserve particular care: a small purchase can create a much larger future exposure if the associated allowance has no useful ceiling or expiry.

A successful payment does not establish that the paid service was delivered, and a timeout does not establish that payment failed. Agentic workflows make this distinction important because they can retry quickly and duplicate consequences. Every order needs a stable identifier, a deduplication strategy, and an explicit state model such as proposed, authorised, submitted, confirmed, fulfilled, refunded, or disputed. Where a merchant or payment rail supports idempotency keys, the workflow should use one. After an interruption, the agent should query the payment rail and merchant using the stable reference before deciding whether to retry.

On-chain transactions add confirmation depth, replacement transactions, and possible reorganisations to that reconciliation work. Off-chain systems add inventory changes, delayed fulfilment, partial refunds, and disputes. An audit trail connects the original intent, offers considered, selected quote, policy decision, human approval where required, exact signed payload, settlement reference, and fulfilment evidence. A blockchain receipt records one part of that audit trail, but it does not establish the purpose or fulfilment of the purchase.

The safest first use case has a known counterparty, a fixed or tightly bounded price, a low consequence of failure, and an outcome the system can verify. Purchasing access to a specialist API, ordering a repeatable digital service, or preparing a transaction for approval is easier to control than open-ended shopping across unknown merchants. Begin with recommendation-only runs, move to unsigned transaction preparation, then allow automatic execution inside a small balance and explicit policy envelope.

Scope should widen according to policy rejection rates, incorrect selections, settlement failures, duplicate attempts, fulfilment exceptions, and the quality of operator review. Funding a wallet demonstrates payment capability, not operational maturity. Maturity requires evidence that the agent spends only for an authorised purpose, that each transaction is independently constrained, and that the system can recover when payment and fulfilment disagree.

Technical controls do not determine whether a purchase is legally authorised. Agency and contract rules, consumer obligations, tax, sanctions, and identity or anti-money-laundering requirements vary by transaction and jurisdiction. The operating policy must identify which requirements apply and route transactions for the necessary review.