MCP Registryからサーバーを選ぶ前に：OAuth・tool poisoning・allowlistの安全な見方

3行まとめ

Registryは発見の入口

掲載されていることは、社内利用の安全審査を通ったことを意味しません。

見るべき中心は権限

OAuthの有無だけでなく、scope、toolの副作用、第三者入力、更新差分を確認します。

allowlistで運用する

用途、権限、version、責任者、停止手順まで含めて接続可否を管理します。

MCP Registryは候補を見つける場所、社内allowlistは接続を許可する場所として分けて考えます。

MCP RegistryはMCPサーバーを見つけるための入口であり、掲載されていること自体を安全審査済みの印として扱うべきではありません。

実務で見るべき中心は、OAuthの有無ではなく、要求scope、ツールの副作用、第三者入力の扱い、更新差分、社内allowlistで管理できるかです。

2026-06-08時点で公式Registry、Registryドキュメント、MCP Authorization、Security Best Practices、NSAのMCP security資料を確認し、Xの投稿内容は本文の事実根拠に使っていません。

この記事でわかること

Registry情報の限界

server名、description、repository、packageは手がかりですが、安全性の保証ではありません。

OAuth認可の読み方

scope、token audience、consent、保存場所、revoke手順まで確認します。

tool poisoning

tool名、description、schema、返却内容がモデルの判断へ与える影響を見ます。

allowlistと更新レビュー

server単位ではなく、用途、tool、権限、version、ownerで管理します。

特定サーバーのランキングではなく、導入前レビューで何を見るかを整理するための観点です。

この記事では、MCP Registryで見つけたサーバーを「入れてよさそう」に見える段階から、実際に開発環境やチーム環境へ接続してよいか判断する段階までを扱います。MCPそのものの基本は、先に MCPとは何か: Tools・Resources・Promptsと権限設計を開発者向けに整理する を読んでおくとつながりやすいです。

判断する4つの論点

1つ目は、Registryに載っている情報で何がわかり、何がわからないかです。server名、description、repository、package、remote endpointなどは手がかりになりますが、実装の安全性や社内データとの相性までは保証しません。

2つ目は、OAuth認可の読み方です。MCP AuthorizationではHTTPベースの制限付きMCPサーバーに対する認可フローが定義されていますが、OAuthを使っていることと、scopeが最小であること、tokenが正しいaudienceで扱われること、操作ごとに承認できることは別問題です。

3つ目は、tool poisoningとoutput poisoningです。MCPのToolsはモデルが選んで呼び出す前提を持つため、ツール名、説明、schema、返却内容がモデルの判断材料になります。人間が読んで自然でも、モデルへの隠れた誘導や過剰な権限につながる説明はレビュー対象です。

4つ目は、allowlistと更新レビューです。組織で使うなら「このサーバー名はOK」では足りません。publisher、repository、package、version、transport、required scopes、allowed tools、data classification、review owner、expiry、rollback planまで管理する必要があります。

この記事で扱わないこと

特定のMCPサーバーをランキング化したり、「このサーバーなら安全」と断定したりはしません。Registry上の掲載数や人気度も評価軸にはしません。掲載数は変わり続け、セキュリティ判断に直結しないためです。

また、攻撃手順の再現は扱いません。tool poisoning、SSRF、token passthrough、confused deputyは、開発チームが導入前レビューで何を避けるべきかを説明するために扱います。

前提知識: MCP Registryはサーバー発見のための公開カタログ

項目	内容	見方
Registryで見える情報		識別子、説明文、repository、package、version、transport、remote endpoint、statusなど。
Registryだけでは足りない情報		実装の安全性、最小scope、toolの副作用、社内データとの相性、更新後の権限差分。
moderation policyの意味		違法コンテンツやmalwareなどの削除方針であり、企業利用の審査ではありません。
社内での位置づけ		候補発見はRegistry、接続許可は社内allowlistで扱います。

descriptionにread-onlyと書かれていても、実装、scope、更新運用は別途確認が必要です。

MCP Registryは、公開されているMCPサーバーの発見性を高めるための公式プロジェクトです。公式ブログでは、Registryを公開MCPサーバーのカタログおよびAPIとして位置づけ、クライアントやサブレジストリがそこからデータを取り込めるようにする構想が説明されています。

