GhostJackingがAIエージェントのアイデンティティガバナンスの欠陥を露呈

研究者が、1件の毒入りエラー報告だけで、認可済みのAIエージェントを攻撃者支配下のコードへ誘導できることを示した後、Google NewsはGhostJackingを取り上げた。この攻撃は、エージェントが各手順を正規のツールと開発者権限を通じて実行するため、境界防御をすり抜けて成功する。

この違いは、セキュリティを巡る議論を変える。エージェントの認証情報が必ずしも盗まれているわけではなく、ソフトウェア自体が侵害されているとも限らない。代わりに、認証済みのアイデンティティが有効なまま、信頼できない運用データがエージェントの意図を変えてしまう。

基礎となる研究では、この広範な手法を「Agentjacking」と呼んでいる。一方、GhostJackingという名称は、乗っ取りがほとんど目に見えない性質を強調する。エージェントは通常のアイデンティティのまま動作を続けるため、防御側は正当な自動化と敵対的な意図を見分けなければならない。

これは単なる別のプロンプトインジェクションの話ではない。言語モデル、信頼されたテレメトリー、Model Context Protocol統合、そして予測可能なユーザー向けに設計されたアイデンティティシステムが衝突していることを示している。

中心的な対立は明確だ。企業は、エージェントに常時の監督なしでインシデント調査や修復作業を実行させたい。しかし、エージェントを有用にする権限は同時に、操作された判断を運用上危険なものにする。

GhostJackingの報告はバグキューを攻撃経路へ変える

GhostJackingは、エージェントが信頼することを期待される情報を、エージェントが実行しかねない指示へと変換する。

GhostJacking reportで説明された攻撃は、偽のソフトウェアエラーから始まる。攻撃者は、未解決の問題を調査する際にコーディングエージェントが後から取得するテレメトリー内に、細工したテキストを埋め込む。

テレメトリーとは、ソフトウェアによって生成されるログ、エラー、トレース、診断記録を指す。開発チームは通常、この種の情報を能動的なコマンドチャネルではなく、システムの挙動に関する証拠として扱う。

言語モデルがこの情報を読むと、その前提は崩れる。モデルは診断上の事実、コメント、書式、そして潜在的な指示を、同一のテキストストリーム内で受け取る。

Tenet SecurityのThreat Labsは、アプリケーションイベントを受け付けるエラー監視プラットフォームSentryを使って、このパターンを実証した。Sentryは、アプリケーションが正しいプロジェクトにイベントを送信できるよう、Data Source Name、すなわちDSNを使用する。

ブラウザアプリケーションでは、そのDSNがクライアントサイドのコードに必要になることが多い。そのため、DSNを保有していれば、組織の内部ネットワークを最初に侵害せずとも、イベントを送信できる場合がある。

攻撃者のイベントには、もっともらしいエラー説明と、見かけ上の修復ガイダンスが含まれる。エージェントが統合機能を介してこのイベントを取得すると、悪意ある指示は正当な診断データとともに届く。

モデルは次に、分類上の問題に直面する。そのテキストがエラーを説明しているのか、外部関係者の発言を引用しているのか、それともエージェントに修正行動を指示しているのかを判断しなければならない。

controlled researchによると、テストされたエージェントは、埋め込まれた情報を有効な解決手順として解釈することがあった。そして、開発者のローカル権限で研究者管理下のパッケージを実行した。

Tenetによれば、その検証用パッケージは有害な活動ではなく、管理されたテスト用に設計されたものだという。同社はまた、収集した情報はマスキングされ、同社の開示プロセスに基づいて取り扱われたとしている。

それでも、セキュリティ上の影響は無害なパッケージにとどまらない。開発者アカウントで実行される敵対的なコマンドは、環境変数、ソースリポジトリ、クラウド認証情報、または認証済みの開発ツールに到達する可能性がある。

Tenetは、注入可能な可能性のあるSentry認証情報を持つ組織を2,388件特定したと報告した。また、管理されたテスト中に、100を超えるエージェントが注入されたエラーに基づいて動作するのを観測したとしている。

