commerce-trust-safety

信頼と安全性に関するルール

commerce_common/ は commerce-common/commerce_common/、shopping_agent/ は shopping-agent/core/shopping_agent/、merchant_agent/ は merchant-agent/core/merchant_agent/ です。docs/safety.md にも同じルールが記載されています。ツール呼び出し内のルールは、1つのエグゼキューター（commerce-architecture）を共有する3つのパスすべてに適用されます。ルール10と15では、適用されるパスを明記しています。マーチャントのステージング、ガードレール、承認、マーケットプレイスの対応方針については、commerce-merchant-operations を参照してください。

サードパーティーのコンテンツを隔離する

1. カタログ、レビュー、ポリシー、注文、指標、メッセージ、またはウェブコンテンツから得られるすべてのツール結果は、Fence.fence_payload（commerce_common/fencing.py）を通します。NFKC 正規化され、不可視文字と制御文字が削除され、フェンスマーカー、偽造されたターンマーカー、特殊トークンが置換され、ロールのラベルで囲まれたうえで、max_fenced_chars で切り詰められます。エグゼキューターの _fenced がすべてのハンドラーに適用します。
2. ラベルと通知はロールごとの定数（shopping_agent/fencing.py の STOREFRONT_FENCE、merchant_agent/fencing.py の MERCHANT_FENCE）です。通知は静的プロンプト内に一度だけ記載し、その中に信頼できない情報は含めません。
3. リクエストごとのブロック（プロフィール、カート、メモリの事実、ページ、ストアコンテキスト）は、キャッシュブレークポイントの後で同じフェンス内に配置します（各ロールの prompt.py にある build_dynamic_context）。バックエンドのコンテキストブロックには、それぞれ独自の上限があります。
4. モデルから提供された結果件数は、max_search_results を上限として制限されます（commerce_common/execution.py の clamp_limit）。

出所と上限に基づいて書き込みを制御する

5. カートへの書き込みで受け付けるのは、ShoppingSessionState.seen_products に含まれる ID のみです。この値はセッションのカタログ読み取りと注文読み取りによって設定されます（shopping_agent/gates.py の check_provenance と remember_order_items）。更新と削除では、すでにカートにある商品行も受け付けます。マーチャントのステージングで受け付けるのは seen_listings に含まれる ID のみで、適用と破棄で受け付けるのは seen_changes に含まれる ID のみです（merchant_agent/gates.py、commerce-merchant-operations）。
6. セッションロックのもとで、書き込み後の商品行には max_quantity_per_item、カートには max_cart_lines が上限として適用されます（shopping_agent/gates.py の gated_add_to_cart、上限は shopping_agent/config.py）。ロックはプロセスごとのため、StorefrontBackend のカートメソッドでも上限を適用します。適格性、価格、在庫は、どちらのロールでもバックエンドが管理します。
7. どちらのインターフェースにも、料金の請求や注文の確定を行う機能はありません。checkout はカートを表示し（shopping_agent/enrichment.py の enrich_checkout）、ホストが注文を完了します。購入後のサポートは読み取りのみで、キャンセルや返金を行うツールはありません。
8. 出所情報はセッション状態（ShoppingSessionState、MerchantSessionState）に保持され、リクエストまたはターンの終了時にセッションとともに保存されます（examples/demo_common/sessions.py の SessionStore。トランスクリプトの隣にバージョン管理された状態ドキュメントが保存されるため、別のプロセスで処理されるリクエストでも読み込めます）。各マップでは最新の PROVENANCE_CAP 件のレコードが保持されます（commerce_common/types.py の remember）。破棄された ID を使うには、再度読み取る必要があります。
9. コンポーネントは検証され、その商品、注文、指標、または変更がこれらのレコードから結合され、出所情報のない ID は破棄されて報告されます（commerce_common/presentation.py の run_presentation、各ロールの enrichment.py、commerce-ui-tools）。

数値や用語に関する回答の根拠を示す

