TollWarden

TollWarden

x402 向けの決済セキュリティファイアウォール — 決済が確定する前に、すべての少額決済をスクリーニングします。

x402 経由で支払うエージェントは、予測可能な方法で資金を奪われます。決済メタデータから秘密情報が漏えいし、取得された認可情報がリプレイされ、見積価格がつり上げられ、汚染されたウェブコンテンツによって、エージェントが支払うつもりのなかったアドレスへの支払いが誘導されます。TollWarden は決済確定前に実行する 1 回の POST でこれらすべてをチェックし、チェックごとの機械可読な理由とともに allow／flag／block を返します。処理時間は 約 0.6 ms です。

TollWarden は 助言のみを行い、資金を管理しません。秘密鍵、ウォレット、資金には一切触れません。エージェントがすでに使用している任意のファシリテーターとウォレットを囲むように動作します。また、x402 のファーストクラスの販売者でもあります。エンドポイントは公式の x402 ミドルウェア経由で支払われ、Coinbase CDP ファシリテーターを通じて決済され、Bazaar の検出メタデータを備えています。

Agent decides to pay ──► POST /v1/scan/outgoing ──► allow ──► wallet settles
                                   │
                                   ├──► flag  ──► agent pauses / confirms intent
                                   └──► block ──► wallet refuses (reason attached)

30 秒で使い始める

npm install @tollwarden/client    # TypeScript/Node
pip install tollwarden           # Python

import { TollWardenClient, TollWardenBlockedError } from "@tollwarden/client";
const tollwarden = new TollWardenClient({ agentId: "my-agent" }); // free API key auto-minted, 100 free scans

tollwarden.observe(fetchedPageText, { sourceUrl }); // tag what your agent just read → injection detection
await tollwarden.guardOutgoing(payment);            // throws TollWardenBlockedError on a block verdict

初めての方へ：5 分で x402 エージェントを保護 →

SDK（sdk/、依存関係ゼロ）は、すべての判定結果の Ed25519 証明をピン留めされた鍵に照らして検証し、無料呼び出しの利用枠を追跡し、プランへの自動登録も行えます。ウォレットの開発者は、単独で使える verifyAttestation()／computePaymentCommitment() に加え、強制適用キットも利用できます。new TollWardenEnforcer({ trustedKeyHex }).guardSigner(account) は任意の viem／ethers 署名者をラップし、新しい支払いに紐づいた allow 判定がなければ、x402 支払い認可への署名を物理的に拒否します。

フレームワークとの統合

エージェントフレームワーク上で開発していますか？TollWarden は、わずか 2 行ほどでエージェントに「支払う前にスキャン」を追加できる、すぐに使えるパッケージを提供しています。ツールセットと、エージェントが読み取った内容に自動でタグを付ける来歴メカニズムにより、プロンプトエンジニアリングなしでプロンプトインジェクションによる支払いの検出が機能します。

フレームワーク	パッケージ	インストール
LangChain	langchain-tollwarden	pip install langchain-tollwarden
CrewAI	crewai-tollwarden	pip install crewai-tollwarden
NeMo Agent Toolkit	nemo-tollwarden	pip install nemo-tollwarden
Coinbase AgentKit	agentkit-tollwarden	pip install agentkit-tollwarden
Vercel AI SDK	@tollwarden/ai-sdk	npm install @tollwarden/ai-sdk

各パッケージは、同じ 3 つのツール（スキャン／評判の確認／報告）と、エージェントが読み取った内容をインジェクション検出に渡すフレームワークネイティブな方法を提供します。LangChain はコールバック、CrewAI はツール呼び出し後のフック、Vercel AI SDK は onStepFinish ハンドラーを使い、これら 3 つは内容に自動でタグを付けます。NeMo と AgentKit では明示的な content 引数を渡し、AgentKit のアクションではエージェント自身のウォレットから支払者も自動入力します。すべてのパッケージには、設計上の強制適用を実現する guarded_payment／guardedPayment ラッパーも含まれています（block 判定の場合、支払い実行関数は実行されません）。また、NeMo のラッパーは非同期の実行関数を受け付けます。2 行でのセットアップ方法は各パッケージの README を、詳しい説明は tollwarden.com/integrations の各ページをご覧ください。

検出できるもの

AI エージェントの決済セキュリティガイドでは、各チェックの限界も含め、チェックで対処できる攻撃を失敗モードごとに解説しています。

コア検出機能