これらの数値はセキュリティベンダーによるものであり、報告対象となった全母集団について独立して再現されたものではない。犯罪者による侵害が確認された件数ではなく、この調査で観測された露出を示すものとして捉えるべきだ。

重要な変化はアーキテクチャにある。ログはかつて、人間や決定論的なソフトウェアにとって受動的な証拠だった。エージェント型ワークフローは、同じログを実行可能なコンテキストへ変換し得る。

これにより、異例のフィードバックループが生まれる。セキュリティ制御が不審なトラフィックをブロックし、ブロックされたリクエストを記録し、攻撃者のテキストを信頼された監視プラットフォームに保存する。

その後、AIエージェントがインシデントを診断するために保存済みの記録を読む。成功したブロックが、次段階の配送経路へと変わる。

Google Newsの注目が一つのセキュリティデモを超えて重要な理由

Google Newsでの可視性が重要なのは、GhostJackingが抽象的なAIリスクを日常的な開発ワークフローへ結び付けるためだ。

間接プロンプトインジェクションは、長年にわたり文書化されてきた。これは、AIシステムが別のタスクを完了する過程で処理するデータ内に、悪意ある指示が埋め込まれることで発生する。

攻撃者は、ユーザーの直接プロンプトに指示を置く必要はない。ペイロードは、ウェブページ、メール、文書、サポートチケット、コードコメント、または取得されたデータベースレコードの中に現れ得る。

GhostJackingは、この既知の弱点を運用上の証拠に適用する。標的は無害な質問に答えるチャットボットではない。ソフトウェアの診断を依頼され、修正コマンドを実行する可能性のあるエージェントだ。

この違いはリスクを高める。チャットボットであれば誤解を招く回答を生成するかもしれないが、権限を持つコーディングエージェントはファイルを変更し、シェルを呼び出し、認証済みサービスにアクセスできる。

この事象は、ツール接続型エージェントの急速な普及の最中に起きている。一般にMCPと呼ばれるModel Context Protocolは、モデルが外部ツールやデータソースと通信するための標準的な手段を提供する。

MCPは、エージェントを課題トラッカー、データベース、リポジトリ、監視プラットフォーム、ローカル開発ツールへ接続するために必要な作業を減らせる。ただし、それらのシステムから得るコンテンツを自動的に信頼できるものにするわけではない。

ツール自体は正当でも、攻撃者が制御するデータを返すことがある。この違いがGhostJacking攻撃の核心だ。

従来のアプリケーションセキュリティでは、呼び出し元がリソースへのアクセスを許可されているかを問うことが多い。ここでは、認証済みのエージェントがリソースへのアクセスと、その結果生じる行動の実行を許可されている。

欠けている問いは、その行動がユーザーの意図を反映しているかどうかだ。認証は誰が行動しているかを示すが、なぜその行動が選ばれたかを証明するものではない。

NISTは、エージェントハイジャックを、信頼された指示と信頼できない外部データの分離が不十分なことによって生じる間接プロンプトインジェクションの一形態と説明している。同機関のhijacking evaluationsには、リモートコード実行、データ流出、自動フィッシングのシナリオが含まれていた。

NISTの研究者は、適応型攻撃が極めて重要であると見出した。ある評価では、最も強力なベースライン攻撃は、更新済みモデルに対して11％の成功率を達成した。

新たに開発された攻撃は、同じ報告済みのテスト環境で81％に達した。この結果は普遍的なモデル失敗率を示すものではないが、プロンプトインジェクション耐性に関する固定的な主張には疑問を投げかける。

モデルは既知のテストスイートでは良好に機能しても、その挙動に合わせて調整された攻撃には失敗する可能性がある。したがってセキュリティチームは、一つのベンチマークを永続的な保証として扱うことはできない。

Google Newsによる報道は、この知見を専門的なAI安全性の領域の外へ広げる助けになり得る。影響を受けるワークフローは、開発チームがすでにエージェントに望んでいる作業、つまり問題の調査、原因の特定、修正の適用に似ている。

