AIエージェントのセキュリティにはSBOMだけでなく構成グラフが必要
従来のSCAはパッケージレベルの脆弱性しか検出できないが、AIエージェントのリスクはコンポーネントの構成から生じる。OpenACAプロジェクトはエージェント構成グラフを構築し、プラグイン、スキル、MCPサーバーなどの相互作用による真のリスクを明らかにする。
近年、AIエージェントの普及に伴い、そのセキュリティ問題が顕在化している。従来のソフトウェア構成分析（SCA）はパッケージ依存関係の既知の脆弱性にのみ注目するが、AIエージェントの真のリスクはコンポーネント間の構成方法にある。Claude公式プラグインマーケットプレイスを例に、なぜパッケージ依存から構成グラフ分析へ移行する必要があるのかを解説する。
プラグイン「imessage」はClaude Codeにワンクリックでインストールでき、AIエージェントがiMessageの読み取りと送信を可能にする。その内部構造は3つの部分からなる：ユーザーのメッセージ履歴全体を読み取り（フルディスクアクセス権限が必要）、AppleScript経由でメッセージを送信するローカルMCPサーバー；「configure」と「access」という2つのスキル（読み取り、書き込み、制限付きBash権限を持ち、アクセス制御状態を設定ファイルに書き込む）；および91のnpmパッケージ。各コンポーネントは単独では安全である。MCPサーバーは設計通り動作し、スキルは正常に機能し、パッケージは一般的なWebサーバー依存関係に過ぎない。リポジトリにSCAスキャンを実行すると、ロックファイルとhonoやpath-to-regexpの数件のアドバイザリが表示され、パッチ適用で報告はグリーンになるが、実際のリスクはほとんど明らかにならない。
リスクは単一パッケージには存在せず、構成に存在する：信頼できない入力に接続されたエージェント（各受信テキストは読み取るメッセージストアに着地する）、プライベートメッセージ履歴の読み取り、ユーザーとしてのメッセージ送信、そして誰が制御を許可されるかを書き換えられるスキルにより管理される。これらすべてが同じコンテキストにあり、各部分が個別にレビューされた後に組み立てられる。これは仮説ではない。研究者は実際に公式Claudeプラグインマーケットプレイスをスキャンした——62のマニフェスト、530のコンポーネント：38プラグイン、27スキル、26コマンド、21エージェント、16 MCPサーバー、8フック、そしてその下の394パッケージ。結果、124の既知脆弱性アドバイザリが発見された。興味深いことに、これらすべては4つのプラグイン（discord、telegram、fakechat、imessage）に集中していた。つまり、メッセージチャネルプラグインである。脆弱性は、信頼できない外部メッセージを取り込み、ローカルファイルを送信できるプラグインに集中していた。脆弱なコードと機密能力が同じコンポーネントに存在する——これはパッケージ単位のスキャンでは表現できない相関関係であり、スキャナーはパッケージがメッセージ読み取りエージェントの一部であることを知らないからだ。
SCAは依存関係ツリーに既知の脆弱なバージョンが含まれているかどうかを答えるだけであり、パッケージのエージェント内での実際のコンテキストを伝えることはできない。ランタイム監視は実行中の悪意ある動作を捕捉できるが、インストール前に構成リスクを明らかにすることはできない。したがって、第3の視点が必要である：エージェント構成グラフ。エージェントスタックはフラットな依存関係リストではなく、グラフである。プラグインはスキル、MCPサーバー、フックを含み、それらが能力を宣言しパッケージを取り込む。権限とインストールパスも関連する。セキュリティ分析はノード自体だけでなく、ノード間のエッジに注目する必要がある。フラットなSBOMはボックスを列挙するが、脆弱なパッケージが信頼できない入力ソース、プライベートデータリーダー、アウトバウンドシンクと同じコンテキストにあることを伝えられない。グラフはそれができる。
オープンソースプロジェクトOpenACAはこの層を構築している。現在、OpenACAはエージェントスタック全体を棚卸し、各パッケージアドバイザリをそれを取り込むエージェントコンポーネントに帰属させ（これにより124のアドバイザリが4つのプラグインに存在することが分かった）、可変インストールや実行可能スキル能力などの姿勢問題をフラグ付けし、CycloneDX形式のエージェントBOM（構成グラフ）を出力できる。次はグラフ派生の露出分析である：構成に基づいてのみ発動するルール、例えば「このコンテキストは信頼できない入力、プライベートデータ読み取り、アウトバウンドシンクを組み合わせている；レビューせよ」、そして発見事項を影響への実現可能な経路の有無で優先順位付けする。OpenACAはまだこれらの露出経路を計算していないが、棚卸し、帰属、グラフがそれを可能にする基盤である。
著者は簡単な演習を提案する：エージェントプラグインリポジトリでSCAスキャンを実行し、次の質問を自分に問いかける——Claudeスキル、ライフサイクルフック、またはローカルファイルを送信できるMCPサーバーを介して到達可能な脆弱な依存関係を特定できるか？できない場合、見ているのはエージェントではなくロックファイルである。uvx --from openaca openaca scan repo --target . --include-postureを実行すれば、プラグイン、スキル、MCPサーバーを含む任意のリポジトリの構成（何がインストールされ、コンポーネントがどのように接続され、どのアドバイザリと姿勢発見がどのエージェントコンポーネントに属するか）を表示できる。
結論として、AIエージェントのセキュリティには構成認識分析が必要であり、単なるパッケージスキャンでは不十分である。パッケージは決して単位ではなかった。エージェントこそが単位である。