2026-06-08に確認した範囲では、Registryはプレビュー段階として案内されており、公式Registryサイトと v0.1 REST APIが利用できます。実際に https://registry.modelcontextprotocol.io/v0.1/servers?limit=1 へJSON取得を行い、servers と metadata を含む応答、cursor pagination用のmetadataが返ることを確認しました。この確認はAPIの到達性と応答形状の確認であり、掲載サーバーの安全性検証ではありません。

Registryが持つ情報

根拠

Registryで見える主な情報は、サーバーの識別子、説明文、repository、package、version、transport、remote endpoint、statusなどです。Registry quickstartでは、MCP Registryは配布物そのものではなくメタデータを扱う前提で、npmなどのpackage側に所有確認情報を置き、server.json を公開する流れが示されています。

注意点

この性質は便利です。MCPクライアント、社内カタログ、サブレジストリ、セキュリティスキャナが同じメタデータを起点にできます。開発者も、GitHubやnpmをひとつずつ探すより、MCP向けの配布情報へ到達しやすくなります。

ただし、便利さと安全保証は違います。descriptionに「read-only」と書かれていても、実装が本当に読み取り専用か、外部APIへのscopeが最小か、更新後も同じ権限かまでは別途確認が必要です。

Moderation policyの読み方

確認項目

Registryのmoderation policyは、違法コンテンツ、malware、spam、壊れたサーバーなどを削除対象にする一方で、かなり寛容な運用であることを明記しています。つまり、Registry掲載は「少なくとも公式発見面に登録されている」という意味であって、「企業利用に耐える審査を通った」という意味ではありません。

評価基準

この線引きは重要です。社内のAIコーディング環境にMCPサーバーを追加すると、そのサーバーが読めるファイル、呼べるAPI、見られるチケット、触れるクラウド権限が、AIエージェントの行動範囲になります。Registryは候補を見つける場所、社内allowlistは接続を許可する場所、と分けて考えるのが安全です。

結果: Registry掲載だけでは接続判断に足りない

1. 11. Registryで候補を見つける

   目的に合うserver、repository、package、transportを確認します。

2. 22. 実装と配布元を確認する

   source、release履歴、package名、publisher、metadataの対応を見ます。

3. 33. toolとcredentialを確認する

   tool list、description、input schema、副作用、OAuth scope、token管理を見ます。

4. 44. 社内allowlistへ登録する

   owner、期限、更新通知、ログ、削除手順、rollback planを記録します。

個人検証でも限定tokenとテストデータから始め、チーム利用では運用条件まで決めてから接続します。

結論から言うと、MCP Registryで見つけたサーバーは、次の順で見ます。

見る順番	確認すること	判断の意味
Registry情報	server名、publisher、repository、package、version、transport、status	候補として追跡できるか
配布元	ソースコード、release、package、署名、Issue、更新履歴	供給元をレビューできるか
権限	OAuth scope、API token、ファイル/ネットワーク/DBアクセス	最小権限にできるか
Tools	tool名、description、input schema、副作用、外部送信	モデルに任せてもよい粒度か
出力	第三者入力、prompt injection、出力の後段利用	次のtool callを汚染しないか
運用	allowlist、owner、更新レビュー、緊急停止、ログ	チームで管理できるか

「見つける」と「許可する」を分ける

確認項目

Registryは発見のために使います。社内利用では、Registryで見つけた候補をそのままMCPクライアントへ登録するのではなく、レビュー済みリストへ移してから使います。

たとえば、GitHubのIssueやrepositoryを読むMCPサーバーを探しているなら、Registryで候補を見つけることはできます。しかし接続可否は、GitHub tokenのscope、対象repository、読み取り専用か、書き込みtoolが含まれるか、PRコメントやIssue作成が人間承認を必要とするかで決めます。読み取り専用MCPサーバーから始める考え方は、TypeScriptでGitHub read-only MCPサーバーを作る：Fine-grained PATとtool allowlistの最小構成 でも扱っています。

注意点

個人検証なら、テスト用データと限定tokenで短時間だけ試す選択もあります。チーム利用なら、owner、期限、更新通知、ログ保存、削除手順まで決めてから使うべきです。本番に近いデータへ接続するなら、セキュリティレビューなしに追加するのは避けます。

公式Registryに載っていても確認する項目