したがってこの記事は、仮説上の超知能について警告しているわけではない。身近な認証情報を使い、身近なクラウドサービスに対して動作する、身近な自動化ツールを扱っている。

まさにその身近さが、リスクを過小評価しやすくする。各コンポーネントを個別に見れば、すべて正当に見える可能性がある。

Sentryサービスは正当だ。MCP統合も正当だ。コーディングエージェントも正当であり、開発者のアカウントは認証されている。

敵対的な要素は、データと意図の間の移行に存在する。現在のアイデンティティ制御がこの移行を検査することは、ほとんどない。

AIエージェントのアイデンティティガバナンスは認証で止まる

AIエージェントのアイデンティティガバナンスは、行為者を検証しても、各判断の背後にある権限を検証できなければ機能しない。

人間向けのアイデンティティシステムは通常、個人、アカウント、割り当てられた権限から始まる。管理者は、誰がアカウントを所有しているか、どのリソースに到達できるかを確認できる。

サービスアカウントは、このモデルをアプリケーションへ拡張する。ソフトウェアが決定論的なコードに従い、狭く文書化された機能を実行する場合には、かなり適切に機能する。

AIエージェントの振る舞いは異なる。次の行動は、自然言語による目標、取得したコンテキスト、モデルの推論、利用可能なツール、そしてワークフロー内の前段階に依存する。

同じ認証済みエージェントでも、エラーのレビュー、リポジトリの編集、デプロイサービスの呼び出し、チームへのメッセージ送信を行える。その実効的な役割は、タスクの進行とともに変化する。

組織はしばしば、この複雑さをエージェントにユーザーの既存アクセスを継承させることで管理する。この手法は導入を簡単にするが、帰属を弱める。

監査記録には、開発者アカウントがパッケージを起動したと表示されるかもしれない。しかし、その開発者がその正確なパッケージを要求したか、事前にコマンドを確認したかまでは示されない可能性がある。

また、どの取得文書がモデルに影響したかも記録されない場合がある。その来歴がなければ、調査担当者には最終行動は見えても、その背後にある権限の連鎖は見えない。

Cloud Security Allianceのagent security surveyは、準備状況のギャップを示している。調査対象組織の40％はエージェントを本番環境で運用していると回答し、さらに31％はテスト中だと回答した。

既存のアイデンティティシステムがエージェントのアイデンティティを効果的に管理できることに高い確信を持つと回答したのは、わずか18％だった。エージェントのリアルタイムな登録簿またはインベントリを維持していたのは、わずか21％だった。

この調査では、静的なAPIキー、共有サービスアカウント、ユーザー名とパスワードの組み合わせへの依存が続いていることも分かった。これらの仕組みはアクセスを認証できても、委任された意図を表現することはできない。

有用なエージェントアイデンティティは、「どのトークンがこのリクエストを行ったのか」以上の問いに答えるべきだ。リクエストを、所有者、タスク、承認済みツール、データ範囲、有効期限と結び付ける必要がある。

その記録は委任後も維持されるべきだ。プライマリエージェントがサブエージェントを作成する場合、子エージェントが親に利用可能なすべての権限を黙って継承してはならない。

委任された各アイデンティティには、割り当てられた手順に必要な権限だけを与えるべきだ。システムは、ユーザー、親エージェント、子エージェント、そして結果としての行動の関係も保持すべきである。

GhostJackingは、この連鎖が暗黙のまま残ると何が起きるかを示している。悪意あるエラーは、すでに存在するアイデンティティを誘導できるため、エージェントのアイデンティティを盗む必要がない。

これは、古典的な混乱した代理人問題に似ている。信頼されたプログラムが、正しく分類できない攻撃者影響下の入力を受け入れた後、その権限を誤用する。

言語モデルはコンテンツを確率的に解釈するため、この問題をさらに難しくする。巧妙に書式化された「解決策」は、曖昧なユーザー指示よりも実行可能に見えることがある。

