Trust Gate Mcp

Trust Gate MCP

重大なエージェントアクションに対する改ざん検知可能なレシートを、ALLOW、DENY、ESCALATEを返す判断ゲート付きのMCPサーバーとして提供します。

16個のツールがあります。共有の署名プリミティブを使用する7つのローカルツール、オープンソースのOpenAgentOntologyのmint_receipt、そしてTrust Gate APIの読み取り専用ビュー（任意）が9つです（下記の「読み取り専用APIビュー」を参照）。

実際に署名される内容は、インストールしたものによって異なります。OAOはインポート時にバックエンドを検出するため、最良のケースをうたうのではなく、この点を明確にしておく必要があります。

インストール	方式	備考
pip install trust-gate-mcp	Ed25519 + ML-DSA-65	デフォルトです。ML-DSAの方式にはdilithium-pyを使用します。これは純粋なPythonライブラリで、READMEでは暗号アプリケーションに使用すべきでないこと、定時間実装ではないことが明記されています。レシートの改ざんを検知可能にし、PQ必須モードの要件を満たしますが、この方式は強化されていないものとして扱ってください。
pip install "trust-gate-mcp[slh]"	Ed25519 + ML-DSA-65（ネイティブバックエンド）	ネイティブのliboqsライブラリを必要とするliboqs-pythonをインストールします。これにより、署名プリミティブはML-DSA-65にliboqsを優先的に使用します。ハッシュベースの方式が追加されるのは、liboqsにSPHINCS+-SHA2-128s-simple（最終的なFIPS 205規格とはバイト互換性のない標準化前のバリアント）が含まれている場合のみです。現在liboqs-pythonが対象としている唯一のリリースであるliboqs 0.16.0ではSPHINCS+が削除されているため、2026-09-29時点では、この追加インストールによってネイティブのML-DSAバックエンドは利用可能になりますが、ハッシュベースの方式は追加されません（liboqsをインストールした状態での確認は未実施です）。liboqsをインポートできない場合、プリミティブは通知なくdilithium-pyにフォールバックします。run_exit_drillはアクティブなバックエンドとハッシュベースの方式が利用可能かどうかを示します。耐量子暗号の方式が重要な場合は、このインストール方法を使用してください。

PQ必須の検証（デフォルト）では、検証済みの耐量子暗号方式が少なくとも1つ必要です。これは、同じバイト列に対する耐量子署名が存在し、有効であることを示します。誰の鍵で作成されたかは示しません（「有効なレシートが証明すること」を参照）。また、デフォルトのバックエンドが本番環境向けの品質であることを意味するものでもありません。

ツール	機能
mint_receipt_for_record_change	CRM レコードの変更に対するレシートを発行します。あらゆる CRM（オープンコアの Relaticle、各 CRM 独自の MCP を介したホステッド CRM、カスタム CRM）で動作します。変更前後の値は SHA-256 ハッシュです（ソルトなしのため、エントロピーの低い値はハッシュから推測できます）。
audit_my_agent_inventory	呼び出し元が提供した MCP ツールのリストを、ツールが実行された場合の最悪の後悔度で順位付けします（名前に基づくヒューリスティックで、名前の最初の単語を最も重く評価します。delete_file は file_delete より上位になります）。読み取り専用です。レシートは発行しません。 他のサーバーを自動検出することはできません。MCP プロトコルではそれが許可されていないためです。オブジェクトでない行はエラーになり、黙ってスキップされることはありません。
mint_action_receipt	重要なエージェントのアクションに対するレシートです。証明値（triggered_by_*、decision_model）は呼び出し元の申告で、安全な文字のみを許可し、署名されますが、検証はされません。ゲートの判定語（allow、deny、escalate、grant、permit、approve、withheld、committed）を含む判定値、単語として gate を含む操作名、ゲート独自のポリシー ID は拒否されます。このチェックはベストエフォートです。レシートをゲートの判定として受け入れるには、署名者を固定し、署名済みの issuer_tool を確認してください（下記参照）。
verify_receipt	証明書のみからレシートを検証します。オフラインで実行され、DB は不要です。署名のないレシートを拒否し、kid を確認します。また、署名者を固定するための expected_kid を受け付けます（その鍵自体の Ed25519 署名が検証された場合にのみカウントされます）。デフォルトでは PQ 必須モードです。成功を示す場合は verified ブロック（判定、証拠ハッシュ、署名時刻、issuer_tool、operation、アクションとリソースを含む検証済みの ontology マニフェスト全体）を返します。レシートを独自に解析した結果ではなく、これらの値を読み取ってください。
gate_decision	実際の判定を行う 2 段階の判定ゲートです。PREVIEW は、実行せずにリスク階層と理由を添えて ALLOW、DENY、または ESCALATE を返します。COMMIT は判定を再評価し、その判定に対する署名済みレシートを発行します。ALLOW のみが GRANTED 許可証を返します。DENY は DENIED を返し、ESCALATE は WITHHELD_PENDING_HUMAN を返して、人間が判断します。下記を参照してください。
check_egress	データサンプル内の機密マーカー（有限のキーワード一覧、SSN とカード番号の形式、および NAME=value の代入を含む一般的な認証情報形式）を検出し、NO_MARKERS_FOUND／INTERNAL／CONFIDENTIAL／RESTRICTED のいずれかを返します。認証情報形式の値と個人識別情報は RESTRICTED に分類され、blocked: true に設定されます。認証情報に関するキーワードのみの場合は CONFIDENTIAL です。無害なサンプルでも、キーやパスワードの代入のように見えるとフラグが立つことがあります。このツール自体で何かをブロックすることはできません。コード側で blocked を読み取り、それに従う必要があります。NO_MARKERS_FOUND は送信許可を意味しません。分類、保持情報、レシートを返します。
run_exit_drill	ベンダー移行準備の訓練です。ローカルの署名鍵（ポスト量子バックエンドの名前と、ハッシュベースの署名方式が利用可能かどうか）と、ローカルモデルのエンドポイントが設定されていることを確認します（Ollama。接続は行われず、リモートホストは対象になりません）。手順ごとの結果とレシートを返します。情報提供用です。レシートを 1 件署名します。署名鍵がまだないホストでは、この操作によって鍵が作成されます。

