A shopping agent needs the merchant's permission too

Amazon's block revealed a contract gap, not just a bot-detection fight

Meta launched Muse on September 8 as a personal agent that can browse, fill forms, negotiate, and make purchases. Meta says Muse runs in a dedicated Secure VM, keeps credentials outside model reach, asks before sensitive actions, produces an audit trail, and can pay with a one-time card. On September 21, Amazon blocked Muse from shopping on Amazon.com and said the access was unauthorized. The focused scan found multiple Hacker News stories, 151-point coverage with 159 comments, and active r/MetaAI and r/amazon discussion.

The tempting conclusion is that one company is protecting users while the other is blocking competition. That may be part of the commercial dispute, but it is not a sufficient engineering model. Both sides control a real boundary. The shopper can delegate a goal, data, budget, and purchase authority. The merchant controls automated access, product representations, fraud rules, inventory, checkout, fulfillment, returns, account use, and the identity of parties entering its systems.

Meta's controls answer important user-side questions: can the model read a reusable password, can it spend without approval, can the user review the plan, and can the payment credential be limited? They do not answer the counterparty question: did this merchant agree to receive this identified agent over this channel for this capability under these rules?

Amazon's 2026 seller-services notice makes that distinction concrete in its own covered context. It says automated systems must identify themselves, follow the agent policy, and cease access when requested. That notice should not be stretched into a universal statement about every Amazon consumer interaction. It does illustrate the general design requirement: the destination needs a machine-enforceable way to accept, scope, and revoke automated access.

Model the transaction as two grants and one shared fact set

A human checkout often hides the relationship because one browser session carries everything. An agentic checkout should make three roles explicit:

The shared fact set is the transaction envelope: merchant, product identifiers, variants, quantities, price, currency, discounts, tax, shipping, delivery promise, refund terms, payment handler, and expiry. If the merchant changes any material field after the user approves, the old approval should fail. If the agent changes the destination, cart, quantity, or substitution rule, the merchant should see a new mandate rather than a replayed authorization.

This is stronger than a screenshot or natural-language approval card. A screenshot helps a person understand the action. The machine boundary should bind the approval to a normalized payload or digest. The user interface and the signed payload must be generated from the same canonical object so a display bug cannot approve different bytes.

user delegation
  -> identified agent + scoped purpose + expiry
  -> merchant capability discovery and acceptance
  -> merchant-signed cart state
  -> user review and payment mandate
  -> merchant verifies both mandates
  -> order receipt + fulfillment state + return path
  -> revocation, dispute, or human handoff

Reject hidden transitions with a capability state machine

A production agent should not move directly from “I found a product” to “purchase complete.” Use states whose transitions have evidence and owners.

REFUSED is a normal business state, not an error to route around. Identity rotation, browser fingerprint evasion, residential proxy switching, or pretending to be a human converts a recoverable product limitation into policy evasion. The correct recovery is to use a merchant-supported channel, ask the user to complete the step, or select another merchant only within the user's declared substitution rules.

Use protocol evidence instead of inferring a merchant's intent from HTML

Shopify and Google co-developed Universal Commerce Protocol (UCP) around explicit discovery and standardized commerce operations. A merchant can expose a profile at /.well-known/ucp describing version, checkout and fulfillment capabilities, services, extensions, and payment handlers. Transports can vary - REST, GraphQL, JSON-RPC, A2A, or MCP - while the commerce contract remains stable.

Google's AP2/UCP reference flow adds signed mandates. The merchant returns a signed cart mandate. The user or authorized agent creates a payment mandate referencing that cart. The merchant verifies its own cart signature and the user's payment authorization before completing the purchase. That double-sided evidence is exactly what opaque browser automation lacks.

{
  "agent": {
    "id": "did:web:shopper.example:agents:travel-17",
    "operator": "shopper.example",
    "purpose": "buy approved headphones",
    "delegation_digest": "sha256:2d7f..."
  },
  "merchant": {
    "profile": "https://merchant.example/.well-known/ucp",
    "capability": "checkout.complete",
    "policy_version": "2026-09-20"
  },
  "cart_mandate": {
    "digest": "sha256:91ab...",
    "amount": "249.00",
    "currency": "USD",
    "expires_at": "2026-09-24T11:05:00Z"
  },
  "payment_mandate": {
    "max_amount": "249.00",
    "substitutions": "none",
    "single_use": true,
    "user_approved_at": "2026-09-24T10:58:13Z"
  }
}