10. 用語についての質問、注文についての質問、未確認の商品 ID（shopping_agent/grounding.py の GROUNDING_RULES）、パフォーマンスについての質問、またはステージング済みの内容がない状態での申請リクエスト（merchant_agent/grounding.py）は、該当する読み取りから開始します。commerce_common/grounding.py の first_forced_tool が読み取りを選択し、Messages API ランタイムは tool_choice でそれを強制し、SDK ランタイムはルールにプリフェッチ形式がある場合に事前取得します（commerce_common/agent_sdk.py の ground。用語のルールにはありません）。ホスト型の経路ではプロンプトのみを使用します。
11. 用語集は設定タプル（policy_intent_terms、order_intent_terms、product_id_patterns、metrics_intent_terms と、それぞれの手がかり）です。デプロイ時に独自の単語を追加でき、ゲートフラグでルールを無効にできますが、どちらもプロンプトのバイト列は変更しません。

サーバー上で本人性を維持する

12. セッション開始時に、認証済みプリンシパルを推測困難なセッション ID に紐付けます。後続のリクエストで送信するのはその ID のみであり、ルートはレコードからプリンシパルを取得します（examples/demo_common/sessions.py の SessionStore.start と session_dependency）。リクエストのフィールドやツール引数でユーザー、マーチャント、オペレーターを指定することはありません。MCP サーバーは環境からプリンシパルを取得し、本番サーバーではリクエストから取得します。
13. プリンシパルがレコード（注文、チケット、出品）を所有しているかどうか、および呼び出しが依存する手順が完了しているかどうかは、バックエンドがストアを照合して確認します。ID の由来がわかっていても、所有者であることや準備ができていることの証明にはなりません。

記憶する内容を制限する

14. 2 つの書き込み経路（save_memory とターン後の抽出）を通るすべての事実は、commerce_common/memory.py の validate_fact による検証を通ります。キーは最大 64 文字、値は最大 200 文字、MemoryCategory の 3 つの値のいずれかである必要があり、さらにデフォルトで識別子の形式の値を拒否する MemoryWriteFilter によるチェックも行われます。memory_blocked_patterns でパターンを追加でき、checks が設定されたフィルターは既存のフィルターを置き換えます（MemoryRuntime.build）。
15. 抽出では直近のやり取りにおけるユーザーとアシスタントのテキストを読み取ります（commerce_common/turn.py の transcript_text）。extract_and_store は、その間に対象が削除されていた場合、バッチ全体を破棄します。Messages API ランタイムは抽出を実行し（update_memory）、SDK ホストはランタイムを呼び出します。ホスト型の経路では save_memory 経由でのみ書き込みます。
16. memory_retention_days（with_retention）、MemoryStore.delete_fact、MemoryStore.clear、enable_memory は、すべての経路で適用され、プロンプトやツールのバイト列は変更しません。サンプルでは読み取りルートと削除ルートを公開し（examples/demo_common/memory.py の install_memory_routes）、アカウント削除時には clear を実行します。
17. 対象は、買い物客の user_id または操作の merchant_id です（各ロールの executor.py にある memory_subject）。

結果で拒否し、インターフェースを固定する

18. 保留された呼び出しは、ゲート名を含む通常の結果を返します（commerce_common/streaming.py の ToolOutcome.held。ホストの tool_result イベントには status: blocked が含まれます）。失敗時にはエラー結果を返し、execute が例外を送出することはありません。
19. ツール一覧は設定によって決まります。enable_web_search（デフォルトではオフ）でツールが追加され、SDK ランタイムでは登録済みの名前を許可リストで制限し、マニフェストではツールを 1 つずつ有効にします。
20. リファレンス MCP サーバーは、認証を行うゲートウェイが前段にあることを環境変数で明示しない限り、ループバックにバインドします（commerce_common/mcp_server.py の enforce_local_only_bind）。

敵対的評価のための 2 つのルール

• 有害な出品、レビュー、メッセージは、デモデータやカタログデータの外部にある評価用フィクスチャとして保存され、実行ごとにマージされます。
• すべての拒否ケースには、同じ領域に処理すべきケースを対にして用意します。これにより、スイートで過剰な拒否も検出できます（commerce-evals）。