Platform Terms for Agent Access

Step 1The protocol is the easy half; the clause is the interface.

Walmart's gateway ships as an MCP server. That is the part your engineers will finish in a week. The part that decides whether the integration still exists next quarter is the sentence saying agents that do not comply with the terms will be blocked from the site, together with an approval step you do not control. Meanwhile Amazon has been moving the other way on the buyer side — it cut off Meta's Muse agent in September 2026, citing security and privacy risk and agents that do not properly identify themselves, a characterisation Meta disputed — and in November 2025 it sued Perplexity over its Comet browser agent making purchases on the marketplace.

Two platforms, one protocol stack, opposite answers. Nothing technical distinguishes the cases. What distinguishes them is a commercial judgement about whether an intermediary that sits between the retailer and the customer is a channel or a competitor, and that judgement is revisited whenever the business reason changes. Treat it as an input with its own volatility, not as a settled fact about the web.

Step 2Follow the payment instrument to find the real enforcement boundary.

Terms documents are long and vague; the handling of money is short and precise, and it tells you what the platform actually intends to police. On Walmart's gateway the agent transacts without ever receiving card details and cannot add or change a payment method, with customer-facing Agent Profiles reported to follow in November 2026, and the ordinary returns process applying even when an agent does not behave as intended. Read that as a design statement: the platform will tolerate an agent choosing and buying, and will not tolerate an agent holding the instrument.

• Agent holds the credential — you are one incident away from being characterised as the Perplexity case was. Expect blocking, not negotiation.
• Platform holds the credential, agent holds a scoped permission — the sanctioned shape. Your durable work is making your agent legible inside it: identify itself, stay inside the rate it was granted, and leave the payment path alone.
• Platform holds both and the human confirms each purchase — the narrowest and most stable grant, and the one to assume you will be pushed toward.

Where a platform draws that line also tells you which of its APIs are strategic. See agent payments for the instrument side and AP2 and agent commerce for the protocol attempts to standardise it.

Step 3Inventory the dependency the way you would inventory a vendor.

Most teams can name their model providers and cannot name the third-party platforms their agent silently requires to deliver its promise. That list is the artefact. One row per platform, and the four columns that decide what you do when one turns red.

# platform-access.yml — the row that makes an outage answerable
- platform: walmart
  grant: approved-agent          # approved | public-api | unsanctioned
  identifies_as: registered-ua   # how THEY recognise us
  holds_payment: platform        # platform | us | agent
  revocable_by: them, unilateral
  user_promise: "buy groceries"  # what breaks for the user
  fallback: handoff-to-human     # NOT "retry"
  detect: 403-rate > 2% for 5m   # the alert that fires first

The grant column is the one people get wrong. An integration built on a public endpoint with no registration is unsanctioned even when it works perfectly, and unsanctioned access is the category that disappears without a deprecation window. Fold these rows into your agent inventory rather than keeping a second list, and assess them like any other third-party dependency.

Step 4A block is not an error; instrument it as a policy event.

Revocation does not arrive as a 500. It arrives as a 403 on a route that worked yesterday, a challenge page where JSON used to be, an account suddenly rate-limited to uselessness, or a silent drop of exactly the one endpoint that mattered. Retry logic reads all of those as transient and will cheerfully turn a policy decision into a retry storm against a platform that has just told you to stop — which is how a recoverable misunderstanding becomes a permanent ban.

• Separate the signal. Count authorisation-shaped failures per platform as their own metric, not inside a generic error rate where a 2% block is invisible.
• Back off hard and asymmetrically. On a sustained 403 rate, stop rather than retry. This is the one failure class where the right automatic response is to go quiet and page a human.
• Keep the evidence. Request identifiers, timestamps and the exact response bodies are what an account-reinstatement conversation runs on, and they are usually gone by the time anyone asks.
• Name an owner. A platform relationship needs a person, not a rota — the block will be resolved in email, not in code.

Step 5Degrade into something honest, and tell the user whose decision it was.

When access goes, you owe the user a true sentence. "Walmart is not currently accepting orders from assistants like me — here is your basket to complete yourself" keeps the user's trust and routes the complaint to the party that made the decision. Silently substituting a different retailer, or faking progress on a task you can no longer perform, converts a partner's policy change into your own credibility problem. The degradation path should have been designed with the feature, and it should hand over real state — the cart, the chosen items, the address — not an apology.

If a single platform carries a promise you have made in your own marketing, you have a concentration risk that no amount of engineering fixes. Either hold a second sanctioned route, or say in the product what the dependency is. One retailer's approval list is a thinner foundation than it looks, and the publicly reported pattern — Walmart admitting approved agents, Target working from an approved-provider list, Amazon restricting them on the buyer side while opening seller APIs — is a market mid-argument, not a settled standard.

Step 6Be the agent that is easy to approve.

Every public justification for blocking so far has named the same two things: agents that do not identify themselves, and agents that take actions the platform cannot attribute to a consenting customer. Both are things you can fix unilaterally, before anyone asks. Identify the agent in the request, keep the consent record that shows which human asked for this action, honour the published rate, and keep the verification signals a platform looks for. The platforms that are opening up are building approval processes, and an agent that already behaves like an approved one is a short review rather than a hard argument.