【要約】送信できない Outlook MCP を作った — 「機能の不在」でプロンプトインジェクションに備える [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者がAIエージェントにメール操作を委ねる際、プロンプトインジェクションによる情報の不正持ち出しや意図しないメール送信のリスクに直面する。攻撃者がメール本文を通じてエージェントに悪意ある指示を送り込むことで、以下の条件が揃うと致命的な被害が発生する。
- ・機密データ（メール内容）へのアクセス権の保持。
- ・信頼できないコンテンツ（メール本文）への曝露。
- ・外部への送信手段（Mail.Send権限）の存在。
// Approach
開発者は、攻撃をアプリケーション層のロジックで防ぐのではなく、攻撃に必要な「能力」そのものを排除する設計を採用した。
- ・OAuthスコープの制限：
Mail.Send権限を要求せず、ID層で送信不能な状態を強制する。 - ・代替機能の提供：送信の代わりに
create_draftを実装し、人間が最終確認を行うフローを構築。 - ・検証の自動化：テストコードで要求スコープを監視し、意図しない権限追加を検知する仕組みを導入。
- ・メタデータの厳格化：機械可読なアノテーション（destructive等）を、実測に基づき正確な値へ修正。
// Result
この設計アプローチにより、セキュリティ強度の向上と実装の品質改善を同時に達成した。
- ・権限の可視化：ユーザーがAzureの同意画面で、要求スコープの安全性を直接検証可能になった。
- ・バグの発見：ドキュメントを実測に基づき書き直す過程で、フォルダ作成時のバリデーション漏れを特定・修正した。
- ・評価の向上：MCPサーバーの自動評価において、ツール定義のスコアが3.2から5.0へ改善した。
Senior Engineer Insight
> 防御層の考え方が極めて実践的である。アプリケーション層の
if 文によるガードは、エージェントの乗っ取りに対して無力だ。ID層（OAuthスコープ）での制限は、システム全体の信頼性を担保する。また、人間向けの docstring と機械向けのメタデータの乖離は、自動化が進む現場では致命的な脆弱性になり得る。ドキュメントの更新を実装の検証プロセスとして組み込む姿勢は、高信頼性システム開発において不可欠である。