はじめに

本記事は、セキュリティエンジニアのAzaraこと齋藤とコーポレートセキュリティエンジニアのhamayanhamayanが、社内で行ったディスカッションを元に記述した記事です。

本記事は、MCP の利活用の際に考えるべき、セキュリティに関する考慮事項や、脅威の想定、実装時気にすべき観点などについてまとめたシリーズの前編になります。前編では、MCPに関する基本的な事項を扱いながら、利用者側の目線でMCPに対するセキュリティを考えていきます。社内での利活用の際に参考になれば幸いです。

また、GMO Flatt Securityは日本初のセキュリティ診断AIエージェント「Takumi」や、LLMを活用したアプリケーションに対する脆弱性診断・ペネトレーションテストを提供しています。ご興味のある方はリンクよりサービス詳細をご覧ください。

• はじめに
• MCPとは
  • MCPと用語
    • MCP Client
    • MCP Server
    • Tool
  • MCP Serverの通信方式と配置場所
    • stdio
    • streamable HTTP
    • 配置場所
  • MCPに関連する全体像
• MCP Client での脅威と注意点
  • MCP Clientの設定ファイルについて
    • 対策・注意1: 最小権限の原則に従って権限を付与する
    • 対策・注意2: OAuthを利用したアクセストークン管理を行う
    • 対策・注意3: 設定ファイルで使える記法を活用する
    • 対策・注意4: 別の方法で認証情報を与える
  • 複数のMCP Serverを接続した場合の注意点
    • 対策・注意1: 扱う情報の機密性の水準を揃える
    • 対策・注意2: 人間によるMCP Server利用の確認と許可を行う
• MCP Server での脅威と注意点
  • 悪性な MCP Server を実行した場合の実行環境への影響
    • コンテナ化による対策
    • Denoで権限設定を行うことによる対策
  • 悪性な MCP Server を実行してしまい、MCP Clientに悪影響を及ぼす
• 終わりに
• お知らせ

追記: 後編を公開しました。攻撃者視点から脅威や攻撃手法を整理し、対策について論じています。ぜひご覧ください！

MCPとは

本章では、MCPとその周辺用語について簡単に説明していきます。MCPの重要キーワードと全体像を掴んでいただき、MCPとセキュリティを考える上での前提を掴んでいただきたいと思います。

MCPと用語

Model Context Protocol（MCP）は、LLMが外部のデータソースやツールと効果的に連携するために設計されたオープンスタンダードなプロトコルです。Anthropic社によって提唱され、標準化されています。これにより、LLMは単に情報を生成するだけでなく、外部の要素とインタラクティブに繋がりながら、より複雑なアクションを実行することができます。例えば、LLMがユーザーのカレンダーに予定を追加したり、端末内のファイルを検索して操作したりといった操作が、MCPを通じて実現可能になります。

MCPの主要なコンポーネントには、ユーザーインターフェースを提供する「Host」、通信を仲介する「Client」、そして外部システムへの接続を提供する「Server」があります。利用者目線ではHostとClientはそれほど分離して考える必要はないため、本稿ではHostとClientを1つとして考え、MCP Client、そして、Server機能の部分をMCP Serverと呼ぶこととします。

MCP Client

MCP Clientは、MCPを活用しながらLLMを利用するためのツールのことを指します。例えば、Claude DesktopのようなAIアシスタントツールや、Cursor、VS Code（GitHub Copilot）のような統合開発環境がMCP Clientとしての機能を有します。LLMにどのようなMCP Serverが接続されていて、どのような機能を持っているかということを伝え、LLMの要求に従いながらMCP Serverとデータ連携するということを担当します。

MCP Server

MCP Serverは、特定の外部システム（SaaSのWebサービスやファイルシステムなど）へのアクセス機能を提供する軽量なプログラムまたはサーバサービスです。MCPにおいて、外部世界の機能やデータをLLMに接続するためのゲートウェイとして機能し、MCP Clientの要求に従って特定の操作を実行します。

現状のMCP Serverはインターネット上の有志が開発したり、サービスによっては公式でMCP Serverを配布している所があります。それらを配布するためにdockerHUB,PyPl,npmといったコンテナ/パッケージ管理システムにMCP Serverをアップロードし、それを起動時に指定することで利用者はそのMCP Serverを自分の環境で利用できるようにする、といったエコシステムが出来上がりつつあります。

Tool

