Plugin4Shell AIエージェント脆弱性、信頼済みプラグインを迂回し、2つのコーディングツールは未修正のまま

Plugin4Shellは、レビュー済みプラグインを導入する際に想定された手順をユーザーが守っていたにもかかわらず、4つのAIコーディングエージェントにまたがる中核的な安全策を突破した。セキュリティ企業AIRによると、この欠陥はClaude Code、OpenAI Codex、GitHub Copilot、Gemini CLIに影響した。同社の研究者は、4製品すべてに対する実行可能なリモートコード実行を実証した。

AnthropicとOpenAIはAIRからの報告を受けて修正をリリースした。AIRは2026年9月17日に調査結果を公表した時点で、GitHub Copilot向けの対応パッチは確認できなかったと報告している。またGoogleは、影響を受けるGemini CLIの挙動を修正せず、ユーザーをAntigravityへ誘導するとした。

対応のばらつきこそが中心的な問題だ。プラグインマーケットプレイスは、レビューとコミットのピン留めによって、承認後のコード変更から開発者を保護すると約束している。報告によれば、Plugin4Shell AIエージェント脆弱性は、不注意なインストール、不審な承認、新たなクリックを必要とせずに、その約束を破った。

Plugin4Shellは信頼された更新をリモートコード実行へ変えた

この攻撃が標的としたのは、プロンプトへの応答を言語モデルが判断する過程ではなく、プラグイン配布プロセスだった。

AIコーディングエージェントは、プラグイン、スキル、拡張機能、その他のアドオンへの対応を急速に進めている。これらのパッケージはワークフローのカスタマイズ、サービスの接続、開発環境内でのコード実行を可能にする。多くの場合、エージェントが持つファイルアクセス、シェルコマンド実行、認証済みシステムとの連携能力を引き継ぐ。

こうしたアクセス権により、エージェントプラグインは受動的なテキストプロンプトよりもローカルアプリケーションに近い存在となる。悪意あるコードがプラグインディレクトリに到達すれば、そのエージェントを実行する開発者に付与された権限で動作できる。

AIRによると、Plugin4ShellはSHAピン留めを迂回することでこの状態に至った。SHAは、特定のGitコミットを表すために一般的に使われる暗号学的識別子である。プラグインをその識別子にピン留めすれば、リポジトリが後から変更されても、導入済みコードは固定されるはずだ。

Plugin4Shell researchによると、影響を受けたエージェントはピン留め済みコミットを要求したものの、実際にチェックアウトされたコミットを検証していなかった。上流リポジトリを制御する攻撃者は、Gitの名前解決の挙動を悪用し、別のコードへすり替えられる可能性がある。

マーケットプレイスのレコードには、期待されたコミット識別子が引き続き表示される可能性がある。エージェントもインストール成功を報告し得る。しかし、作業ディレクトリ内のファイルは、レビュー済みコミットではなく、攻撃者が制御するブランチ由来となる。

AIRは実行可能な侵入経路を2つ説明した。攻撃者は正規のプラグインを公開して利用を広げ、後の更新時にリポジトリを悪意あるものへ変えられる。あるいは、既存プラグインを支えるリポジトリを乗っ取ることもできる。

2つ目の経路は、責任の所在を個々のプラグイン作者から移すため重要だ。プラグインは正規プロジェクトとして始まり、あらゆるレビューを通過し得る。そのリポジトリが敵対的になるのは、開発者やセキュリティチームがすでに信頼した後だけでもよい。

AIRによると、研究者は2026年5月に問題を発見し、6月に4ベンダーへ報告した。同社は9月17日に技術的な説明を公開した。Help Net Securityは翌日にこの調査結果を報じた。

いずれの組織も、公開前にPlugin4Shellが実際の被害者に対して悪用されたことを示す公的証拠を挙げていない。実証された影響は、記録された犯罪キャンペーンではなく、AIRの概念実証テストに基づく。

この区別は、即時の侵害について主張できる範囲を限定する。しかし、破綻した制御の重要性を下げるものではない。攻撃が成功すれば、組織がすでにレビューし承認したコンポーネントを介してコードが実行される。

この問題は、プラグイン配布に関するAIRの先行研究にも続くものだ。同社によると、テスト用スキルは削除されるまでに26,000超のエージェントへ到達した。別の研究では、134,000のエージェントに影響した925件の乗っ取られたスキルが特定されたとされる。

