Verifiable Intent in Agentic Commerce: How an AI Agent Proves It Was Authorized to Buy

Short answer: A merchant should verify a chain, not a claim. The chain needs a recognized customer identity, an identifiable agent, a signed delegation with explicit limits, a fresh transaction-specific approval where required, and a payment request bound to the approved cart. Each step should be independently validated and logged without exposing more customer data than the transaction needs.

Today, a shopper proves intent through familiar gestures: signing in, adding an item, reviewing a total, selecting an address, and pressing a button. A human can see the screen and recognize the consequence.

An autonomous agent breaks that visual sequence. It may receive a goal on Monday, compare products across several merchants, wait for a price change, and transact on Thursday. The merchant never sees the original conversation. The payment network sees credentials, but not necessarily the customer's constraints. The agent can present a polished explanation, but prose is not proof.

Verifiable intent is the emerging answer. It turns “my user wanted this” into portable, testable evidence of who delegated what authority, to which agent, for what purpose, within which limits, and for how long.

Verifiable intent is not the same as identity

Identity answers who an actor is. Authorization answers what that actor may do. Intent answers what outcome the customer meant to authorize in this context. Payment authentication answers whether a valid payment credential or account holder approved a payment step.

Agentic checkout needs all four, but they should not be collapsed:

A verified agent can still exceed its mandate. A valid payment token can still fund the wrong seller or an unapproved subscription. A signed mandate can still be replayed after use. Strong identity is necessary, but it is not sufficient.

The six-link trust chain

1. Establish the principal

The customer authenticates to a trusted issuer, wallet, or agent provider. The resulting identifier should be stable enough to enforce limits but need not reveal the customer's legal identity to every merchant. Consumers may use a pseudonymous account; businesses may need verified organizational roles.

2. Identify the agent

The merchant needs to distinguish an agent from an ordinary browser and one agent provider from another. A registry can help answer who operates the agent, which credentials it uses, and whether its status has changed. Visa's Trusted Agent Protocol work, for example, describes signals intended to help merchants distinguish legitimate agent traffic from malicious automation. Identity alone does not grant purchase rights, but it gives policy and incident response something concrete to evaluate.

3. Issue a bounded mandate

The principal delegates a purpose and constraints. Good mandates express what is permitted rather than giving the agent a general power to shop.

Useful constraints include:

• product category, attributes, or exact SKUs;
• maximum item price, shipping cost, tax, and total;
• currency and quantity;
• approved or excluded merchants, marketplaces, and sellers;
• delivery country or pre-approved address class;
• whether substitutions, used goods, warranties, tips, or subscriptions are allowed;
• start, expiry, and single-use or cumulative limits;
• whether final confirmation is required.

Mastercard's draft Verifiable Intent specification models a delegation chain and a constraint vocabulary using selectively disclosable credentials. It is one concrete approach, not the only possible architecture. The durable design principle is that merchants should receive enough signed evidence to make an authorization decision without receiving the shopper's entire conversation or profile.

4. Selectively disclose what the merchant needs

A shoe store may need proof that the agent can spend up to $160 on running shoes. It does not need to know that the shopper is also researching a medical device, planning a trip, or has a larger total wallet limit.

Selective disclosure reduces privacy risk and commercial leakage. It also makes mandates easier to reason about: reveal the applicable constraints and a cryptographic or issuer-verifiable link to the broader authority, while withholding unrelated fields.

5. Bind intent to the transaction

Delegation says what could be purchased. Checkout binding proves that the submitted transaction is within that permission.

Create a canonical transaction summary containing merchant, seller, line items and variants, quantity, unit price, total, currency, delivery terms, recurring-payment status, and relevant policy identifiers. Sign or hash the summary as part of approval. If a material field changes, compute a new summary and require a new authorization decision.

This prevents a classic substitution failure: the agent receives approval for one product at one price, then a marketplace swaps the seller, adds a service plan, or raises the total before submission.

6. Preserve an auditable receipt

Store the mandate identifier, credential issuer, agent identity, disclosed constraints, transaction digest, policy version, decision, approval event, payment reference, and timestamps. Avoid storing the full conversation unless there is a separate, justified need.

The receipt should answer: what was the agent allowed to do, what did it attempt, why did the merchant accept or reject it, and did the resulting order match the approved transaction?

What merchants should verify

