SpendVeto

支払いを行うAIエージェントのための支出ガバナンスレイヤー。 ペイメントレールはエージェントの資金を動かす。SpendVetoは、エージェントがその資金を動かしてよいかを決定する — ポリシーチェック、人間による承認、委任された予算上限、暴走エージェント用のキルスイッチを、支払いが発生する前に強制する。

web3 リサーチブリーフの「最小の実テスト」として始まり、2回のリサーチ主導フィーチャーラウンド（GPTディープリサーチ + ライブ市場調査）を経て、ガバナンス付きのx402 + MCPスタックに成長した。資金調達のポジショニングと市場数値は PITCH.md にある。

これが実際に何か

有料エンドポイントのカタログの前に置くガバナンスゲート。アクセス方法は、CLI・委任された子エージェント・任意のMCPクライアントの3つ:

agent (CLI / child wallet / Claude via MCP)
   → frozen? (manual kill switch, or auto-frozen by the runaway-burst detector)
   → policy check (per-call, hourly, rate, cascading delegation caps)
   → [maybe: human approval on the dashboard — fails closed on timeout]
   → pay $X USDC via x402 (simulate or Base Sepolia testnet)
   → GET /api/agent/<tool> → Claude does the task
   → everything lands in the ledger; blocked-spend dollars roll up on the dashboard

Related MCP server: Proofpane

クイックスタート

npm install
npm run server               # terminal 1 — :8402, dashboard at http://localhost:8402
npm run call                  # terminal 2 — pays for "review" ($0.01), auto-approved
npm run call -- summarize      # $0.02 — above the approval line: go approve/deny it on the dashboard
npm run call -- translate      # $0.005

npm run verify で全体をヘッドレスに実行 — エンドツーエンドのアサーション264件: カタログ、署名偽造の拒否、ハードポリシーブロック、3つの承認結果（承認 / 拒否 / タイムアウト時はフェイルクローズ）、委任上限（n段階のカスケードを含む）、ツール＋チェーンのスコープ制御、マルチチェーン決済（チェーンスコープ付き署名、チェーンごとの残高、チェーン許可リスト）、暴走バーストの自動フリーズ、手動キルスイッチ、署名済みレシートの検証、CSVエクスポート、ツール別・ウォレット別・チェーン別の分析、実際に受信側へ届くwebhookアラート、構造化された自己修正拒否、副作用ゼロのドライラン、TTL付与の期限切れ、ワンクリック承認リンク、統計エンドポイント、AP2マンデート連鎖のドリフト検出、人間が不在である間の権威、ガバナンスされたマーケットプレイス探索、ACP共有支払いトークンのスコープ、リクエストの完全制約バインド（承認後にすり替られたペイロードを含む）、署名付き紛争証拠パックとその改ざん検出、受信traceparent配下でのOpenTelemetryスパンエクスポート、実際のMCP stdio JSON-RPCラウンドトリップ。

数について: 新しいクローンで実行されるのは 264 件のアサーション。さらに3件は、Basis に対する実クロスプロジェクト統合にテスチェックであり、このリポジトリの隣に ../prediction-copilot がチェックアウトされているときだけ実行される — ないときは、スイートは (skipped: cross-project Basis integration test …) を表示する。公開している数値は、誰でも想像できる264のか。

マーケティングサイト: npm run site でデプロイ可能なランディングページ（Three.jsヒーロー、アニメーション機能概要）が http://localhost:8403 で提供される — site/ は完全静的で自己完結型なので、Vercel/Netlify にそのまま置ける。実際のポリシー・ロジックをクライアントサイドで動かすインタラクティブプレイグラウンド（site/playground.html） — 予算を設定し、エージェントの支払いを発火させて、pass/pause/block を確認可 — と、実際の 2026 年のエージェント支出シナリオに基づくユースケースページも含む。

カタログ

shared-config.js にある、実際のClaude対応ツールを3つ、3つの価格で:

MCP — モデルに回避できないガバナンス

mcp/server.js は有料カタログをあらゆるMCPクライアントに公開する。エージェントにはふち ょうなツールに見えるが、すべての発見はタスク実行前に完全なガバナンスパイプラン（ポリシー → 承認 → x402支払い）を通過する。一方で、パイプライン・ブロックされた呼び出しは「どのゲートで止まり、何も支払われなかった」を説明するツールエラーとして返る。

# Register with Claude Code (server must be running: npm run server)
claude mcp add spendveto -- node ~/Desktop/spendveto/mcp/server.js

または Claude Desktop の設定で:

{ "mcpServers": { "spendveto": { "command": "node", "args": ["/Users/you/Desktop/spendveto/mcp/server.js"] } } }

4つのツールが現れる: review、summarize、translate (それぞれの説明文に価格あり) と spendveto_status (無料 — ウォレット、残高、ポリシー、直近1時間の支出、保留中の承認、委任バジェット)。Claudeに 「私のエージェントの予算状態は？」 と聞いてから、「有料の summarize ツールを実行して」 と依頼すると、ダッシュボードふじに承認が出る動きを確認できる。

予算の委任 (「お金のためのIAM」)