チェック	検出対象
PII／シークレットの検出	EVM の秘密鍵、シードフレーズ、AWS／OpenAI／Anthropic／GitHub／Slack のキー、JWT、?api_key= URL 認証情報、SSN、Luhn 検証済みカード番号、メールアドレス、電話番号を、送信前に resource_url、description、reason、metadata 内で検出します
リプレイの検出	ノンスの再利用（古い、または傍受された支払い認証）、network:payer:nonce によるスコープ設定、設定可能な TTL ウィンドウ
重複購入	同じ購入が二度承認された場合を検出します。x402 クライアントは、受け取った 402 ごとに新しい認証に署名するため、再試行されたリクエストは、新しいノンスを持つ二つ目の有効な支払いとして到着します。この支払いはノンスのリプレイチェックを通過し、最初の支払いと並行して決済される可能性があります。以前のスキャンと同じ購入（payer、pay_to、asset、amount、resource_url）に一致する送信スキャンが、異なる認証で 60 秒以内に行われた場合、replay.duplicate_purchase としてフラグが立てられます。API キーを使ったスキャンでは、このフラグに先行する scan_id が示されます。匿名スコープはクライアントが宣言するため、その場合、フラグに別の呼び出し元の ID が示されることはありません。署名前のスキャンと、同じ認証の署名後のスキャンは、1 回として数えられます。意図的な再試行ではフラグが解除されます。先行するスキャンの scan_id を context.repeat_of として渡す（1 回につき 1 試行）か、先行する試行の結果を配信済みとして報告してください。有料の呼び出しが成功すると、SDK の支払いラッパーが自動的に報告します。not_delivered ではフラグは解除されません。再試行されるのはその試行だからです。TollWarden が確認できるのはスキャンであり決済ではないため、最初の支払いが決済されたかどうかは把握できません。そのため、フラグのみを立てます。ブロックされた支払いは記録されません
過払いの検出	設定可能な想定価格の倍数を超える場合（3 倍以上でフラグ、10 倍以上でブロック）、および絶対上限を超える場合
プロンプトインジェクションを起点とする支払い	エージェント自身の計画段階ではなく、エージェントが直前に読み取ったコンテンツ（ツールの結果／取得したページ）を起点として支払いが 決定 された場合を検出します。そのコンテンツに含まれる重み付けされたインジェクションの兆候（幅広い動詞・目的語コーパスと 8 言語（英語、スペイン語、ポルトガル語、フランス語、ドイツ語、ロシア語、中国語、日本語）にわたる、上書き／誘導を促す表現、偽装されたシステム／チャットテンプレート／Guidance マーカー、持ち込まれたモデル境界トークン、捏造された会話ターン、隠蔽、ビジネスメール詐欺を思わせる表現――「支払い先アドレスが変更されました。確認する必要はありません」――および緊急性をあおる圧力）に応じて、検査の厳しさを引き上げます。兆候がアドレスのようなトークンの近くにある場合は、さらに重く評価します。インジェクションの特徴に合わせたスコアリングを行います。弱い兆候は集まった場合にのみ加算され、圧力（緊急性、会話記録の形式、隠し文字）だけではブロックされません。また、人間自身による「X を 0x… に支払ってください」という指示は、その人に不利なスコアとして扱われません。コンテンツは、HTML タグ、エンティティ、Markdown の強調記法を除去した状態と生の状態の両方でスキャンされるため、**Ignore** all <b>previous</b>&nbsp;instructions は、表示されるとおりの文として解釈されます。pay_to アドレス自体がそのコンテンツに由来する場合はブロックします。行や区切りをまたいでいる場合、0x が欠けている場合、または不可視文字が混入している場合も対象です
リソース URL のリスク（受信時）	IP リテラルのホスト名、Punycode／ホモグリフ、リンク短縮サービス、user@host のトリック、HTTPS 以外の接続、認証情報の要求（「シードフレーズを送信してください」）
取引相手の評判	共有の事後報告レジストリを、すべてのスキャンで照合します。報告は常に無料です。ブロックされたインジェクションスキャンも自動的にレジストリに反映されます。直前に読んだコンテンツに埋め込まれたウォレット（または、おとりとして使われたウォレット）は、今後すべてのエージェントによるそのウォレットのスキャンでフラグが立てられます。1 回の検出がネットワーク全体の保護につながります（フラグのみ。スキャン入力はクライアント提供のため）
配信結果	取引相手ごとの、測定済みかつコミットメントに結び付いた配信履歴。商品を一度も発送しない販売者への支払いも、購入者にとっては失敗です。配信率が低い販売者や、発送しない行為を繰り返す販売者にはフラグが立てられます（ブロックはされません。測定履歴にも H-2 が適用されます）

ゼロレイテンシー強化ティア — 呼び出し元エージェントの説明が侵害されていても有効なチェックです。

