Azure DevOpsのPull Request（PR）に、人間には見えないコメントを仕込むだけで、AIレビュー担当を別プロジェクトへ誘導し、ソースコードや秘密情報まで読ませてしまう――そんなかなり嫌な話が出てきました。The Hacker Newsが紹介したのは、Microsoftの公式 Azure DevOps MCP server にある欠陥です。
MCPは、ざっくり言うとAIエージェントが外部サービスを操作するための接続口です。今回の件では、その接続口が「PRを読む」役割を持っていて、そこで受け取った文章の扱いが甘かった。ここがまず面白くて、そして怖いところです。
人間にはただのレビュー対象に見えるものが、AIにとっては「命令文」になってしまう。しかもその命令文が、画面上では消えて見える。かなり厄介です。
脆いのは、Microsoftが提供している Azure DevOps MCP server の中の、PRを取得する機能でした。
Azure DevOpsのPR説明欄はMarkdownに対応していて、そこに <!-- ... --> というHTMLコメントを入れられます。HTMLコメントは、Web画面では完全に非表示です。つまり、レビュー画面を見ている人は気づきません。
ところがREST APIはそのコメントを消さずに返す。そしてMCP serverは、その生の文字列をAIエージェントへ渡してしまった。
この「人間が見る画面」と「AIが受け取るデータ」のズレが、攻撃の入り口になります。実に嫌らしい。こういうのは、守る側がUIだけ見て安心していると見逃しやすいんですよね。
攻撃者は、PRの本文の中に見えない命令を埋め込みます。
レビュー担当者が「このPRを見て」とAIに頼むと、そのAIはコメント内の隠し文を読んで、本来のレビュー目的をずらされる。しかもAIはレビュー担当者の権限を持っているので、攻撃者本人には触れないプロジェクトにも行けてしまうわけです。
Manifold Securityの報告では、PoC（概念実証）として、こうした流れが確認されています。AIは別プロジェクトのパイプラインを起動し、攻撃者が開けないはずのWikiページを読み、その内容をPRコメントとして書き戻してしまった。
要するに、中で見つけた秘密を外へ持ち出してしまうわけです。AIが「便利な自動秘書」から「うっかり情報を運ぶ配達係」に変わる瞬間です。
この攻撃、単なる「AIがだまされる話」ではありません。
もっといやらしいのは、攻撃者が直接AIに話しかけていないことです。攻撃の素材は、もともとPRに書かれた文章。つまり、レビュー対象そのものが命令文に化ける。
しかも、レビュー担当者は攻撃者より上位の権限を持っていることが多い。
つまり攻撃者は、自分では入れない場所に、他人の権限を借りて入ることになります。これは昔からある「権限の横取り」に、生成AI時代の味付けが乗った感じです。かなり現実的な危険だと思います。
Manifoldは、漏えい先がWikiだけに限られないと指摘しています。ソースコード、秘密情報、work items（作業チケットのようなもの）まで対象になりうる。
レビュー用AIに「ちょっと読んで、ちょっと操作して」と任せるほど、被害の幅は広がります。
ここが今回の話でいちばん興味深い点かもしれません。
Microsoftは、こうしたindirect prompt injection（間接的なプロンプト注入、つまり“AIが読む外部データに命令を紛れ込ませる攻撃”）に対して、すでに一部防御を入れていました。
その防御は spotlighting と呼ばれるものです。難しく聞こえますが、要するに「これは信頼していい命令ではなく、外から来たデータですよ」とAIに印を付けるやり方です。
ところが、Wikiやビルドログを返す経路では共通の保護処理 createExternalContentResponse が使われていたのに、PRを返す repo_get_pull_request_by_id ではそれが呼ばれていなかった。つまり、PRだけ丸裸だったわけです。
正直、これはかなり人間くさいミスだと思います。
防御策を入れた気になっていても、1本だけ通り道が抜けている。しかも外から見えにくい。こういう穴は、レビューしづらいコードに潜りがちです。セキュリティって、派手なゼロデイよりこういう“入れ忘れ”が地味に効くんですよね。
The Hacker Newsによると、7月21日時点でも同じ経路は修正されていなかったとのことです。
ManifoldのPoCでは、ローカルで動かした v2.7.0 を使って、次のような流れを再現しています。
まず、あるプロジェクトに属する投稿者が、普通のPRを出します。見た目はただのレビュー依頼。でも中には隠しコメントが入っている。
レビュー担当者がAIエージェントでそのPRを見始めると、AIは指示を読み取って、別プロジェクトのパイプラインを起動し、秘密のWikiを読み、内容をPRコメントに書き戻します。攻撃者はそのコメントを見て、情報を回収できてしまう。
この一連の動きは、すべてAIが「許可されている操作」の範囲内で起きているのがポイントです。
つまり、1回ごとの権限チェックをすり抜けているのではなく、順番と意図だけを奪われている。研究者が「人間が見ていないテキストに動かされた」と表現したのも、まさにそこでしょう。
しかもこの問題は、Copilot CLIでもClaude Codeでも再現したそうです。特定製品のバグというより、AIエージェント全般に刺さる形だと見たほうがよさそうです。
この手の話、実は初めてではありません。
2025年5月には、Invariant LabsがGitHubのMCP serverに対する似た攻撃を示しました。公開issueをきっかけに、AIをプライベートリポジトリへ誘導し、漏えいをPull Request経由で外へ出すというものです。その後、同系統の攻撃は自動化されたGitHub agentのワークフローにも広がっています。
つまり、今回のAzure DevOps版は別製品で起きた同種の問題です。
AIに「読む」「判断する」「動く」を一体化させると、外から入ってくるテキストがそのまま操作命令になりうる。これが本当に厄介です。
セキュリティ研究者のSimon Willisonが言う “lethal trifecta” という考え方があります。
これは、
Microsoftは、Manifoldからの報告に感謝し、これは「既知のAIリスクの一種」だと述べています。
ただし、コードを変えるのか、CVEを付けるのかについては明言していません。公開DB上でも、少なくとも記事執筆時点ではCVEは見当たらないようです。最新リリースは v2.8.0 で、6月24日に出ています。
では、使う側は何をすればいいのか。
記事が勧めているのは、まず最小権限です。AIエージェントに広いトークンを渡さない。レビュー対象のプロジェクトだけに絞る。
それから、AIに読み込ませるMCPのドメインも必要最小限にする。ローカルサーバーでは -d フラグで対象を絞れるそうです。要するに、使わない能力を持たせないことです。
もうひとつ大事なのは、パイプライン実行、Wiki閲覧、コメント投稿のような操作を、コードレビュー用のAIに持たせすぎないこと。
レビューしかさせないなら、レビューに必要な機能だけに絞る。すごく当たり前の話なんですが、AIを入れるとつい「せっかくだから何でもできたほうが便利」となりがちで、そこが危ない。
Manifoldは、すでに起きたかどうかを確認するなら、AIのツールトレースを見るべきだとしています。
別プロジェクトのパイプラインを動かしていないか、Wikiを読んでいないか、レビュー中に変なコメントを投稿していないか。あわせて、PRの説明欄に見えないHTMLコメントが潜んでいないかも確認したほうがいい。
画面上で見えないものを、人間が「見たつもり」で済ませるのは危険です。
この話は、単なる脆弱性レポート以上の意味があると思います。
AIエージェントは、これから開発現場でかなり普通に使われるはずですが、今回のように「人間の目に見えない入力」が、そのままAIの行動になると、境界があいまいすぎる。攻撃者はAIをだましているというより、レビューの仕組みそのものを逆手に取っている感じです。
しかも、守る側ができることも地味です。最小権限、入力の隔離、ツールの絞り込み。
派手なAIセキュリティ製品を入れれば終わり、という話ではない。むしろ、どの経路で外部データを読ませるかを一個ずつ見直すしかない。こういう泥臭さが、いまのAIセキュリティの本体だと思います。
参考: Microsoft Azure DevOps MCP Flaw Lets Hidden PR Comments Hijack AI Review Agents