Perform checks in a deterministic policy service. A language model may translate a shopper's request into proposed constraints, but it should not be the final authority on whether the cryptographic evidence, totals, or seller scope pass.

Four mandate patterns

Immediate purchase

“Buy this exact item for no more than $85 from this merchant now.” Narrow scope, short expiry, single use. This is the simplest and safest pattern.

Search, then confirm

“Find a compliant option under $150, but ask before purchase.” The mandate allows discovery and perhaps reservation; final transaction intent is a separate customer approval bound to the cart.

Conditional autonomous purchase

“Buy one approved air filter when the delivered total falls below $40 during the next 30 days.” The mandate must encode time, product equivalence, total cost, quantity, and replay limits. The system also needs a clear substitution policy.

Recurring replenishment

“Reorder up to two units monthly while the unit price remains below $25.” This requires cumulative limits, cancellation, periodic notice, and a policy for price or formula changes. Treat it as an ongoing authorization with revocation, not a sequence of unrelated one-time approvals.

Failure modes to design out

Overbroad scope. “Handle household shopping” is hard for merchants to verify and dangerous for customers. Break goals into narrower mandates.

Ambiguous totals. A $100 item limit does not answer whether tax, shipping, tips, or add-ons may push the charge higher. Define maximum payable total and currency.

Seller blindness. Marketplace item identity is not seller identity. Bind both when warranties, authenticity, fulfillment, or return rights differ.

Replay. A signed mandate can be valid and still be used twice. Use nonces, single-use status, idempotency keys, and cumulative spend tracking.

Context leakage. Sending the full customer prompt to prove intent creates unnecessary privacy and manipulation risks. Disclose constraints, not the private reasoning trail.

Approval theater. A confirmation screen is meaningless if the final order can change afterward. Bind approval to a canonical transaction digest.

Protocol monoculture. Merchants will encounter several agent, wallet, and payment schemes. Normalize them into one internal authorization model rather than embedding business rules separately in each integration.

A protocol-neutral merchant architecture

1. Credential gateway: validates formats, signatures, issuers, status, and agent identity across supported ecosystems.
2. Intent normalizer: maps incoming mandates into a common set of constraints with explicit unsupported fields.
3. Policy decision point: evaluates merchant rules, risk, shopper authority, product, seller, amount, and transaction state.
4. Transaction binder: creates the canonical cart digest and determines whether fresh confirmation is required.
5. Payment connector: carries the relevant intent or evidence reference into payment authorization without treating payment success as proof of mandate compliance.
6. Evidence ledger: stores a privacy-minimized decision receipt, revocation state, nonce use, and operational audit events.

This architecture lets a merchant support AP2, network-specific protocols, or future credential formats without rebuilding the core authorization policy each time.

A 30-day readiness plan

Week 1: list every agent-initiated action the business will accept. Separate discovery, cart creation, reservation, purchase, cancellation, return, and refund. Assign impact and approval requirements.

Week 2: define the internal mandate schema and transaction summary. Include seller, subscriptions, totals, expiry, reuse, and unsupported-constraint behavior.

Week 3: implement a verifier against test credentials. Exercise invalid issuer, expired mandate, stolen agent binding, replay, cart mutation, and cumulative-spend cases.

Week 4: connect the decision receipt to order, payment, fraud, support, and dispute systems. Write customer-facing denial and re-approval flows. Run the entire sequence with synthetic accounts and payment instruments.

Frequently asked questions

Is verifiable intent a payment credential?

No. It proves or conveys delegated purchase authority and constraints. A payment credential funds the transaction. The two should be bound, but one does not replace the other.

Does the merchant need to trust every agent provider?

No. Maintain issuer and agent trust policies, risk tiers, and supported capabilities. Unknown agents can be denied, limited to discovery, or routed to a conventional customer-confirmed checkout.

Will one industry protocol solve this?

Unlikely in the near term. AP2, network protocols, registries, and verifiable-intent specifications address overlapping layers. Build a stable internal authorization model and adapters at the edge.

What should happen when the mandate is unclear?

Fail closed for the unclear action and return a structured request for narrower authority. Do not let the agent infer permission from conversational tone or available payment credentials.

What is the privacy minimum?

Share only the identity assurance and constraints needed for the merchant's decision. Prefer selective disclosure and store a decision receipt rather than the shopper's full conversation.