配布元

まずrepositoryを確認します。実装が公開されているか、READMEが過度に抽象的でないか、package名とrepositoryが対応しているか、release履歴があるかを見ます。Registry metadataだけでなく、実際の配布物を確認します。

ツールと運用

次に、serverが提供するtoolsを確認します。search や list のように見えるtoolでも、内部で外部APIへ送信したり、複数repositoryを横断したり、ファイルを書き換えたりする可能性があります。tool名より、description、input schema、実装、必要credentialの組み合わせで見ます。

最後に、運用できるかを確認します。サーバーが更新されたときに誰が差分を見るのか。toolが追加されたら再承認するのか。publisherが変わったら止めるのか。Registryのstatusが変わったときに社内リストへ反映するのか。ここまで答えられないなら、チーム導入はまだ早いです。

OAuth認可を見るときは「誰が何へ接続するか」まで分解する

1. 1resource server

   tokenがどのMCPサーバーに対して発行されているかを確認します。

2. 2authorization server

   認可を誰が運用し、metadataやredirect先をどう検証するかを見ます。

3. 3scope

   read、write、admin、allなどの幅と、対象データの範囲を分けて見ます。

4. 4downstream API

   MCPサーバーからGitHub、Google、Slack、社内APIへ渡る認可境界を分けます。

5. 5token handling

   audience、issuer、保存場所、rotation、revoke、ログ混入の有無を確認します。

confused deputy、token passthrough、SSRFは、OAuth対応サーバーでも選定前に確認する項目です。

MCP Authorizationの2025-11-25仕様では、HTTPベースのtransportで制限付きMCPサーバーへアクセスするための認可が定義されています。保護されたMCPサーバーはOAuth 2.1のresource serverとして振る舞い、MCP clientはresource ownerの代わりにリクエストするclientとして扱われます。MCPサーバーはOAuth 2.0 Protected Resource Metadataを実装し、authorization serverの場所を示す必要があります。

ここだけ読むと、「OAuth対応のMCPサーバーなら安心」と受け取りたくなります。でも実務では、OAuth対応は入口です。肝心なのは、どのresource serverに対するtokenか、authorization serverは誰が運用しているか、scopeはどこまで広いか、tokenをMCPサーバーがどう検証するかです。

OAuth 2.1対応は入口であり、scope確認が本体

確認項目

MCPサーバーがOAuthに対応している場合、最初に見るのはscopeです。read と書かれていても、対象が全repositoryなのか、特定projectなのか、個人の全ファイルなのかでリスクはまったく違います。admin、write、delete、execute、all のような広いscopeを最初から要求するサーバーは、個人検証でも分離環境で扱うべきです。

運用条件

次に、tokenが誰のために発行されるかを見ます。個人ユーザーごとのtokenなのか、チーム共有のservice accountなのか。refresh tokenを保存するのか。保存するなら、どこに、どの暗号化で、誰がアクセスできるのか。ログにtokenや認可コードが出ないか。ここはMCPの仕様だけでなく、実装と運用の問題です。

さらに、MCPサーバーが外部APIのproxyになる場合は、MCP clientからMCP serverへの認可と、MCP serverから第三者APIへの認可を分けます。GitHub、Google、Slack、社内APIなどへ接続するサーバーでは、ユーザーが何に同意したのかが曖昧になりやすいです。

confused deputy、token passthrough、SSRFを選定前に見る

根拠

MCP Security Best Practicesでは、confused deputy、token passthrough、SSRF、session hijacking、local server compromise、scope minimizationなどが扱われています。MCPサーバーを選ぶ側も、この観点をレビュー表に入れるべきです。

注意点

token passthroughは、MCPサーバーが自分宛てに発行されたtokenではないものを受け取り、そのまま下流APIへ渡すような設計です。これは監査、audience分離、rate limit、権限境界を壊しやすくなります。選定時には、MCPサーバーがtokenのaudienceやissuerを検証しているか、下流APIへ渡すtokenが適切に分離されているかを見ます。

SSRFは、OAuth metadata discoveryやauthorization server discoveryの過程で、MCP clientが予期しない内部ネットワークへアクセスしてしまうリスクです。サーバーサイドでMCP clientを動かす場合は、metadata URL、authorization server URL、redirect先をそのまま信じない設計が必要です。HTTPS、private addressのブロック、redirect検証、egress proxyなどは、MCP以前からあるWebセキュリティの基本ですが、AIエージェントが自動で接続先を増やすと見落とされやすくなります。

