AIに「このコマンドを実行して」と言われたとき——承認を二重化する防御

1. 攻撃者が狙うのは、コードではなく承認である

AIコーディングツールでアプリを作っている最中にエラーが出る。

AIがこう提案する。

「問題を解決するため、次のコマンドを実行してください」

開発者は作業を先へ進めたい。提示されたコマンドをコピーし、ターミナルへ貼り付け、Enterキーを押す。

これは、AIを使った開発では日常的な光景だ。

しかし、この流れは攻撃の構造とも一致する。

偽のエラー画面を表示し、「問題を修復するために、このコマンドを実行してください」と利用者を誘導するClickFix型攻撃では、攻撃者自身が端末上でコードを実行する必要はない。

正規ユーザーに実行させればよい。

AIコーディング環境には、この攻撃を成立させる条件が最初から揃っている。

• AIという、もっともらしい指示元
• エラーを早く解決したいという焦り
• 開発作業を中断したくないという心理
• コマンドを実行できる正規ユーザーの権限
• AIの提案を日常的に承認する操作習慣

悪意あるコマンドが実行されても、OSから見れば正規ユーザーによる正規の操作である。

脆弱性の悪用も、権限昇格も必要ない。

破られているのはソフトウェアではない。

人間の承認プロセスである。

ここから導かれる結論は明確だ。

人間の注意力を最後の防御線にしてはいけない。

ただし、これは「人間を防御から外す」という意味ではない。

一人の人間の判断だけで処理が完結する構造をやめ、異なる責任を持つ人間をもう一層加えるべきだ、という意味である。

2. 開発者本人の承認だけでは、防御にならない

多くのAIコーディングツールは、危険性のある操作の前に利用者へ確認を求める。

「このコマンドを実行しますか」

「このファイルを変更しますか」

「このパッケージをインストールしますか」

一見すると、人間が最終判断をしているように見える。

しかし、同じ利用者が、AIから説明を受け、AIの提案を評価し、AIが生成したコマンドを承認するのであれば、実質的には単一の判断系である。

しかも利用者は、その操作を何十回、何百回と繰り返す。

最初はコマンドを注意深く読む。

やがて確認画面を流し読みする。

最後には、作業を進めるためのボタンとして承認する。

これは利用者の怠慢ではない。

承認を大量に要求する設計が生み出す、予測可能な結果である。

さらに、開発者本人には利害の偏りがある。

開発者の目的は、作業を止めることではない。エラーを解決し、ビルドを通し、機能を完成させることだ。

そのため、判断に迷ったときは「実行しない」よりも「実行して先へ進む」方向へ傾きやすい。

つまり、開発者本人による承認は必要だが、それだけでは独立した防御層にならない。

AIの提案を受けた当事者が、そのまま最終承認者でもあるからだ。

3. 必要なのは、人間を減らすことではなく二重化すること

危険なインストールや拡張機能の導入を、開発者本人の判断だけで完結させない。

ここで必要になるのが、Device Protectionによる承認の分離である。

AikidoのDevice Protectionは、開発端末上で行われるインストールを監視し、危険性のあるソフトウェアや開発者向けコンポーネントを検知する。

対象は、従来のnpmやPyPIのパッケージだけではない。

• パッケージレジストリ（npm、PyPI、Maven、NuGetなど）
• IDE拡張機能
• ブラウザ拡張機能
• AIツール・AIモデル
• MCPサーバー
• AIスキル

重要なのは、検知だけではない。

検知した操作について、ポリシー設定により、開発者本人とは別に管理者の承認を要求するフローを構成できることである。

ここでは人間の層が二重になる。

第一の人間は開発者だ。

なぜそのパッケージや拡張機能が必要なのかを理解し、業務上の必要性を判断する。

第二の人間は管理者だ。

そのインストールが組織のセキュリティポリシーに適合するか、既知の危険性がないか、許可すべき例外かを判断する。

