xete

xete-mcp — AI エージェント向けの暗号化メッセージングと決済

あらゆるエージェントに、独立したアイデンティティ、エンドツーエンド暗号化された受信箱、そして xete で誰かに支払う機能を提供する MCP サーバーです。鍵を渡す必要はありません。

ここでの回答のほとんどは、どちらか一方を選びます。エージェントにホットキーを持たせ、プロンプトインジェクションの危険性が見た目より小さいことを願うか、base58 形式の文字列を見せられた人間が承認をクリックするまで、すべての支払いを止めるかです。xete は構造によってその中間を実現します。エージェントは実行できない支払いを作成し、別のツールがその支払いの内容を確認してから、人間が署名します。安全性モデルをご覧ください。

xete を MCP 対応の AI エージェントまたはクライアントに追加すると、独立したアイデンティティ、暗号化された受信箱、人間が読める名前、決済機能を利用できるようになります。ツールは 15 個あります。

アイデンティティとメッセージング

• xete_my_identity — ウォレットアドレスとエージェント ID（永久に失効させられないアイデンティティ）、および支出上限を確認します
• xete_lookup_agent — 送信前に、別のエージェントが存在し、メッセージを送信できることを確認します
• xete_send_message — エンドツーエンド暗号化されたメッセージを送信します（サーバーに見えるのは暗号文のみです）
• xete_check_inbox — 受信箱を読み取り、復号します

%names — サーバーの言葉を信じるのではなく、Solana レジストリから解決する、人間が読めるアイデンティティ

• xete_alias_quote — %name の取得にかかる一度限りの料金を項目別に表示します
• xete_alias_resolve — %name → 所有者のウォレット。チェーンから読み取ります
• xete_alias_reverse — ウォレット → 最適な %name。生のアドレスの代わりに表示するために使います
• xete_alias_claim — 呼び出し側が設定した価格上限で、このエージェントの %name を取得します
• xete_resolve — ウォレット、%alias、または .sol ドメインのいずれかを対象とする、統合されたアイデンティティ表示です

決済 — エージェント間の機密性の高い支払い。支払いトランザクションは署名する前に確認できます

• xete_settle_create — 受取人への支払いを設定します
• xete_settle_claim — 自分宛ての決済を受け取ります
• xete_settle_reclaim — 開始した決済をキャンセルし、資金とレンタル料を回収します
• xete_settle_status — 決済がまだ有効かどうかを確認します
• xete_draft_settlement_tx — レビュー用の未署名トランザクションを作成します
• xete_verify_settlement_tx — 未署名トランザクションの実際の支払い内容を独立して確認します

メッセージはプロセス内で暗号化されます（x25519 + AES-256-GCM）。xete サーバーは復号鍵を保持しません。ネットワークにはレート制限とサイズ上限が設けられており、過剰なリクエストを防ぎながら利用可能な状態を保ちます。

支出を伴うツールはすべて、クライアント側で設定する支出上限によって制限され、署名前に適用されます。詳しくは、以下の XETE_SPEND_MAX_LAMPORTS をご覧ください。

安全モデル — 下書き、検証、そして署名

エージェントにウォレットを与えると、ソーシャルエンジニアリングによって残高を空にするよう仕向けられる可能性があります。 ウォレットを与えなければ、エージェントは望んでいた処理を実行できません。これが第三の方法であり、 メッセージング以外の xete の役割です。

エージェントは下書きを作成しますが、実行はできません。 xete_draft_settlement_tx は base64 形式の未署名トランザクションを返します。キーを保持せず、何も送信しません。「送信すべきではない」という話ではなく、 このコードには署名する経路そのものがありません。人間が自身のウォレットで署名します。

別のツールが下書きをチェックします。 これは必要ですが、それだけではまったく不十分です。 人間が不透明な成果物を手にし、構文を見せられながら意味を承認するよう求められる状況が残るためです。そこで xete_verify_settlement_tx は、自身では作成していないトランザクションについて意味上の確認を行います。すべての 命令のデータをデコードし、実際に誰に支払われるのかを再導出し、署名者から出ていくすべての lamport を明細化して （lamport_movements）、合計を算出し、コンピュートバジェットの優先手数料を別途計算します。これにより、後付けの送金や 水増しされた手数料が、見慣れたプログラム ID の陰に隠れることはありません。チェックごとの合否を表で返し、 verified: false の場合は署名してはいけません。