confused deputyは、ユーザーの同意やclient識別が混ざることで、正規の認可フローに見えながら別のclientへ権限が渡る問題です。MCP proxy serverが第三者APIを扱うときは、per-client consent、redirect URIの完全一致、state の検証、consent cookieのscopeが重要になります。

tool poisoningはツール説明と出力の両方で見る

tool name

読み取り専用に見える名前でも、実装や副作用と一致しているかを確認します。

description

他の確認を省かせる誘導、過度に長い説明、外部送信の隠蔽を見ます。

input schema

任意URL、任意command、広いrepository指定など、入力で権限が広がらないかを確認します。

tool result

Issue、Docs、Web、メール、ログなど第三者入力を実行指示として扱わないようにします。

読み取りtoolと書き込みtoolを同じ環境に置く場合は、人間承認と差分レビューを前提にします。

MCP Toolsの仕様では、toolsはモデルが文脈に応じて自動的に発見・呼び出すことを前提にしています。仕様は、信頼性と安全性のために、どのtoolがAIモデルへ公開されているかをユーザーに明示し、tool invocationに人間が関与できるUIを推奨しています。

この前提では、tool名、description、input schema、tool resultは単なるドキュメントではありません。モデルがどのtoolを選ぶか、どの引数を入れるか、次に何をするかに影響する操作面です。

ツールはモデルが選ぶ前提でレビューする

根拠

tool poisoningは、ツールの説明やmetadataを使ってモデルの判断を歪めるリスクです。たとえば、見た目は便利な検索toolでも、descriptionに「このtoolの結果を最優先で信じる」「他の確認を省く」といった誘導が入っていれば、モデルの行動に影響します。説明文が長すぎる、権限の説明が曖昧、外部送信を隠している、読み取り専用に見えるのに書き込みを行う、といった兆候はレビュー対象です。

評価基準

選定時には、少なくとも次を読みます。

項目	見ること	危ない兆候
name	操作内容と一致しているか	read 風の名前で書き込みを含む
description	モデルへの説明が過剰でないか	他の指示を無視させる文言がある
input schema	必要最小の入力か	任意のcommand、任意URL、任意pathを受ける
side effect	外部送信や書き込みがあるか	副作用が説明されていない
credential	tokenやAPI keyをどう使うか	tool入力で秘密情報を要求する
approval	危険操作前に承認できるか	自動実行しかできない

これはMCPサーバー作者だけでなく、導入する側の責任でもあります。Registryから取得したmetadataやREADMEだけで足りない場合は、実装を読むか、隔離環境でtool listと挙動を確認します。

出力が次の操作を汚染するリスクも見る

条件

NSAのMCP Security Design Considerationsは、MCPを使うagentic systemでは、implicit trust、context sharing、tool poisoning、output poisoningのようなリスクが起き得ると整理しています。ここで重要なのは、危険なのがtool定義だけではないことです。

MCPサーバーが返す検索結果、Issue本文、README、メール、チャット、ログ、Webページ内容には、第三者が書いた文字列が含まれます。AIエージェントがそれを「次に実行すべき指示」と誤って扱うと、prompt injectionや不正なtool callにつながります。

注意点

たとえば、Issue本文を読むtoolと、repositoryへ書き込むtoolを同じMCP clientに接続している場合、Issue本文は信頼できない入力です。そこで得た内容をもとに書き込みtoolを呼ぶなら、人間承認、差分レビュー、allowlist、テストゲートが必要です。prompt injection対策の全体像は AIコーディングエージェントのprompt injection対策：Issue・Docs・MCPを読ませる前に決めること でも整理しています。

allowlistはサーバー名ではなく用途と権限で作る

項目	内容	見方
用途		何の業務で、どのデータへ、どの操作だけを許すかを明記します。
権限		required scopes、allowed tools、read/write/delete/executeの有無を分けます。
配布元		publisher、repository、package、version、transport、remote endpointを固定して確認します。
運用		review owner、expiry、更新通知、rollback plan、緊急停止のdenylistを持ちます。
データ分類		社内のdata classificationに合わないサーバーやtoolを除外します。

