Commerce Trust Safety

Trust and safety rules

commerce_common/ is commerce-common/commerce_common/, shopping_agent/ is shopping-agent/core/shopping_agent/, and merchant_agent/ is merchant-agent/core/merchant_agent/; docs/safety.md lists the same rules. A rule inside a tool call holds on all three paths, which share one executor (commerce-architecture); rules 10 and 15 name the paths they run on. Merchant staging, guardrails, approval, and marketplace posture are in commerce-merchant-operations.

Fence third-party content

1. Every tool result from catalog, review, policy, order, metric, message, or web content goes through Fence.fence_payload (commerce_common/fencing.py): NFKC-normalized, invisible and control characters removed, fence markers, forged turn markers, and special tokens replaced, wrapped in the role's label, and cut at max_fenced_chars. The executor's _fenced applies it to every handler.
2. The label and the notice are per-role constants (STOREFRONT_FENCE in shopping_agent/fencing.py, MERCHANT_FENCE in merchant_agent/fencing.py); the notice appears once, in the static prompt, with nothing untrusted in it.
3. The per-request block (profile, cart, memory facts, page, store context) sits inside the same fence after the cache breakpoint (build_dynamic_context in each role's prompt.py); backend context blocks have their own cap.
4. A model-supplied result count is clamped to max_search_results (clamp_limit in commerce_common/execution.py).

Gate writes on provenance and caps

5. A cart write accepts only ids in ShoppingSessionState.seen_products, filled by the session's catalog and order reads (check_provenance and remember_order_items in shopping_agent/gates.py); update and remove also accept a line already in the cart. Merchant staging accepts only ids in seen_listings and read_listings, apply and discard only ids in seen_changes (merchant_agent/gates.py; commerce-merchant-operations).
6. max_quantity_per_item caps the line after the write and max_cart_lines the cart, under a session lock (gated_add_to_cart in shopping_agent/gates.py; caps in shopping_agent/config.py). The lock is per process, so StorefrontBackend cart methods enforce them too; eligibility, pricing, and inventory are the backend's in both roles.
7. Nothing in either interface charges or places an order: checkout renders the cart (enrich_checkout in shopping_agent/enrichment.py) and the host completes it; post-purchase care is reads, with no cancel or refund tool.
8. Provenance lives on the session state (ShoppingSessionState, MerchantSessionState), saved with the session when the request or turn ends (SessionStore in examples/demo_common/sessions.py, a versioned state document beside the transcript), so a request on another process loads it. Each map keeps its newest PROVENANCE_CAP records (remember in commerce_common/types.py); a dropped id needs a fresh read.
9. A component is validated, its products, orders, metrics, or changes are joined from those records, and ids without provenance are dropped and reported (run_presentation in commerce_common/presentation.py; each role's enrichment.py; commerce-ui-tools).

Ground the answers that are figures or terms

10. A terms question, an order question, or an unseen product id (GROUNDING_RULES in shopping_agent/grounding.py), or a performance question or an apply request with nothing staged (merchant_agent/grounding.py), starts from the matching read: first_forced_tool in commerce_common/grounding.py picks it, the Messages API runtimes force it with tool_choice, and the SDK runtimes prefetch it when the rule has a prefetch form (ground in commerce_common/agent_sdk.py; the terms rule has none); the hosted path has the prompt only.
11. The lexicons are config tuples (policy_intent_terms, order_intent_terms, product_id_patterns, metrics_intent_terms, and their cues); a deployment appends its own words, a gate flag turns a rule off, and neither changes prompt bytes.