7月10日、CSO Onlineが「AI coding tool hole illustrates a big problem with human in the loop」と題した記事を公開した。AIコーディングツールにおける「human-in-the-loop」設計の構造的欠陥と、それを悪用した攻撃概念「GhostApproval」について詳しく論じた内容だ。

「承認した」はずなのに、別のコードが動いていた

AIコーディングエージェントの普及に伴い、その設計そのものを標的にした攻撃が明らかになってきた。今回焦点が当たっているのが「GhostApproval」だ。これはセキュリティ研究者が命名した攻撃概念であり、AIエージェントの表示と実行の乖離を悪用する手法を指す。

MCP（Model Context Protocol）をはじめとするエージェント型ツールの台頭により、AIはコードを生成するだけでなく、ファイルの読み書き・コマンド実行・外部サービス呼び出しといった実環境への操作を自律的に行えるようになっている。GitHub CopilotやCursor、Claude Codeといったツールがその代表例だ。こうしたエージェント型ツールが開発現場に急速に浸透している一方、その信頼モデルの検証は十分に追いついていない。

GhostApprovalが突く問題の核心は、AIエージェントがユーザーに対して自身の行動を正確に提示できていないという設計上の欠陥にある。ユーザーが「承認」したと思っているコードと、エージェントが実際に実行するコードが一致しない状況が発生しうる。いわば「見せているものと動かしているものが違う」状態だ。

セキュリティ研究者のNorton氏（CSO Onlineの記事中で同問題を指摘した研究者）はこの問題について次のように述べている。

「この脆弱性はコードの品質や安全でない出力とは無関係だ。エージェントがファイルを扱う方法と、自身の行動をユーザーに提示する方法における欠陥であり、不正なプロンプトや侵害された依存関係ではなく、ツールの設計によって生じている。コーディングツール自身の攻撃対象領域を考慮していないことが、こうした穴を放置する原因だ。」

つまり、問題はAIが生成するコードの中身ではなく、ツール自体のアーキテクチャにある。

「human-in-the-loop」という建前が崩れる

AIエージェントによる自律的なコード生成・実行においては、「人間が最終確認する」（human-in-the-loop）という仕組みが安全装置として機能することが前提とされている。しかしGhostApprovalはまさにその安全装置を無効化する。

ユーザーが画面上で確認・承認したと思っている内容と、エージェントが実際にファイルシステムに書き込んだり実行したりする内容が乖離する。承認というUIの操作が、実質的なセキュリティ制御として機能しないということになる。

エージェント型AIツールの普及は目覚ましく、2025年に入ってからはVS Code拡張・CLI型エージェント・IDE統合型など多様な形態でコーディング支援ツールが市場に投入されている。human-in-the-loopはこれらすべてにおいて「人間による監督」の根拠とされてきたが、GhostApprovalはその前提そのものを問い直す。

Amazon、Anthropic、Google、Cursorも例外ではない

Norton氏によれば、この種の問題はひとつのベンダーに限った話ではない。

「2025年3月以降、セキュリティベンダーや研究者は、ほぼすべての主要なAIコーディングアシスタントにおいて同様の問題を開示してきた。緩和策がリリースされると、数ヶ月以内にその緩和策を回避する手法が現れる、というパターンが続いている。このカテゴリの脅威モデルが業界全体としていかに新しいかを示している。」

Amazon、Anthropic、Google、Cursorといった主要プレーヤーが提供するAIコーディングツールで、類似の脆弱性が次々と報告されている状況だ。緩和策を出しても数ヶ月で迂回されるというサイクルが繰り返されている点は、単発のバグ修正では対処しきれない構造的な問題を示唆している。

ソフトウェアサプライチェーンとしてのリスク

Norton氏が強調するもうひとつの論点は、AIコーディングツール自体がソフトウェアサプライチェーンの一部を構成しているという視点だ。

従来のソフトウェアサプライチェーン攻撃といえば、依存ライブラリへの不正なコード混入（npmやPyPIへの悪意あるパッケージ公開など）が典型例だった。しかしAIコーディングエージェントはコードを生成・操作するツールそのものであり、そのツール自体が攻撃対象になりうる。

「エージェント型コーディングツールには多層防御が必要だ。リスクはエージェントが生成するコードだけに限らない。ツール自体がソフトウェアサプライチェーンの中に位置しており、直接攻撃される可能性がある。GhostApprovalはその点を明確に示している。」

エンジニアへの実務的示唆

この問題から読み取れる実務上のポイントは明確だ。

• AIエージェントの「承認UI」を過信しない。ユーザーに見えている情報が完全な真実とは限らない
• AIコーディングツール自体の更新・パッチ適用を怠らない。生成コードのレビューだけでなく、ツール本体のセキュリティ状態にも目を向ける必要がある
• 多層防御の設計を検討する。エージェントが実行する操作をサンドボックス化する、ファイル操作のログを独立して記録するなど、エージェントの自己申告に頼らない仕組みを取り入れることが望ましい（※編集部の考察。元記事ではNorton氏が「多層防御」の必要性を言及しているが、具体的な実装手段の列挙は編集部による補足）

Norton氏の言葉を借りれば、「コーディングツール自身の攻撃対象領域の考慮が抜けている」ことが根本原因だ。AIエージェントを導入している開発組織は、ツールが生成するコードと同様に、ツールそのものをセキュリティレビューの対象に含める必要がある。

詳細はAI coding tool hole illustrates a big problem with human in the loopを参照していただきたい。