GhostApprovalが示す、AIコーディングエージェントの承認画面の死角
AIコーディングエージェントの承認画面は、本当に実行される操作を正確に示しているでしょうか。「GhostApproval」という調査結果を手がかりに、承認が安全策として機能する条件を考えます。
AIコーディングエージェントでは、ファイルの編集やコマンドの実行前に、人へ確認を求める仕組みが安全策として使われています。
エージェントが一度処理を止め、実行する操作を示し、人が許可または拒否する。
ただし、確認画面が存在するだけで、その承認が有効に機能するとは限りません。
2026年7月8日、Wiz Researchは、6つのAIコーディングツールで確認した一連の脆弱性パターンを「GhostApproval」として公表しました。
悪意あるリポジトリ内のシンボリックリンクを通じて、エージェントがワークスペース外のファイルへアクセスできるという問題です。
製品によって現れ方は異なり、確認画面に実際とは異なるパスが表示されるものだけでなく、承認前に書き込みが行われるものや、確認自体が表示されないものもありました。
この調査が示したのは、Human-in-the-Loopが安全策として機能するためには、単に人を工程へ加えるだけでなく、操作が承認前に停止し、判断に必要な情報が正しく示される必要があるという点です。
GhostApprovalが示すもの — シンボリックリンク追従と、一部で重なった承認UIの問題
Wiz Researchが「GhostApproval」と名付けたのは、悪意あるリポジトリ内のシンボリックリンクを通じて、AIコーディングアシスタントがワークスペース外のファイルを読み書きできる一連の脆弱性パターンです。
基礎にあるのは、リンク先を十分に検証せずに辿るシンボリックリンク追従の問題です。
project_settings.json のような無害そうな名前のファイルの実体を、シンボリックリンクで ~/.ssh/authorized_keys のような機微なファイルに向けておく。
開発者が「このリポジトリのワークスペースをセットアップして」とエージェントに指示すると、エージェントはリンクを辿ってその機微なファイルに書き込んでしまいます。
Wiz Researchはこれを、既知の脆弱性分類（CWE-61）そのものだと説明しています。
その現れ方は製品によって異なりました。
一部では、ユーザーが承認する前に書き込みが行われました。
別の製品では確認画面自体が表示されませんでした。
また複数の製品では、確認画面にシンボリックリンクの表面上のパスだけが表示され、実際のリンク先が示されませんでした。
この最後のケースについて、Wiz Researchは、UIでの重要情報の誤表示（CWE-451）が、シンボリックリンクの脆弱性の上に重なっている状態だと整理しています。
なお、このUI側の問題が確認されたのは検証対象のうち複数の製品であり、6製品すべてが同じ二層構造だったわけではありません。
Wiz Researchが示したClaude Codeでの検証例は、この構造を分かりやすく表しています。
エージェント側の処理では、リンク先が実際にはzsh設定ファイルであることが認識されていた一方、承認者に提示された確認画面には、その情報が反映されず「project_settings.jsonへのこの編集を行いますか？」という一文だけが示されました。
承認者は、実際の書き込み先を知らないまま判断を求められていたことになります。
Wiz Researchは、意味のある同意（informed consent）はダイアログが正確な情報を示していて初めて成り立つ、と指摘しています。
6ツールに共通した設計課題、対応は割れた
Wiz Researchが検証対象としたのは、Amazon Q Developer・Anthropic Claude Code・Augment・Cursor・Google Antigravity・Windsurfの6ツールです。
単一製品の実装ミスではなく、複数の独立したベンダーが同じ種類の設計上の死角を抱えていたという点が、この調査の重みだと私たちは受け止めています。
2026年7月8日のWiz Research公表時点の対応状況と、8月11日時点で参照できた公開情報を並べると、次のとおりです。
ベンダー公式資料が公開されているものはそれを、無いものはWiz Researchの記述として帰属を残しています。
| ベンダー／製品 | 深刻度（Wiz評価） | Wiz公表時点（7月8日）の状況 | 8月11日時点で参照した公開情報 |
|---|---|---|---|
| AWS／Amazon Q Developer | High | 修正済み。言語サーバー1.69.0で対応（CVE-2026-12958） | AWS公式のセキュリティ情報でも、シンボリックリンク検証の不足は1.69.0未満が対象で1.69.0で修正されたと記載 |
| Google／Antigravity | Critical | 修正済み。Wizの開示タイムラインには、2026年5月22日にGoogleが修正を配布したと記載 | ただしWizの記事では、修正済みバージョンの番号が明確に特定できる形では示されていない。1.19.6という番号は影響を確認したバージョンとして記載。CVEは公表時点で未採番（Pending） |
| Cursor | Critical | 3.0で修正（CVE-2026-50549） | Cursor公式のアドバイザリでも3.0未満を対象としていることを確認 |
| Augment | Critical | 報告を認知。検証時点では確認画面が表示されず、書き込みが無警告で行われていた。公表時点まで続報なし | 2026年7月30日公開のAuggie CLI 0.34.0で、機微なパスへの保存に承認を求める機能を追加。ただしリリースノートはGhostApprovalにもシンボリックリンクにも言及しておらず、Wizが検証した経路の修正までは示していない |
| Windsurf（現Devin Desktop） | Critical | Wiz公表時点では報告受領のみ、続報なし | Windsurfは2026年6月にDevin Desktopへ名称変更。2026年8月1日公開のDevin Local 3.6.27で、編集・書き込み系のツールがシンボリックリンク経由の書き込みを拒否する変更が公式変更履歴に記載 |
| Anthropic／Claude Code | Disputed | 当初は脅威モデル外として却下 | 経緯は次段落。Wizによれば、2.1.32で警告機能が報告前に導入済み、2.1.173以降ではリンクを解決したうえで機微なファイルへの書き込み前に警告 |
Anthropicのケースは単純な「却下→放置」ではありません。
Wiz Researchの報告に対してAnthropicは、「ユーザーはディレクトリでClaude Codeを起動する際にそのディレクトリを信頼するかどうか確認しており、その上で編集の確認プロンプトにも明示的に同意している以上、この状況は自社の脅威モデルの範囲外だ」という趣旨の説明とともに、当初は却下として回答したとWiz Researchは記しています。
一方で記事の更新情報によれば、確認ダイアログにシンボリックリンク警告を出す機能自体はバージョン2.1.32で、この報告が提出される9日前にすでに出荷されていたとされています。
そのうえで、Wiz Research公表時点の最新版（バージョン2.1.173以降）ではシンボリックリンクを解決したうえで機微なファイルへの書き込み前に警告する挙動になっている、ともWiz Researchは記しています。
この経緯が示しているのは、ベンダーがある挙動を「脆弱性」として受理するかどうかと、製品をより防御的に強化するかどうかは、必ずしも同じ判断ではないということです。
また、どこまでを製品側が防ぎ、どこからを「信頼したワークスペースを開いた利用者の責任」とするかについて、ベンダー間で脅威モデルの捉え方が異なることも分かります。
なお、上記の対応状況はWiz Researchの記事および各社公式のセキュリティ情報・変更履歴に基づくものです。
各ツールのバージョンや挙動はその後も更新され続けるため、自社が使っているツールの現在の状態は、導入判断の際に個別に確認することをおすすめします。
承認が安全策として機能するための条件
私たちがこの調査から受け取った論点は一つです。
人を承認フローに挟むこと自体は、安全を自動的に保証しません。
一部の製品では、承認者が実際の対象を知らないまま許可を求められました。
別の製品では、承認画面が出る前に処理が行われたり、確認自体が表示されなかったりしました。
形式は異なりますが、共通しているのは、人の判断を安全境界として使う設計と、実際の処理との間にずれがあったことです。
これは私たちが日頃、AI導入の設計を考えるときに置いている前提とも重なります。
「人を挟めば安全」は必ずしも成り立ちません。
人が工程に含まれていても、実際の対象や影響が示されないまま許可を求められるのであれば、その承認は有効な安全策として機能しません。
問題は承認者が慎重でなかったことだけではなく、慎重に判断するために必要な情報が、確認画面へ渡されていなかったことです。
承認という工程を置くこと自体を目的化せず、その承認が実際に何を根拠に下されているかまで設計する必要がある、というのが私たちの考え方です。
この原則は、ファイル操作に限りません。
私たちの制作工程でも、人が成果物を確認する際には、生成結果だけでなく、参照元・変更箇所・未確認事項が分かる状態を作るようにしています。
ただし、記事の確認とファイルシステム上のセキュリティ境界とでは、必要な統制の水準が大きく異なります。
共通するのは、承認者へ「判断に必要な情報」を渡さなければ、人を工程に加えただけでは有効な確認にならないという点です。
実務上の留意点：承認画面・実際の操作・実行時点を一致させる
AIコーディングエージェントの導入を検討・運用している開発責任者にとって、実務上意識しておきたい点がいくつかあります。
まず、対応状況はツールごと・バージョンごとに異なるという点です。
上表はあくまで一時点の情報であり、修正済みとされているツールでも、実際に自社が使っているバージョンが対象に含まれているかは別途確認が必要です。
次に、承認ステップを増やせば安全になる、という単純な足し算では考えないことです。
承認の回数を増やしても、表示される情報自体が不正確なままであれば、確認の負担が増えるだけで実効性は上がりません。
ここで重要なのは工程の数ではなく、各工程で承認者が見ている情報が実体と一致しているかどうかです。
Wiz Researchも対策として、確認画面を表示する前にシンボリックリンクを解決すること、ワークスペース外なら明示的に警告すること、明示的な承認より前にディスクへ書き込まないことを挙げています。
これを踏まえると、人の承認が実質的な安全策として機能するには、少なくとも次の3条件が要ります。
- 承認前に処理が停止しているか：Accept／RejectやUndoが表示されても、表示前にファイルが書き換えられていれば、その画面は認可ゲートとして機能していません。
- 実際の対象が表示されているか：シンボリックリンクの表面上の名前ではなく、解決後の実体パスと、ワークスペース外かどうかが分かる必要があります。
- 拒否時に副作用が残らないか：拒否を選んだ場合、ファイルの変更や読み出しがまだ起きておらず、実行履歴にも実際の対象が記録される必要があります。
最後に、ワークスペース外への書き込みや機微なパスへのアクセスを伴う操作については、ツール側の警告設計に頼り切らず、リポジトリの取り扱いルール（外部から取り込んだコードは隔離した環境で先に確認する等）を社内側でも用意しておくと、単一の防御層に依存しない構成になります。
持ち帰れる具体：自社の承認フローを点検する3つの問い
自社が使っているAIコーディングエージェントについて、次の3点を確認しておくと、GhostApprovalのような死角の有無を判断する手がかりになります。
- 確認画面には、シンボリックリンクを解決した後の実際の書き込み先が表示されるか。表面上のファイル名だけでなく、ワークスペース外や機微なパスへのアクセスであることを判断できるか
- ワークスペース外または機微なファイルへの操作は、通常の編集とは区別して警告・拒否されるか。単なる「ファイルを編集します」という表示に埋もれていないか
- 読み書きは承認後に初めて実行され、拒否した場合に副作用が残らないか。実行履歴には、表示上のパスではなく実際にアクセスした対象と実行結果が残るか
このうち、確認画面でシンボリックリンクを解決すること、ワークスペース外を明示的に警告すること、明示的な承認より前に書き込まないことは、Wiz Researchの提言に沿った内容です。
一方、実行履歴に実際の対象を残すという点は、同じ原則を運用面へ広げた私たちの追加であり、Wiz Researchのガイダンスに含まれるものではありません。
これは正しい設定を示す規範ではなく、あくまで点検の出発点となる叩き台です。
実際にどこまで確認するか、どの程度の頻度で見直すかは、扱うコードの機微度や社内のセキュリティ体制によって会社ごとに異なります。
まずは、利用中のバージョンとベンダーのセキュリティ情報を確認することが最初の一歩になります。
製品の挙動を独自に検証する必要がある場合は、実環境の機微なファイルを対象にせず、セキュリティ担当者の管理下で、隔離した環境とダミーの対象を使って確認することが前提です。
まとめ
GhostApprovalが示したのは、特定の一社だけの実装ミスではなく、AIコーディングアシスタントの承認設計に共通し得る信頼境界の問題でした。
ただし、6製品で問題の現れ方は同じではありませんでした。
一部では、確認画面にシンボリックリンクの表面上のパスだけが表示されました。
別の製品では、承認より前に書き込みが行われたり、確認画面自体が表示されなかったりしました。
ここから得られる教訓は、「人を挟めば安全」という考え方が常に誤りだということではありません。
人の承認を安全境界として使うなら、少なくとも次の条件が必要だということです。
実行前に処理が停止する。
実際の操作対象と影響が表示される。
ワークスペース外や機微な対象は明確に区別される。
拒否した場合、変更や読み出しが発生しない。
実行履歴が実際の対象と一致する。
確認すべきなのは、承認画面が存在するかどうかだけではありません。
その画面が実際の操作を止める認可ゲートになっているか、承認者が判断するための情報を正確に示しているか、許可後の実行結果と一致しているかです。
Human-in-the-Loopは、単に人を工程へ加える設計ではありません。
人が意味のある判断を下せる情報と権限を持つようにする設計です。
私たちは、AIエージェントの自律性やファイル操作権限が広がるほど、ユーザー・エージェント・ファイルシステムのあいだにある信頼境界を、より明確にする必要があると考えています。
情報確認について
本記事は、Wiz Researchが2026年7月8日に公表した「GhostApproval: A Trust Boundary Gap in AI Coding Assistants」を主要な参照元として、2026年8月上旬時点の情報をもとに作成しています。
Amazon Q Developerについては、AWS公式のセキュリティ情報（言語サーバーの脆弱性、2026年6月23日付）も確認しています。
本稿で扱うGhostApprovalのシンボリックリンク検証の問題は CVE-2026-12958 です。
同じセキュリティ情報には CVE-2026-12957 も併記されていますが、こちらはプロジェクト設定ファイルを経由するコマンド自動実行という別の信頼境界の問題であり、本稿の対象ではありません。
Cursorについては、CVE-2026-50549に関する公式のセキュリティアドバイザリも確認しています。
Google Antigravityについて、Wiz Researchの開示タイムラインには、2026年5月22日にGoogleが修正を配布したと記載されています。
ただし記事中で修正版として明確に特定できるバージョン番号までは示されておらず、1.19.6という番号は影響を確認したバージョンとして記載されています。
CVEは公表時点で未採番（Pending）です。
Augmentについては、検証時点で書き込みがシンボリックリンクを黙って辿り、Allow/Denyのダイアログも取り消しの操作も示されなかったとWiz Researchは記しています。
Wiz Research公表後の2026年7月30日に、機微なパスへの保存時に承認を求める機能が追加されていますが、公開情報だけではGhostApprovalで指摘されたすべての経路が修正されたかまでは確認できません。
Windsurfは現在Devin Desktopの名称で提供されています。
2026年8月1日公開のDevin Local 3.6.27の公式変更履歴では、編集・書き込み系のツールがシンボリックリンク経由の書き込みを拒否するようになったことを確認しています。
Anthropicについては、Wiz Researchによると、報告は当初脅威モデル外として処理されましたが、シンボリックリンク警告は報告前から導入されており、その後のバージョンではリンク先を解決して機微なファイルへの書き込み前に警告する挙動になっています。
本稿はMIFが各製品を独自に侵入試験した結果ではありません。
脆弱性の再現性、実際の攻撃事例、利用環境ごとの影響を独自に検証したものでもありません。
深刻度とWiz公表時点の対応状況はWiz Researchの評価に基づくものであり、現在の製品挙動や利用可能な修正版は今後も変更される可能性があります。
導入・継続利用の判断時には、各ベンダーの最新のセキュリティ情報をご確認ください。