セキュリティ
yen402を安全に運用するための注意事項です。
秘密鍵をLLMルーター経由で送信しない
AIエージェントを利用する場合、秘密鍵（PRIVATE_KEY）をLLMのAPIリクエスト経由で 送信しないでください。LLMプロバイダーやルーターがリクエスト内容をログに記録する 可能性があります。秘密鍵は必ずローカル環境の環境変数として管理し、 署名処理はローカルで実行してください。
Facilitatorは信頼できるものを使う
Facilitatorはクライアントの署名を検証し、オンチェーンでトランザクションを実行する 中間者です。信頼できないFacilitatorを利用すると、署名の悪用やトランザクションの 改ざんリスクがあります。公式のFacilitator（yen402.com）か、 自身でホスティングしたものを使用してください。
APIキーは定期的に再発行する
APIキーが漏洩した場合、第三者があなたのFacilitatorアカウントを不正に利用する 可能性があります。定期的にAPIキーを再発行し、古いキーは削除してください。 APIキーの管理はダッシュボードから行えます。
recipient_addressはDBで管理する（リクエスト改ざん対策）
受取アドレス（recipient_address）をクライアントからのリクエストパラメータとして 受け取るのは危険です。攻撃者がリクエストを改ざんし、自分のアドレスに変更する 可能性があります。受取アドレスはサーバー側のデータベースで管理し、 APIキーに紐づけて取得するようにしてください。yen402ダッシュボードでは、 APIキーごとに受取アドレスを登録する設計になっています。
Upstash Redis によるリプレイ保護（実装済み）
同一の署名を使い回す「リプレイ攻撃」を防ぐため、Facilitator は Upstash Redis の atomic SET NX + TTL で nonce をクレームしたうえで、オンチェーンの authorizationStateと二段構えで検証します。TTL は認可のvalidBeforeに連動して自動失効し、Redis 障害時は fail-open（オンチェーンが最終防衛線）。 クライアント側で追加の実装は不要です。
チェックリスト
- ☐秘密鍵をLLMリクエストやログに含めていないか
- ☐信頼できるFacilitatorを使用しているか
- ☐APIキーを定期的にローテーションしているか
- ☐受取アドレスをDB管理にしているか（リクエストからの上書き不可）
- ☐リプレイ保護（nonce/txhash管理）を実装しているか