プロンプト階層は、モデルがシステム指示とユーザー指示を優先する助けになる。だが、事実に基づくツール出力と、その出力に埋め込まれたコマンドとの間に暗号学的な境界を作るものではない。

ソースを信頼できないものとしてラベル付けすることにも限界がある。Tenetによれば、設定で外部コンテンツを信用しないよう指示されていた場合でも、エージェントが注入された指示に従うことがあった。

この主張には、より幅広いモデルや構成にわたる独立した検証が必要だ。ただし、NISTの適応型評価結果は、指示だけに依存する防御が標的を絞った圧力の下で弱まるという、より広範な警告を裏付けている。

したがって、アイデンティティ層はモデルが誤った判断を下し得ることを前提にしなければならない。ガバナンスは、その判断が取り返しのつかない行動になる前に影響を抑えるべきだ。

中核的なトレードオフは、有用なアクセスと検証可能な意図の間にある

エージェントはアクセス権限を得るほど有用になるが、追加される権限の一つ一つが、操作された意図による影響範囲を広げる。

提案機能に限定されたコーディング支援ツールでも、安全でないコードを生成する可能性がある。ターミナルアクセスを持つコーディングエージェントは、開発者が読む前にそのコードを実行できる。

要約に限定されたインシデント対応エージェントは、調査を歪める可能性がある。同じエージェントが本番環境にアクセスできれば、汚染された診断記録に従いながらインフラを変更できてしまう。

これは、すべてのエージェント型自動化を拒む理由ではなく、実務上のトレードオフである。組織は、自律性と段階的に強化される制御を結び付ける必要がある。

調査や診断では、読み取り専用アクセスをデフォルトにすべきだ。書き込みアクセスは、特定のタスク、リソース、時間枠に対して付与すべきである。

コマンド実行には別個の境界が必要だ。監視データを取得できるエージェントに対し、そのデータが推奨する内容を何でも実行できる無制限の権限を自動的に与えるべきではない。

高リスクな操作には、意味論的な認可も必要である。これは、呼び出し元が有効なトークンを持っているかを確認するだけでなく、操作の目的と文脈を評価することを意味する。

たとえば、ポリシーは隔離されたワークスペース内で承認済みのテストコマンドを実行することをエージェントに許可できる。同じポリシーで、パッケージのインストール、認証情報へのアクセス、外向き接続を拒否することもできる。

こうした判断はモデルの外部で行うべきだ。操作されている可能性がある同じエージェントに自身のコマンドを判断させても、独立した制御にはならない。

実行時の強制は、より強固な分離を提供する。ゲートウェイは要求された各ツール呼び出しを検査し、ポリシーと照合し、承認済みタスクの範囲外にある操作をブロックできる。

ゲートウェイは、構造化された証拠を記録する場所にもなる。その証拠には、要求元のアイデンティティ、ユーザーの目的、取得元ソース、要求された操作、ポリシー判断、結果を含められる。

潜在的な影響が大きい場合、人による承認は依然として有用だ。しかし、一般的な確認ダイアログだけでは不十分である。

レビュー担当者は、コマンドが何を行うか、アクセス可能なファイルやシステム、そしてそれを引き起こした外部コンテンツを確認する必要がある。そうでなければ、承認は単なる日常的なクリック操作になる。

サンドボックス化は、認可に失敗した場合の被害を抑える。コーディングエージェントは、本番の認証情報や無制限のネットワーク接続にアクセスできない使い捨て環境内で作業できる。

短命な認証情報も常設的な露出を減らす。エージェントは現在の操作に限定されたトークンを取得し、タスク終了時にはその権限を失うべきだ。

MicrosoftのAutoJack researchは、別の仕組みを通じて同じ設計上の教訓を補強している。信頼できないWebコンテンツがローカルのMCP制御経路に到達し、開発ビルドでプロセスを生成できた。

Microsoftは、影響を受けた領域は該当するパッケージ版に到達する前に強化されたと報告している。それでも、エージェントが通常は信頼できるものとして扱われる境界を解消したという、より広範な発見は重要である。