読み取り専用 API ビュー（任意、デフォルトでは無効）

9 つのツールで、ユーザーが提供したレコードを Trust Gate API がどのように処理するかを確認できます。TRUST_GATE_API_URL（https。localhost では http のみ可）、TRUST_GATE_API_KEY（1 つのテナント用に発行されたベアラー認証情報）、および TRUST_GATE_TENANT_ID を設定するまで、これらのツールは何もしません。上記の 7 つのローカルツールにはこれらの設定は不要で、外部に接続することもありません。

ツール	内容
inspect_oversight_case	1 件の監督ケースに関する準備状況レポート
propose_role_question	ケースについて、特定のロールに振り分ける質問。質問を提案するだけで、誰かに質問することはありません
get_intervention_evidence	介入が効果をもたらしたことを示せるかどうかに関する証拠
compare_qualification_change	変更後の各再テストのステータス：最新、最新ではない、または未紐付け
export_acceptance_pack	受け入れパックのエクスポート。任意で、指定した 1 つのコントロール ID とバージョンに対応付けられます
get_receipt_evidence	1 件の受領記録に関する証拠ビュー。サービスが確認できた内容と確認できなかった内容を含みます
get_decision_evidence	判断とその事実に関する証拠ビュー、判定、および未解決の質問
replay_decision	提供されたレコードに基づき、判断の証拠経路を再現します。何も実行しません
propose_requalification	影響と再適格性確認の提案。再テストを実行することはありません

各ツールは 1 つのオブジェクト request を受け取り、呼び出し本文として転送します。すべてのツールに共通するルールは次のとおりです。

• 読み取り専用です。 書き込み、署名、実行、承認は行われません。回答は渡されたレコードに基づいて作成されます。その記載内容はユーザー自身の主張であり、検証済みの事実ではありません。
• テナントは設定値で決まります。 request のトップレベルでテナントを指定することはできません。また、どの階層にある場合でもテナントキー（tenant、tenant_id、tenant-id、TenantId。大文字と小文字は問いません）の値が TRUST_GATE_TENANT_ID と一致しない場合、呼び出し前にリクエストは拒否されます。テナントとして送信されるのは TRUST_GATE_TENANT_ID のみです。
• フェイルクローズです。 設定の欠落、404（この機能が無効または未デプロイ）、レート制限、サーバーエラー、通信エラー、または形式が不適切な回答がある場合、reason を伴う status: "UNAVAILABLE" を返します。API に拒否された場合は、短い code を伴う REFUSED を返します。データが補完されたり、デフォルト値が設定されたりすることはありません。
• 認証情報がログに記録されたり、返されたりすることはありません。例外テキストも渡されません。
• マッピングや読み取り結果は、コンプライアンスに関する判定ではありません。 すべての結果にその旨が示されます。
• バージョンの一致が必要です。 受領記録、判断、再現、提案、再適格性確認の各ビュー（get_receipt_evidence、get_decision_evidence、replay_decision、propose_requalification、compare_qualification_change）と、ケース、質問、証拠、パックの各ビューを利用するには、それらに対応した Trust Gate API バージョンが必要です。古いサーバー、または機能が無効になっているサーバーでは、対応するまで UNAVAILABLE（surface_not_available）を返します。
• リクエストは 64 KiB までに制限されます。回答の読み取りは最大 1 MiB（エラー本文は最大 4 KiB）で、それ以上は読み取りません。タイムアウトは 10 秒で、リダイレクトは行わず、プロキシ環境変数は無視します。