この二人は、同じものを見ていても役割が違う。

開発者は「作業に必要か」を見る。

管理者は「組織として許可できるか」を見る。

この役割分離が重要である。

単に確認画面を一枚追加するのではない。

同じ操作を、異なる責任と異なる視点を持つ二人が承認する。

これによって、AIのもっともらしい説明に開発者が納得してしまった場合でも、管理者側で止められる可能性が生まれる。

一人の理性が突破されても、もう一人の理性が残る。

これが、人間の防御層を二重化するということである。

4. 承認には、判断材料と履歴が必要である

承認者を二人に増やすだけでは不十分だ。

管理者に「許可しますか」とだけ表示しても、適切な判断はできない。

承認には文脈が必要である。

たとえば次のような情報だ。

• 誰がインストールを要求したか
• どの端末から要求されたか
• 何をインストールしようとしたか
• どのパッケージマネージャやツールが使われたか
• どのバージョンか
• どこから取得されるか
• 初回公開からどれだけ経過しているか
• 既知のマルウェア判定があるか
• 組織内で過去に許可された実績があるか
• なぜ業務上必要なのか

さらに重要なのが、履歴である。

• 誰が要求したか
• 誰が承認または拒否したか
• いつ判断したか
• どの端末で実行されたか
• どのバージョンが対象だったか
• 判断時にどのようなリスク情報が存在したか

これらが記録されていれば、承認は単なるボタン操作ではなく、説明可能なセキュリティ判断になる。

後から悪性パッケージだったと判明した場合も、影響範囲を追跡できる。

どの端末に入ったのか。

誰が申請したのか。

誰が承認したのか。

同じソフトウェアが他の端末にも存在するのか。

いつから利用されていたのか。

履歴がなければ、インシデント発生後に一台ずつ調査するしかない。

履歴があれば、承認時点の情報から対象を絞り込める。

防御におけるログの価値は、「誰かを責めるため」ではない。

過去の判断を再現し、被害範囲を特定し、次の判断を改善するためにある。

5. AIレビューだけでは、人間の承認を守れない

コマンドを別のAIにレビューさせる方法も考えられる。

危険なシェルコマンド、外部通信、ファイル削除、認証情報へのアクセスなどを、実行前にAIが評価する。

これは有効な補助層ではある。

しかし、境界にはならない。

レビューするAIも、コマンドを生成したAIと同じように、与えられた文脈に影響される。

悪性コマンドであっても、もっともらしい目的や説明が添えられていれば、安全な処理だと評価する可能性がある。

モデルを変える。

複数モデルで多数決を取る。

ルールベース判定を併用する。

いずれも検知率を上げることはできるが、完全な遮断にはならない。

AIによるレビューは、確率的な防御である。

一方で、管理者の承認がなければインストールできないという仕組みは、ポリシーとして強制できる。

ここに性質の違いがある。

AIレビューは「危険かもしれない」と判断する。

Device Protectionは「許可されていないため実行できない」という境界を作る。

レビューと強制は別物である。

6. パッケージスキャンにも時間差がある

SCAは、既知の脆弱性や悪性パッケージの検知に有効である。

しかし、悪性パッケージが公開された瞬間から、すべてのセキュリティ製品が検知できるわけではない。

公開される。

誰かが異常に気づく。

調査される。

悪性と判定される。

データベースへ反映される。

利用者側の製品が情報を取得する。

この間には必ず時間差がある。

そのため、既知の悪性判定だけに依存すると、公開直後の時間窓が残る。

ここで有効なのが、最低パッケージ年齢である。

たとえば、公開から48時間を経過していないパッケージは、原則としてインストールを保留する。

これは「悪性かどうか」を予測する仕組みではない。

公開から一定時間が経っていないという客観的条件によって、機械的に止める仕組みである。

新規公開されたパッケージがすべて危険なわけではない。

しかし、攻撃者が公開した直後の悪性パッケージを、セキュリティ側の判定が追いつく前に導入してしまうリスクを減らせる。

