The Agent Can Build the Cart. Anthropic Still Did Not Give It the Card.

Read enough vendor material about agents and permission and you stop trusting the word approval on sight. It gets used for a button, a sentence, a checkbox, a vibe. So it is worth being exact about what Anthropic actually built into its new commerce reference code, because the exactness is the point.

What shipped

On 2 September 2026 Anthropic published anthropics/commerce-agents, described in its own README as a reference blueprint for building shopping and merchant agents with Claude, with worked examples across retail, travel, telecom and entertainment, and a Claude Code plugin for scaffolding a deployment's own version. It ships two agents. A shopping agent, customer facing, embedded in a storefront, searches, compares, plans a purchase, keeps a cart, tracks orders and answers policy questions. A merchant agent, staff facing, sits in a back office portal: it explains performance, maintains listings, acts on inventory and order alerts, prices and promotes, and drafts campaigns. Both run on any of three paths, the Messages API directly, the Claude Agent SDK, or Anthropic's own hosted Managed Agents, and the repository states that all three execute tool calls through the same executor, so a rule enforced inside a tool call holds on all three paths rather than depending on which runtime a deployment happens to pick.

The repository's own README states its own boundary before anything else: every company, brand and product in the examples is fictional, and nothing places an order, charges a card, or changes a live listing. That sentence is the one worth testing against the actual code paths rather than taking as marketing, and Anthropic's own safety documentation, docs/safety.md, is written for exactly that kind of testing. It lists, rule by rule, what is enforced in code, what is still only asked of the model, and what the reference stops short of and leaves for a deployment to build.

No method that can spend money

That is a narrower and more checkable claim than an instruction not to charge a customer would be. It is an absence in the interface itself. A deployment implements StorefrontBackend to connect the shopping agent to its own catalog, cart and order systems, and the abstract interface the reference code defines for that backend simply has no method named place_order, charge, or anything equivalent. There is nothing for the model to call, correctly or otherwise, that would move money. When a shopping session reaches checkout, the tool renders the cart for the host application to complete, and a hosted checkout URL, where one exists, is produced by a host side enrichment step after the model's own call finishes rather than being generated or passed through by the model. Payment happens, if it happens, entirely inside the host's own systems, on the far side of a boundary the shopping agent's own tool surface does not cross.

This is worth separating from a design choice about how careful an agent is asked to be. This desk has already covered a platform choosing to open real trading and purchases to third party agents, a deliberate decision to grant that authority. Anthropic's reference shopping agent makes the opposite choice, and makes it structurally: not a rule the model is asked to respect while holding the capability, but the capability's absence from the code the model can call at all.

What the merchant agent can prepare, and what it cannot commit

The merchant agent is a different case, because it genuinely can reach consequential state: a price, a promotion, an inventory figure, a campaign budget, the text on a listing. Anthropic's documentation calls the relevant rule staging provenance. Staged writes accept only listing and campaign ids that a tool already returned within that same session, a content edit needs a preceding read of the listing, and a price update or a restock naming a listing that has product variants is held and redirected to the specific variant rather than applied to the parent. The two operations that actually move a staged change, apply_change and discard_change, accept only change ids that a staging call or a get_pending_changes call returned in that same session. An id the agent did not just see through its own tools is not a valid argument, regardless of what the model's own text claims about it.

Staging is not the gate. It is the shape the proposal has to arrive in before the gate can apply to it, and Anthropic's documentation is specific that the gate itself runs twice.

That second evaluation is the detail this record is built around, because it answers a question that matters in practice and that most approval workflows leave silent. Say a price change clears every guardrail the moment it is staged. Before anyone applies it, the deployment tightens its price movement limit, or a protected field gets added to the configuration, or a campaign budget cap drops. Under Anthropic's documented behaviour, the change is checked again at apply time against whatever configuration is in force then, not against the configuration that was in force when it looked acceptable. A staged proposal that was fine an hour ago is not automatically still fine now. Approval of a proposal at one point in time does not override a deterministic policy that has since moved.

What that guardrail re evaluation does not establish is anything about the wider world the change is being applied into. It checks the change against configured limits again. It is not documented to re check the change against a live inventory count, a since changed price on the same listing set by another actor, or any other external state beyond the guardrail configuration itself. Moona Intelligence treats that as a real but bounded property: the policy is re evaluated, not the entire external target state.

The approval that a preview card and a chat message cannot supply

The part of Anthropic's documentation this record leans on hardest is the host approval rule, because it draws a line this desk has been watching other vendors gesture at without actually drawing.

Read that against a different vendor's production sign off, described in a channel a person and an agent share, with no published statement of what enforces it. Anthropic's documentation states the opposite arrangement in the same breath it describes the feature: the mechanism that flips a change from staged to approved is a specific, separate call, either a route the host's own portal exposes or a tool the SDK toolset carries, and nothing in the conversational surface the agent and the human share can produce that call by itself. A person telling the agent yes in the chat window does not touch the field the executor checks. A rendered preview of the change, however convincing, is not that field either. The gate lives outside the conversation, which is exactly what a gate needs to do if the thing being gated is a conversation.