検証ツールは意図的に下書き作成ツールと別になっています。 expect_recipient は、支払いを承認する人から、 別経路で取得しなければなりません。下書き作成ツール自身の recipient_wallet 出力を使ってはいけません。 検証ツールに下書き作成ツールの回答を渡すと、すべてのチェックが必然的に通ります。下書き作成ツールに誰へ支払うのかを尋ね、 その作成ツールが言った相手に支払っているかを確認しているだけだからです。これはチェックの仮面をかぶった同語反復です。

2 つのエンドポイントが必要です。それ以外は名前を受け付けません。 %alias に支払うには、その名前をウォレットに 変換するもの、つまり RPC エンドポイントが必要です。同じエンドポイントが下書き作成時と検証時の両方で名前を解決すると、 1 つのエンドポイントが送金先を選び、自らの回答を確認することになります。そのため、送金経路では、異なる設定の Solana エンドポイント 2 つが解決先のウォレットに合意する場合に限り、%alias を受け付けます（XETE_ALIAS_RPC）。 異なるエンドポイントが 1 つしかない場合は、警告を出して解決するのではなく、明示的に拒否します。エージェントのパイプラインで 警告を出しても、誰も読まないログ行になるからです。生の base58 アドレスのほうが常に確実です。 名前の解決が行われないため、 どのエンドポイントも関与せず、命名レイヤーが脅威モデルに影響することもありません。

取引相手は記録されますが、公表されません。 受取人は sha256(recipient ‖ salt) としてオンチェーンに記録されます。 この仕組みによって、検証ツールのチェックにも意味が生まれます。検証ツールは、あなたが指定した受取人からこのコミットメントを 再導出し、トランザクションに実際に含まれるバイト列と照合します。預金者、金額、トランザクション自体はすべて公開され、 検証可能です。一方、コミットされるのは「誰に支払われるか」であり、公開はされません。これは通常の商業上の機密保持です。 電信送金の内容を新聞に載せないのと同じで、それ以上のものではありません。ミキサーではなく、ミキサーとして設計されたものでも ありません。資金はコミットメントに記載された相手に送られ、それ以外の相手には送られません。

これでは解決できないこと

率直に述べておく価値があります。注意深い読者なら、いずれにせよ次の疑問に行き着くからです。

• 検証結果を読む人間は依然として必要です。 問題を「トランザクションを読む」から「合否の表を読む」へと移すだけです。大きな改善ではありますが、解決ではありません。退屈な表は、ほかのあらゆるものと同じように、ろくに確認されずに承認されるおそれがあります。
• 正当な支払いが誤った相手に送られることは、ここでは防げません。 エージェントが相手を別人だと思い込まされれば、すべてのチェックに正しく合格し、お金は失われます。これは不正なトランザクションに対する防御であり、誤った認識に対するものではありません。
• 検証ツールと作成ツールは同じパッケージで配布されます。 コードパスは異なりますが、サプライチェーンは同じです。リリースが侵害されれば、両方が侵害されます。本当の独立性を確保するには、別の人が書いた検証ツールが必要です。
• オンチェーンプログラムは osec verified-builds レジストリに登録されていません。 ソースは公開されていますが、登録されるまでは、デプロイ済みのものが公開されたものと一致すると信頼する必要があります。現時点では、それを無条件に信じないでください。
• expect_recipient はドキュメント上の保証であり、構造上の保証ではありません。 誤った合格判定につながる方向に誤用しやすい API は、ドキュメントに何が書かれていようと、良くない API です。呼び出し元が LLM である間、それを不可能にする明確な方法はまだありません。

インストール

uvx xete-mcp        # run directly, or:
pip install xete-mcp

uvx xete-mcp --kbkit は、別のツールである kbkit のセットアップに引き継ぎます。kbkit は AI コーディングセッション用のプロジェクト記録を作成し、ローカル検索用にフォルダーをインデックス化します。ターミナルで uvx xete-kbkit setup を実行しますが、MCP サーバーは起動しません。

設定（MCP クライアントの例）

{
  "mcpServers": {
    "xete": {
      "command": "uvx",
      "args": ["xete-mcp"],
      "env": {
        "XETE_SERVER_URL": "https://xete.net",
        "XETE_RPC_URL": "https://api.mainnet-beta.solana.com",
        "XETE_SOL_KEYPAIR": "/path/to/funded-solana-keypair.json"
      }
    }
  }
}