同じserverでも、テストデータだけを読む場合と本番repositoryへ接続する場合では許可条件が変わります。

MCPサーバーのallowlistを作るとき、server name だけを並べるとすぐに形骸化します。同じサーバーでも、個人検証でテストデータだけを読む場合と、本番repositoryや社内チケットへ接続する場合では、リスクが違います。

allowlistは「便利なMCPサーバー一覧」ではなく、許可された用途、権限、データ分類、バージョン、責任者を記録する運用台帳として作ります。

最低限入れる項目

確認項目

チームで使うallowlistには、少なくとも次を入れます。

項目	例	理由
server ID	Registry上のname	候補を追跡するため
publisher	GitHub org、npm scope、vendor	発行元を確認するため
repository	ソースコードURL	実装とIssueを確認するため
package	npm/PyPI/OCIなど	配布物を追跡するため
version	固定版または許可範囲	自動更新で権限が変わる事故を防ぐため
transport	stdio、HTTP、remote	実行場所とネットワーク境界を判断するため
required scopes	OAuth/API token scope	最小権限か見るため
allowed tools	許可するtool名	tool単位で制御するため
data classification	public/internal/confidentialなど	接続してよいデータを分けるため
allowed users	個人、team、CIなど	利用者を限定するため
review owner	security、platform、repo ownerなど	更新時の責任者を決めるため
expiry	再レビュー日	入れっぱなしを避けるため
rollback plan	disable手順、token revoke手順	事故時に止めるため

運用方法

この表は、MCP clientの設定ファイルそのものではなく、レビュー記録として管理します。設定ファイルに近い形で残すなら、機械可読なYAMLやJSONにして、PRレビュー対象にすると運用しやすくなります。

サブレジストリと社内レジストリの使い分け

条件

MCP Registryのaggregator向けドキュメントでは、RegistryのREST APIを使ってデータを取り込み、独自のサブレジストリを作る構成が示されています。公開Registryを上流データとして取り込めるのは便利ですが、公開Registryのコピーをそのまま社内承認面にしてはいけません。

確認項目

社内向けサブレジストリを作るなら、上流から取り込んだあとに次の加工が必要です。

• 承認済みserverだけを出す
• versionを固定する
• deleted や deprecated のstatusを反映する
• 社内のdata classificationに合わないserverを除外する
• tool単位で許可範囲を付ける
• security scanやmanual reviewの結果を _meta や別DBで管理する
• 緊急停止できるdenylistを持つ

個人検証では公開Registryを直接見るだけでも十分な場面があります。チーム導入では、公開Registry、社内allowlist、MCP client設定、秘密情報管理、ログの境界を分けます。

失敗点: MCPサーバー選定で起きやすい事故

Registry掲載を審査済みと見る

候補選定の条件にはなっても、社内承認の条件にはなりません。

OAuthがあれば安全と見る

広すぎるscope、共有account、token passthrough、audience検証なしでは事故が起きます。

tool listを見ずに接続する

目的外のwrite、delete、command execution toolがモデルの選択肢に入ることがあります。

更新差分を見ない

新しいversionでtool、scope、transport、publisherが変わる可能性があります。

対応策は、ソースコード、配布元、権限、tool定義、実行環境、ログ、更新運用を分けて確認することです。

失敗の多くは、MCPが危険だからではなく、AIエージェントに渡す権限の境界を人間が先に決めていないことから起きます。特に、MCPサーバーは「便利な外部ツール」に見えますが、実際にはモデルに外部システムへの操作面を渡します。

Registry掲載を安全審査済みと誤解する

注意点

一番起きやすいのは、公式Registryにあるから安全と考えることです。公式Registryは発見性を高める場所であり、社内利用可否の審査を代行する場所ではありません。moderation policyも最小限の削除方針であり、企業のvendor risk assessmentやcode auditとは違います。

対応策

対応策は単純です。Registry掲載は候補選定の条件にし、承認条件にはしない。承認条件は、ソースコード、配布元、権限、tool定義、実行環境、ログ、更新運用に分けます。

OAuthがあるから安全と考える

注意点

OAuthは重要ですが、万能ではありません。広すぎるscope、共有account、token passthrough、audience検証なし、redirect URI検証不足、consent cookieの混同があれば、OAuth対応でも事故は起きます。