人間がブラウザで外部ページを閲覧しても、通常はローカルの自動化プロセスになることはない。エージェントに制御されたブラウザは、両方の役割を同時に担うことができる。

GhostJacking攻撃は意味論的な境界を越え、AutoJackはWeb、localhost、コントロールプレーンの境界を越えた。どちらの事例も、従来の制御が分離していたセキュリティドメインをエージェントが接続してしまうことを示している。

この比較は、アイデンティティベンダー、モデルプロバイダー、エージェントフレームワーク、企業のセキュリティチームに同時に対応を迫る。どの一者も単独でこの問題を解決できない。

モデル開発者は悪意ある指示への耐性を改善できる。フレームワーク開発者はデータをラベル付けし、ツールを制約できる。

アイデンティティプロバイダーは、範囲を限定したワークロード認証情報を発行し、委任関係を保持できる。企業は依然として、所有者、承認のしきい値、許容される自律性を定義しなければならない。

正しい設計は、あらゆる層が失敗し得ることを前提にする。耐性のあるモデルも最小権限で動作すべきであり、適切にスコープ設定されたアイデンティティも実行時ポリシー検査を受けるべきだ。

GhostJackingの証拠がまだ示していないこと

この実証は信頼できる攻撃類型を明らかにしているが、犯罪者による広範な悪用や、あらゆるエージェントの失敗を証明するものではない。

報告された最大規模の数値は、エージェントシステム向けの保護製品も販売しているTenet Securityによるものだ。この商業的な立場が調査結果を無効にするわけではないが、独立した再現検証の重要性を一層高める。

2,388組織という数字は、発見された露出条件を示している。攻撃者がすべての組織の侵害に成功したことや、それぞれがSentryのデータを権限を持つエージェントに積極的に接続していたことを意味するものではない。

同様に、観測された100件超のエージェント操作は管理された研究環境でのものだ。この結果は、報告されたテスト内での実現可能性と規模を示すものであり、ソフトウェア業界全体で測定された侵害率ではない。

製品構成も異なる。一部のエージェントではシェルコマンドの前に承認が必要だが、他のエージェントはコンテナや制限付きクラウドワークスペース内で動作する。

モデルごとに、同じペイロードの解釈は異なり得る。また、更新、新しいシステムプロンプト、ツール応答の書式変更によって挙動が変化することもある。

攻撃対象領域は権限に依存する。隔離されたリポジトリ内で読み取り専用アクセスしか持たないエージェントは、クラウドキーと無制限のターミナルアクセスを持つエージェントよりもリスクが低い。

これらの違いにより、単一の見出し向け失敗率は誤解を招く。セキュリティチームには、実際に使用しているモデル、ツール、認証情報、承認ルールに基づくテストが必要だ。

「GhostJacking」という名称も混乱を招く可能性がある。Tenetが公開した資料では、汚染されたエラーを用いる手法に主として「Agentjacking」という名称を使っている。

GhostJackingは、必ずしも独立した標準化済み脆弱性カテゴリではなく、目に見えないエージェント乗っ取りを表す説明的な名称として扱うのが適切だ。中核となる仕組みは、依然として間接的なプロンプトインジェクションと、それに続く認可済みツールの使用である。

また、すべてのプラットフォームに共通するパッチは存在しない。既知のペイロードをフィルタリングすれば一つの実証を止められるかもしれないが、一般的な「指示とデータ」の問題を解決することにはならない。

Markdownの見出し、パッケージマネージャーのコマンド、特定のフレーズをブロックしても、攻撃者は同じ意図を別形式で表現するだけだ。適応型評価は、シグネチャのみに依存する防御がすぐに時代遅れになる理由を繰り返し示している。

反対に、この問題がまったく解決不可能だと言うことも証拠を誇張することになる。より良いモデル訓練、データラベル付け、ツール分離、ポリシー強制によってリスクを低減できる。

現実的な目標は、モデル内での完全な検出ではない。一つの誤った解釈が無制限の実行につながることを防ぐことである。

