Vorim Now Guards Anthropic’s Commerce Agents

Last week Anthropic open-sourced commerce-agents under the Apache 2.0 licence, a reference blueprint for two agents that run a shop. The shopping agent searches a catalogue, fills a cart, and hands the customer to checkout. The merchant agent reads store performance, stages price and inventory and promotion changes, and applies them to the live store. Each agent is defined once and runs on the Messages API, the Claude Agent SDK, and Managed Agents, with four worked verticals across retail, commerce, telecom and entertainment. Anthropic calls it a reference implementation rather than a maintained product, and it's well built, with real guardrails baked in.

As of this week, Vorim guards both agents. The integration ships in @vorim/sdk 3.20.0 and vorim 3.20.0 on PyPI.

What the blueprint already does, and what it can't

Credit where it's due. commerce-agents fences the model harder than most agent frameworks. Cart writes only accept product ids the session actually saw, so the model can't invent a SKU. Staged merchant changes run through guardrails before they're accepted. And the live apply_change call refuses any change id the host hasn't explicitly marked as approved.

Those gates are real. They're also in-process. They live and die with the running turn, nothing signs them, and they can't answer the questions that come up after the fact. Which agent ran this? On whose authority? Was it allowed at the time? Who approved the price change that went live at three in the morning, and can you prove that approval wasn't just host code trusting the conversation?

That gap is the whole reason Vorim exists, so we built the layer that sits beside those gates and supplies exactly that.

How it works

The blueprint plugs into your deployment through two backend contracts, StorefrontBackend and MerchantBackend. Every tool the model calls lands in one of their methods, executed server-side. So the backend is the one place worth guarding, and that's what the integration wraps. You don't touch the model loop, the prompts, or the three runtimes the blueprint ships with.

Each backend method maps to one of Vorim's scopes. Catalogue, order, policy and analytics reads need agent:read. Cart writes and staged merchant changes need agent:write. checkout_handoff, the moment a payable cart exists, needs agent:transact. And apply_change, the only call that changes what shoppers see and the only one the agent can't undo, needs agent:elevate plus a named human, the same way we treat an Okta role grant or an AWS IAM change.

Before any of those methods runs, Vorim checks the acting agent holds the scope and clears your minimum trust score. After it runs, Vorim signs a tamper-evident record of what happened, who acted, and for whom. A denial throws before the store is ever called, and you can map it onto the blueprint's own NotOffered or Unavailable wording so the model gets a message it already knows how to handle.

The approval bridge

This is the part we're most pleased with. commerce-agents requires host approval for apply_change by default, and it checks a set called approved_change_ids on the session. The blueprint leaves it to you to decide how an id gets into that set. Most hosts will write a line of code that adds it when the conversation looks fine.

approveChange() replaces that line. It raises a Vorim escalation, waits for a named human to approve it, and only then marks the id. So the mark the blueprint applies on is backed by a signed human decision rather than by code that took the model's word for it. When an auditor asks who approved the 40% markdown, you have a name, a timestamp, and a signature, not a log line.

The shape of it

Here it is in TypeScript. The Python SDK mirrors it under vorim.integrations.commerce_agents, and works under both the sync and async clients.

import createVorim from "@vorim/sdk";
import {
  createVorimCommerceGuard,
  guardStorefrontBackend,
  guardMerchantBackend,
} from "@vorim/sdk/integrations/commerce-agents";

const vorim = createVorim({ apiKey: "agid_sk_live_..." });

// The shopping agent: reads at agent:read, cart writes at agent:write,
// checkout handoff at agent:transact.
const shopper = createVorimCommerceGuard(vorim, {
  agentId: "agid_shopper_1",
  role: "shopping",
  humanId: "cust_42",      // the customer it acts for
  storeId: "acme-retail",
  minTrustScore: 60,
});
const storefront = guardStorefrontBackend(new AcmeStorefront(), shopper);

// The merchant agent: staging is agent:write; apply_change is agent:elevate
// and, with runtime control on, waits for a named human.
const merchant = createVorimCommerceGuard(vorim, {
  agentId: "agid_merchant_1",
  role: "merchant",
  humanId: "ops_lead",
  storeId: "acme-retail",
  useRuntimeControl: true,
});
const store = guardMerchantBackend(new AcmeMerchantBackend(), merchant);

// Every call below is permission-checked before it runs and signed after.
await storefront.addToCart(session, "sku_1", 2);
await store.stageChange(session, priceChange);
await merchant.approveChange(session, priceChange.id); // signed human decision
await store.applyChange(session, priceChange.id);

Nothing here imports commerce-agents. The wrappers proxy your backend structurally, so there's no version to pin and no fork to maintain. Method names match in either spelling, so a TypeScript backend that exposes searchProducts is understood the same as the blueprint's search_products.

One honest limit

Vorim signs what goes through the backend. The blueprint's own provenance and guardrail checks still run inside the executor, and we don't replace them; we add who and by what authority. If you extend the backend with a method neither scope map knows, the guard gates it at agent:write by default rather than waving it through, because a method we can't classify is assumed to write.

Why this matters now

Commerce is where agents meet money, and money is where the accountability questions stop being theoretical. A shopping agent that checks out on a customer's behalf and a merchant agent that reprices a live store are exactly the two agents a regulator, a payments partner, or your own finance team will ask about first. Running them through Vorim means the answer is a signed record you hold, verifiable offline, rather than a dashboard you'd have to ask them to trust.

If you're building on Anthropic's commerce-agents, or on any agent that touches a cart, a price, or a checkout, we'd like to show you what this looks like on your store.

Book a demo →