これらの数値はAIRによるものであり、Plugin4Shellの開示において独自に再現されたものではない。それでも、配布網の獲得と上流リポジトリの侵害は単なる理論的前提ではなく、現実的な段階だという研究者の広範な主張を示している。

Plugin4Shell AIエージェント脆弱性はいかにSHAピン留めを迂回したか

Plugin4Shellが成立したのは、影響を受けた各エージェントが最終的にチェックアウトされたコミットを検証せず、要求されたGit参照を信頼したためだ。

Claude Code、Codex、GitHub Copilotは、報告によれば同じ亜種を共有していた。各プラグインインストーラーはリポジトリをクローンし、ピン留めされた40文字のコミット識別子をgit checkoutに渡していた。

Gitでは、多くのホスティング構成においてコミット識別子に似たブランチ名を許容している。名前がブランチとオブジェクトの両方を指し得る場合、Gitは曖昧性の警告を出しながら参照として解決することがある。

プラグインリポジトリを制御する攻撃者は、ピン留めされたコミットと完全に同じ名前のブランチを作成できる。続いて、そのブランチをリポジトリのデフォルトに設定し、悪意あるコードを指すようにできる。

最初のクローンでは、攻撃者のデフォルトブランチが取得される。その後のチェックアウトでは、一見コミット識別子に見える値がローカルブランチへ解決される可能性がある。その結果、エージェントはマーケットプレイスでレビューされたものとは異なるファイルを読み込む、または実行することになる。

この手法は、すべてのホスティングサービスで同一には機能しない。GitHubは、完全なGitオブジェクト識別子に見えるブランチ名およびタグ名をブロックしている。これは同社のbranch-name restrictionsに記載されている。

ただしAIRによると、Bitbucketおよびセルフホスト型Gitサービスでは、そのような名前を受け入れられる。いくつかのエージェントマーケットプレイスはGitHub以外でホストされるリポジトリを公式にサポートしており、より広い構成が露出したままとなる。

Gemini CLIは、同じ結果へ至る別の経路を使用していたとされる。そのインストーラーはピン留め済みコミットを取得した後、通常は取得済みコンテンツを指すGit参照であるFETCH_HEADに対してチェックアウトを実行していた。

AIRは、リポジトリがFETCH_HEADをデフォルトブランチ名として使用できることを発見した。この場合、チェックアウトは取得したコミットを含む特別なファイルではなく、そのブランチへ解決される可能性がある。

両方の亜種は、最終比較の欠如に依存していた。チェックアウト完了後、エージェントはHEADを解決し、それがマーケットプレイスでピン留めされたSHAと一致することを検証する必要があった。

このチェックは小さいが、その実行場所が重要だ。マーケットプレイスは、クライアントが最終的にローカル作業ツリーへ何を配置したかを確認できない。検証はクローンとチェックアウトを実行するエージェント内で行われなければならない。

ゼロクリックという表現は、バックグラウンド更新に由来する。AIRによると、Claude CodeとCodexはデフォルトで導入済みプラグインを自動更新する。したがって、悪意ある置き換えは、マーケットプレイスがピンを変更した後、追加のインストール判断なしに到達し得る。

被害者は、新たな悪意あるプラグインを見つける必要はない。攻撃者はすでにマシン上に存在するプラグインを標的にし、エージェントの更新プロセスを待つことになる。

リモートコード実行、すなわちRCEとは、攻撃者が制御する命令が対象システム上で実行されることを意味する。結果として及ぶ範囲は、影響を受けたエージェントが利用できるアカウント、環境、サンドボックス、認証情報、ネットワークアクセスに依存する。

AIRは、潜在的な影響を、そのツールを実行する従業員が持つアクセスと同等と説明している。これは最悪の場合の説明であり、すべての導入環境を普遍的に測定したものではない。

厳格に隔離されたエージェントであれば、一時的なワークスペースだけが露出する可能性がある。クラウド認証情報、ソースリポジトリ、署名鍵、または本番環境アクセスを持つローカル導入エージェントでは、潜在的な被害範囲ははるかに大きくなる。

この変動性こそ、バージョンの棚卸しだけでは不十分な理由だ。セキュリティチームは、各エージェントがどこで動作するか、どのプラグインを読み込むか、そしてその実行境界内でどの認証情報が利用可能かも把握する必要がある。

