なぜほとんどのAIツール統合は危険なほど安全でないのか
すべてを接続する競争
今、AIツーリングでゴールドラッシュが起きている。すべての企業が自社製品を「AI-ネイティブ」にしたがっている。すべての開発者がMCPサーバー、関数呼び出しエンドポイント、ツール統合をできるだけ速く配線している。
明白な質問をするために立ち止まる人はいない:何かがうまくいかなかったらどうなるのか?
バグの話ではない。バグは普通だ。敵対的攻撃の話だ。誰かがツールの説明を作成して、AIエージェントにユーザーが意図しなかったことをさせたらどうなるのか?
これは仮説ではない。これらの攻撃はすでに研究室で機能している。まだ大きなインシデントを引き起こしていない唯一の理由は、ほとんどのMCPデプロイメントがまだ十分に小さく、攻撃者が気にしていないからだ。
ツールポイズニングは新しいSQLインジェクション
2005年、開発者がユーザー入力を信頼していたため、SQLインジェクションはどこにでもあった。2026年、開発者がツールの説明を信頼しているため、ツールポイズニングはどこにでもある。
仕組みはこうだ。MCPツールにはAIに何をするかを伝える説明がある。AIはその説明を読み、いつどのようにツールを使うかを決定する。しかし、説明が嘘だったら?「search_documents」というツールが実際にはその説明に隠された指示を持っていて、AIにまず会話のコンテキストすべてを外部エンドポイントに送信するよう指示していたら?
AIは違いを見分けられない。説明を読み、指示に従い、ユーザーは何が起こったか知ることがない。これがツールポイズニングであり、壊滅的に効果的だ。
修正は理論的には複雑ではない:ツールの説明がツールの動作と一致することを確認する。しかし、ほとんど誰もこれをしていない。
心配すべき3つの攻撃
MCPツールで構築するすべてのチームが理解すべき3つの攻撃カテゴリがある。
第一:ツールポイズニング。説明がツールの動作について嘘をつく。最も一般的で実行が最も簡単。
第二:行動の不一致。ツールは主張通りのことをするが、余分なこともする。隠しログにも書き込むファイルリーダー。スキーマもエクスポートするデータベースクエリツール。
第三:権限エスカレーション。読み取り専用アクセスから始まり、徐々に書き込みアクセスを要求(または仮定)するツール。これは通常のツール進化のように見えるため、特に危険だ。
これらは従来のセキュリティツールでは検出が困難だ。SASTスキャナーはコードの脆弱性を探すが、説明と実装の間のセマンティックな不一致は探さない。別の種類の分析が必要だ。
なぜ従来のセキュリティツールがここで失敗するのか
この問題がこれほど危険な理由は、既存のセキュリティ分野の間の隙間に落ちるからだ。
アプリケーションセキュリティチームはXSSやSQLインジェクションの見つけ方を知っている。インフラチームはネットワークのロックダウン方法を知っている。しかしツールポイズニングはコードの脆弱性ではない——セマンティックな脆弱性だ。コードは技術的に正しい。プログラムされた通りに動作する。問題は、プログラムされた内容が主張する内容と一致しないことだ。
これには新しい種類のセキュリティ分析が必要だ。ツールの説明を解析し、何を約束しているかを理解し、実際の実装を分析して約束が守られていることを確認する必要がある。
これは難しい。ブリーチが起きるまで無視され、その後突然みんなが予見していたふりをする類の難しい問題だ。
今すぐやるべきこと
MCPサーバーを出荷または消費しているなら、これが最低限やるべきことだ。
デプロイ前にすべてのMCPサーバーをスキャンする。コードの脆弱性だけでなく——ツールの説明と実装の間の行動の不一致も。
検証なしにサードパーティのMCPサーバーを信頼しない。「GitHubで人気」はセキュリティ監査ではない。すべての外部MCPサーバーを信頼されていないAPIと同じように扱う——許可リスト、サンドボックス、モニタリングで。
本番環境でツールの動作を監視する。どのツールが呼ばれているか、どのくらいの頻度で、どのパラメータで呼ばれているかを知る。MCPツール使用の異常検出はオプションではない——基本要件だ。
セキュリティを正しく行うチームは、ブリーチを避けるだけではない。ツールがデフォルトの選択肢になる信頼を勝ち取る。
関連記事
SmeltSecを試す準備はできましたか?
60秒で安全なMCPサーバーを生成。無料で始められます。