上位ウォレットは、子エージェントのウォレットに上限付きの生涯予算を付与する。子もさらに委任できる。上限はカスケードする: 孫の支出は自分の上限とすべての祖先の上限に同時にカウントされるので、サブエージェントのチーム全体でも、その分岐の最上位にある予算を超えられない。強制は、呼び出しごとに呼び出し元自身のポリシーチェックで実施。ダッシュボードには、階層が実際の支出対上限バーとして表示される。

npm run delegate -- 0.015 "team lead"                 # main wallet grants $0.015
npm run delegate -- 0.05 "intern" --parent "team lead" # team lead grants onward
npm run call -- review --child=intern                  # fine — fits both caps
npm run call -- review --child=intern                  # BLOCKED … granted to ancestor "team lead"
npm run delegate -- 0.02 "translator" --tools translate # scope, not just size
npm run call -- review --child=translator               # BLOCKED … outside its delegated scope
npm run delegate -- 0.02 "base only" --chains base-sepolia  # pin the settlement chain too
npm run call -- review --child="base only" --chain=polygon   # BLOCKED … outside its delegated chain scope
npm run delegate -- 0.05 "flash task" --ttl 10m              # time-boxed budget: self-expires

いつでも撤回可能: POST /api/delegations/:id/revoke — 撤回リンクは、その下の分岐全体を即座に無効にする。

レシート・エクスポート・アラート・分析

シミュレートモードのすべてには サーバーの ECDSA署名が付く (settlement.signature / signedBy / receiptId)。これによりレシートは独立して検証でき、さらにアドレス指定も可能になった: GET /api/receipts/:id で検索、POST /api/receipts/verify は任意のレシートの署名をサーバー側検証する（価格を改ざんすると拒否 — テスト済み）。ポリシーに alertSigningSecret を設定すると、webhook配信ごのに X-SpendVeto-Signature HMACヘッダーが付与され、受信者はSpendVetoからのアラートであることを証明できる。完全な台帳は /api/export.csv からCSVで取り出せ、 /api/analytics にはツール別・ウォレット別サマグリゲートがある。data/policy.json に alertWebhookUrl を設定すれば、フリーズ、ブロックされた呼び出し、承認待ちが例えばSlackのインバウンドwebhookへと実時間でPOSTされる。

キルスイッチ＋暴走検出

ダッシュボード（または POST /api/freezes）で任意のウォレットをフフリーズできる。ポリシーのバースト閾値（デフォルト: 10秒間で10回）を超える速度で支払いを試行するウォレットは 自動的にフリーズ される — 暴走エージェントのループは、来月の請求書ではなく、バーストの途中で捕捉される。凍結されたウォレットは、自身のポリシーチェックで入口を塞がれる上、正しい署名渡の署名付き支払いであってもシミュレート支払いゲートで 403 拒否される。エージェントが何をしていたのか原因を調べた上で、クリックでフリーズを解除できる。

強制プロキシ — キーレス展開（“支払い経路上のSpendVeto”）

npm run proxy (:8404) で信任 モデルが逆転する: エージェントに秘密鍵を一切持たせない。 エージェントは支出の意向をPOSTし、プロキシは資金を保持し、フルパイプライン（フリーズ → ポリシー → カスケード上限/スコープ → 承認）実行、そのあと初めて署名と支払いをする。悪意のあるエージェントは、署名に使える何かを持っていないので、ポリシー点検をスキップすることができない。

curl -X POST localhost:8404/proxy/call -H 'Content-Type: application/json' \
  -d '{"tool":"review"}'                      # custody wallet
  -d '{"tool":"review","child":"intern"}'      # spend as a delegated child, by label

拒否された意向は 403 応答となり、どのゲートで、なぜ、そして構造化された拒否理由が返る — 何も署名されず、何も移動されない。Idempotency-Key を（ヘッダまたはボディで）送れば、再試行された意向は2重支払いではなく保存済みの応答を再生する — クラッシュループを続けるエージェントが二重支出できないようになっている（テスト済み：同じキーで2回送信 → 台帳への記録は1件）。

エージェントがアクションできる拒否、トライラン、時間ボックス付き予算

2026年7月のリサーチラウンドで生まれた3つの仕組み（launch/DEEP_RESEARCH_PROMPTS.md を参照）:

• 自己修正型拒否 — すべてのブロックが command-readableな code（per_call_cap、chain_scope、hourly_usd_cap、delegation_expired、…）と具体的な suggestion（「許可されたチェーンで再試行: base-sepolia, base」/「このラインの残予算は $0.0050 — もっと安いツールを選ぶ」）を含む。CLIはこれを Fix: 行で表示し、MCPのブロックツールエラーにも含まれるため、モデルは無限リトライループではなく自己修正できる。プロキシは 403 ボディでこれを返す。

• ドライラン — npm run call -- summarize --dry-run（またはプロキシで {"dryRun": true}）は、パイプライン全体（フリーズ、チェーンルール、上限、委任のウォーク、承認しきい値）を評価し、支払う / 承認のために一時停止 / ブロック（修正策つき） を副作用なしで報告する: 支払いも、承認依頼も、台帳記録も発生しない（テスト済み）。

• 時間ボックス付き予算 — 任意のグラントに --ttl 90 / --ttl 10m / --ttl 2h を指定できる: expiresAt を過ぎ取り消し済みと同じ死にグラントと扱われる。さらに期限切れの 祖先 を持つと、その分岐全体が無効化される。