プラグインレビューは設計どおり機能したが、導入されたコードは変わった

中核的な対立は、不変のレビューという約束と、クライアント側のGit参照解決という現実の間にある。

ソフトウェアサプライチェーンの制御では、承認と実行を分離することが多い。レビュアーは既知のバージョンを評価し、そのダイジェストを記録し、システムがそのバージョンのみを導入できるようにする。

このモデルは、ダイジェストが実行されるファイルを識別することを前提とする。報告によれば、Plugin4Shellは可視化されたピンを維持しながら、そのピンと最終的な作業ツリーの間のつながりを断ち切った。

これは、未知の拡張機能に注意するようユーザーへ警告する以上に深刻だ。研究者によると、この攻撃は、プラグインが信頼できるマーケットプレイスから提供され、レビューを通過し、ピン留めされたままでも機能する。

そのため、マーケットプレイスの評判だけに基づくセキュリティガイダンスでは、脆弱な手順を見落とすことになる。ローカルエージェントがチェックアウト時にだまされ得るなら、攻撃者はマーケットプレイスのデータベースを侵害する必要がない。

同じ制約は、社内プラグインカタログにも当てはまる。企業はすべてのパッケージをレビューし、承認済みメタデータをミラーリングできる。しかし、従業員のクライアントが解決済みコミットを検証しなければ、これらの制御は不完全なままだ。

AIRはPlugin4ShellをAIエージェントエコシステム初のサプライチェーン脆弱性と呼んでいる。この表現は同社による位置づけであり、一定の慎重さが必要だ。

AI開発ツールはすでに、リポジトリポイズニング、プロンプトインジェクション、悪意ある設定ファイル、拡張機能関連の脆弱性に直面してきた。Plugin4Shellは、ピン留めされたエージェント用アドオンとその更新経路に焦点を絞っているという意味で、より限定的だ。

それでも、この仕組みは明確な信頼の失敗を露呈している。レビュー済みのエージェント機能が、リポジトリから開発者のマシンへ移動する過程を攻撃するものだ。

最近の研究は、これが孤立した弱点ではないことを示している。Wizは2026年7月、6つのAIコーディングアシスタントをテストした後にGhostApprovalを開示した。この問題は、シンボリックリンクを使って想定されたワークスペース境界の外部にあるファイルへ到達するものだった。

GhostApproval findingsは、Amazon、Anthropic、Augment、Cursor、Google、Windsurfの製品に影響した。ベンダーの対応はさまざまで、複数の修正と、少なくとも1件の脅威モデル判断をめぐる異論があった。

GhostApprovalとPlugin4Shellは異なる技術的プリミティブを使用する。一方はシンボリックリンクを介したパス解決を悪用する。もう一方は、報告によればプラグインのインストールおよび更新中にGit参照解決を悪用する。

両者を結びつけるパターンは、ユーザーに見える判断とシステムの実際の動作の間にある隔たりだ。パスはローカルに見えても別の場所へ解決される。ピンは不変に見えても別のコードへ解決される。

権限プロンプトだけでは、この不一致を修復できない。インターフェースが信頼済みの名前を表示する一方で、基盤となる操作が別の対象を指すなら、ユーザーは十分な情報に基づく判断を下せない。

Anthropicは、Claude Codeにおける補完的な安全策として、ファイルシステムとネットワークの分離を公に説明している。同社のsandboxing modelは、インジェクトされたプロセスが機密ファイルや許可されていないネットワーク宛先へ到達することを防ぐことを目指している。

サンドボックス化は、悪意あるプラグインコードによる影響を抑えられる。ただし、特にプラグインが同じ制限の外で実行されたり、より広い権限を与えられたりする場合、正確なパッケージ検証の代替にはならない。

したがって企業には、独立した2つの境界が必要となる。インストールプロセスは、レビュー済みコードが実際に導入されることを検証しなければならない。実行時環境は、そのコードが実行後に到達できる範囲を制限しなければならない。

いずれかの層で障害が発生しても、それが自動的にワークステーションやクラウドアカウントの侵害につながるべきではありません。多くのエージェント導入環境では、変更可能な拡張機能と価値の高いローカル認証情報が依然として組み合わされているため、Plugin4Shellは重要です。

