MCPを使う前に知っておくべきこと――便利さの裏にある攻撃の仕組み は、MCPのリスク構造を整理した一本だ。1Passwordと生成AIの連携を起点に、間接プロンプトインジェクション・ツールポイズニング・シャドウサーバーという3種の攻撃手法を具体的に解説している。記事が最後に残す問いは、「承認制は設計上の意図であり、実際にどう実装されているかはツールによって異なる」という一点だ。
MCPは今、急速に存在感を高めている。GitHub・Slack・Google DriveなどがMCPサーバーを提供し、Claude DesktopやCursorから横断的に操作できる環境が整いつつある。ファイル・コード・コミュニケーション・情報検索を一つのエージェントから扱える統合は本物の機会だ。
ただ、その前提として確認しなければならないことがある。
「承認制がある」と「承認制が機能している」は別の命題だ
多くのMCPツールは「ユーザーの承認を経て実行する」という設計を売りにしている。この方向性は正しい。AIがあらゆる操作を無条件に実行するより、人間の意思が介在する設計の方が安全性は高い。
問題は、「承認制がある」と「承認制が安全に機能している」が別の命題だということだ。
記事が指摘するツールポイズニングは、MCPサーバーのツール説明文に悪意ある命令を仕込む手口だ。ユーザーに承認UIが表示されても、その説明文が改ざんされていれば、ユーザーは実質的に何を承認しているか分からない。承認のステップは存在するが、形骸化している。「承認制があるから安全」という判断は、この実装ギャップを見落とす。
承認制は安全の証明ではなく、安全のための設計要素の一つに過ぎない。
確認できることから始める
この問題が示す前向きな側面は、確認できる性質のものだということだ。
まず、承認UIで何が開示されているかを見る。実行されようとしているツール名・引数・アクセス先が人間に読める形で示されているか。「実行しますか？」の一言だけなら、その承認は意味を持ちにくい。
次に、MCPサーバーの提供元と更新履歴を確認する。ツールポイズニングはサーバー側の説明が書き換えられることで成立する。公式かつオープンソースで透明性があるか、不審な更新が入っていないかは調べられる。
さらに、AIがどの外部ソースを読むかを把握しておく。間接プロンプトインジェクションは「AIが読む可能性のあるファイル」すべてを攻撃面とする。利用範囲を絞ることは、攻撃面を絞ることに直結する。
これらは特別な技術を要しない。ツールを使う前に、誰が作ったか・何が承認されるのか・どこにアクセスするのかを確認する——その習慣が、MCPエコシステムの恩恵を安全に受け取る条件になる。
MCPの可能性は本物だからこそ、使いこなす側の判断軸が問われている。「承認制があるから大丈夫」は入口の安心感に過ぎない。「承認制がどう実装されているかを自分で確かめた」がエンジニアとしての判断になる。
関連記事
- 週刊 AI 懐疑論 #5
- 仕事の根本的な再設計は組織的なAI導入の前提条件なのか？
- Specialization Beats Scale: A Strategic Variable Most AI Procurement Decisions Overlook
参考文献
コメント