ゲートが行うことと行わないこと

• 適用範囲。 対象となるのは、コードが gate_decision を経由させるアクションのみです。エージェントが実行することを監視、傍受、またはブロックすることはなく、アクションが実際に行われたかどうかを後から確認することもありません。コード（フックやラッパー）から事前に問い合わせ、その回答に従う必要があります。
• ALLOW の対象は限定されています。 アクションが ALLOW になるのは、その名前が既知の読み取り動詞（read、get、list、search、query、find、show、view、inspect、describe）に続き、組み込みの小さな名詞語彙に含まれる語だけで構成される場合（例：read_file、list_files、search_files、list_dir、get_user、describe_table）、名前が単純な識別子であり、リソースがその語彙に含まれる語、一般的なドキュメント関連語（readme、guide、changelog など）、ソースコードまたは文章のファイル形式（md、txt、py など）のみで構成され、語の間に数字を含めることもできる場合（docs/2024/notes.md）に限られます。それ以外の語を含む名前は、ゲートが認識していないため、人による判断に回されます。意図的に範囲を狭くしているため、実際のファイル名の多くは人による判断に回されます。 範囲を広げるには、ソース内の語彙に語を追加する必要があり、その変更は明示されます。
• 構造上のルールに該当する場合も、人による判断に回されます。 隠しパス（.env、.ssh、.git、..）、絶対パス、URL、パスの先頭部分がホスト名であるもの（example.com/x、localhost）、一般的な表記のいずれかによるネットワークアドレス（幅を問わないドット区切りの4つの数字、16進数、0177.1 のような8進数、1つの長い整数、0。1.2.3 のような短いドット区切りの数字は、最後の数字がバージョン番号として大きすぎる場合、または先頭が 0 や 127 の場合を除き、バージョン番号として扱われます）、- で始まるリソース、3語以上からなる句、文字、数字、スペース、_ . - / 以外の文字を含むもの（Unicode 互換文字への折りたたみ後）、さらに実際の種類が設定、データ、鍵、状態、またはアーカイブであるファイル（.1 のようなローテーション番号は種類の判定時に無視されます。users.csv.txt のように、ドット区切りの名前の前のほうにリスト掲載済みのデータ形式やアーカイブ形式が含まれている場合も該当します）。コマンドを含むリソースも人による判断に回されます。該当するのは、リスト掲載済みの変更動詞（alter、merge、flush、load など）、語に結合した重要動詞（deleteall など）、または query 動詞の後に続く複数語のリソースです。
• DENY の対象は、重要な意味を持つ先頭動詞です（支払い、削除、デプロイ、コード実行、権限変更）。名前の別の箇所またはリソースにリスクのある語が含まれる場合は、人による判断に回されます。高リスクの先頭動詞（format、remove、reset、release、escalate）や、リスクのある語を含むファイル名（test_delete_user.py）も同様です。
• リスクのある語や機微な語はリストに記載されており、そのリストは有限です。 リスト掲載済みの秘密情報や規制対象データに関する語（password、token、key、pass、config、ssn、diagnosis など。語への結合形、複数形、数字置換形を含む）には、HIGH ティアで具体的な理由が示されます。名前が ALLOW の対象にならないのは、これらのリストによるものではありません（機微な名前がリストにない場合でも、ALLOW の対象が限定されているため、人による判断に回されます）。history は読み取り名詞ではありません。照合は語の境界をまたいで行われるため、無害な名前でも機微な理由が示されることがあります（api/index.md には「pii」が含まれます）。list_users のような検索は、ほかの読み取りと同様です。ゲートは、返される個人データの量を判断しません。名前にリスクのある動詞と同じ語を含む一般的な読み取りツール（get_email、list_messages）は、人による判断に回されます。
• これは名前に基づくヒューリスティックであり、安全性の証明ではありません。 ALLOW であっても、アクションが安全だとは限りません。危険なツールを read_file という名前で呼び出すエージェントは、ゲートが動作ではなく名前を確認するため、検出されません。context はレシートにハッシュとして記録されますが、判断には使用されません。このパッケージには、オペレーターによる上書き機能はありません。
• レシートから判定結果を読み取り、発行者を確認してください。 receipt.decision（および receipt.evidence.ontology.verdict）には署名があります。レスポンスのトップレベルにある verdict フィールドと permit フィールドには署名がありません。verify_receipt は、検証対象のレシートに含まれる署名のないキーを列挙します。レシートが自分のサーバーからのゲート判定であると認められるのは、自分のサーバーの kid を expected_kid に設定した verify_receipt が signer_pinned: true を返し、かつ verified.issuer_tool が gate_decision、verified.operation が decision_gate_commit である場合のみです。それ以外のツールはそれぞれ自身の issuer_tool に署名します。また、ピン留めを行わない場合、これらのフィールドは署名者による申告にすぎません。
• このサーバーが受け入れるレシートがなければ、許可は発行されません。 COMMIT が GRANTED を発行するのは、レシートが生成されて署名され、このサーバー独自のポリシーに基づく検証に成功した場合のみです（PQ 必須モードでは、有効な耐量子署名も必要です）。
• アクションとリソースは、署名済みレシートに平文で記録されます。 ここに秘密情報や個人データを含めないでください。
• レシートは判定の証拠であり、ログエントリーではありません。 atom_id は内容（証拠ハッシュの40ビット）から導出されるため、同一の判定は同じ ID を共有し、異なる判定が同じ ID になることもあります。evidence_hash と signed_at をキーにしてください。サーバーは署名したレシートのログを保持しません。必要なレシートは保存してください。再生チェックや鮮度チェックはありません。実行しようとしている内容と evidence.ontology.action および resource を比較してください。
• 0.2.1 は、すべてのアクションに対して GRANTED を返していました。 0.3.0 以降にアップグレードしてください。変更履歴を参照してください。