4つのコーディングエージェントが4つの異なるセキュリティ結果をもたらした

この開示により、類似したプラグインワークフローを実装するツール間で、パッチ対応プロセスが分断されていることが明らかになりました。

AIRによると、AnthropicはClaude Codeの脆弱性をバージョン2.1.179で修正しました。同社は、Anthropicが修正を確認した日付として2026年6月17日を記録しています。

AIRによれば、OpenAIは影響を受けたCodexの挙動をバージョン0.146.0で修正しました。調査タイムラインでは、同社がそのリリースで修正済みであることを8月12日に確認したとされています。

これらの製品の利用者は、自動更新が正常に完了したと想定すべきではありません。管理対象ワークステーション、オフライン環境、パッケージのロック、社内配布システムにより、古いバージョンが残っている可能性があります。

組織は実際のエンドポイントを照会し、バージョンを修正済みリリースと比較する必要があります。また、導入プロセスで稼働中のエージェントプロセスが置き換えられない場合は、長時間実行されているセッションも再起動すべきです。

GitHub Copilotには異なる問題があります。AIRによれば、Microsoftは同じ脆弱性報告を受け取ったものの、調査が公開された時点では修正を出荷していませんでした。

GitHubは最近、エージェント操作に対する集中管理機能を拡充しました。9月9日の発表では、管理者がmanaged agent permissionsを通じて、シェルコマンド、ファイル操作、ネットワークドメインをブロック、許可、または承認必須にできるとしています。

これらの制御により影響を狭めることはできますが、Plugin4Shellのパッチが適用された証拠にはなりません。未修正のインストーラーと制限的なランタイムポリシーは、攻撃の異なる段階に対処するものです。

したがってCopilotの管理者は、製品固有のアドバイザリ、修正済みバージョン、またはベンダーによる確認を求めるべきです。それまでの間、組織はマーケットプレイスのプラグイン更新を停止するか、エージェントを自組織が管理する承認済みリポジトリに限定できます。

Gemini CLIの状況は最も複雑です。AIRによると、Googleは8月4日に影響を受けるワークフローを修正しないことを確認し、Antigravityへの移行を勧めました。

Googleはすでに個人ユーザーをGemini CLIからAntigravity CLIへ移行し始めていました。6月の発表では、Gemini CLIは個人アカウントへのリクエスト提供を停止する一方、エンタープライズおよびAPIキーでの利用は引き続き可能とされていました。

しかし、Googleの以前の移行通知では、オープンソースのGemini CLIプロジェクトがエンタープライズ顧客向けにモデル更新、バグ修正、セキュリティ修正を引き続き受け取るとも述べられていました。

この公開文言は、すべてのGemini CLIインストールが無期限に脆弱なままであるという主張とはきれいに整合しません。管理者にとって重要な検証上の空白が残されています。

Googleの9月の変更履歴では、消費者向け移行後もGemini CLIのリリースが継続していることが示されています。また、問題のチェックアウト不具合とは関係のないセキュリティ強化も記載されています。この活動はPlugin4Shellの修正を立証するものではありません。

慎重な結論はより限定的です。AIRは、開示時点でGemini CLIにPlugin4Shellのパッチはなく、Antigravityを推奨したと報告しています。Googleはエンタープライズ用途向けにGemini CLIの一部を継続保守していましたが、この特定の修正を示すリリースノートは引用されていません。

エンタープライズ利用者は、一般的な保守に関する文言から安全性を推測すべきではありません。拡張機能のインストールまたは更新後に、対象リリースが最終的にチェックアウトされたコミットを検証することについて、直接の確認が必要です。

また、移行を単なる名称変更として扱うべきではありません。スキル、フック、MCPサーバー、認証情報を新しいエージェントへ移す際、設定を精査せず転送すれば、別のリスクを再現する可能性があります。

AIRによると、AntigravityはPlugin4Shellに悪用されたプラグインSHA固定メカニズムを使用していません。研究者の分析に基づけば、この特定の経路は適用されないことを意味します。

これは、Antigravityが悪意あるプラグイン、プロンプトインジェクション、安全でないツール、将来のサプライチェーン障害に対して免疫を持つことを意味するわけではありません。セキュリティチームは移行後も同じ隔離と最小権限の要件を維持すべきです。

