MCPの「S」はセキュリティを意味する

• MCPはLLMとツールを接続する標準プロトコルだが、デフォルトではセキュリティが適用されていない
• コマンドインジェクション、ツールポイズニング、定義改ざんなど、さまざまなセキュリティ脆弱性が存在する
• MCPには認証、暗号化、完全性検証の機能がなく、信頼しにくい構造になっている
• 現時点では、ScanMCPのようなツールで可視性と統制を確保することが最善の対応である

MCPとは何か、そしてなぜ重要なのか

• MCPはModel Context Protocolの略で、Claude、GPT、CursorのようなLLMがツールやデータと統合される方法の新しい標準である
• 「AIエージェントのためのUSB-C」と呼ばれるほど、標準化された接続方式を提供する
• MCPを通じてAIエージェントは次のような機能を実行する
  • 標準化されたAPIでツールと接続する
  • セッション状態を維持する
  • コマンドを実行する（過度に自由に実行され得る）
  • ワークフロー間でコンテキストを共有する
• しかし、デフォルトではセキュリティが適用されていない
• ユーザーに気づかれないままシステムにアクセスできるサイドチャネルを開いてしまう危険がある

MCPで発生する主なセキュリティ脆弱性

• コマンドインジェクション脆弱性（Equixlyの調査）

  • 2025年現在も、**コマンドインジェクションによるリモートコード実行（RCE）**が発生している
  • Equixlyの調査によれば、MCPサーバー実装全体の43%以上が安全でないシェル呼び出しを使用している
  • 攻撃者はツールの入力値にシェルコマンドを含めることで、信頼されたエージェントを通じてリモートコードを実行できる

• ツールポイズニング（Tool Poisoning、Invariant Labs）

  • 攻撃者が悪意ある命令をツールの説明文の中に隠しておく方式
  • ユーザーの目には見えないが、AIはそれをそのまま認識して実行する
  • 単純な数学演算のように見えるツールが、実際にはユーザーのシステム上でSSHキーや機密設定ファイルを読み取れる場合がある

• 静かなツール再定義（Rug Pull）

  • ツールはインストール後に自ら定義を変更できる
  • Day 1では正常だったツールが、Day 7には攻撃者のAPIキー収集ツールに変わっている可能性がある
  • これはサプライチェーンセキュリティ問題の新しい形であり、LLM内部で発生する

• クロスサーバーのツールシャドーイング

  • 複数のMCPサーバーが1つのエージェントに接続されている場合、悪意あるサーバーが信頼されたサーバーの呼び出しを横取りしたりオーバーライドしたりできる
  • その結果、次のような問題が発生し得る
    • ユーザーに送ったように見せかけて、攻撃者にメールを送信する
    • 隠されたロジックをツールに注入する
    • エンコードされたデータを流出させる

MCPがまだ安全ではない理由

• MCPは次の点を優先している
  • ✅ 容易な統合
  • ✅ 統一されたインターフェース
• しかし、次の点が欠けている
  • ❌ 認証標準がない
  • ❌ コンテキスト暗号化がない
  • ❌ ツールの完全性を確認できない
• ユーザーは、エージェントが実際にどの説明に基づいてツールを使っているのかを知ることができない

開発者とプラットフォーム運営者ができるセキュリティ対策

• 開発者

  • 入力値検証を必須にする
  • MCPサーバーとツールのバージョンを固定する（pinning）
  • ツール説明から機密情報を取り除く

• プラットフォーム運営者

  • すべてのツールメタデータをユーザーに表示する
  • サーバー更新時に完全性ハッシュを使用する
  • セッションセキュリティを強制適用する

• ユーザー

  • 信頼できないMCPサーバーには接続しない
  • セッションログを本番環境と同じように監視する
  • 不審なツール更新を監視する

ScanMCP.comのアイデア提案

• ScanMCPは、次を実行するスキャナー兼ダッシュボードとして提案されている
  • 接続されたMCPツールを監査する
  • RCE、ツールポイズニング、セッション漏えいなどのリスクを検知する
  • ユーザーが見る情報とエージェントが認識する情報を比較して可視化する
• 次のようなユーザーに有用かもしれない
  • エージェントプラットフォームのセキュリティチーム
  • AIインフラのスタートアップ
  • 信頼ベースのツールを作りたい独立開発者

締めくくりの考え

MCPは強力なプロトコルだが、APIセキュリティの成熟度が不十分なまま、あまりにも速く導入されている
Secure-by-defaultの方式が導入されるまでは、ScanMCP.comのようなツールが可視性と統制力を確保する最善の方法である

• 結論: MCPの「S」はSecurityではない。だが、そうあるべきだ

[GN⁺]

Hacker Newsのコメント