The protocol does not eliminate fraud, bad catalog data, account takeover, or fulfillment failure. It moves the transaction onto a surface where capabilities, parties, and state can be checked. Shopify's merchant guidance also shows why explicit activation matters: agentic storefront configuration controls which channels can expose products, and direct checkout can be disabled by default in some setups.

Make destination acceptance a runtime policy, not a prompt

The model may suggest a channel, but deterministic policy should decide whether the agent may use it. Store the merchant identity, policy evidence, capability, request class, data classes, approval rule, and refusal behavior outside the model context.

apiVersion: commerce-agent-policy/v1
merchant: amazon.com
evidence:
  checked_at: 2026-09-24T03:00:00Z
  source: merchant-policy-register
agent_identity:
  required: true
  allow_disguise: false
channels:
  protocol:
    allowed_when: verified_profile_and_capability
  browser:
    mode: deny_unless_explicitly_permitted
actions:
  search: {approval: none, data: public_only}
  add_to_cart: {approval: task_scoped}
  purchase:
    approval: exact_cart_and_total
    require_merchant_mandate: true
    require_single_use_payment: true
on_refusal:
  stop_access: true
  preserve_receipt: true
  offer: [supported_channel, human_handoff]

Cache policy only with a short expiry and change trigger. A merchant can withdraw a capability, change checkout terms, or block a class of agents. Before a consequential action, revalidate merchant identity, capability, cart expiry, and the policy version named in the authorization. Treat a redirect to a different domain or marketplace seller as a new counterparty.

Separate discovery, cart building, and purchase identities. Read-only product search should not automatically inherit payment capability. A compromised content page should not be able to promote the session into checkout. A purchase worker should receive only the normalized cart mandate, scoped user authorization, and a one-time payment instrument - not the entire browsing transcript or reusable account credential.

Browser automation needs a stricter fallback contract

Many merchants will not publish an agent protocol soon. A browser agent can still be useful, but “the user can do it in a browser” does not mean an automated delegate may do it silently. Establish four gates.

Policy gate: check robots, terms, agent policy, account rules, and any machine-readable discovery. Robots directives are not a complete authorization system, but ignoring an explicit refusal is not acceptable. Preserve the exact evidence and retrieval time.

Identity gate: identify the agent where the destination provides a mechanism. Do not spoof human interaction, defeat challenges, or rotate identities to bypass a block. If the site cannot accept the identity, route to human control.

State gate: re-read product, variant, seller, price, tax, shipping, subscription, and return facts immediately before approval. Bind the confirmation to a digest. Any material DOM or network response change invalidates the approval.

Outcome gate: reconcile the merchant's order confirmation, payment result, receipt, and account state. A button click, HTTP 200, or tool success is not proof that an order exists. This extends the execution receipt pattern to a counterparty-signed business outcome.

Failure modes when one side's authorization is mistaken for both

Test authorization changes, not only successful purchases

Run the matrix across protocol, embedded-checkout, and browser paths. Record false blocks, unsafe accepts, approval repeats, merchant-policy cache age, cart invalidations, handoff completion, and time to reconcile. A high checkout completion rate can hide an unsafe system if it includes stealth access or approvals that no longer match the order.

FAQ

Does user approval authorize an AI agent to shop on any website?

No. It authorizes the agent from the user's side. The destination still decides whether automated access is accepted, how the agent must identify itself, and which capabilities and channels are available.

Is browser automation enough for agentic commerce?

It can be a bounded fallback, but it is brittle and often ambiguous. Merchant protocols make identity, capabilities, checkout state, payment authorization, receipts, and revocation more explicit.

What should be bound to a purchase approval?

Bind the merchant and seller identity, agent and user account, exact cart, variants, quantity, price, currency, discounts, tax, shipping, subscription state, return terms, payment method class, substitution rules, and expiry.

What should an agent do when a merchant blocks it?

Stop, record the refusal, explain it to the user, and offer an accepted integration or human takeover. It should not rotate identities, disguise itself, solve around the block, or continue with hidden retries.