組織はインベントリから始めるべきだ。ローカルの開発者ツールや実験的な統合を含め、存在を把握していないエージェントを統制することはできない。

各エージェントには、明確に名付けられた所有者と文書化された目的が必要だ。セキュリティチームは、モデル、ツール、データソース、認証情報、実行環境、委任経路を記録すべきである。

外部から影響を受けるコンテンツには、明示的な分類が必要だ。ログ、チケット、リポジトリコメント、メール、Webページは、信頼できないデータとしてエージェントに渡されるべきである。

ツールの権限は、コンテンツ分類から独立させるべきだ。信頼できるコネクターが取得したというだけで、信頼できないソースに権限を与えてはならない。

次にチームは、現実的な攻撃チェーンをテストすべきだ。レッドチーミングには、汚染されたテレメトリー、操作されたチケット、悪意あるWebページ、侵害されたツール説明、欺瞞的な修復テキストを含めなければならない。

テストでは、モデルが悪意あるフレーズを繰り返すかどうかだけでなく、結果を測定すべきだ。重要な問いは、エージェントが未許可の操作を要求または完了するかどうかである。

Google News読者が次に注目すべきこと

次の段階を左右するのは、実行時制御、アイデンティティ標準、そして実運用環境から得られる証拠だ。

第一のシグナルは独立した再現検証である。研究者は、コーディングエージェントの現行バージョン、承認モード、サンドボックス、企業ポリシー全体で、汚染されたテレメトリーチェーンをテストすべきだ。

再現検証で高い実行率が確認されれば、必須の実行時強制を求める根拠が強まる。強化された構成で低い率が示されれば、すでに有効な制御を特定できる。

第二のシグナルは、取得データと実行可能な指示との製品レベルの分離だ。ツールプロトコルには、来歴、信頼性、許可された使用方法を記述する構造化された方法が必要である。

モデルは、テキストが認証されていないイベントフィールドから来たことを認識すべきだ。より重要なのは、実行層がそのテキストにコマンドを要求する権限を与えないことである。

エージェントプラットフォームがツール応答に検証可能な来歴を付与し、それを複数ステップの推論を通じて保持するかどうかに注目したい。強制がなければ、単なる警告ラベルの価値は限定的だ。

第三のシグナルは、委任のために構築されたアイデンティティ基盤である。企業には、短命なエージェント認証情報、タスクに紐付いたスコープ、リアルタイムのインベントリ、監査可能な親子関係が必要だ。

アイデンティティシステムが次の明確な問いに答えられるようになったとき、進展は可視化される。どの人間が、どの目的のために、どの制限の下で、このエージェントを認可したのか。

これらのシグナルは、コーディングを超えて重要である。カスタマーサポートエージェントはチケットを読み、財務エージェントは文書を処理し、セキュリティエージェントはアラートを調査する。

信頼できないコンテンツと特権ツールを組み合わせるあらゆるワークフローには、同じ構造的なリスクがある。具体的な配信チャネルは変わっても、権限の問題は残る。

Google Newsでの注目はGhostJackingに記憶に残る名称を与える。より永続的な教訓は、より劇的ではないが、より重大だ。認証だけでは信頼できる意図を確立できない。

セキュリティチームは今、エージェントが外部から影響を受けるコンテンツを読んでから行動を起こすすべての場所をマッピングすべきだ。まずはログ、チケット、メール、リポジトリ、Webツールから着手する。

次に、データを変更する、コードを実行する、秘密情報を露出させる、外部システムに接続するといった操作を特定する。それらの入力と結果の間に、独立したポリシー検査を置くべきだ。

大規模な悪用キャンペーンの証明を待つ必要はない。報告された攻撃を統制された警告として扱い、自社のエージェントで再現可能かをテストすべきだ。

エージェントが、誰がその権限を委任したのか、どのソースがその判断を形作ったのか、なぜツール呼び出しが許可されたのかを説明できなければ、そのエージェントは完全には統制されていない。