ただし、ここでも業務上の例外は発生する。

新しく公開された正当な社内パッケージ。

緊急修正版。

開発チームが今すぐ必要とする新規依存関係。

そこで必要になるのが管理者承認である。

機械的なルールで止める。

業務上必要なら、理由を添えて申請する。

別の責任者が判断する。

判断結果を履歴として残す。

技術的な検知と、人間による例外管理を組み合わせることで、厳格さと業務継続を両立できる。

7. シェル統合型の防御と、デバイスレベルの防御

パッケージマネージャのコマンド実行に組み込まれ、悪性パッケージのダウンロードを遮断する方法もある。

Aikido Safe Chainのように、npmやpipの実行時にパッケージを検証し、問題があればインストールを止めるCLIラッパーである。

開発者の通常操作をほとんど変えずに導入でき、最低パッケージ年齢の適用まで含めて、有効な第一防御層になる。

ただし、シェル統合に依存する防御だけでは、AIエージェントや非対話プロセスを含むすべての実行経路を、組織として統制することは難しい。

個々の開発者が自主的に導入する構成では、設定漏れや無効化も起きうる。

そこで、個々のシェル設定ではなく、MDMを通じてデバイスへ強制配備し、パッケージや拡張機能の取得経路を端末側で監視・制御するDevice Protectionが、別の防御層になる。

防御の単位を「コマンド」から「デバイス」へ引き上げるのである。

CLIラッパーとデバイスレベルの保護は、対立するものではない。

前者は開発者個人がすぐに導入できる層、後者は組織がポリシーとして強制する層であり、重ねて使える。

8. EDRだけでは、開発者端末の変化を理解できない

EDRは、プロセス実行、ファイル変更、外部通信、不審な挙動などを監視する。

マルウェアの実行段階では重要な防御層である。

しかし、EDRが「npm install」という文字列を見たからといって、その依存パッケージが組織で許可されたものか、新規公開されたものか、typosquattingの疑いがあるかまで理解するとは限らない。

同様にMDMは、端末へソフトウェアを配布し、設定を強制することはできる。

しかし、導入されたMCPサーバーが何を実行できるのか、IDE拡張がどのリポジトリへアクセスするのか、AIツールがどの外部サービスへデータを送るのかまでは理解できない。

つまり、従来の端末管理と開発者エコシステムの間に空白がある。

• EDRは実行後の挙動を見る
• MDMは端末の構成を見る
• SCAはリポジトリの依存関係を見る
• Device Protectionは、開発端末へ新たに持ち込まれるツールや拡張機能を見る

これらは競合するものではない。

見ている段階が違う。

特にAI時代には、MCPサーバーやAI向け拡張機能のように、従来のソフトウェア資産管理では十分に把握されていない新しい実行主体が増えている。

ここを監視し、承認し、履歴化する層が必要になる。

9. 「unknown」をゼロにして、異物を見えるようにする

SBOMはマルウェア検知ツールではない。

ソフトウェアを構成する部品のインベントリである。

しかし、運用次第では異常検知の基盤になる。

注目すべきなのが「unknown」である。

SBOMやライセンスレポートには、正体を十分に特定できない依存関係や、既知のレジストリ情報と照合できない成果物がunknownとして表示されることがある。

unknownには複数の種類が含まれる。

• 正当な社内プライベートパッケージ
• パッケージ側のメタデータ不備
• ツール側のデータ不足
• 手動で持ち込まれた成果物
• レジストリ上の既知の成果物と一致しないソフトウェア
• 正規パッケージ名に似せた偽パッケージ
• AIが生成した架空のパッケージ名
• 正規名を騙る改変物

したがって、unknownだから悪性ということではない。

しかし、unknownは「組織が正体を説明できていない」という意味では異常である。

問題は、unknownが常に大量に存在する環境だ。

本当に危険な異物が混入しても、既存のノイズに埋もれてしまう。