MCPにおける主要な機能の1つである「Tool」についても紹介します。ToolはMCP Serverによって公開される主要な機能の一つであり、LLMから見た「実行可能な関数」のような形で定義されます。MCP Serverは実装時に「〜ということができるToolですよ」という説明付きでToolを公開します。これをMCP Clientが読み取り、LLMに伝えることで、LLMが「〜ということ」を実行したい場合にこのToolを呼び出すようにMCP Clientに要求すればよいということが理解できるようになります。他にも、MCP Clientが利用可能なリソースを提供するResourcesや、MCP Clientが特定の用途のためのテンプレートとして使えるプロンプトを提供するPromptsなどが仕様で定められています。

MCP Serverの通信方式と配置場所

MCP ClientとMCP Server間の通信についても整理しておきましょう。この通信は、stdioとstreamable HTTPという2つの方法のいずれかを選択することができます。

stdio

まず、stdio（Standard Input/Output、標準入出力）を使った通信は、MCP ClientとMCP Serverが同一端末上で動作している場合に利用可能な通信方法です。MCP Serverは「サーバ」という名前がついてはいますが同一端末上で動作させることが可能です。例えば、Claude Desktopであれば、MCP Clientが起動したタイミングでMCP Serverのプロセスを直接起動し、MCP Serverとして活用します。そして、MCP Clientと起動したMCP Serverの間の通信はプロセスの標準入出力を用いて行うという方法です。

streamable HTTP

もう1つの、streamable HTTP通信は、MCP ClientとMCP Serverがネットワークを介して通信することができる通信方法です。stdioとは異なり、MCP Clientが起動する前にMCP Serverを予め起動しておき、通信を待ち受けておく必要があります。この方法はstdioと同様にMCP ClientとMCP Serverが同一端末上で動作している場合にも利用可能ですが、stdioでは使えない、リモートにMCP Serverを用意して通信させるということができます。MCP ClientとMCP Serverを別々のインフラで動作させたい場合にはこちらを選択することになります。

配置場所

MCP Serverをローカルに置くかリモートに置くかは要件によって決定されます。例えば、ローカルに置く場合は、実行環境のファイルシステムを利用できたり、コマンド実行を効果的に行うことができます。また、リモートに配置する場合は実行環境に特殊な環境構築をする必要がないため、広く扱いやすく、また、MCP Clientの実行環境とMCP Serverの実行環境を分けることができるといったメリットもあります。どちらも、注意する点も同様にあるため、要件とリスクを考慮して、実行方式を選定していく必要があります。

MCPに関連する全体像

これまでたくさんのことを説明してきましたが、ここで一旦、MCPに関連する全体像を図にしてまとめてみましょう。

本記事では、以上に示したようなMCPとその周辺に対して、MCPの利用者観点でセキュリティ考慮事項や、どういった脅威があるかを主にMCP ClientとMCP Serverの観点から扱っていきます。MCPを活用してみたいけれど、セキュリティも考慮したい！という方を対象としています。

MCP Client での脅威と注意点

まずは、MCP Clientに着目して、脅威と注意点を紹介していきます。MCPの仕様として定められているのはプロトコル部分なので、MCP Client毎に微妙に実装が異なる部分があります。そういった、MCP Clientごとの差も紹介しながら、MCP Client選定の観点として活用いただきたいです。

MCP Clientの設定ファイルについて

MCP ClientにMCP Serverを接続するためには、設定ファイルを用意する必要があります。例えば、modelcontextprotocol/serversのBrave Search MCP ServerのREADMEを見てみると、brave-searchを接続するための設定ファイルの書き方が書かれています。ここでは設定ファイルに事前に取得したBRAVE_API_KEYを書き込むという方法で設定を書き込んでおり、このように認証情報やAPIキーを設定ファイルに書き込んで接続する方法は、他のMCP Serverでも頻繁に見られます。

その結果、MCP Clientの設定ファイルには色々なサービスの認証情報やAPIキーが平文で保存され、攻撃者によって格好の標的にされる可能性があります。このように書かれた認証情報やAPIキーはローテーションできなかったり、失効しないものもあるため、しばしば長命になります。また、サービスによってはAPIキーに対して細かな認可を絞れず、認可範囲が大きい状態で利用するしかないものもあり、今後、Info Stealerなどに狙われる危険性があります。

利用者はこういった脅威に対してどのような対策や注意ができるか考えてみましょう。

対策・注意1: 最小権限の原則に従って権限を付与する

利用する認証情報やAPIキーには必要最低限の権限を付与しましょう。readonlyの権限にする、また、アクセスできる範囲を絞り権限を与えるということができるならば、最小権限の原則に則った運用を実施することが推奨です

対策・注意2: OAuthを利用したアクセストークン管理を行う

