なぜこの「翻訳」が実務で役立つのでしょうか。理由は単純で、脆弱性診断・監査の現場は、次々に出てくる新技術を一つひとつゼロから学ぶ時間の余裕がないからです。しかし「権限チェック不備」と「入力とロジックの境界崩壊」という2つの型さえ体に染み込んでいれば、初めて見る技術（今日ならMCP、明日は別の何か）に対しても、「まずこの2つの型を疑う」という初動が取れます。本記事は、AIエージェント/MCPという具体例を通じて、その”型を疑う力”そのものを鍛える記事でもあります。

▲ 読み方：本来は「この操作を依頼した“人間”は、顧客データ全件を見る権限を持っているか」を確認すべきところ、MCPサーバーは自分自身の接続権限のまま処理を実行しています。呼び出し元の実際の認可を確認しないこの構造が、まさにIDORの「オブジェクトIDさえ指定できれば権限チェックを経ずにアクセスできてしまう」構図と同じです。

CTFでIDOR（CTF実践編②）やIAM誤設定（CTF上級編⑥）を解いたことがある方は、この時点で「あ、あの時のパターンだ」と気づいたはずです。実際に、体験型教材「AIエージェント監査官」のケース④は、パストラバーサル型の権限昇格をMCPの文脈で再現しています。

▲ SQLは「?」という構文的な壁でコードとデータを分離できますが、LLMのプロンプトは両方とも同じ自然言語の文字列です。これが「プリペアドステートメントのようなプロンプトインジェクション対策は存在しない」と言われる理由です。

それでも、SSTI対策の考え方から転用できるヒントはあります。SSTIでは「テンプレートエンジンの権限を最小化する」「危険な関数を呼べないサンドボックス環境で実行する」という設計が有効でした。AIエージェントでも同様に、「LLM自身が直接コードやコマンドを実行できないようにする」「ツール呼び出しの結果を鵜呑みにせず、実行前に別レイヤーで検証・承認を挟む」という多層防御の発想は、そのまま生きています。「入力とコードを完全に分離できない」からこそ、分離できない前提で周囲を固める、という考え方の転換が要になります。

CTFでSSTI（CTF上級編③）やプロトタイプ汚染（CTF実践編④）を解いたことがある方なら、「入力を信頼しすぎるとロジックごと乗っ取られる」という感覚はすでに馴染みのはずです。体験型教材「AIエージェント監査官」のケース①(Web要約経由の間接プロンプトインジェクション)・ケース③(悪性MCPサーバーの天気ツール)は、まさにこの構造を再現しています。より詳しい間接プロンプトインジェクションの技術的な仕組みは実践編を参照してください。

ここまでの対応関係は、文章で読んだだけではまだ「知識」のままです。実際に自分の手で「これは承認すべきか、ブロックすべきか」を判断してみると、パターン認識が体に入っていきます。以下のゲームとCTFシリーズは、いずれも当サイトの体験型教材として無料で遊べます。