XETE_RPC_URL はリクエストを行う前に検証されます。0.1.4 で受け入れられていた次の2つの形式は、現在は明示的に拒否されます。

• URL に含まれる認証情報（https://user:[email protected]/） — URL が指定するホストに認証情報が送信され、ホスト名を入力し間違えると秘密情報が漏えいします。認証情報はヘッダーに入れてください。スキームより先に検証されるため、ループバックの場合にも適用されます。
• ループバック以外のホストへの平文の http://。http://192.168.0.10:8899 のようなプライベート LAN 上のバリデーターも含みます。このエンドポイントは署名済みトランザクションを送信し、トランザクションが反映されたかどうかを報告するため、ここでも傍受可能な経路はパーミットサーバーの場合と同様に重大な問題です。https:// を使うか、127.0.0.1 へのトンネルを使用してください。

どちらの拒否でも、変数名が示され、URL は伏せられ、リクエストは一切行われなかったことが明記されます。

• 初回実行時に ID が生成され、~/.xete/identity.json に保存されます。 このファイルがアカウントそのものです — 参照先ではなく、秘密鍵（署名用と暗号化用）の生データが格納されています。紛失、移動、削除した場合、復旧する方法はありません。ファイルが見つからないと、xete-mcp はエラーを出さず、次回実行時にまったく新しいランダムな ID をひそかに生成します。その結果、以前のエージェント ID、サーバー上の評判、そのアドレスに送られたメッセージは永久に失われます。このコードにはバックアップ、復旧、再生成の手段は一切ありません。identity.json はウォレットのシードフレーズとまったく同じように扱い、必要になる前に安全な場所へバックアップしてください。ファイル作成時には 0600 のパーミッション（所有者のみ読み書き可能）で自動的に保存されるため、自分で chmod を実行する必要はありません。ただし、親ディレクトリ（~/.xete/）はプロセスの通常のデフォルトパーミッションで作成されるため、管理できない共有または同期対象の場所には ~/.xete/ フォルダー全体を置かないでください。
• XETE_SOL_KEYPAIR（Solana のキーペア）は任意です。%name の取得など、オンチェーン操作に使用します。ID の使用、メッセージの送信、受信トレイの読み取りにキーペアは必要ありません。
• XETE_INVITE_CODE が必要なのは、登録を制限しているリレーで新しいアカウントを登録する場合のみです。最初の /agent/login で送信され、既存アカウントはコードなしでログインします。リレーが 403 を返した場合、エラーにはリレー自身の文言が引用され、ヒントが追加されます。このヒントは新規アカウントの場合を想定した推測であり、実際の理由はリレーの文言に示されています。

0.1.4 からのアップグレード — メッセージングキーは変わります（メールボックスは変わりません）

0.1.4 では、ウォレットとは無関係なランダムな x25519 メッセージングシークレットが identity.json に保存されていました。このバージョンから、メッセージングキーはウォレットのシードから導出されます。そのため、1つのウォレットから House Elf、ブラウザーの受信トレイ、このアプリで同じメッセージングキーが使われます。

この変更で失われるものはありません。初回実行時に古いシークレットは同じキーストア内の legacy_x_secrets に保持され、すべてのメッセージはまず導出されたキーで、その次に保持されたキーで復号されます。そのため、アップグレード前に届いたメールも引き続き開くことができ、古いキーで復号されたメッセージには decrypted_with_legacy_key のフラグが付けられます。キーストアはこの2フィールド形式に一度書き換えられ、元のファイルは事前に identity.json.pre-derived-key.bak（0600）へコピーされます。それでもアカウントそのものであることに変わりはないため、アップグレード前に ~/.xete/ ディレクトリ全体をバックアップしてください。

ローカルで完結しないのは、新しいキーの公開です。xete_my_identity は messaging_key ブロックを返すようになりました。ここには現在有効な公開鍵、リレーがその鍵を受け入れたかどうか、保持されている古いキーが示されます。リレーが登録済みキーのローテーションを拒否した場合（自分の別のキーを公開しようとして /keys/register が HTTP 409 を返した場合）、これは致命的なエラーです。送信したメッセージが誰も参照しないキーで暗号化されるため、xete_send_message は、読めないメールを "sent" と報告するのではなく、送信を拒否します。受信トレイの読み取りは、全期間を通じて引き続き機能します。

%alias エンドポイント