対応策

対応策は、OAuthの有無ではなく、最小scope、per-user consent、token audience、保存場所、rotation、revoke手順を見ることです。特に外部APIをproxyするMCPサーバーでは、MCPサーバーへの認可と外部APIへの認可を分けてレビューします。

tool listを見ずに接続する

注意点

MCPサーバーは、複数のtoolをまとめて提供します。目的は1つのread toolだけでも、同じサーバーにwrite tool、delete tool、command execution toolが含まれていることがあります。MCP client側でtool単位のallow/denyができないなら、サーバー単位で接続するだけで不要なtoolがモデルの選択肢に入ります。

対応策

対応策は、接続前にtool list、description、input schema、副作用を確認し、必要なtoolだけをallowlistに入れることです。MCP clientやhostがtool単位制御に対応していない場合は、server側でread-only版を分けるか、別の接続方法を選びます。

更新差分を見ない

注意点

MCPサーバーは更新されます。新しいversionでtoolが追加される、scopeが増える、transportが変わる、remote endpointが追加される、publisherが変わる可能性があります。自動更新を許すと、承認時とは違う権限が知らないうちに入ることがあります。

対応策

対応策は、version固定、更新通知、差分レビュー、期限付き承認です。新しいtool追加、scope変更、外部通信先変更、package変更、repository移転は再承認にします。

実務で使うなら

1. 個人検証

   テストデータと限定tokenで、metadata、repository、package、version、tool listを確認します。

2. チーム検証

   allowlist、owner、監査ログ、更新通知、緊急停止、データ分類ごとの許可範囲を追加します。

3. 本番業務利用

   private repository、社内チケット、本番DB、クラウド権限への接続はセキュリティレビューを必須にします。

個人環境で便利だった設定を、そのままチームへ配布しないことが重要です。

実務導入では、利用段階ごとに許容する権限を変えます。個人検証、チーム検証、本番業務利用を同じルールで扱うと、厳しすぎて使われないか、緩すぎて事故になります。

個人検証で最低限見る項目

条件

個人検証では、まずテストデータだけを使います。private repository、顧客データ、社内チケット、本番DB、クラウド権限を接続しない状態で、tool listと挙動を見ます。

確認項目

この段階で見る項目は次です。

• Registry metadataとrepositoryが対応している
• packageが意図したpublisherから出ている
• versionを固定できる
• tool listを確認できる
• 書き込みや削除toolを使わずに試せる
• OAuth scopeを最小にできる
• tokenを検証後すぐrevokeできる
• 失敗しても実データへ影響しない

注意点

個人検証で便利だったからといって、同じ設定をチームへ配布しないことも重要です。個人環境で許した権限が、そのまま他のメンバーのrepositoryや社内データへ広がると、レビュー不能になります。

チーム導入で追加する項目

追加条件

チーム導入では、allowlist登録、owner設定、監査ログ、更新通知、緊急停止、データ分類ごとの許可範囲を追加します。

セキュリティレビュー対象

特に、次のどれかに当てはまる場合は、セキュリティレビューを必須にします。

• private repositoryを読む
• Issue、PR、Slack、メールなど第三者入力を読む
• repository、ticket、DB、cloudへ書き込む
• CI/CDやdeploymentに触る
• OAuth refresh tokenを保存する
• 任意URL、任意path、任意commandを受ける
• remote MCP serverへ社内ネットワークから接続する
• tool resultを別のtool callへ自動で渡す

補足

AIエージェント導入全体の権限設計は、MCPだけで閉じません。APIキー、非公開リポジトリ、人間承認フローを含めた整理は 法人導入前のAIコーディング権限設計: APIキー、非公開リポジトリ、人間承認フロー につながります。

導入レビューを3段階にする

接続前

接続前レビューでは、利用目的、対象データ、必要tool、OAuth scope、実行環境、ユーザー確認、失敗時の影響範囲を見ます。ここで「何のために、どのデータへ、どの操作だけ許すか」が言えないサーバーは入れません。

利用中

利用中レビューでは、ログを見ます。誰が、どのtoolを、どのscopeで、どの対象へ呼んだか。失敗したtool call、拒否された承認、scope elevationの試行、想定外の外部通信を確認します。

更新時