• この記事は、数日前にInvariant Labsが公開したセキュリティノートで説明された攻撃シナリオ（ツールポイズニング、シャドーイング、MCPラグプル）を強調し、引用している。私はそのブログ記事の著者である

  • 多くの人が疑っているのとは違い、MCPスタイルのLLMツール呼び出しにおけるセキュリティ問題は、異なるMCPサーバー実装を分離することにはない
  • ローカルで実行されるMCPサーバー実装は、インストールに使うパッケージマネージャーが検証すべきである（リモートMCPサーバーは実際には検証がさらに難しい）
  • 問題は、エージェントシステムでMCPを使うときに発生する、間接プロンプトインジェクションの特殊な形にある
  • エージェントは同じコンテキスト内にインストール済みのすべてのMCPサーバー仕様を含むため、信頼できないMCPサーバーが他のMCPサーバー（たとえば機密データベースにアクセスできるサーバー）の動作を容易に操作できる。これをツールシャドーイングと呼んでいる
  • さらに、MCPの動的な性質のため、MCPサーバーは提供するツールセットを特定のユーザーに対してのみ変更できる。これは、MCPサーバーがいつでも悪意あるものに変化しうることを意味する
  • 現在のMCPクライアントであるClaudeとCursorは、こうした変更を通知せず、そのためエージェントとユーザーが脆弱になる
  • もっと関心のある人は、[1]でより詳しいブログ記事を確認してほしい。私たちはエージェントセキュリティについて研究し、Invariantで長く取り組んできた
  • また、人気のWhatsApp MCPサーバーに対するツールポイズニング攻撃を含め、誰でも試せるコードスニペットを公開した [2]

• これらの攻撃は、大半がエアロックの間違った側にある別の例にすぎない。権限境界を越えているわけではなく、すでにできることを奇妙な方法でやっているだけだ

  • MCPサーバーはユーザーレベルでコードを実行するので、AIをだましてSSHキーを読ませる必要はない。そのままキーを読める
  • 残りは基本的に、他の開発者ツール／エコシステム（NPMやVS Code Extensions）にも向けられるのと同じ不満である

• 次のようなより良い設計を構想するという課題:

  • 1. 人々に「Sはセキュリティを意味する」という記事を書かせないような、適切なセキュリティ標準を備え
  • 2. プログラムが、現在最も有用なMCPが提供しているのと同じ機能セットを提供できるようにし、自動機能を手動のユーザー確認が必要なものへ置き換えず、全体のアイデアの目的を無力化しないようにし
  • 3. すべてを企業のゲートキーパーがいる独占的マーケットプレイスに閉じ込めない
  • 提案を見てみたい。というのも、これまで私が見てきたのは、一般論で具体性のない「MCPは安全ではない!!!111」という話ばかりだからだ。特に、セキュリティと有用性が相反する力であることを人々が忘れると、なおさら簡単ではない

• 良い記事だが、これがすべてAI生成なのではないかと気になる

  • プロフィール写真はStableDiffusionで生成されたように見えるし、アカウントは今日作成されていて、過去の記事もない
  • さらに、Elena Crossについて他の参照も見つけられなかった

• OはObservabilityを意味する。今週はMCPサーバーの探索と作成に深くのめり込んでいた

  • 私のおもちゃ実装も含め、ほとんどの実装には監査やメトリクスがない。ClaudeはMCPサーバーのログ出力を保存するが、それはデバッグ用であり、DevOps/SecOps向けではない
  • 文化的に見ると、OPが説明した問題はソフトウェアに詳しくない人たち（マグル）にとって大きな問題だ。関連するsubredditでは、人々が自分のマシンでMCP CLIプログラムを実行して楽しい時間を過ごしている
  • OPのセキュリティに関するコメントは開発者には明白だが、そうしたユーザーにはそれがどれほど危険かという視点がない
  • 人々はDockerについて学びつつあり、Claudeもサンプルにその使い方を含めている。しかし大半の人は、ただブロブをダウンロードして実行するだけだ。人々はMCPサーバーを深く考えずにコーディングして実行している
  • MCPが広まるにつれて、セキュリティ、可観測性などを支援するためのフレームワークやツールが育っていくだろう。これは90年代半ばにWebを構築していたのと似ている
  • OPとは関係ないが、これを構築している間、Claude Desktopに何か入力してVSCodeでブレークポイントをトリガーするのはとても興味深かった

• その通り。私も同じことを考えていた。メモを公開したときにはそこまで深く掘り下げなかったが

• 使っているソフトウェアが悪意のあるものでなく、安全に実装されていたとしても、それが望む形で使われていることをどう確認すればよいのだろうか？

  • ローカルファイルシステムを変更できるMCPサーバーと、クラウドストレージ内のオブジェクトを変更するMCPサーバーがあると仮定しよう。ユーザーはLLMエージェントが正しい選択をすることをどう保証できるのだろうか？
  • 多くの選択肢を与えつつ、すべての行動を監視したくはないが、そうするとさらに多くの問題が起きる可能性がある

• EquixlyがテストしたMCPサーバー実装の43%以上に、安全でないシェル呼び出しがあった

  • どうして毎回こういう落とし穴にはまるのか

• MCPが何なのか気になる。何度もドキュメントを読もうとしたが、どんな問題を解決するのか理解できなかった。主に、AIエージェントに特有な点は何なのか、そして何十年も前から存在する決定論的エージェントには当てはまらない点は何なのかがわからない

• 私はMCPの本来の目的は、Anthropicがプロンプトと出力を盗み見て学習データを最大化することだと勝手に思っていた。これがすべてのAIモデル向けのミドルウェアなのだと初めて知った