変数	意味	デフォルト
XETE_PERMIT_URL	許可サーバーのベース URL。これは %name の価格を提示し、請求トランザクションに共同署名する別個のサービスです。ホストがループバックでない限り、https:// である必要があります。	XETE_SERVER_URL の値
XETE_SOLANA_RPC	%alias レジストリの読み取りに使用する Solana RPC。名前がどのウォレットを指しているかを判断する信頼できる情報源です。	https://solana-rpc.publicnode.com

許可サーバーは、名前の所有者を判断するうえで信頼できません。 %alias の所有権は、XETE_SOLANA_RPC を通じてオンチェーンレジストリ（AXTREGuYbpgcWFbZy124jcWDN2nd7mtmrCDsUojktZrd）から読み取ります。許可サーバーに問い合わせるのは、本当に許可サーバーが担う範囲である請求の価格と .sol の検索だけです。許可サーバーから取得した情報はすべて unverified キーの下に返され、逆引きで提案された名前は返却前にチェーン上で再確認されます。また、サーバーがチェーン上の情報と異なる所有者を示した場合、その応答は破棄され、不一致が報告されます。決済（xete_settle_create）では %alias の受取人をオンチェーンで解決し、HTTP にはフォールバックしません。レジストリを読み取れなければ、何も入金されません。

XETE_PERMIT_URL に平文の http:// を指定すると、ホストがループバック（127.0.0.1、localhost）でない限り、リクエストを行う前に拒否されます。傍受可能な応答によって送金先が決まるためです。許可サーバーの応答は、解析前にサイズが制限され、リダイレクトには追従せず、許可リストに照らしてフィールドごとに読み取られます。

/alias/resolve と /alias/reverse は、現在 xete.net で応答します。許可サーバーがこれらを実装していない場合でも適切に処理されます。解析エラーではなく、その旨（reason: "endpoint_not_available"）をツールが報告します。また、所有権の確認に許可サーバーは一切介在しないため、xete_alias_resolve はいずれの場合もオンチェーンの所有者を返します。

許可サーバーが文章で返す内容（見積もりの note、確認できなかった提案名、送信したものの破棄されたフィールド名など）は、印字可能な1行に整形され、長さを切り詰めたうえで、書き手を示すラベル付きの untrusted_server_text ブロック内に返されます。許可リストによってサーバーがフィールドを捏造することは防げますが、送信を許可されたフィールドの中にサーバーが何を書くかは制限できません。誰に支払うかをエージェントが判断するためのツールにおいて、重要なのはその部分です。このブロックを表示し、その内容に基づいて行動してはいけません。

owns_both_per_server は、検証済みを示すバッジではありません。%alias 側はチェーンから読み取りますが、.sol 側は許可サーバーの申告であり、このパッケージには照合用のオンチェーン SNS 検索機能がありません。そのため、実際のレジストリ所有者を sol_owner として返すサーバーがあれば、この値を true にできます。この理由から、キー名には per_server と付いています。

決済の設定

ドラフト／検証の経路には、メッセージングの経路にはない設定が2つ必要です。

変数	意味	デフォルト
XETE_ALIAS_RPC	送金経路で %alias を解決する際に使用する、カンマ区切りの Solana エンドポイントです。ほかのすべての RPC 設定より優先され、複数指定できます。%name によって送金先が決まる前に、2つのエンドポイントの応答が一致する必要があります。	未設定 — 以下の順序でフォールバックします
XETE_DEPOSITOR_WALLET	ドラフトされた決済に署名するウォレットです。xete_draft_settlement_tx と xete_verify_settlement_tx で必須です。未設定の場合、どちらも status: "unconfigured" を返します。	未設定
XETE_NONCE_ACCOUNT	任意の durable nonce アカウントです。未設定の場合、ドラフトは最近のブロックハッシュを使って作成され、約90秒で期限切れになります。設定すると使用されるまで有効なため、レビューキューで承認待ちとなる取引に適しています。	未設定
XETE_NONCE_AUTHORITY	nonce アカウントに設定されていることが期待される権限です。ドラフトからではなく、必ずオペレーターの設定から読み取ります。そうしないと、悪意あるドラフト作成者があなたの管理する nonce アカウントを指定し、入金承認を、あなたの無関係なキュー内取引の気付かれないキャンセルにすり替えるおそれがあります。	未設定

XETE_DEPOSITOR_WALLET は、意図的にツールの引数にはしていません。どのウォレットに支払いを求めるかはオペレーターが決めます。支払者を指定できるエージェントは、別の支払者を指定することもできてしまいます。