4つの対応は、このバグを超えたガバナンス上の問題を示しています。類似機能が、共有された開示慣行、共通の重大度評価、同期した是正措置なしに、複数のエージェントへ展開される可能性があります。

開発者は、個別の変更履歴とベンダーの声明を追跡しなければなりません。その後、エンタープライズ管理者は、それらの不均一な記録を単一の強制可能なセキュリティ態勢へと変換する必要があります。

開発チームが直ちに変更すべきこと

最優先事項は、脆弱なプラグイン更新を停止し、エージェントのバージョンを検証し、すべてのコーディングエージェントが利用できる認証情報を減らすことです。

Claude Codeについては、組織はすべてのインストールをバージョン2.1.179以降へ移行すべきです。Codexについては、AIRはバージョン0.146.0を修正済みリリースとして特定しています。

チームはアンケートではなく、エンドポイントのインベントリを通じてバージョンを検証すべきです。開発者はローカル端末、IDE拡張機能、リモートワークスペース、CIシステムで複数のコーディングエージェントを利用している可能性があります。

GitHub Copilotについては、管理者はGitHubまたはMicrosoftに明示的な是正ガイダンスを求めるべきです。関係のない権限改善を、チェックアウト脆弱性が修正された確認として扱うべきではありません。

プラグイン機能が必須ではない場合、サードパーティのマーケットプレイスパッケージを無効化することが、最も明確な一時的リスク低減策となります。無効化できない組織は、自動更新を停止し、リポジトリのソースを制限すべきです。

Gemini CLIの利用者は、特にマーケットプレイス拡張機能を使用している場合、Antigravityへの移行を検討すべきです。エンタープライズ顧客は、利用している正確なGemini CLIリリースの状況についても書面による確認を求めるべきです。

開示後に影響を受けたプラグインを削除することは有用ですが、それだけでは不十分です。侵害されたパッケージは、削除前に永続化を作成し、起動ファイルを変更し、認証情報をコピーし、リポジトリを改変していた可能性があります。

インシデント対応担当者は、プラグイン更新履歴、Gitアクティビティ、プロセス実行、ネットワーク接続、機密ファイルの変更を確認すべきです。脆弱な自動更新が有効だった場合、対象期間は公開開示より前から始まります。

テレメトリーが予期しないプラグインコードの実行を示す場合、チームは認証情報をローテーションすべきです。優先対象には、ソース管理トークン、クラウド認証情報、パッケージ公開キー、署名用マテリアル、シェル環境に保存されたシークレットが含まれます。

認証情報のスコープは、ローテーションと同様に重要です。AIコーディングエージェントは、それを起動する開発者がその権限を持っているというだけで、無制限の本番アクセスを継承すべきではありません。

エージェント用アイデンティティを分離すれば、異常な操作をより容易に封じ込め、監査できます。短期間で失効するトークンも、ワークステーションから収集された認証情報の価値を限定します。

ランタイム隔離は別の防御層を提供します。ファイルアクセスはアクティブなプロジェクトをデフォルトとし、ネットワークアクセスにはタスクに適した限定的な許可リストを用いるべきです。

シェル実行にも同様の境界が必要です。開発者アカウントの下で任意のコマンドを呼び出せるプラグインは、生成されたソースコードだけに適用される多くの制御を回避できます。

組織は、サンドボックスのルールが、プラグイン、フック、パッケージマネージャー、MCPサーバーによって生成されるサブプロセスにも適用されるかを検証すべきです。モデルの直接ツールに対する制限が、すべての拡張プロセスをカバーするとは限りません。

プラグインのガバナンスにも、より強力な証跡が必要です。社内カタログには、レビュー済みコミット、リポジトリの出所、解決済みツリー識別子、レビュアー、承認日、導入済みバージョンを保存すべきです。

インストーラーはチェックアウト後に解決されたHEADを検証すべきです。承認済みコミットと一致しない場合、インストールは警告して継続するのではなく停止しなければなりません。

セキュリティチームは、悪意ある実行を再現せずにこの挙動をテストできます。制御されたリポジトリで曖昧な参照を提示し、検証システムがインストールをフェイルクローズで失敗させるか確認できます。

その結果は、調達および社内受け入れテストの一部にすべきです。ベンダーは、クローン、フェッチ、更新の後に、自社のエージェントがプラグイン内容をどのように検証するか説明できるべきです。