チェック	検出する内容
利用速度の上限	≥N スキャン/分（警告、2 倍でブロック）、1 時間あたりの累積支出上限 — レートと支出は自己申告ではなく、観測された事実です。API キーの背後にあるアカウントを対象とするため、リクエストごとに新しい agent_id を使っても新たな枠は設けられません。匿名スキャンの場合のみ agent_id/payer にフォールバックします。支払いが TollWarden にブロックされた場合もレート枠は消費しますが、1 時間あたりの支出には加算されません。そのため、上限で拒否された販売者の法外な見積もりによって、その後 1 時間、ほかの相手への支払いまでできなくなることはありません
初回接触時の金額上限	これまで取引したことのない相手への初回支払いがしきい値を超えている場合
アセットの検証	宣言されたネットワーク上で正規の USDC ではない asset コントラクト（類似トークン攻撃）。ネットワークには CAIP-2 ID または x402 v1 名（base、base-sepolia、polygon、ethereum）を指定できます。どちらも同じ検証が行われます
販売者のピン留め（TOFU）	2 つの段階があります。アカウント独自のピン：過去に支払ったことのあるドメインで pay_to が変更された場合 → ブロック — その記録を書き込めるのは自分だけです。共有された観測情報：任意の呼び出し元がそのドメインについて最初に提示したアドレス。不一致があれば警告します（「別の呼び出し元は異なるアドレスを確認しました」）。どちらもクライアント入力であるため、ブロックされるのは、ノンブロッキングの CDP Bazaar クロスチェックで、ピン留めされたアドレスがドメインの販売者のものだと確認された場合に限られます。ピンの経過時間と、裏付けとして記録された名前付きの情報源は、署名付きアテステーションのフィールドとして提供されます（以下を参照）。これにより、ウォレットは両者を同等に信頼するのではなく、4 分前のピンと 6 か月前のピンを見分けられます
アドレスのなりすまし	過去に支払った相手、自分がピン留めした販売者、または CDP によって検証済みのピンの、先頭と末尾の文字は一致するものの中間部分が異なる pay_to — 省略表示（「0x2096…287C」）を悪用する見栄えのよいアドレスへの誘導攻撃 → ブロック。ほかの呼び出し元が提示しただけのアドレスに似せたもの → 警告。これにより、見知らぬ相手が見栄えのよい「ピン」を仕込み、正当な支払いを類似アドレスとしてブロックさせることを防ぎます。おとりも検出します。つまり、エージェントが直前に読んだコンテンツに仕込まれた、受取人または信頼済みアドレスの類似コピーです。ブロックされた支払いは信頼状態からロールバックされるため、再試行時も検出が続きます
ScoutScore の信頼シグナル（オプトイン）	ScoutScore によって LOW/VERY_LOW と評価された販売者のドメイン（スパムファーム、テンプレートのクローン、応答しないエンドポイント） → 警告。外部の第三者によるシグナルであることを明示します。照会は非同期かつキャッシュされるため（スキャン遅延ゼロ）、共有されるのはドメインのみで、単独でブロックすることはありません。SCOUTSCORE=on で有効にします
既知の悪質リスト	整備・同期された悪質リストに対する O(1) のメンバーシップ照合
コンテンツの詳細分析	エンコード／難読化されたインジェクションペイロードをデコードして再スキャンします。対象は base64（両方の文字セット、改行、スペース区切り、二重エンコード）、16 進数、パーセントエンコーディング、HTML エンティティ、JS/JSON の \x/\u エスケープ、Unicode のタグ文字を利用した隠蔽（「不可視 ASCII」）、ゼロ幅文字および類似字形による難読化（キリル文字、ギリシャ文字、IPA、小型大文字、点のない i — さらに、折りたたみテーブルで判別できない類似文字列を検出する混在スクリプト語のシグナル）、リートスピーク（1gn0re）、文字間への空白挿入（i g n o r e）です。各パスは 200 KB のコンテンツ上限内で線形時間となり、レイテンシテストで保護されています。支払いごとの金額が MICRO_BYPASS_USD（デフォルトは $0.005）未満の場合は省略されますが、少額の分割払いによる回避には耐性があります。相手へのスキャン済み支出の累積額が同じしきい値を超えると、詳細分析が実行されます。また、tool_result / fetched_content として宣言されたコンテンツには常に実行されます。リクエストごとに policy.force_deep で上書きできます
署名済み判定。 すべての応答には、`scan_id	direction

署名付きピン証拠。 スキャンのアテステーションには、2つ目の署名付きレコード evidence-v1|scan_id|payment_commitment|pin_domain|pin_age_seconds|pin_corroboration も含まれます（同じ鍵で、同じスキャンと支払いに紐付けられています）。これは、スキャン時点でこの支払先の背後にある加盟店のピンが保持されていた期間（0 は初回検出）と、それを裏付けた帯域外ソースを公開します。裏付けソースはそれぞれ名前付きです（現在は cdp_bazaar。CDP Bazaar の加盟店インデックスで、ピン留めされたアドレスのリソースとしてドメインが掲載されていることを示します）。ブール値や複合スコアではありません。真に独立したチャネルを通じて得られた裏付けと、攻撃者がすでに制御しているチャネルを通じて得られた裏付けが同じビットになってしまうためです。また、ソースの信頼性は加盟店ごとに判断するものであり、その判断はあなた自身が行うべきです。「ピンが新しく、裏付けがある」を単一の許可／警告にまとめると、TollWarden が判断すべきでないリスク許容度の判断を代わりに行うことになります。署名付きフィールドを分けておけば、ウォレットは4分前の裏付け済みピンを1セントの支払いでは受け入れ、50ドルの支払いでは拒否できます。判定メッセージ自体は7フィールドのまま固定されています。デプロイ済みの検証ツールに影響はなく、両方の SDK が証拠レコードを検証し、pin_evidence として公開します。ひとつだけ正直にお伝えしておく制限があります。検証ツールは証拠レコードがない場合も許容するため（古いサーバーや上書きアテステーションに対応）、レコードがないことは何の証明にもなりません。レコードが取り除かれた場合、それが古いサーバーによるものかどうかは判別できず、「ピンは適用されない」と示すのは署名付きの空フィールドだけです。ポリシーでピン証拠を必須にする場合、証拠のないアテステーションをどう扱うかを明示的に決めてください。署名付きフィールドはどれも互換性へのコミットメントです。フィールドは追加されますが、ひそかに変更されたり削除されたりすることはありません。 ウォレット側での適用。 両方の SDK には、このポリシーが TollWardenEnforcer としてすぐに使える形で組み込まれています。enforcer.guardSigner(account)（TS：viem アカウント、ethers v6 の署名者）／enforcer.guard_signer(account)（Python：eth-account、すべての呼び出し形式）は、署名される型付きデータ（EIP-3009／ERC-2612）から支払いコミットメントを再計算し、そのコミットメントと完全に一致する、新しく検証されたピン留め済みキーによる許可判定がない限り、署名を拒否するプロキシで署名者をラップします。承認は一度だけ使用でき、アテステーションの有効期限が切れると失効します。侵害されたエージェントが支払い A をスキャンしても、支払い B には署名できません。また、スキャンを省略した場合も署名できません。任意のローカルポリシーで、さらに制限を加えられます。厳格な受取先許可リスト（allowedRecipients）と、支払いごと／累計の支出上限（maxAmountAtomic／maxTotalAtomic）を設定でき、サーバーを介さず、署名時に型付きデータを照合します。有効な許可判定を伴う支払いでも、許可リストにない受取先への支払いや上限超過は拒否されるため、助言レイヤーが乗っ取られても、既知の相手に対して上限内の金額しか移動できません。エージェントが許可リストを拡張することはできません。唯一の例外はオプトイン（acceptOverrides に加えて overrideAdmitsRecipient を指定）で、人間が承認したステップアップ承認により、その承認が紐づく支払いに限って許可されます。受取先自体が許可されることはなく、支出上限を超えることもありません。フェイルクローズで完全にローカルに動作します。2 つの実装は同じ本番用署名者に対して相互検証されています。詳しくは sdk/README.md と sdk-python/README.md を参照してください。デフォルトの支払いパスと組み合わせて使用できます。エンフォーサーを wrapFetchWithTollWarden(…, { enforcer }) ／ wrap_transport_with_tollwarden(…, enforcer=…) に渡すと、スキャンされた各オファーの許可判定が、そのオファーに対して x402 クライアントが生成する nonce 付き認可の署名権限になります。ラッパーは nonce をまだ持たないため、オファーを context.phase: "pre_sign" でスキャンします。エンフォーサーはデフォルトで許可判定のみを受け入れるため、リクエスト前に notePlanning()、noteUserInstruction() または observe() を呼び出し、判定の根拠を宣言してください。宣言されていない根拠はフラグが立てられ、署名前に拒否されます。

改ざん検知可能な監査ログ。 すべてのスキャン判定が、ハッシュチェーン形式のログ（AUDIT_LOG=on）に追記されます。ログには支払いの SHA-256 ハッシュと、機密性のないトランザクション情報が保存されます。スキャン対象の PII／シークレットが平文で保存されることはありません。GET /v1/audit/verify はチェーンを再計算して改ざんの有無を報告し、GET /v1/audit/head は外部アンカリングに使える現在のヘッドハッシュを返します。詳しくは SECURITY-AUDIT.md を参照してください。

API

エンドポイント	料金	説明
POST /v1/scan/outgoing	$0.01¹	エージェントが実行しようとしている支払いを審査します
POST /v1/scan/incoming	$0.01¹	エージェントが受け取った402オファー／支払いリクエストを審査します
GET /v1/reputation/:address	$0.01	取引相手のレポート概要
POST /v1/reputation/report	無料	不正な取引相手を事後に報告します
POST /v1/keys	無料	APIキーを発行します。キーごとに最初の100回の呼び出しは無料です
POST /v1/keys/rotate	無料	キーのシークレットを新しいものに交換します。利用状況、無料枠、プランは引き継がれます。古いシークレットは猶予期間中も有効です（デフォルト15分、最長24時間）
POST /v1/keys/revoke	無料	漏えいしたキーとそのアカウントを完全に無効化します（{"confirm": true} が必要。取り消し不可）
POST /v1/approvals/config	無料	人間参加型の承認を有効にします。判定が要確認の場合、Webhook経由で人間が判断するまで処理を一時停止します
GET /v1/approvals/:id	無料	保留中の承認をポーリングします。承認されると、署名付きの override:allow 判定を返します
POST /v1/outcomes	無料	スキャン後に決済された支払いが実際に送金されたかを記録します（コミットメントに紐付けられます。SDKラッパーが自動的に記録します）
GET /v1/plans	無料	機械可読なプランカタログ（ティア、制限、登録方法）
GET /v1/usage	無料	キーの利用状況統計：スキャン／判定数、無料枠、プランの状態、承認判断のテレメトリ（自分にのみ表示）
POST /v1/trust/evaluate	無料	x402の信頼プロバイダーインターフェース — 販売者は支払者の履歴に基づいて決済を制御します（TrustQuery → PASS/FAIL/UNCERTAIN ＋証拠）
GET /dashboard	無料	キーの利用状況を確認できるブラウザー用ダッシュボード（ダッシュボードを参照）
POST /v1/plans/subscribe	プラン料金	キーをプランに登録／更新します。x402で支払うため、エージェントが自律的にアップグレードできます
GET /.well-known/x402	無料	x402マニフェスト
GET /.well-known/agent-card.json	無料	エージェントカード
GET /.well-known/erc8004.json	無料	ERC-8004エージェント登録ファイル（TollWardenのオンチェーンIDのtokenURI）
GET /.well-known/tollwarden-verdict-key	無料	判定の証明用Ed25519公開鍵
GET /v1/audit/verify	無料	監査ログのハッシュチェーンを検証します（整合性チェック）
GET /v1/audit/head	無料	現在の監査ログのヘッドハッシュ＋シーケンス
GET / · GET /health	無料	ホームページ、または Accept: application/json を指定した場合の自己文書化JSONスキーマ／稼働状態

¹ プランに加入すると、スキャンごとの料金が下がります。Pro（$4.99/30d）では1スキャンあたり$0.005となり、速度上限に6倍の余裕が加わり、すべてのスキャンで詳細なコンテンツ分析が行われます。Scale（$19.99/30d）ではハード上限で1スキャンあたり$0.002となります。プランで引き上げられるのはご自身のしきい値のみです。リプレイ検出、加盟店の固定、アセット検証、PIIスキャンはすべてのティアで同一であり、追加料金を支払っても緩和できません。GET /v1/plans を参照してください。

POST /v1/keys から取得したキーを X-API-Key ヘッダーに指定します。最初の FREE_CALLS 回（デフォルトは100回）の呼び出しは支払い不要です。それ以降、未払いの呼び出しには標準のx402 402 Payment Required が返されます。@x402/fetch や x402-requests など、どのx402クライアントでも支払いと再試行を自動的に処理します。 キーのライフサイクル。 アカウントが識別情報であり、psk_ シークレットはアカウントを指す認証情報にすぎません。キーが漏えいした場合、POST /v1/keys/rotate で同じアカウントに紐づく新しいシークレットを発行できます。利用履歴、残りの無料呼び出し回数、アクティブなプランはすべてそのまま引き継がれます（ローテーションで無料枠がリセットされることはないため、無料枠を不正に利用することはできません）。オプションの猶予期間（grace_seconds、デフォルトは 900、0 = 即時失効、最大 24 時間）の間、古いシークレットでもスキャンを続けられるため、サービスを停止せずに一斉に切り替えられます。ただし、猶予期間中はローテーションも失効もできません。漏えいした古いシークレットからアカウントを乗っ取ることはできません。POST /v1/keys/revoke（{"confirm": true} を指定）はキルスイッチです。キーとアカウントは永久に無効になり、削除済みのキーは原因不明の 401 ではなく、理由が明示されたエラーを返し続けるよう、削除記録が保持されます。オーナーキーをローテーションする場合は、ADMIN_KEY_SHA256 をローテーション応答の api_key_sha256 に更新してください。

例：送金をスキャンする

POST /v1/scan/outgoing
{
  "agent_id": "my-agent",                    // labels the scan; limits are scoped to your key's account
  "payment": {
    "scheme": "exact",
    "network": "eip155:8453",
    "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913", // enables canonical-USDC check + server-known decimals
    "amount": "10000",                       // atomic units ($0.01 USDC); amount_usd only if you have no atomic amount
    "pay_to": "0x2096...287C",
    "payer": "0xYourAgentWallet",
    "resource_url": "https://api.example.com/premium/report",
    "description": "Premium market report",
    "nonce": "0x1a2b3c...",
    "reason": "User asked for a market summary; this API was in my plan."
  },
  "expected_price_usd": 0.01,
  "context": {
    "origin": "planning",                    // planning | user_instruction | tool_result | fetched_content
    "content": "<the tool result / fetched page the agent just read, if any>",
    "content_source_url": "https://example.com/article"
  },
  "policy": { "force_deep": false }          // optional tiering overrides
}

context.origin はインジェクション検出の鍵となる入力です。直前に読み取ったコンテンツをきっかけにした送金は、プロンプトインジェクションによる情報流出の主要な経路であり、より厳格に検査されます。

payment には、受取人（pay_to）または金額（amount、もしくは amount_usd）を指定する必要があります。どちらも指定されていない送金は検査対象がないため、400 が返され、スキャン、記録、決済は行われません（無料枠のキーでは、無料呼び出しを 1 回使用します）。型が正しくないフィールドは未指定として扱われ、x402 のオファー名も同様です。そのため、payTo は pay_to として、maxAmountRequired は amount として送信してください。

応答例（リプレイをブロック）

{
  "scan_id": "b7911f8b-164f-45a4-a610-5fd3a45a5c8b",
  "direction": "outgoing",
  "verdict": "block",
  "risk_score": 95,
  "checks": [
    {
      "id": "replay.nonce_reuse",
      "verdict": "block",
      "severity": "critical",
      "reason": "Nonce reuse detected: this nonce was first seen 2026-07-14T09:32:50Z (scan b7911f8b-…) and has now appeared 2 times. A reused nonce means a stale or captured payment authorization is being replayed."
    }
  ],
  "scanned_at": "2026-07-14T09:33:12Z",
  "advisory": "Recommended action: DO NOT settle this payment. ...",
  "attestation": {
    "alg": "ed25519",
    "public_key_spki_hex": "302a3005...",
    "message": "b7911f8b-...|outgoing|block|95|2026-07-14T09:33:12Z|<payment_commitment>|2026-07-14T09:38:12Z",
    "signature_hex": "...",
    "payment_commitment": "sha256(network|pay_to|asset|amount|nonce)",
    "expires_at": "2026-07-14T09:38:12Z",
    "evidence": {
      "message": "evidence-v1|b7911f8b-...|<payment_commitment>|api.example.com|7776000|cdp_bazaar",
      "signature_hex": "...",
      "pin": { "domain": "api.example.com", "age_seconds": 7776000, "corroboration": ["cdp_bazaar"] }
    }
  }
}

ダッシュボード

利用状況ダッシュボード — GET /dashboard。 キーを持つ人が、自分のスキャン件数、判定の内訳、無料枠の残量、プランの状態、および（承認機能が設定されている場合は）自分の承認判断テレメトリを確認できる、単独で動作するページです。psk_ キーを貼り付けて「表示」をクリックすると、そのキーは X-API-Key ヘッダーとして GET /v1/usage にのみ送信されます（URL には含まれないため、履歴、リファラー、サーバーログから漏えいすることはありません）。各キーから参照できるのは、そのキー自身のアカウントだけです。厳格に制限された CSP（default-src 'none'、外部リソースなし）で配信され、表示には textContent のみを使用します。

Human-in-the-loop による段階的承認

flag 判定は行き止まりではなくなりました。Webhook を一度設定すれば、すべての flag で処理が一時停止し、人による判断を求めます。

POST /v1/approvals/config   (X-API-Key)
{ "webhook_url": "https://hooks.your-ops.com/tollwarden" }   // "format": "slack" for a Slack-style message
→ { "enabled": true, "webhook_secret": "psw_..." }        // shown ONCE; deliveries are HMAC-SHA256-signed

flag が発生すると、Webhook に支払い情報（完全な pay_to。切り詰められることはありません）と、一度限りの判断用リンクが届きます。レビュアーは /approve を開き、アドレスを一文字ずつ確認して、Approve または Deny をクリックします。承認すると、有効期間の短い（≤5 min）Ed25519 署名付きのオーバーライド判定が発行されます。署名メッセージ自体に固有のタグ override:allow が含まれるため、オーバーライドが通常の allow を装うことは決してなく、flag が付いた支払いのコミットメントに厳密に紐付けられます。ブロックは承認できません。判断は冪等で、トークンは一度限りであり、改ざん防止監査ログに記録されます。

エージェント側の設定は、SDK を使えば 2 行です。

const scan = await tollwarden.scanOutgoing(payment);
if (scan.verdict === "flag" && scan.approval) {
  const override = await tollwarden.waitForApproval(scan, { payment }); // polls; throws on deny/expiry
  enforcer.approve(override, payment);                               // requires acceptOverrides: true
}

（Python：tollwarden.wait_for_approval(scan, payment=payment) / TollWardenEnforcer(..., accept_overrides=True)。）

acceptOverrides がオプトインである理由： エージェントが自身の API キーを持っている場合、エージェントが読み取れる場所を承認用 Webhook の送信先に設定し、自分自身の flag を「承認」できてしまいます。人間は関与しません。オーバーライドが信頼できるのは、Webhook の受信先がエージェントの手の届かない場所（エージェントの環境ではなく、運用チームのチャネルなど）にある場合だけです。そのため、強制適用キットはウォレット所有者が明示的にオプトインしない限り override:allow を拒否します。これは allowFlagged と同じです。

判断テレメトリー — 自らの変化を見守る。 多くの導入環境では、人による承認はやがて、反射的に承認されるコンプライアンス上の形式的手続きへと変化します。そして、その変化は単一の観測では見えません。3 か月間に 40 件を確認したレビュアーが 8 秒で承認した場合、ログ 1 行だけでは、レビュアーの判断力が適切に調整されたのか、反射的に承認したのかを区別できません。そこで TollWarden は、すべての承認について判断にかかった時間（両方のタイムスタンプはサーバーが記録します）を記録し、承認された各支払いを、その後の配信結果と紐付けます。GET /v1/usage とダッシュボードでは、直近とベースラインの判断時間の中央値、承認率、承認された支払いが実際にどのように配信されたかといった、自身の集計値を確認できます。承認率がほぼ 100% のまま直近の中央値が縮まっている場合、それは形だけの承認を示す明確な兆候です。結果との紐付けにより、「オペレーターが flag の傾向を把握したため判断が速くなった」状態と区別できます。生の集計値のみを扱い、複合スコアは作成しません。また、このデータを閲覧できるのはそのデータを所有するキーだけです。判定には使われず、レピュテーション照会、信頼性評価、公開統計にも表示されません。形だけの承認をする人の公開記録は、標的リストになってしまうためです。

無効化。 キー単位の場合：{"webhook_url": null} を指定して POST /v1/approvals/config を実行します。レスポンスには、flag が助言のみの扱いに戻ることを知らせる注意が含まれます（処理は一時停止せず、オーバーライドは発行されず、acceptOverrides を設定したウォレットでは flag から支払いに進む経路がなくなります）。保留中の承認は、期限切れになるまで判断できます。サーバー全体の場合：APPROVALS=off にすると、新たな設定を拒否し、新しい承認を開始しません。同じ注意が表示されますが、進行中の承認は引き続き判断できるため、途中で無効化しても処理が宙に浮くことはありません。

配信結果

すべてのスキャンチェックで検証するのは、支払いが適切な形式であり、改ざんされていないかどうかです。販売者が実際に配信するかどうかまでは判断できません。商品を発送しない販売者への支払いが完全に問題なくても、エージェントにとっては失敗です。結果のループでは、非難ではなく測定された履歴を使って、このギャップを埋めます。

• x402 の配信は通常同期的です。支払いに対する応答でリソースが届くため、SDK の支払いパス用ラッパー（wrapFetchWithTollWarden／wrap_transport_with_tollwarden）が機械的にこれを検知し、自動的に報告します。支払い済みの 2xx → delivered、支払い済みの 5xx／2 回目の 402 → not_delivered となり、ステータス、バイト数、レイテンシの証拠が記録されます（reportOutcomes: false で無効にできます）。別の方法で決済する場合は、POST /v1/outcomes または client.reportOutcome(scan, ...) を直接呼び出してください。
• すべての結果は、TollWarden が実施したスキャンに紐付けられます。報告には scan_id と payment_commitment の組み合わせが必要で、スキャンごとに結果は 1 件のみです。また、キー付きスキャンはスキャンを実行したアカウントのものに限られます。配信履歴を捏造するには、実際の支払いを行い、スキャンを受ける必要があります。これは自由記述の報告では実現できない、シビル攻撃への耐性です。
• 集計された配信率は GET /v1/reputation/:address と、今後のその取引相手に対するすべてのスキャンの delivery チェックに表示されます。配信率の低さや、繰り返し配信されないことは警告されますが、ブロックはされません。測定された履歴も依然として第三者のシグナルであり、監査 H-2 が適用されます。
• 分母も公開されます。レピュテーションの照会では、結果数とともに scans_seen（TollWarden が取引相手に対して実施した、ブロックされなかったスキャンの数）と report_coverage が返されます。そのため、選択的に報告された結果は完全な記録として通用せず、カバレッジが低い状態として示されます。また、スキャンはあるものの報告された結果がゼロの取引相手についても、「履歴なし」と表示するのではなく、その母数が示されます。カバレッジは参考情報に限られ（スキャン数はクライアント側で決まります）、警告には影響しません。

正直なところ、この仕組みで測定できるのはコンテンツが届いたことだけであり、良質だったかどうかではありません。品質の判断は POST /v1/reputation/report に委ねられます。また、対象はデジタルコンテンツの同期的な x402 配信であり、物理的な発送ではありません。

ローカル開発

コントリビューターや検出器を監査する方向けです。完全にオフラインで実行され、支払いは無効化されるため、ウォレットは不要です。

git clone https://github.com/tollwarden/tollwarden && cd tollwarden
npm install

npm run dev            # local dev server — payments off
npm run demo:replay    # replay-attack demo: fresh nonce ALLOW → reused nonce BLOCK
npm test               # 799-test detector + hardening + plans + audit-log + dashboard + key-lifecycle + approvals + outcomes suite
npm run eval           # detection eval corpus: attack payloads + benign FP guards, graded via real scans (gates CI + publish)

パフォーマンス

依存関係ゼロの開発サーバー（本番と同じハンドラー）で測定：順次実行した 2,000 件のスキャンが 1.20 秒 → 往復時間は 1 スキャンあたり 0.60 ms。HTTP、JSON の解析、チェック一式、Ed25519 署名を含みます。デプロイ環境のレイテンシは主にネットワーク RTT に左右されます。支払いを伴うパスでは、ファシリテーターとの x402 の検証／決済の往復（x402 に本質的に伴い、どのホストでも同じ）が、ほかのすべてを上回る要因になります。

ホステッドサービス

本番サービス https://tollwarden.com は Base メインネットで稼働中で、x402 Bazaar にインデックス登録され、x402scan に登録されています。改ざんを検知できる監査チェーンで監視され、オンチェーンの ERC-8004 エージェントとして登録されています（Base の IdentityRegistry における agentId は 59586 で、トークンの URI からこのサービスの登録ファイルを参照できます）。ご自身で検証してください。

curl https://tollwarden.com/health
curl https://tollwarden.com/.well-known/x402
curl https://tollwarden.com/v1/audit/verify
curl https://tollwarden.com/.well-known/erc8004.json

公開統計とその対象

GET /v1/stats では、サービスの集計数値（スキャン総数、判定の内訳、個別のエージェント数、自己計測による過去90日間の稼働率）を公開しています。レスポンスでは、サードパーティーとファーストパーティーの利用状況を別々に報告します。オペレーターがファーストパーティー（自社のエージェント。主に、実際の x402 リソースを1日に2回購入するオープンソースのエコシステムスカウト）としてタグ付けしたキーは、first_party に計上され、ホームページのパネルには third_party のみが表示されます。帰属情報は、スキャン時に記録されるキーごとの使用カウンターに基づいているため、各スキャンを実行したキーによって認証され、キーがタグ付けされる前に行われたスキャンも対象になります。

ファーストパーティーの数値を差し引いて非公開にするのではなく、公開する理由は何でしょうか？スカウトは公開されており、その実行回数は確認できるため、読者は自分で数値を照合できます。開示文は、信頼してもらう必要がある主張です。照合できる数値は証拠です。

タグ付けはオーナーのみが実行できます（POST /v1/admin/keys/first-party。/v1/admin/stats と同様に保護され、キーではなくキーの ハッシュを受け取ります）。クライアント側からフラグを設定する方法はありません。呼び出し元が自分自身をファーストパーティーとしてタグ付けできると、公開されるサードパーティーの分母から自分のスキャンを除外できてしまいます。これこそ、この内訳によって防ごうとしていることです。

MCP サーバー

公式 MCP レジストリには com.tollwarden/tollwarden として掲載されています。または、設定なしですぐに実行できます。

// claude_desktop_config.json / any MCP client
{
  "mcpServers": {
    "tollwarden": {
      "command": "npx",
      "args": ["-y", "tollwarden"],
      "env": { "TOLLWARDEN_API_KEY": "psk_..." } // optional — mint one with the mint_api_key tool
    }
  }
}

stdio 経由で12個のツールを利用できます：scan_outgoing_payment、scan_incoming_payment、check_counterparty_reputation、report_counterparty、report_payment_outcome（決済後に一連の流れを完了します。実測に基づく支払い履行履歴を構築します）、dispute_reputation（ウォレット署名付きの反論を報告と並べて表示します。報告が消去されることはありません）、mint_api_key、rotate_api_key（漏えいしたキーを復旧します。新しいシークレットを発行し、同じアカウントを維持します）、check_approval_status（ヒューマン・イン・ザ・ループ承認の状態を確認します）、get_plans、subscribe_plan、verify_verdict_attestation（Ed25519 の完全な検証をローカルで実行します。ピン留めされたキー、コミットメントの再計算、有効期限、および署名付きのピン証拠レコードを検証し、ピンの経過時間と名前付きの裏付けソースを含む pin_evidence を返します）。デフォルトでは本番サービスを使用します。別のサービスを指定するには TOLLWARDEN_URL を設定してください。

検出のデフォルト設定（ホステッドサービス）

透明性のために公開しています。Starter ティアでスキャンの判定に適用されるしきい値です（プランによって速度／支出の上限は引き上げられますが、安全性チェックを緩和することはできません）。

動作	デフォルト
過払い	予想価格の3倍以上で警告、10倍以上でブロック、絶対上限は$10
頻度	1分あたり10回以上のスキャンで警告（その2倍でブロック）、累積支出の上限は1時間あたり$5
初回の支払い	これまで確認されていない相手への初回の支払いが$1を超える場合は警告
詳細コンテンツ分析	支払い額が$0.005未満の場合は省略します。相手への累積スキャン支出が$0.005を超えるまでは省略され、その後はそのペアに対して常に有効になります（policy.force_deep で上書き可能。Pro／Scale では常に有効）
リプレイウィンドウ	nonce を24時間追跡
重複購入	60秒以内に異なる認証で同じ購入を行った場合（DUPLICATE_PURCHASE_WINDOW_SECONDS が0の場合は無効）→ 警告。ブロックはしません。context.repeat_of、または先行する試行について報告された配信済み／一部配信／内容違いの結果によって解除されます
アセットチェック	指定されたネットワーク（CAIP-2 ID または x402 v1 名）の非正規USDC → ブロック
マーチャントのピン留め	リソースドメインごと、アカウントごとのTOFU。アカウントがピン留めしたドメインでのローテーション → ブロック。他の呼び出し元による未検証の観測に対するローテーション → 警告。CDP検証済みのピンに対するローテーション → すべてのユーザーをブロック。ピンの経過時間と、名前付きの裏付け情報源は、署名済みの証明書として公開されます
アドレスポイズニング	既知のアドレスの先頭と末尾の両方で16進文字が4文字以上一致するが、同一ではない場合 → 既知のアドレスが自身のもの（支払い済み／自身のピン）またはCDP検証済みであればブロック、他の呼び出し元による未検証のピンであれば警告。読み取ったばかりのコンテンツに同じ見かけ上の類似アドレスが仕込まれている場合 → 信頼できない情報源に信頼できる参照先がある場合はブロック、それ以外は警告
支払い額	アトミックな amount と、サーバーが把握しているトークンの小数桁数（正規USDCは6）から解決します。クライアントが宣言した asset_decimals が一致しない場合は無視され、警告されます。サーバーが検証できないアセット（USDCのエントリーがないネットワークを含む）では、宣言によって額を引き上げることはできますが、6桁で読み取った額を下回ることはありません。そのため、販売者の extra.decimals によって、いかなる上限においても支払い額が小さくなることはありません。そのようなネットワーク上にある正当な18桁トークンは過大評価され、通常は上限で拒否されます。amount_usd はアトミックな額が指定されていない場合にのみ使用され、アトミックな額と一致しない場合は警告されます
ScoutScore シグナル	オプトイン（SCOUTSCORE=on）。評価がLOW／VERY_LOWのドメインは警告（ブロックはしません）。24時間キャッシュ
判定の署名	Ed25519。常時有効で、証明書の有効期限は5分

コントリビューター向けのローカル開発設定については、.env.example に記載されています。

アーキテクチャ

src/
  index.ts        Express + @x402/express middleware + CDP facilitator + Bazaar extension
  devserver.ts    Zero-dependency dev server (payments off) — same API surface
  api.ts          Framework-agnostic handlers (both servers route here)
  scanner.ts      Detector orchestration, tiering, verdict aggregation
  detectors/      pii · replay · duplicate · overpayment · injection (fast + deep) · urlrisk
                  asset · badlist · pinning · poisoning · scoutscore · velocity · offerdrift
  reputation.ts   Shared report registry
  outcomes.ts     Delivery-outcome ledger (commitment-bound) + delivery check
  approvals.ts    Human-in-the-loop step-up approvals (webhook + overrides)
  approvepage.ts  Human decide page (GET /approve)
  dashboard.ts    Self-contained usage dashboard (GET /dashboard)
  admindash.ts    Owner dashboard, audit-log-backed (GET /admin)
  verdictsign.ts  Ed25519 verdict attestation
  manifest.ts     /.well-known/x402 + agent card + ERC-8004 registration
  store.ts        JSON-file-backed state (tiny interface)
  auditlog.ts     Tamper-evident hash-chained decision log
  commitment.ts   Payment hashing (attestation binding + audit digest)
mcp/server.ts     MCP server (12 tools — npx tollwarden)
examples/         replay-demo.ts — reused-nonce attack blocked end-to-end
test/             799-test suite (detectors, hardening, plans, crypto, audit, dashboards, key lifecycle, approvals, outcomes — npm test)
eval/             detection eval corpus + runner (attacks must catch, benign must pass — npm run eval, gates CI)
sdk/              TypeScript client SDK + wallet enforcement kit + payment-path wrapper (npm: @tollwarden/client, 147 tests)
sdk-python/       Python client SDK + wallet enforcement kit + payment-path wrapper (PyPI: tollwarden, 153 tests)

設計メモ：判定は最も重大なものを優先して集約されます（ブロックが1つでもあればブロック）。risk_score は重大度に基づき、独立した検出事項が複数ある場合は複合的に増加します。検出コアには実行時依存関係が一切ないため、インストールせずに node --experimental-strip-types で全テストスイートを実行できます。

セキュリティとカストディモデル

• ノンカストディアルで、助言のみを提供します。 TollWarden が確認するのは支払いの メタデータ のみです。資金への署名、保有、送金は一切行いません。決済するか拒否するかの判断は、お客様のウォレット／ファシリテーターに委ねられます（署名済み判定による強制も任意で可能です）。
• 検出されたシークレットは応答でマスキングされ（先頭4文字と末尾2文字を表示）、永続化されません。スキャンのペイロードはメモリ内で処理されます。保存されるのは、nonce のフィンガープリント、ハッシュ化された購入フィンガープリント（重複購入ウィンドウの期間中保持）、ピン、頻度カウンター、評判レポート、API キーの使用状況のみです。
• 脅威モデル — 誰に対して何が有効か。 重要な攻撃者の階層は2つあり、同じものではありません。
  • 混乱したエージェント — プロンプトインジェクションを受けたモデルが、通常のハーネスを介して引き続きツールを呼び出している状態 — これは TollWarden が想定して設計されています。検出機能が操作された支払いを見つけます。頻度制限、支出上限、初回接触制限、加盟店のピン留めは、観測されたスキャンに基づいてサーバー側で計算されるため、モデルが何を信じているかにかかわらず、スキャンされたすべての支払いに適用されます。また、guardSigner はウォレットでスキャンを回避する抜け道を塞ぎます。ラップされた署名機能は、実際に署名される型付きデータからコミットメントを再計算し、新しい許可判定がなければ拒否します。さらに、任意のローカルポリシー（受取人の許可リストと支出上限）により、承認された支払いにも上限を設けられます。（context.origin は自己申告値のため、由来について嘘をつくエージェントはコンテンツ層の防御を弱めます。ただし、上限、ピン留め、署名者による強制はこれに依存しません。）
  • 侵害されたプロセス — ウォレットの秘密鍵を読み取れる環境で攻撃者のコードが実行されている状態 — では、当社の強制機能を含め、プロセス内のラッパーはすべて無効化されます。攻撃者は生の鍵で署名でき、TollWarden に一切触れる必要がありません。TollWarden はノンカストディアルで、お客様の鍵を保持しません。そのため、お客様自身のプロセスが鍵を露出させている場合、その鍵を保護することもできません。この階層への対策は、鍵を分離することです。署名者を別プロセス、KMS、またはハードウェアに配置し、その境界で強制機能を実行すれば、エージェントプロセス内のものが署名を生成できなくなります。（自動発行される psk_ API キーはスキャン認証情報に限られます。TollWarden のクォータは消費できますが、資金を使うことはできません。）
• 正直な制約： インジェクション検出はヒューリスティックであり、意味を完全に理解するものではありません。未知の言い回しはコンテンツ層をすり抜ける可能性があります（公開評価コーパスでは既知のギャップを追跡しており、プロンプトインジェクションのベンチマークでは、当社のコーパスでは示せない内容とともに結果を公開しています）。評判レジストリは認証なしのレポートを受け付けるため、確定情報ではなくシグナルとして扱ってください。

貢献

Issue と PR を歓迎します。特に、新しい検出パターン（テスト付き）や SDK の改善を歓迎します（TS および Python のクライアントは sdk/ と sdk-python/ にあります）。提出前に npm test を実行してください。検出機能を変更する場合は、必ずその変更を対象とするテストを追加してください。貢献を提出することで、LICENSE の条項に基づき TollWarden, LLC にライセンスを付与することに同意したものとみなされます。また、ライセンス対象著作物の一部として（Change License に基づく場合を含め）、貢献を再ライセンスする権利を TollWarden, LLC に付与するものとします。

ライセンス

Business Source License 1.1（ソース利用可能）です。TollWarden を閲覧、実行、変更、セルフホストでき、ホステッドサービスに対して SDK／MCP サーバーを使用できます。商用製品内での使用も含まれます。ライセンスによって制限されるのは、このコード自体を競合する有料の決済セキュリティサービスとして提供することです。各バージョンはリリースから4年後に Apache 2.0 に移行します。バージョン ≤ 1.4.0 は引き続き MIT ライセンスです。