有効なレシートが証明すること

verify_receipt が ok: true を返す場合、証拠は署名されてから変更されておらず、レシートには署名が含まれ、レシートに kid が含まれている場合はその値がレシート内の鍵と一致し（デフォルトの PQ 必須モードでは）、同じバイト列に対する少なくとも 1 つの耐量子署名が検証されています。

これは、レシートが信頼できるサーバーから届いたことを意味するものではありません。誰でも鍵を生成してレシートに署名できます。誰が署名したかを確認するには、expected_kid（信頼する Ed25519 鍵の kid。別経路で入手してください。32 桁の 16 進文字列で、大文字・小文字と前後の空白は無視されます。空または形式が不正なピンは拒否されます）を渡します。ピンが有効とみなされるのは、その鍵自体の Ed25519 署名が検証された場合に限られ、signer_pinned: true はその検証が成功したことを示します（署名の検証に成功したことから分かるのは、その鍵がそのバイト列に署名したということであり、誰かがその秘密鍵を保有しているということではありません。Ed25519 では、任意のメッセージに対して検証に成功する特殊な公開鍵がいくつか認められていますが、信頼する鍵へのピンには影響しません）。signer_pinned: false の ok: true は完全性のみを示し、kid が報告されるのは Ed25519 署名が検証された場合に限られます。Ed25519 の署名者（鍵または kid）を示すレシートで、その署名者による有効な署名がないものは拒否されます。これら 2 つの値は公開情報であり、別の鍵で署名されたレシートにコピーできるためです。

stdio では、署名鍵はユーザーのホームディレクトリに暗号化されずに保存されるため、そのユーザーとして実行されるエージェントは鍵を読み取れます。したがって、ピンはゲートの対象となるエージェントに対する保護にはなりません。kid がフィンガープリントするのは Ed25519 鍵だけです。レシート内の ML-DSA 鍵とハッシュベースの鍵はこれによって保護されないため、ピンによる検証が量子攻撃者に対して持つ強度は Ed25519 の強度までです。また、結果は検証ホストにインストールされている耐量子バックエンドに依存する場合があります（検証できない署名の種類は unverifiable と報告されます）。

強化