そこで、平時にunknownをすべてトリアージする。

正当なものはallowlistへ登録する。

不要なものは削除する。

照合できない理由を解消する。

そして、unknownゼロを通常状態として維持する。

ゼロの環境で新しいunknownが一つ発生すれば、それ自体が調査対象になる。

これは高度なAI検知ではない。

ベースライン管理である。

Device Protectionの承認履歴とSBOMを組み合わせれば、さらに追跡しやすくなる。

リポジトリに存在する部品だけでなく、誰がどの端末へ何を導入し、誰がそれを承認したのかまで関連付けられるからだ。

10. 多層防御では、人間も一つの層として設計する

この攻撃に対する防御を整理すると、次のようになる。

重要なのは、「人間か自動化か」という二者択一ではない。

人間の判断が必要な場所を絞り、その判断を一人に集中させず、役割を分離することである。

AIレビューは大量の操作を高速に評価できる。

最低パッケージ年齢は、新規公開直後の成果物を機械的に止められる。

Device Protectionは端末上の導入を検知し、ポリシーを強制できる。

開発者は業務上の必要性を説明する。

管理者は組織リスクを判断する。

履歴は、判断の根拠と結果を残す。

それぞれが別の役割を持つ。

11. 認証情報とAIエージェントの権限も分離する

インストールを止められなかった場合に備え、侵害後の被害を小さくする設計も必要だ。

第一に、開発端末へ本番の長命クレデンシャルを置かない。

端末に存在しなければ盗めない。

短命トークン、ワークロードID、シークレットマネージャを利用し、開発者のローカル環境へ恒久的な認証情報を保存しない構成へ移行するべきである。

第二に、AIエージェントへ人間と同じ権限を与えない。

AIが人間のセッションや認証情報をそのまま使うと、監査上も人間の操作とAIの操作を区別できなくなる。

エージェントには専用のアイデンティティを与える。

権限は人間より狭くする。

操作対象を限定する。

すべてのAPI呼び出しに、テナント、ユーザー、エージェントの識別情報を残す。

これによって、誰の指示で、どのエージェントが、どの操作をしたかを追跡できる。

承認履歴と実行履歴がつながって初めて、責任分界が成立する。

12. 結論 — 人間の理性を、一人に背負わせない

AIコーディング環境では、確認画面が表示されるから安全なのではない。

人間が承認しているから安全なのでもない。

攻撃者は、その人間が承認するところまで含めて攻撃を設計する。

AIがもっともらしい理由を説明する。

開発者は作業を進めたい。

表示されたコマンドは、技術的には正しく見える。

承認ボタンは、毎日何度も押している。

この条件で「本人が注意すれば防げる」と考えるのは、設計責任を利用者へ転嫁しているだけだ。

必要なのは、人間を防御から外すことではない。

人間の層を二重にすることだ。

開発者本人が必要性を判断する。

管理者が組織としての安全性を判断する。

システムが危険性を検知し、未承認の操作を止める。

承認と拒否の履歴を残す。

後から、誰が、何を、なぜ許可したのかを追跡できるようにする。

一人の人間の注意力に依存するのではなく、役割分離、技術的強制、監査履歴を組み合わせる。

確率的なAIレビューで入口を見つつ、Device Protectionでインストールを制御し、管理者承認で例外を管理する。

さらにEDR、最小権限、短命トークン、egress制御によって、仮に突破されても被害が成立しにくい構造を作る。

完璧な製品は存在しない。

完璧な人間も存在しない。

だからこそ、一人の理性を最後の砦にしてはいけない。

人間の理性が攻撃対象になる時代には、人間の判断そのものを多層化し、その履歴を防御資産として残す必要がある。

---

なお、Device Protectionが扱うエコシステムや承認・監査機能は現在も拡張されている。unknownの判定条件や実行経路ごとの捕捉範囲など、追加確認できた内容は続編で報告する。