チームには、各プラグインが存在する理由についても信頼できる記録が必要です。検索可能なエンジニアリングナレッジベースは、承認、所有者、インシデント、置き換えの判断を結び付けられます。

この文書化が悪用を防ぐわけではありません。しかし、次の開示が現れた際に、影響を受けるチームを特定し、リスクのある統合を削除するまでの時間を短縮します。

最後に、開発者が広告された固定指定を信頼したことで責められるべきではありません。Plugin4Shellは、その信頼を合理的なものにするために設計された制御を、報告によれば回避しました。

是正措置はベンダーコード、エンタープライズポリシー、ランタイムアーキテクチャ全体にまたがるものです。承認済みのダイジェストとは異なるコードをインストーラーが実行する場合、利用者にすべての更新を検査するよう訓練しても補えません。

エージェントのプラグインセキュリティが改善しているかを示す3つの兆候

次の試金石は、ベンダーがこの開示を、より広範なセキュリティ上の約束ではなく、検証可能なインストール制御へと転換するかどうかです。

最初の兆候は、GitHub Copilotに対する具体的な是正措置です。管理者は、チェックアウト後のコミット検証を確認するセキュリティアドバイザリ、リリース識別子、または技術的な声明を探すべきです。

一般的なCopilotの更新では、この疑問には答えられません。関連する証拠は、クライアントがワーキングツリーのHEADを解決し、それをマーケットプレイスの固定指定と比較するかどうかです。

GitHubがその挙動を文書化し、サポートされるCopilotの各利用形態に展開すれば、現在のパッチの空白は縮小します。沈黙が続けば、一貫性のない脆弱性対応に対する懸念は強まるでしょう。

2つ目の兆候は、エンタープライズGemini CLI利用者に向けたGoogleの説明です。公開された移行文言では、エンタープライズアクセスとセキュリティ保守が継続するとされる一方、AIRはPlugin4Shellのパッチはないと報告しています。

Googleは、影響を受けるバージョンを明示し、修正の有無を説明し、サポート期限を定義することで、この緊張関係を解消できます。具体的なアドバイザリがあれば、チームはパッチ適用と移行のどちらを選ぶべきか判断しやすくなります。

Gemini CLIが検証済みコミットのチェックを受け取れば、AIRによる開示時点の状況は古くなります。Googleが修正しないことを確認した場合、組織は移行を製品上の選好ではなくセキュリティ要件として扱うべきです。

3つ目の兆候は、検証可能なクライアント挙動がマーケットプレイスレベルで採用されることです。マーケットプレイスだけでは最終的なチェックアウトを強制できませんが、互換性のあるエージェントを要求し、安全でないリポジトリ構成を拒否することはできます。

有用な変更には、署名付きマニフェスト、不変のパッケージ成果物、来歴証明、解決済みコミットを含むインストールレシートが含まれます。各制御は独立してテスト可能であるべきです。

エージェントベンダーは、プラグインが生成コマンドと同じサンドボックス内で実行されるかも開示すべきです。検証済みパッケージであっても、レビュー前に上流で侵害されていたり、見落とされた脆弱性を含んでいたりする可能性があります。

より大きな教訓は、プラグインが本質的に安全でないということではありません。自律エージェントは、パッケージングのエラーを開発者権限で実行される操作へと変えてしまうということです。

Plugin4Shellは、実装が同じ未検証の前提に依存していたため、報告によれば4つの競合製品をまたいでいました。要求されたGit識別子が、実際にインストールされたコードと同等のものとして扱われていたのです。

開発者とセキュリティリーダーは今、すべてのコーディングエージェントベンダーに直接尋ねるべきです。レビュー済みのコードが、マシン上で実行されているコードであることを何が証明するのか、と。

CopilotとGemini CLIが製品固有の回答を持つまで、影響を受ける組織はプラグイン利用を制限し、すべてのエージェントバージョンを検証し、認証情報を隔離すべきです。パッチ適用済みのClaude CodeまたはCodexを使用するチームも、インストール済み拡張機能を監査し、更新がすべてのエンドポイントに到達していることを確認すべきです。

Plugin4Shell AIエージェント脆弱性は、突き詰めれば運用可視性が問われる問題です。次のバックグラウンド更新が実行される前に、組織内の各エージェント、そのプラグイン、バージョン、権限を特定できるでしょうか。