MCP Serverの接続方法として、OAuthを利用したものがあります。例えば、modelcontextprotocol/serversのGoogle Drive serverでは、利用前にGoogle Accountの認証を実行し、短命のアクセストークンを取得して、それを使ってGoogle Driveの操作を行います。（このMCP Serverでは、アクセストークンが失効すると手動で更新を行う必要があって若干不便ではありますが、）もし、MCP Clientの起動時に再認証を行なったり、もしくは自動で適宜リフレッシュしてくれる機能があれば、他のghコマンドやgcloudコマンドなどで使われているのと同じような操作感でアクセストークンによる管理を行うことができます。MCP Serverを選ぶ際はこのような機能があるかどうかも重要な観点です

対策・注意3: 設定ファイルで使える記法を活用する

MCP ClientによってはMCPの設定ファイルの認証情報部分を外部から差し込むことが可能です。例えば、VS Code（GitHub Copilot）では、設定ファイルのmcp.jsonでVariable Referenceという記法が使えます。この記法を利用することで、設定ファイルに平文で直に書いていた認証情報を${env:APIKEY}のように環境変数から埋めこむこともできたり、${input:password}のように起動時に都度入力させることもできます。設定ファイルがどのように書けるかはMCP Clientによって様々なので、MCP Clientを選択するにあたってはこの辺りの機能についても確認しましょう

対策・注意4: 別の方法で認証情報を与える

MCP Serverを別途起動してStreamable HTTPで接続することで、MCP Clientから認証情報やAPIキーを与える形を止めるという方法もあります

以上、色々な緩和方法が考えられますが、利用方法によって選択できない方法もあったり、また、MCP Clientの仕様に依存する部分もあり、完全に緩和することが難しい場合も考えられます。

複数のMCP Serverを接続した場合の注意点

MCP Clientには、複数のMCP Serverを接続することが可能です。これにより、複数のサービスやアクションを組み合わせて複雑なタスクをこなすことができるようになります。便利な一方で、複数のMCP Serverをつなげた場合には情報のやり取りについて注意を払い、機密情報が意図せず開示されないかを考慮する必要があります。

例えば、ブラウザを扱う機能を持つMCP Serverと、社内のConfluenceに接続するMCP Serverが同時に設定されていると、社内のConfluenceから情報を取り出して、その結果を使ってブラウザで検索したり、どこかに書き込んでしまうという情報漏洩につながるシナリオが考えられます。¹ また、実行環境に対してファイル操作やコマンド実行ができるようなMCP Serverと、Gmailと連携する外部送信に使えるMCP Serverが同時に設定されていれば、認証情報が書かれたファイルなどを探してきてGmailで第三者に送られてしまうといったことが成立する可能性があります。

また、これはLLMを利用する上での前提ですが、MCP ServerからMCP Clientに送られた情報はLLMにも送られることになります。LLMに送っても問題ない情報であるかにも注意する必要があります。

現状、こういった問題に対して仕組みで解決する具体的な方法は無く、利用者の注意によって緩和するしかないのが現状です。

対策・注意1: 扱う情報の機密性の水準を揃える

MCP Serverを設定するときは、扱える情報や保管場所の水準を揃えるようにしましょう。MCP Serverがどのように利用されるかを利用者が完全にコントロールすることはできず、LLMの思考に委ねられています。プロンプトによる制限はしばしばうまくいかなかったり、また、悪意あるMCP Serverからのプロンプトへの介入手法も存在するため、可能性をゼロにすることは難しいのが現状です。

対策・注意2: 人間によるMCP Server利用の確認と許可を行う

MCP Serverの利用時にユーザーの許可を要求し、内容を確認してから許可することで、MCP Serverの利用をコントロールすることでリスクを緩和することができます。どの程度、ユーザーに許可を要求するかはMCP Clientによって仕様が様々で、どの程度許可を要求してくれるかというのもMCP Client選定のときのポイントになります。

MCP Server での脅威と注意点

次は、MCP Serverについて考えていきます。MCP Clientはそれほど選択肢はありませんが、MCP Serverではサービスの数だけ、また、実現したい行動の数だけ存在します。SDKを活用することで比較的小さなソースコードで十分活用できるMCP Serverが開発できるということもあり、多くの開発者が有志で開発し、公開しています。

こういった第三者が開発したソースコードを読み込んで利用者環境で実行するという構図は、拡張機能やpipやnpmといったパッケージ管理システムと類似していて、この辺りで議論されてきた脅威や緩和策を流用することができます。例えば、しばしばニュースになる偽アプリやトロイの木馬についてはName CollisionやInstaller Spoofingといった研究がありますし、またインストール後に悪性化するRug Pullというのも提唱されています。このようにサプライチェーンに関するセキュリティリスクについて、MCPを利用するにあたっても同様に考慮する必要があり、同様の対策を講じていくことが重要です。