• ワンクリック承認 — 承認webhookが approveUrl / denyUrl を持つようになり、Slackのアラートから1クリックで承認の可否を決定可能。

1つのAPI、あらゆるレール（rails/）

すべての支払いレールは、同じ4行のコントラクトの裏につながる — { id, name, status, pay({ tool, account, chain, baseUrl }) } — ガバパイプラインはどのレールが決済したかを一切感知しない。現時点で x402-simulate（シミュレートモード）と x402-live（ライブモード、ファシリテーターが支援する全チェーンに適応）の2つのレールがあり、GoogleのAP2、OpenAIのACP、Stripe Machine Payments は「アダプタ・スロット」として宣言されており、実装ではなく（not implemented yet — funded-roadmap slot）と正直に返す。GET /api/rails で台帳を提供し、プロキシは /proxy/health でそれを公開する。まさに「AgentのためのStripe」のような仮想を、送金業者ライセンスを宛てずに実現している: 一の前にある単一の統合、ガバネンスは上位、決済実効は下位。

SDK・LangChain・並行性安全な大きさ

CLI と MCP サーバー以外に、コード・レベルの統合で2つの選択:

• sdk/ — Node クライアント（SpendVeto クラス）: .pay()、.dryRun()、.chat()（ガバナンス付き LLM/API 支払い）、.registerAgent()、.catalog()。ブロックされた呼び出しは、静かに何もしないのではなく、型化された SpendVetoDenialError{code, suggestion, stage} を投げる。