• H1 鍵の永続化と、FAIL-CLOSED な kid 不一致チェックを備えたブートストラップ（コンテナへのデプロイ。ブートストラップがチェックするのは Ed25519 鍵のみです）
• H2 IP ごとのトークンバケット方式のレート制限（FIFO 方式のエビクション）。MCP トランスポートと同じ方法で、リクエスト本文を生のバイト列から正確に解析し（バイトオーダーマーク、UTF-16、UTF-32 も読み取ります）、指定されたツールに対して課金します。署名ツールは同じ署名用予算を共有します。解析できない本文、または 64 KiB を超える本文は署名用予算に課金されます。本文が 1 MiB を超えた時点でリクエストは 413 で拒否されます（バッファリングされるのは最大 1 MiB です）。署名処理（デフォルトのバックエンドでは呼び出しあたり約 70 ms）と検証処理（約 20 ms）はイベントループ上で実行され、予算はクライアントごとに設定されるため、これらの処理全体に対する上限はありません。クライアントは uvicorn が解決した接続アドレスで識別されます。プロキシのアドレスを TRUST_GATE_FORWARDED_ALLOW_IPS に設定してください。そうしないと、どのクライアントも X-Forwarded-For ヘッダーで自分の識別情報を指定できます。
• H3 PQ 必須の検証：検証済みの耐量子署名を含まないレシート（および署名のないすべてのレシート）を拒否します
• H4 発行されるすべてのレシートに 128 ビットの kid を付与し、正規化された鍵バイト列から再計算して検証時にチェックします
• TRUST_GATE_BEARER_TOKEN と TRUST_GATE_ALLOWED_ORIGINS による、オプションのベアラー認証と、許可リストを絞り込んだ CORS
• テストスイートでは、列挙されたすべての動詞、名詞、機微な単語をそれぞれ個別に固定し（リストの独立したコピーを使用）、活用形、複数形、連結形、数字を入れ替えた形、互換文字の形もテストします。また、レシートの偽造や PQ の除去に対する敵対的なケースもテストします。実際の MCP リクエストは HTTP スタック全体を通して送信されます

HTTP でのデプロイ

HTTP エントリーポイント（server_http.py）は、モジュールが同じ階層に置かれるコンテナーイメージ向けに記述されています。pip install を使用する場合は、stdio サーバーを使用してください。Bearer 認証はデフォルトで無効で、このモードでは CORS は * です。公開されているデプロイにアクセスできる人は誰でも、そのデプロイの鍵で署名されたレシートを取得できます。読み取り専用の名前に対する「ALLOW」レシートも含まれます。また、公開デプロイからのレシートは、誰が要求したかについて何も示しません。ホストする場合は、TRUST_GATE_BEARER_TOKEN と TRUST_GATE_ALLOWED_ORIGINS を設定してください。

HTTP エントリーポイントは、?via=<label> へのアクセスを、1 行のログ（ラベル、種類、ユーザーエージェントのファミリー）として記録します。記録されるのは、組み込みの 3 つのラベルと、TRUST_GATE_CHANNELS（カンマ区切り）で指定されたラベルのみです。ホスト自身のアクセスログにも、クライアントアドレスを含むリクエスト行が記録されます。

DNS リバインディング対策は無効で、これを有効にする設定はありません。Bearer 認証なしでローカル HTTP サーバーを実行している場合、訪問した Web ページはどれもサーバーを呼び出せます。Host ヘッダーを確認するプロキシの背後に配置するか、TRUST_GATE_BEARER_TOKEN を設定してください。

インストール（stdio）

pip install trust-gate-mcp
trust-gate-mcp

ネイティブの ML-DSA バックエンドを使用するには、[slh] を追加してください（上の表を参照）。チェックアウトからは、pip install -e ".[dev]" を実行してから、 python -m trust_gate_mcp を実行してください。

コンテナーへのデプロイ（Smithery／任意のコンテナーホスト）

docker build -t trust-gate-mcp .
docker run -p 8081:8081 -v trust-gate-data:/data/oao trust-gate-mcp

/data/oao へのボリュームマウントは本番環境で必須です。これがないと、コンテナーが再起動するたびに署名鍵が変わります。再起動前に署名されたレシートは、それぞれの証明書を使って引き続き検証できますが、固定された kid は新しいレシートと一致しなくなります。永続化される key_metadata.json には署名者の kid が保存されます。ブートストラップ手順では、これに不一致がある場合、起動を拒否します。イメージにはデフォルトで dilithium-py がインストールされます。上の表を参照してください。

ライセンス

Apache-2.0（全文は LICENSE にあります）。Copyright 2026 Cyber Warrior Network。オープンソースの OpenAgentOntology プリミティブを基盤としています。