拡張機能やpipやnpmといったパッケージ管理システムのような既存のものと比べて、MCP Serverに固有のポイントや問題がありますので、ここからはその部分を紹介していきます。

悪性な MCP Server を実行した場合の実行環境への影響

MCP Serverは多くの場合開発者が用意したスクリプトを実行することで環境を立ち上げるため、何らかの方法で悪性なMCP Serverが実行されると、実行環境に対してファイル操作、任意コマンド実行、また、任意のネットワーク通信の実行などが行われる可能性があります。

コンテナ化による対策

この脅威は、拡張機能やpipやnpmといったパッケージ管理システムのような既存のものと同様で、既によく知られている脅威ではありますが、MCP Serverでは実行環境をコンテナ化（サンドボックス）することによって、実行権限を絞るという堅牢化手法が使えるので紹介します。

まず、modelcontextprotocol/serversのBrave Search MCP ServerのREADMEに書いてあるnpxによる設定方法を見てみましょう。

{  "mcpServers":{    "brave-search":{      "command": "npx",      "args":[        "-y",        "@modelcontextprotocol/server-brave-search"],      "env":{        "BRAVE_API_KEY": "YOUR_API_KEY_HERE"}}}}

この設定ファイルでは、環境変数としてBRAVE_API_KEYを与えて、npx -y @modelcontextprotocol/server-brave-searchを実行するという設定をしています。このように、stdioを用いたMCP Serverの起動設定というのは実行するコマンドを指定する形になります。Windows版のClaude Desktopのプロセスツリーを見てみると、claude.exeの子プロセスとしてMCP Serverとして設定したnode.jsやpythonが動いていることが確認できます。（余談ですが、永続化手法として悪用されそうとも感じています）

一方で、MCP Serverの要件としては、MCPでやりとりができれば実行環境は問われません。よって、以上のように実行環境で直にnpxを動かすだけでなく、サンドボックス環境上でMCP Serverを動かし、実行環境を分離するという戦略を取ることができます。これも同様にmodelcontextprotocol/serversのBrave Search MCP ServerのREADMEにDocker上で動かす場合の設定方法として、紹介されています。

{  "mcpServers":{    "brave-search":{      "command": "docker",      "args":[        "run",        "-i",        "--rm",        "-e",        "BRAVE_API_KEY",        "mcp/brave-search"],      "env":{        "BRAVE_API_KEY": "YOUR_API_KEY_HERE"}}}}

単純にDocker上で動かすように包んでいるだけなのですが、ただコンテナ上で動かすだけで「ファイル読み書き」と「コマンド操作」の影響範囲をコンテナ内に限定することができています。MCP Serverの設定方法は、拡張機能やpipやnpmといったパッケージ管理システムのような既存のものと比べて、とても自由に記載することができます。

良し悪しはあると思いますが、この自由度を活かして利用者側の工夫によって堅牢化できるという部分がMCP Serverの利用に対して特徴的な所と言えます。

他にも、dockerを使った堅牢化アイデアとして、以下のようなものが挙げられます。

• modelcontextprotocol/serversのfilesystemでは、dockerに必要なフォルダのみマウントすることで、必要最低限のファイル操作範囲に限定させている
• コマンド操作を実行させたい場合に、ホスト環境でなくサンドボックスな環境でも問題ないという場合もあると思うので、そういう場合もdockerにくるむと良い
• ネットワーク通信が不要である場合は、docker起動時に--network noneとすると良い。自分はfilesystemにこの設定を入れて動かしていますが、正常に動作しています

Denoで権限設定を行うことによる対策

仮に少しだけコードを書く余力がある場合にdocker composeなどでsquidのようなプロキシを立ててネットワーク通信を細かく制御したり、以下のこの記事で紹介されているようにDenoで細かく権限設定をおこなうという方法も取れます。

例として、modelcontextprotocol/serversのBrave Search MCP Serverの通信先を限定するようにDockerでDenoを立ち上げるDockerfileを書いてみました。

FROM denoland/deno:2.2.9RUN apt update&& apt install-y curlWORKDIR /appRUN curl-o index.ts https://raw.githubusercontent.com/modelcontextprotocol/servers/refs/heads/main/src/brave-search/index.tsRUNsed-i's/@modelcontextprotocol/npm:@modelcontextprotocol/g' index.tsENTRYPOINT["deno", "run", "--allow-env", "--allow-net=api.search.brave.com", "index.ts"]