更新時レビューでは、version、tool list、scope、transport、publisher、package、remote endpointの差分を見ます。新しいtoolが追加された場合は、既存承認の範囲外として扱います。

セキュリティ・コスト注意

秘密情報の混入

API key、OAuth token、認可コード、社内URL、private repository名をログや記事に残しません。

local serverの近さ

端末上のファイルやコマンドに近くなるため、installerや実行内容を確認できる必要があります。

remote serverの境界

network、OAuth、SSRF、tenant分離、ログ、可用性、データ保持を確認します。

tool定義の増加

大量のtool定義はcontextを圧迫し、不要な選択肢をモデルへ渡します。

再試行の増加

scope不足や承認不足の失敗が続くと、tokenとAPI callが増えます。

localかremoteかだけでなく、接続先データと許可toolを先に見ることが現実的です。

MCPサーバー選定では、最初にコストより権限事故を見ます。AIコーディングツールの料金やtoken消費も重要ですが、MCPサーバーが広い権限を持ってしまうと、費用より先に情報漏えい、誤更新、監査不能が問題になります。

OAuth tokenとAPI keyを記事や設定に残さない

確認項目

MCPサーバー検証のログ、README、スクリーンショット、記事には、API key、OAuth token、認可コード、社内URL、private repository名、顧客情報を残しません。必要な場合はダミー値に置き換えます。

運用方法

MCP client設定を共有するときも、credentialを設定ファイルに直書きしないようにします。環境変数、secret manager、OS keychain、team向けcredential管理など、既存の秘密情報管理へ寄せます。

local serverとremote serverでリスクが違う

local server

local MCP serverは、ユーザーの端末上で実行されます。stdio transportならネットワーク公開面は小さくできますが、端末上のファイルやコマンドへ近くなります。installerやone-click設定で任意コマンドを実行する仕組みは、実行内容を人間が確認できる必要があります。

remote server

remote MCP serverは、端末上の任意実行リスクを減らせる一方で、network、OAuth、SSRF、tenant分離、ログ、可用性、データ保持が問題になります。どちらが安全かは用途次第です。社内利用では、localかremoteかより、接続先データと許可toolを先に見ます。

コストは「広いtool定義」と「再試行」で増える

確認項目

MCPサーバーを大量に接続すると、tool定義がモデルのcontextを圧迫します。公式のclient best practicesでも、tool定義をすべて最初からモデルへ渡すのではなく、必要に応じて発見する考え方が説明されています。

注意点

また、scope不足や承認不足でtool callが失敗し続けると、再試行でtokenとAPI callが増えます。allowlistとscope設計はセキュリティだけでなく、運用コストにも効きます。

FAQ

Registry未掲載の扱い

使えないとは限りませんが、repository、package、publisher、version、更新通知を自分たちで確認します。

自動allowlist登録

公開Registryの自動取り込みだけで社内承認済みにするのは避けます。

OAuthとAPI key

方式名ではなく、最小権限、consent、revoke、audience分離、監査可能性で判断します。

tool poisoningの責任

サーバー作者だけでなく、導入側もtool description、schema、result、外部入力を確認します。

最初に許可する条件

read-only、対象データ限定、小さいscope、短いtool list、version固定、revoke容易なものから始めます。

書き込み、外部送信、任意command、任意URL、広いrepository access、本番データ接続は後回しにします。

MCP Registryに載っていないサーバーは使わない方がよいですか

必ずしもそうではありません。社内専用MCPサーバーや、まだRegistryに登録していないOSSもあります。ただし、Registryにない場合は、発見面のメタデータがないぶん、repository、package、publisher、version、更新通知、セキュリティ連絡先を自分たちで確認する必要があります。

Registryに載っているサーバーは社内allowlistへ自動登録してよいですか

おすすめしません。Registryは候補を探す入口であり、社内承認済みリストではありません。自動取り込みする場合も、承認済みserverだけを公開するサブレジストリ、またはレビュー結果を持つ社内カタログを挟むべきです。

OAuth対応のMCPサーバーならAPI keyより安全ですか

OAuthはscope、consent、revoke、audience分離を設計しやすい点で有利です。ただし、scopeが広すぎる、token passthroughをしている、第三者APIとの認可境界が混ざっている、refresh token管理が弱い場合は安全とは言えません。API keyかOAuthかではなく、最小権限と監査可能性で判断します。