On Anthropic's own hosted runtime, Managed Agents, the mechanism is not identical, and the documentation says so rather than leaving a reader to assume one universal implementation. There, the platform's own always_ask prompt on apply_change stands in as the approval, and the MCP server's configuration for that path sets require_host_approval to false. That is not the portal route or the SDK's host_approve tool doing the work. It is a different, platform level interruption mechanism performing the same role inside a different runtime, and this record treats the two as related but distinct rather than describing Managed Agents as running the identical check.

Configurable, not fixed

It would overstate what Anthropic published to read any of this as a permanent property of a Claude commerce agent. The documentation says the opposite about itself, in one sentence placed right where a reader might otherwise assume the guarantee is unconditional.

Turn require_host_approval off, and an approval typed in chat does count, by Anthropic's own account of its own reference code. The staging step, the provenance check on change ids, and the guardrail re evaluation at apply time do not depend on that flag and stay in place regardless. What depends on it is specifically the requirement that the mark come from a host controlled surface rather than from the conversation. Anthropic is not claiming every deployment keeps that requirement on. It is documenting a default and naming the exact switch that removes it, which is a more honest disclosure than most vendors make about the same kind of control, and also a plain statement that the separation this record is about is a choice a deployment makes, not a property Claude enforces regardless of what anyone configures.

What a deployment still has to build

Anthropic's documentation is direct about where its own responsibility ends. Authentication and authorization on every route and on the MCP servers, since the published examples accept any caller. The credentials a deployment's own backend uses to call its own services, resolved by the host and never shown to the model. Rate limiting. Fraud, eligibility, pricing and inventory business rules, which the gates do not decide, they check provenance and caps and leave the backend to decide whether a write is allowed at all. Payment processing itself, entirely outside the reference code, in the host application after checkout. Who counts as an eligible approver on the merchant approval surface, since the gate checks only that a deployment's own code set the mark, not who was entitled to set it. And the specific guardrail values themselves, which the documentation calls demonstration defaults.

That list matters as much as the enforcement it sits beside. A grantor legitimacy question sits underneath the whole host approval mechanism: Anthropic's code checks that an approval mark exists and came from the designated surface, not that the specific person who set it was actually entitled, inside a given merchant's business, to approve that specific change. Nothing in the published documentation shows a second, independent approver is required, and a host approver may in some deployments be the same person who asked the agent to prepare the change in the first place. A host approval existing is not the same thing as proof that the approver held the business authority the action required, and it is not by itself evidence of separation of duties between two different people, only evidence that the approval passed through a surface the conversation itself cannot reach.

Several other properties this record went looking for are not established by the published documentation and are recorded here as unknown rather than assumed. Whether the content of a staged change can be mutated after a host approval mark is set and before apply_change runs. Whether an approval is consumed once an apply succeeds or could be replayed against a later change carrying the same id. Whether change ids are immutable identifiers or could, in principle, be reused. The documentation demonstrates that a change id must have originated from staging or a pending changes call this session, which is a real provenance check, but that is not the same claim as a cryptographic binding between an approval and the exact bytes of the action it authorized, and this record does not make that stronger claim.

Read against what this desk has already traced

Moona Intelligence's Risk Registry already names the pattern this record is evidence for: execution authority collapsing into the capability to prepare, the review seat that exists in a workflow's description going empty because the actor that reasons about a change is also the actor that commits it. A Terraform plan computed exactly what a destroy would do, and nothing stood between the plan and the execution because one agent held both halves. Anthropic's own AI native SDLC playbook later described a production deploy hook that blocks a release until a named release manager authorizes it, a deterministic gate rather than an instruction. Anthropic's commerce reference code is the same architecture, applied a level down from infrastructure and software delivery to storefront and back office state. It removes the consequential capability entirely from the shopping agent, and it keeps the capability but gates the state transition for the merchant agent, with the gate living outside the surface where the agent and the human talk.

What Anthropic's commerce code adds that the SDLC playbook only described in general terms is the apply time guardrail re evaluation: a specific, checkable answer to what happens when policy moves between a proposal being staged and being approved. That answer is narrower than a claim that the whole external world is re verified before every apply, and this record states it at that narrower scope rather than a broader one the evidence does not support.

What this is, and what it is not

This is not a claim that Claude commerce agents can be deployed unattended and stay safe by construction. Anthropic's own documentation lists authentication, credentials, business rules, payment processing, approver eligibility and the actual guardrail values as work a deployment still has to do, and a deployment that flips require_host_approval off has, by Anthropic's own account, removed the one control this record spends the most words on. It is also not a claim that this pattern is unique to Anthropic or new to this desk's coverage. It is a second, independently engineered instance of a distinction this desk has argued belongs at the point of execution rather than in an instruction, this time built for commerce rather than for infrastructure or code review, with the added precision of an apply time policy re check that the earlier examples did not document.

What it is: a reference implementation, published by the company that trains the model most of this coverage is otherwise about, drawing the same line this desk keeps finding drawn well only when it is drawn in code. Preparation authority is not commit authority. Shopping and cart authority is not payment authority. Anthropic did not write that as a slogan. It wrote it as an interface with a missing method, a set of ids an executor will not accept from anywhere but its own session, and a field a chat message cannot set.