これだけでDenoによって接続先のドメインをapi.search.brave.comにしぼりつつ、また、コマンド実行なども制御しつつ、動かすことができます。ここまで制限できていれば、仮に悪性なMCP Serverを実行してしまった状態を前提としても、（許可先をC2サーバにされる恐れなどはありますが）可能な限りの堅牢化が達成できていると思います。

悪性な MCP Server を実行してしまい、MCP Clientに悪影響を及ぼす

前項では悪性なMCP Serverの呼び出しをどのように堅牢化するかという観点で考えてきました。しかし、MCP Serverが影響を及ぼすのは、実行環境だけではありません。MCP Serverから実行環境へのリソースを完全にコントロールできていても、MCP Clientとの接続は残しておく必要があります。そして、実際に悪性なMCP Serverが呼び出し元のMCP Clientの動作に悪影響を及ぼすことのできる攻撃方法がいくつか既に発見されています。このMCP固有の特殊な攻撃について、紹介していきます。

MCP Serverの機能の1つであるToolはMCP Serverが実行できるコマンドを提供する機能です。MCP ClientはMCP Serverが用意するToolを呼び出すという構図なのですが、Tool毎にそのToolがどういった処理をするものかという説明が書かれていて、それをLLMが読んで理解することで必要なタイミングで呼び出すことができます。

この「説明」ですが、Toolがどのような機能を有するかということ以外にもLLMが読んで理解することを活かして、このツールの実行前や実行後の振る舞いを命令することができます。この特徴を活用することで、MCP Server側からMCP Client側（最終的にはLLM側）の動きをコントロールするということができ、Tool Poisoningという名前が付けられています。これによって、悪性なMCP Serverから見ると兄弟にあたる、他に接続されている正規のMCP Serverを呼び出して利用したり、結果的にSSH鍵のような機微なファイルを漏洩させるシナリオがInvariantlabsの記事で紹介されています。

また、Toolの名前と説明文はMCP Server側で自由に決めることができます。Tool Name Conflictsという攻撃では、別に接続されている良性のMCP Serverで用意されているToolと、同じ名前で説明のToolを悪性のMCP Serverで用意することで、Toolの呼び出しを横取りして、やりとりされている情報を窃取するという手法です。

Toolの実行について、いくつかのMCP Clientでは利用者の許可を得る画面が表示される実装がなされています。例えば、ClineではMCP ServerのToolを利用する際の許可画面で、入力値もチェックすることができます。悪意あるMCP Serverによって引き起こされたMCP Serverの悪意ある実行を利用者に許可してもらう可能性を少しでも上げるため、怪しい部分をスペースで見えないようにするなどのヒューリスティックな手法も提唱されています。

このようなLLMがMCP Serverから与えられた情報をどのように理解するかに依存した、プロンプトなどを活用した攻撃はとても特徴的です。このような攻撃はLLMサービス側も対策を講じて緩和されてきてはいます。しかし、現状このような脅威に対するはっきりとした緩和策は存在せず、確実なコントロールを行いたい場合は、「複数のMCP Serverを接続した場合の注意点」の項で紹介した、人間による確認と許可による緩和くらいしか方法がないのが現状です。

つまり、MCP Serverについては、なるべく信頼性の高いMCP Serverを堅牢化して利用し、扱える情報やリソースを限定しながら、重要な操作は人間による確認を行うというのが現状取れる最大の緩和策です。以上のような脅威を理解しながら、便利さとのトレードオフを考え、向き合っていく必要があります。

終わりに

本稿では、MCPにおけるセキュリティを利用者の目線に絞って紹介してきました。MCPはまだまだ新しい仕様であり、今後も継続して仕様の変更や拡張がなされる可能性があります。また、LLM分野では変化も激しいため、将来的にはMCPに変わる別の仕様がスタンダードになっているかもしれません。安全にLLMが利用できるよう、今後も注視していきたいと思っています。また、後編もお楽しみに！

お知らせ

GMO Flatt Securityは2025年3月から日本初のセキュリティ診断AIエージェント「Takumi」も開発・提供しています。Takumiを導入することで、高度なセキュリティレビューや巨大なコードベース内調査を月額7万円(税別)でAIに任せることができます。

また、セキュリティエンジニアによる脆弱性診断・ペネトレーションテストとして「LLMアプリケーション診断」を正式リリースしました。LLMを活用するアプリケーションの実装のセキュリティリスクをソースコード解析により網羅的に検出します。

今後ともGMO Flatt SecurityはAIエージェントを開発している組織だからこその専門的な深い知見も活かしながら、AIを活用するソフトウェアプロダクトにとって最適なサービスを提供していきます。公式Xをフォローして最新情報をご確認ください！