tool poisoningはサーバー作者だけが気にすればよいですか

いいえ。導入する側も、tool description、input schema、tool result、外部入力の扱いを見ます。AIエージェントがtoolを選ぶ以上、ツール定義は実行面の一部です。特に、Issue、Docs、Web、メール、チャットを読むtoolと、書き込みtoolを同じ環境に置く場合は、人間承認と差分レビューを必須にします。

最初に許可してよいMCPサーバーの条件はありますか

最初は、read-only、対象データが限定、scopeが小さい、tool listが短い、実装が公開、version固定、token revokeが簡単、ログが残るものから始めます。書き込み、外部送信、任意command、任意URL、広いrepository access、本番データ接続は後回しにします。

関連資料と導線

1. 1権限レビュー

   MCPサーバー導入前に、用途、対象データ、許可tool、承認者をそろえます。

2. 2allowlist設計

   公開Registry、社内allowlist、MCP client設定、秘密情報管理の境界を分けます。

3. 3社内ガイドライン

   prompt injection対策、ネットワーク制限、ログ、更新レビューを運用に落とします。

4. 4継続的な更新確認

   仕様やセキュリティ資料の変更を追い、判断表を自社のデータ分類に合わせて見直します。

判断表をテンプレート化する場合は、自社のデータ分類と承認フローに合わせて調整します。

MCPサーバー導入は、ツール選定だけでなく、AIエージェント運用ルール、prompt injection対策、ネットワークallowlist、秘密情報管理とつながります。MCPサーバー導入前の権限レビュー、allowlist設計、社内ガイドライン整備を相談したい場合は、お問い合わせ から状況を共有してください。

MCP仕様やAIエージェントセキュリティの更新を追う場合は、ニュースレター でも更新通知を受け取れます。本文の判断表をテンプレート化するなら、まずは自社のデータ分類と承認フローへ合わせて調整するのが現実的です。

次に読むなら

参照した主な情報源

• Official MCP Registry: https://prod.registry.modelcontextprotocol.io/
• Introducing the MCP Registry: https://blog.modelcontextprotocol.io/posts/2025-09-08-mcp-registry-preview/
• MCP Registry quickstart: https://github.com/modelcontextprotocol/registry/blob/main/docs/modelcontextprotocol-io/quickstart.mdx
• MCP Registry aggregators: https://github.com/modelcontextprotocol/registry/blob/main/docs/modelcontextprotocol-io/registry-aggregators.mdx
• MCP Registry moderation policy: https://github.com/modelcontextprotocol/registry/blob/main/docs/modelcontextprotocol-io/moderation-policy.mdx
• MCP Authorization 2025-11-25: https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization
• MCP Security Best Practices: https://modelcontextprotocol.io/specification/2025-11-25/basic/security_best_practices
• MCP Tools 2025-11-25: https://modelcontextprotocol.io/specification/2025-11-25/server/tools
• NSA, Model Context Protocol (MCP): Security Design Considerations, May 2026: https://www.nsa.gov/Portals/75/documents/Cybersecurity/CSI_MCP_SECURITY.pdf
• MCP Client Best Practices: https://modelcontextprotocol.io/docs/develop/clients/client-best-practices

更新履歴

1. 2026-06-08 仕様と資料を確認

   MCP Registry、Registryドキュメント、MCP Authorization、Security Best Practices、MCP Tools、NSA資料を確認しました。

2. 2026-06-08 Registry APIを確認

   Registry APIのv0.1 servers endpointが応答することを確認しました。

3. 2026-06-08 X投稿は根拠に不使用

   指定アカウントの直近投稿は、本文の事実根拠として使わない方針にしました。

公開時点の確認結果であり、Registry掲載状況や仕様は更新される可能性があります。

• 2026-06-08: MCP Registry、Registryドキュメント、MCP Authorization 2025-11-25、MCP Security Best Practices、MCP Tools、NSA MCP Security Design Considerationsを確認。Registry APIの v0.1/servers?limit=1 が200 OKを返すことを確認。
• 2026-06-08: 指定Xアカウントの直近投稿は、動的表示および取得制約により本文根拠として確認できなかったため、Xの投稿内容を事実根拠に使わない方針で公開。