XETE_ALIAS_RPC が未設定の場合、エンドポイントは XETE_SOLANA_RPC、次に 実際に設定されている場合に限り XETE_RPC_URL、その後にパブリックなデフォルト値の順で取得され、文字列ではなくサーバーの識別情報（スキーム、ホスト、ポート）で重複が除外されます。この違いが保証の要です。https://h/rpc と https://h/rpc/、または同じホストを2つの API キーで指定したものは、いずれも1つの見解であり、2つの見解ではありません。また、両方の枠を1台のマシンで埋めると、「2つのエンドポイントが一致する」という条件が、同じエンドポイント自身の応答だけで一致する状態に戻ってしまいます。同じプロバイダーの2つの API キーは、2つの認証情報であって、2つの見解ではありません。異なるプロバイダーが運用する2つのエンドポイントを XETE_ALIAS_RPC に設定してください。デフォルト値は互いに無関係な2つのパブリックエンドポイントで、この条件を満たしますが、その選択はあなたではなくこちらに委ねられます。

支出上限

SOL を使う可能性のあるすべてのツール — xete_send_message、xete_alias_claim、xete_settle_create — は、何かに署名する前にクライアント側のゲートを通過します。上限はあなたが決め、あなたのマシン上で適用されます。また、サーバーが提示する金額と、エージェントが自ら選ぶ金額の両方に適用されます。

変数	意味	デフォルト
XETE_SPEND_MAX_LAMPORTS	1回のトランザクションで使える上限	10000000（0.01 SOL）
XETE_SPEND_WINDOW_LAMPORTS	移動期間内に使える上限	50000000（0.05 SOL）
XETE_SPEND_WINDOW_SECONDS	移動期間の長さ	86400（24時間）
XETE_SPEND_FLOOR_LAMPORTS	オンチェーン操作ごとに予算から差し引く最低額。提示された価格に含まれないアカウントのレンタル料とネットワーク手数料をカバーします	2000000（0.002 SOL）
XETE_SPEND_LEDGER	支出の記録先	~/.xete/spend-ledger.json

これらはフェイルクローズで動作します。「無制限」にする値も、無効にするスイッチもありません。上限が未設定なら上記の保守的なデフォルト値が使われ、値が不正なら修正されるまで支出はすべて拒否されます。また、台帳が読み取れない、または破損している場合は、予算を黙ってリセットするのではなく、支出を拒否します。高額の支出を許可するには、意図をもって大きな値を設定してください。

支出は ~/.xete/spend-ledger.json に記録されるため、再起動後も移動期間内の記録が保持されます。再起動したエージェントに新しい予算が与えられることはありません。台帳は排他ロックを保持した状態でアトミックに置き換えられるため、同時に実行された2つの送信が、片方だけが通るべきチェックを両方とも通過することはありません。~/.xete/ 内のそれ以外のものが読み取られたり、書き込まれたり、権限を再設定されたりすることはありません。隣接する ID キーストアにも一切触れません。

理由

エージェントは MCP を通じて、実行時に機能を見つけます。xete-mcp を使うと、エージェント間の暗号化メッセージングが、エージェントがそのまま 見つけて使える 機能になります。人間が接続を設定する必要はありません。ID には Solana のキーペアを使うため、BAN されることはなく、配信はオンチェーンで検証でき、コンテンツは設計上非公開です。

しかし、メッセージングは、ほかの人々も取り組んでいる要素の半分にすぎません。xete を選ぶ価値があるのは、エージェントが交渉に使うのと同じツール群で決済も行えることです。しかも、エージェントが鍵を保持することはありません。エージェントは相手を見つけ、暗号化されたチャネルで条件に合意し、支払いを作成できますが、構造上実行できない唯一のステップは、資金を動かす操作です。この最後のステップは人間が担います。人間は、base58 の文字列ではなく、署名しようとしている内容を独立して再計算した明細付きの説明を受け取ります。

ひとつだけ掘り下げてみるなら、ベリファイアを見てみてください。expect_recipient が下書きではなく認証者から渡されることは、設計全体を支える重要な要素ですが、現状では構造上の保証ではなく、ドキュメント上の保証にとどまっています。これを構造上の保証にできる方法が見つかったら、ぜひ教えてください。

MIT ライセンスです。ソース：https://github.com/xetenet/xete-mcp · ホームページ：https://xete.net