• integrations/langchain.js — カタログツールをLangChain形式の { name, description, func } 文章として提供。@langchain/coreへのハード依存がまったくない、ブロック拒否に対するは構造化code` を内包するので、エージェントの次の推論ステップで自己修正される。

• integrations/openai-agents.js — OpenAI Agents SDK 形式の { name, description, parameters, execute } として同じガバナンスカタログを提供する（tool() ヘルパーの規約）。@openai/agents へのハード依存なし。LangChainアダプタを再構成しているので両方一方のパイプラインで動く。

これらはすべて執行プロキシを経由してし、現在はウォレットごとに決定と実行を直列化している（client/pay.js の withWalletLock） — 複数リクエストが同時に同じウォレットに届き、同じ「支出合計」スナップショットを読んで、最終的に全体で上限を超えてしまう競合条件を防ぐ。上限をちょうど1つ分だけ許容するケースで6並列コールを試すと、100%い率でそのうちの1つだけ成功する。API例：docs.html#sdk。

エージェント、マルチマーケットプレイス、レポートページ（Console が完成）

この2ページで、APIがすでにできたことと、人間がクリックできることを連携クローズする。 エージェントは、ウォレットに結び付けられANDウェブフォームからマーケットプレイスツールを追加できる（curl不要）。レポートはローリングウィンドウで「このコストは何に、ガナンスは何て止めたか」 — GET /api/report?days=7 — を、チャット用の1行にまとめたヘッドライン、カテゴリ別・チェーン別消費、ガバナンスが止めた理由のトップ原因とともに返す。

競合他社に対するパリティコントロール(2026年7月リサーチマップから)

この市場で資金を得たプレーヤーが持つ4つのコントロールを、誠実に再現し、テストしたもの。

• エージェントID（Skyfire 式の "know your agent"）— POST /proxy/agents {label, child} がベアラートークンを発行し、オプションで1つのウォレットにバインドできます。IDが1つも存在しない間はオープンモード（セットアップ不要のデモ用）です。最初のアイデンティティが登録された瞬間から、プロキシインテントには Authorization: Bearer … が必須になり、バインド済みトークンは自分のウォレットとしてだけしか支払えません（動作確認済み: ボディ内の child によるオーバーライドは無視されます）。GET /proxy/agents/:id/credential はKYAクレデンシャルそのものであり、その1回の読込で、そのアイデンティティをウォレットのライブな信頼スコア、フリーズ状態、委任スコープ（上限/ツール/チェーン/支払先）に結び付けます。これにより、取引相手は「このエージェントは実際に何を許可されているのか」を、4つのエンドポイントを手作業で照合しなくても確認できます。

• カテゴリ上限（Ramp式）— 各ツールは支出カテゴリを持ちます。ポリシー内の "categoryCapsUSD": {"content": 5} は、カテゴリごとの1時間あたりの上限を、台帳自身のタグから算出します。

• 複数承認者ルール（Safe式）— "approversRequired": 2: 拒否は即時かつ最終です。承認は、必要な人数の人間がクリックして初めて成立します（テスト済み: 承認が1件だけでは保留のまま）。

• 取引時間帯ウィンドウ — "allowedHoursUTC": {"start": 13, "end": 21}: このウィンドウの外側では、どの金額も支出されません。「自分のボットが午前3時に取引してしまった」を防ぐ制御であり、日付をまたぐウィンドウにも対応します。

2026年7月の競合再スキャン時からさらに5件（x402 Foundation発足、AP2/Mastercard Agent Pay/Visa Trusted Agent が稼働開始）

• エージェントごとのレート制限＋フリーズ（proxy/server.js）— ウォレットレベルの予算上限は引き続き金額の正本ですが、複数のエージェントIDが1つのウォレットを共有する（agents.json）ため、そのウォレット上の他の全エージェントをフリーズしなくても、特定の1つの異常があきれたループするエージェンだけを停止できる必要があります。各IDには独自のスライディングウィンドウ式コール上限（PER_AGENT_CALLS_PER_MIN、デフォルト20回）があります。カウンタが制限に連続3回当たるという、そのIDだけを自動でフリーズします（POST /proxy/agents/:id/freeze と /unfreeze で手動制御も可能）。これは既存のフリーズストアを合成キー agent:<id> で再利用するという、他と同じダッシュボード表示・アラートの対象になります。

• 署名付き同意記録（server/consents.js、Visa Trusted-Agent-Protocol方ぶり）— 委任の発行または取り消しの際に、ECDSA署名付きの同意記録も書き込まれます（決済レシートとAP2判定に署名する同じサーバ側キーを使います）。GET /api/consent/:delegationId で証跡を参照し、POST /api/consent/verify で、JSONファイルを無条件に信頼せずに、どのレコードの署名も独立に検証できます。

• Agentic Token (POST /api/agentic-token、Mastercard Agent Pay 式) — 前述の2つのプリミティブを薄くて誠実なまとまりとして実現: ちょうど1つ のマーチャント支払先に限定されたデリゲーションと、それに対応した署名済み同意を1つのオブジェクトとして返します（GET /api/agentic-token/:id で参照）。執行は、全てのデリゲーションがすでに受け取る、同じ permitチェック＋上限チェックです。

• AP2 判定結果用のであるVerifiable-Credential 書き出し（server/vc.js） — POST /api/ap2/evaluate?format=vc は、同じ署名済み判定を W3C-VC 型のエンベロープに組み替えます（AP2自体が Verifiable Credential 上に築かれています）。このラベルは正直です。proof タイプは SpendVeto 独自のもので、登録済み的DIDメソッド・証明スイートではありませんが、proof.message と proof.proofValue は、ラップされていないエンドポイントが返すものとまったく同じ ECDSA 署名してあり、verifyMessage や任意の ECDSA ライブラリで独立に検証できます。

• レール横断のレシート正規化（server/receipts.js） — GET /api/receipts/normalized は、すべてのレジャーエントリ（x402 の暗号通貨上での決済、継続計測した LLM/API 支出、今後どのレイルで決済されるかに関わらず）を、安定した1つの形に射影します。これにより、クライアントは各レエントリがどの決済レール由来か知る必要がありません。proof は、実際に署名済みのレシートを持つエントリにのみ格納され、持たないエントリに対して含められることはありません（誤造されない）。

2026年8月の再スキャンからさらに3件（AP2 v0.2.0、x402 v2 Bazaar）

前回から進んだ2つのプロトコルによって、ガバナンス層が対象としなければならない領域が変わりました。このどちらも、コール単位の支出上限が構造的に見つけられないギャップを生んでいます。

• エージェントの委任連鎖（チャネルマンデート）—「カートが本当に意図どおりか？」 (server/ap2.js、POST /api/ap2/mandate-chain) — AP2 は購入を連鎖としてモデル化します。人間が署名する Intent Mandate の連なり、エージェントが組み立てる Cart Mandate (購入カートの委任) です。/api/ap2/evaluate は単一の金額だけを判定するため、この委任連鎖が明示しようとしている失敗、つまり「予算内だが未承認のカート」を検出できません。この機能は、カートが由来と主張する Intent（意図）に対し、カートを検証します。インテントの上限を超える合計（cart_exceeds_intent）、自身の明細行と矛盾する申告合計 (cart_total_mismatch — カートが証明できない合計というのは上限と比較すべき数値ではないため、上限の検証より先に実施）、インテントが承認していないマーチャントまたはカテゴティ (merchant_drift / category_drift)、インテントが許容するより多くの販売者に1回の承認を分散させた分散買い占め (multi_merchant_spray — 作為ある構成されたもののコードで、この機能を文書化しています)、期限切れのインテント、過去のインテントに由来しないインテントを付けて提出されたカート、を検出します。決定専決でローカル処理です。モデルがドリフトを判定することはありません。判定は他の全判定と同じ、ECDSA 署名で行います。

• 人間が居ない場の認可（同じエンドポイント）— AP2 v0.2.0 は、人間が存在せずエージェントが購入するフローを正式に定めました。こうした場合、「承認のために一時停止」は停止ではなく、誰にも答えられない問いになります。それを停止のように扱うと、フローが止まったままになるか、静かに承認を通してしまいます。SpendVeto の原則: 署名済みの Intent Mandate こそが人間の事前承認であるため、その明示された上限内であれば呼び出しを進めます（preAuthorizedByIntent: true として判定にも記載）。上限を超えた場合、あるいはインテントが上限をまったく指定していない場合は、その支出を許可する根拠が存在せず、問い合わせる人もいないため、安全側に倒れて拒否します (hnp_no_authority)。上限を超える支出を、暗黙のうちに「許可」へ上げることはありません。

• ガバナンス付きBazaarディスカバリ（server/discovery.js）— x402 v2 の Bazaar レイヤーでは、エージェントが出会ったこともないサービスを発見して支払うことができ、事前に組み込んだ統合も不要です。これはメリットであり問題でもあります。というのも、決済時にだけ参照される安全な支払先リストは、プロンプトインジェクションに boot かかったエージェントが選択したエンドポイントを、遅すぎるタイミングで知るからです。GET /api/discovery/resources は、Bazzar のスキーマで SpendVeto 自身のカタログを公開します（CA-IP2 ネットワーク、USDC のもととなる単位、governed と標識して価格が下限であることを購入者に通知）。POST /api/discovery/govern は反対方向に動きます。それは 探索された カタログを、エージェントが確認する前にライブのポリシーでフィルタリングし、決して支払いを許されないサービスを、候補の一覧から除外します。各除外には、対象になったルールと施行中のポリシーバージョンが明示されます。この事前フィルタは、侵害されたエージェントから「どんな名前を聞きうるまで」かを縮めます。最終的に選んだものは、呼び出し時にフルのパイプラインを実行されます。

さらに4つ。2025年8月の競合ディープスキャンから（Fireblocks/x402、ACP、エージェント・チャージバック、OpenObservability）

バイヤー側にプレイヤーが急増しました。Fireblocksが x402 Foundation に加わり、リクエストの完全性と支出ガバナンス のためのセキュリティ拡張を提供しています。HWWは支出上限つきの Bedrock Agent Core Payments をプレビューし、Cloudflare は出すの幅を調整する Account Wallets を発表しました。2025 年の Cloud Security Alliance 調査では、エージェント運用企業の65%が 12 か月に一つ以上のエージェント関連 events を経験したと出ています。このスキャンから4つの隙間が出てきましたが、どれも「1回の利用ごとの上限支払」という構造にできるものではありません。

** request integrity ―「これは自分が許可した支出かどうか」 (server/integrity.js、POST /api/integrity/bind → /api/integrity/verify) — ここまで紹介してきたあらゆる制御は「これは許可されている支出か？」に答えるものです。しかし、どれも「これは自分が許可した支出か？」には答えていません。ポリシーは記述された要求に対して実施されます。その実体は別のものごとに確認されます。両者の間に、改題されたエージェンまたはのでgithubな動きをするエージェントが、ペイロードを変えることができます — 同じ支払い者、同じ価格、同じ承認、しかし別のマーチャントかまったく別の商品、という形で、そして金額ベースのすべての制御を通りすぎて、金額が何も動いていないからです。そこで、リクエストを正規のダイジェストにして（再帰的ソートキーによるSHA-256、キーの並び順では結果を変更できない）、その digest に レシートと 判定に署名するで同じキーで署名し、ペイロードが合致しなくなったとき実行事はられます（request_integrity_mismatch）。このバインドは1回限り（binding_consumed — 再生可能な承認はクーポンであり、バインドではありません）、TTL制限(binding_expired)、エージェントにスコープ (binding_agent_mismatch)。これは、Fireblocks が x402 に提供しているものの購入者側の同等物です。

• ACP Shared-Payment-Token のスコープ（server/acp.js、POST /api/acp/checkout）— ACP Delegated Payments Spec は SPT を発行します。つまり、金額、マーchant、有効期限を入れて発行される bearer 証明であり、エージェントは購入者のカードを見なくてもチェックアウトができます。マーchant がトークンを検証します。しかし買い物かごを検証する人-宇宙の誰も検証しません。その場合、$200 にスコープされた別のマーchant でのトークンが、その $200 の間違った商品を平然と通します。これは、上記の AP2 ドリフトと同型内訳でしょうかソリューションです。よって同じ方式が当た： spt_merchant_drift、session_exceeds_spt、spt_expired、spt_category_drift、session_total_mismatch（これは明細行で正当に説明できない合計なので、cellingの前に計算されます）、spt_currency_mismatch — Year長社见得は一方の通貨の ceiling を他方の通貨の負担と比較することを拒否しますが、为替 conversion tempting を推測しません。認可されたセッションはそのまま自身のバイト列にバインドされた実行で終わり、拒否されたセッションにはバインディングが作られません。

• 紛争証拠パック（server/disputes.js、GET /api/disputes/:entryHash/evidence） — 人間が請求に対して異動を申し出たとき、マーチャントは デバイスの指紋、IP、復旧、閲覧セッション、配達確認時の配達証明 で防御します。しかしエージェント購入はこれらのどれも生成しないため、エージェントのトランザクションはデフォルトで定義の反証され、マーチャントが支払いを支払うことになります。Visa TAP、Mastercard Agent Pay、AP2 と Amex の agent 保護はすべて 認可プロセス を説明しています。しかし、何も「事後の防御ファイル」を定義していません。SpendVentoはすできっとそれを持っています—新しくcaptureするもの種類はありません。1つは、レジャーエントリを、そのハバウチャーのハッシュに挟ませた形で(バックデートを防ぐ議論)、当時のポリシーハッシュとその後のデータドリフトを隠さずに普及中より開示で、人間の承認記録、および pay payがその下行動した従来委任の署名済み同意をまとめ、束全体をその同じダイジェストで署名します。そしてパックを挂号中に編集されたものは、検証が折れるるとエラーを表示します (pack_tampered)。各パックは、アーティファクト内部に doesNotEstablish リストを保持します。これは配達、満足、ポリシーが適切だったことを意味しません。単に「そのポリシーが有効であり、それが適用された」ということをだけを告知ますし。

• OpenTelemetry 判定スパン (server/otel.js、GET /api/otel/spans) — エージェントチームは、すでにプロンプト、ツールコール、サブエージェントのリレーションをトレースしています。ガバーサンス評価で何度も頭に出るセキュリティ要求は OTel ネイティブの可視化で、向かでは「その支出を引き起こしたトレース内のスパン」として見えなければならないというものです。つまり、誰かが午前3時に別の、システム内のtimestampを相関させるのではなく。OTLP/HTTP はJSON over POST のため、依存関係がありません。信頼しないことが役割であるそのコンポーネントに OpenTelemetry SDK を導入するのは、無益に供給連鎖の表面積を増やすだけです。W3Cの traceparent を渡すと、拒絶イベントは支払いを試みたエージェントの実行のまがりくねった痕跡の下に記録されます。span idはエントリのハッシュから求まるため、再出力してもバックエンドでスパンが重複しません。不正なヘッダーは1,000のトレースに崩れますが、デシジョンサーフェスが壊れることはありません。ブロックされた支払いは、エラーではなくステータスokです。ゲートはその仕事を行ったからで、拒否を赤色にすると、チームが重要な色を読まなくなるというトレーニングになります。

マーケットプレイス＋アローワンス：双方向フライウェル

このゲートの裏で、誰でもある有料ツールを出品できます。これツールがコストになることですね。固定したデモではありません：

curl -X POST localhost:8402/api/catalog/tools -H 'Content-Type: application/json' \
  -d '{"id":"haiku","price":0.008,"label":"Haiku writer","upstreamUrl":"https://your-api.example/haiku"}'
npm run call -- haiku        # any agent pays it through the full governed pipeline

出品されたはツールも、前と同じレベルの 402 ゲート（チェーンscooeシグネチャ、、レシート、レジャー）を持ちます。upstreamUrl があれば支払いされた呼び出しが転送され、なければ固定本文で応答します。スウェラーはリストし、購入側はガバナンスを行う。エージェントからコマースの両側がワンのスタックに存在します。

予算は、許可という形も可能です — 決して枯渇しないローリングウィンドウで再度充填されるキャップです。:

npm run delegate -- 5 "shopping agent" --every 7d    # $5 a week, self-refilling

ウィンドウ内の支出は上限にカウントされ、期限が切れると予算は自動的に補充されます（2秒ウィンドウでテスト済み：支出→ブロック→自動補充→再び支出）。これは「エージェントに週次手当を与える」プリミティブです——今日はチーム向け、明日はコンシューマーエージェント向け。

シミュレートされたチャージアップ: POST /api/balances/topup {address, chain, amount} は、シミュレートモードでチェーンごとの残高に資金を供給します（そしてそこだけです——オンチェーン残高は実際のフォーセットから来るもので、APIから来ることは決してありません）。

API支出レール：エージェントがすでに消費している資金を統治する

暗号通貨はレール#1です。なぜならローカルで検証可能だったからです——しかし同じパイプラインがLLM/API支出を統治します。これは、すべてのエージェントチームが今日資金を失っている場所です：

curl -X POST localhost:8404/proxy/llm -H 'Content-Type: application/json' \
  -d '{"prompt":"summarize x402 in one line","maxTokens":200}'
  -d '{"prompt":"…","maxTokens":20000}'          # big estimate → pauses for human approval, FAILS CLOSED
  -d '{"prompt":"…","child":"intern"}'            # delegated budgets bind token spend too

認証/キャプチャは、実際の支出プラットフォームと同様に：最悪ケースのコストが事前に見積もられ（LLM_RATE_IN_PER_M / LLM_RATE_OUT_PER_M、100万トークンあたりのUSD——プロバイダーの価格表から設定）、完全なパイプラインが見積もりに対して実行され（フリーズ→ポリシー→カスケード予算→承認）、上流の呼び出しはそれを通過した場合のみ発生し、実際の計測コストは同じ台帳に記録されます——チェーンと並んで独自のapiバケットに集計されます。ANTHROPIC_API_KEYが設定されていれば完了は実際のものになり、なければ完了はシミュレートされますが、統治と計測はシミュレートされません。エージェントのトークン、API呼び出し、USDCはすべて1つのポリシーエンジンに従います。

マルチチェーン：チェーン認識型の統治、ロゴの飾りではない

7つのチェーンがshared-config.jsに登録されており（それぞれ正規のUSDCコントラクトとRPCを持つ）、/api/chainsで公開されています。チェーンはすべての支払いの統治される次元であり、エンドツーエンドで：

• チェーンスコープの署名 — チェーンは署名された支払いメッセージ内に含まれるため、Polygon用に作成された認可が別のチェーンの残高に対して決済されることは決してありません（テスト済み：polygon署名の認可はarbitrumで拒否されます）。

• チェーンごとの残高 — すべての(wallet, chain)ペアは独自のシミュレートされたUSDC残高を持ちます。Polygonでの支払いはPolygonのみを借方に記録します。

• チェーン許可リスト — data/policy.jsonの"allowedChains": ["base-sepolia", "base"]は、エージェントが他の場所で決済することをブロックします。cautiousおよびproductionパックはチェーンが固定されて出荷されます。

• チェーンスコープの委任 — --chains base-sepoliaは子の決済チェーンを固定し、（キャップやツールスコープと同様に）すべての祖先のチェーンスコープがサブツリー全体を拘束します。

• どこでも — npm run call -- review --chain=polygon、プロキシインテント（{"tool":"review","chain":"arbitrum"}）、/api/analyticsでのチェーンごとの集計、CSVエクスポートのチェーン列、ダッシュボード台帳のチェーンタグ。

• ファシリテーター適応型ライブ決済 — テストネットモードでは、ゲートは起動時に設定されたファシリテーターに何を決済できるか（GET /supported）を尋ね、ファシリテーターが指定するすべてのレジストリチェーンをライブにします：チェーンごとのスキーム登録と、各402にチェーンごとに1つのacceptsエントリ。各チェーンの正規コントラクトに対する明示的なアトミックUSDC金額として価格設定されます。モックファシリテーターに対して両方向でテスト済み：7つすべてを宣伝すると7つすべてがライブになり、1つを宣伝すると正確に1つだけがライブになり、残りは/api/chainsでsettlement: "ready"を報告します。公開ファシリテーターは今日Base Sepoliaを決済します。SPENDVETO_FACILITATOR_URLをCDPファシリテーター（APIキー付き）に向けてウォレットに資金を供給すると、コード変更ゼロでそのメインネットチェーンがライブになります——実際のメインネット支出への残りのギャップは、キー、資金、セキュリティ監査であり、エンジニアリングではありません。

オンチェーン決済は今日x402経由でBase Sepolia上でライブです。登録されたすべてのチェーンはシミュレートモードで完全なパイプラインを実行します（実際のチェーンスコープの署名、ローカル決済）。チェーンごとのファシリテーターアダプターが資金提供されたマイルストーンです——統治レイヤーはすでにチェーン完全です。

証拠サーフェス：SIEMイベント、ポリシーバージョン管理、署名付き判定、請求

2026年7月の調査ラウンドは明確に述べました：レールは支払いをログします。企業はその前の決定の証拠を必要とします。4つのサーフェス（すべてテスト済み）：

• 決定イベント — GET /api/eventsはハッシュチェーン台帳を1つの安定したスキーマ（spendveto.decision.v1）に再形成します：エージェント、決定、金額、受取人、拒否理由、レシートID、ポリシーバージョン、保管連鎖ハッシュ。GET /api/events/exportはJSON Linesを出力します——1行に1つの決定、Splunk/Datadog/Elastic/jqに直接、エンベロープ解析なし。

• ポリシーバージョン管理 — すべてのゲート決定には、その時点で有効なポリシーのSHA-256であるpolicyHashがスタンプされます。「この支出を許可したポリシーはどれか？」は、ポリシー編集を何回行った後でも、台帳だけで回答可能です。

• AP2スタイルのマンデート評価 — POST /api/ap2/evaluateは、AP2形式のマンデート（エージェント、金額、受取人、有効期限）に対して完全なポリシーパイプラインを実行し、サーバーのレシートキーによってECDSA署名された判定を返します：誰でも検証できるポータブルな証拠。期限切れのマンデートはmandate_expiredで拒否されます。AP2 決済は正直なロードマップスロットのままです——これは統治の半分であり、今日現実のものです。

• 統治された請求 — 決済は1つのspendveto.usage.v1イベント（レシートIDでキー付け）をpolicy.billingWebhookUrlにプッシュし、オプションでHMAC署名されます：SpendVetoは支払い前を強制します。Lago/Orb/Metronomeタイプのプラットフォームは使用後を請求します。分業であり、請求エンジンではありません。

CONTROLS.mdのコントロールインベントリは、これ（および他のすべてのコントロール）をEU AI法 / NIST AI RMFランタイム期待にマッピングします——各行はそれを実行するverifyアサーションを引用しています。自己評価であり、明示的に認証ではありません。

トラストスコアとポリシーパック

GET /api/trust/:addressはウォレットの統治履歴を0〜100のスコアとレターグレードに圧縮します——支払い履歴は信頼を獲得し、ブロック、失敗、フリーズはそれを燃やします（暴走ウォレットはスコア0でグレードF）。スコアは現在2つの方法でスケールアウトします（両方テスト済み）：GET /api/trust/graphはトラストグラフを構築します——すべてのウォレットがスコア付きノード、すべての委任がエッジ、すべての委任ルートが「組織」で、そのサブツリー全体にわたる支払い量加重スコアを持ちます——そしてGET /api/trust/payee/:addressはカウンターパーティ信用調査所です：受取人の評判が、それに支払った（または支払いをブロックされた）すべてのウォレットにわたって集約され、その支払い者の平均統治スコアを含みます。依然として1つのデプロイメントの独自の台帳から計算されます——これらのグラフの組織間連合が、これが種をまくロードマップです。

統治はプリセットとして出荷されます：npm run policyはパックを一覧表示し（cautious / standard / production）、npm run policy -- apply cautiousは1つを適用します（以前のポリシーは.bakに保存されます）。チームは独自のパックをコミットできます。

ヒューマン・イン・ザ・ループ承認

requireApprovalAboveUSD（data/policy.json内）を超える価格は呼び出しを一時停止し、ダッシュボードの承認キューに投稿します——承認/拒否ボタン、ライブ。3つの結果、すべて理由付きで台帳に記録されます：承認→支払い。拒否→支払いなしで終了。30秒以内に決定なし→フェイルクローズ（署名なしで支出することは決してありません）。

2つのモード、両方とも本物

本物に見せるために偽装されたものはありません——シミュレートモードは本物の署名を検証し、偽造された署名を拒否します（テスト済み）。ローカルで決済するだけです。テストネットモードは、ライブの公開ファシリテーターに対する実際の@x402/express/@x402/fetch v2パッケージであり、フォーセット資金供給境界までツールごとに動作確認済みです（ブラウザ+キャプチャ——自動化できない唯一のステップ）。

ファイル

shared-config.js         tool catalog (id/path/price), 7-chain registry (USDC contracts, RPCs), mode, port
server/
  index.js                Express app: catalog, ledger, stats, analytics, CSV export, policy, approvals, delegations, freezes APIs
  simulate.js              per-tool 402 gate factory: real signature verify, replay protection, freeze refusal, signed receipts
  agent.js                 the paid tasks — one Claude call per tool, canned fallback without a key
  ledger.js                JSON ledger + simulated balances
  approvals.js              in-memory pending-approval store
  delegations.js            durable budget-grant store (caps + tool scopes)
  freezes.js                durable kill-switch store
  anomaly.js                runaway-burst detector → auto-freeze
  alerts.js                 fire-and-forget webhook alerts (Slack-ready)
  ap2.js                    AP2 mandate chains: cart-vs-intent drift + human-not-present authority
  discovery.js              x402 v2 Bazaar: publish the catalog, and policy-filter a discovered one
  acp.js                    ACP shared-payment-token scope: is the session the purchase the token funds?
  integrity.js              request binding: is this the spend I allowed? (canonical digest, single-use)
  disputes.js               signed dispute evidence packs — the agent-chargeback defence file
  otel.js                   OTLP decision spans; adopts an inbound W3C traceparent, blocked ≠ ERROR
client/
  wallet.js                parent keypair + delegated child wallets (pick by label)
  policy.js                the governance wedge: freezes, hard limits, approval threshold, cascading caps
  pay.js                   shared governed pipeline: policy → approval → pay → log
  pay-and-call.js           CLI wrapper (--child, --child=<label-or-address>)
rails/
  index.js                 rail registry: one pay() contract, x402 live, AP2/ACP/MPP as honest slots
  x402-simulate.js         zero-setup rail: real ECDSA, chain-scoped, local settlement
  x402-testnet.js          real on-chain rail: Base Sepolia via the public facilitator
mcp/
  server.js                MCP middleware: paid catalog + spendveto_status over stdio
proxy/
  server.js                enforcement proxy: key custody, agents POST intents (:8404)
dashboard/                the Console: 8 pages (overview, approvals, budgets, ledger, chains, analytics, trust, policy) with create/edit/freeze/apply controls
scripts/
  delegate.mjs              grant a capped budget (--parent for deeper levels, --tools for scope)
  gen-wallets.mjs           one-time testnet wallet generation
  policy.mjs                list/apply policy packs
  site.mjs                  serves the marketing site on :8403
  verify.mjs                264 end-to-end assertions incl. MCP stdio round trip + multichain + auto-freeze
data/
  policy.json               editable spend rules incl. anomaly burst threshold + alertWebhookUrl
  policy-packs/             importable governance presets (cautious/standard/production)
  ledger/balances/delegations/children/freezes.json   runtime state (gitignored)
site/                     deploy-ready landing page (Three.js hero, fully static)
PITCH.md                  funding pitch: TAM/SAM/SOM, competition, accelerator targets (all cited)
launch/                   Show HN draft, 90-second demo script, ecosystem-listing blurbs
RESEARCH_PROMPT.md        the deep-research prompt behind feature round 2

ロードマップ（資金調達が買うもの——PITCH.mdを参照）

• JSONファイルストレージを置き換えるホスト型バックエンド（Postgres）。組織、SSO、監査エクスポート

• よりリッチな異常シグナル（価格ドリフト、新規マーチャント、時間外）+ フリーズ時のWebhook/Slackアラート

• マルチレールアダプター：Google AP2、Stripe MPP、Mastercard AP4M——ポリシーレイヤーはどのレールが決済するかを気にすべきではない

• CDPファシリテーター経由のメインネット決済（x402 v2移行：完了）——資金供給されたウォレット+ CDP APIキーが必要

• フレームワークフック：CrewAIミドルウェア、より深いClaude Code統合。実際のSentient SDLCパイプラインステップをゲート（LangChain：完了、integrations/langchain.jsを参照）

価格設定： セルフホストは永久に無料です（このリポジトリが製品全体です）。ホスト型ローンチティア——Desk $49/月、Team $199/月+統治されたAPI支出の0.5%、Money Pathは統治されたボリュームの10〜25ベーシスポイント——は価格ページのウェイトリストの背後にあります。

Apache-2.0ライセンス——LICENSEを参照。