AIエージェントの依存物を固定、JFrog新機能で先に決める4つの境界

JFrogは、2026年9月2日付の発表 で、AIコーディングエージェントが利用する依存物を検査・統制するAgentSecOps機能群を公表した。対象にはモデル、MCPサーバー、スキル、プラグイン、通常パッケージが含まれ、AI Asset Scanning、Agent Guard、Agent Package Manager（APM）Registry、Agent Package Resolution、Traffic Controllerが示された。

同日付のDevOps.comの報道 も、AI資産の検査、プロジェクト単位のポリシー、Microsoft主導のAPMへの対応、公開レジストリ通信のArtifactoryへの迂回を取り上げている。AIエージェントの取得物を承認済みの供給元に限定するには、製品を有効化する前に、許可元、固定する内容、拒否規則の適用範囲、外部への通信経路という4つの境界を決める必要がある。

第一の境界：資産の種類ごとに許可元を定める

通常パッケージだけを社内レジストリに集約しても、モデルやMCPサーバー、スキル、プラグインを外部から直接取得できれば、供給網の管理は途中で切れる。最初に5種類の資産を同じ台帳へ載せ、種別ごとに承認済みレジストリ、正規の上流配布元、利用可能なプロジェクトを定める。

JFrogのAI Asset Scanningは、モデル、MCP、スキル、プラグインを索引化し、危険または悪意のある内容を検査する機能とされる。Markdownの指示、スキルのスクリプト、命令セットも意味解析の対象に含まれるため、既知の脆弱性やファイルハッシュだけでは捉えにくい振る舞いを取り込み時に調べる構成だ。

運用台帳には、資産名、種別、所有チーム、許可した取得先、検査結果、対象プロジェクト、例外の期限を残す。これは製品に依存しない設計原則であり、別のアーティファクト管理基盤を使う場合も、AI向け資産だけを審査外にしないことが要点になる。

第二の境界：名前ではなく版と内容を固定する

供給元が正規でも、可変タグやブランチだけを指定すると、承認後に内容が変わる可能性が残る。通常パッケージは完全なバージョンとロック情報、コンテナはダイジェスト、モデルは改訂識別子または成果物のハッシュ、MCPサーバー、スキル、プラグインはリリース版とチェックサムで固定するのが基本となる。

APM Registryは、プロンプト、スキル、MCPサーバーなどをパッケージとして版管理し、依存関係の追跡と固定バージョンを扱う位置付けである。重要なのは「最新版」を許可することではなく、検査を通過した同一内容を開発環境、CI、リリース工程で再現できる状態にすることだ。

• 通常パッケージ：取得レジストリ、完全なバージョン、整合性ハッシュ、依存ロック。
• モデル：配布元、モデル識別子、改訂版、成果物のダイジェスト。
• MCPサーバー：配布版、実行物のダイジェスト、公開するツール、必要権限。
• スキル：版、指示ファイルとスクリプトのハッシュ、許可する実行環境。
• プラグイン：発行元、版、署名またはチェックサム、対応するエージェント。

資産形式が不変参照を提供しない場合は、取得時のハッシュを台帳へ保存し、差分が生じた時点で再審査へ戻す。名称や配布URLだけでは、以前に検査した内容と現在取得できる内容が同一かを証明できない。

第三の境界：拒否規則をプロジェクト単位に分ける

全社共通の許可一覧だけでは、特定チーム向けに認めた資産や権限が別の開発環境にも広がる。Agent Guardは、AI Catalogの許可・拒否ポリシーをプロジェクト単位で開発ツール内に適用し、エージェントが利用できるAI資産を制御する機能として位置付けられている。

規則は「資産が承認済みか」だけで終わらせず、プロジェクト、エージェント、資産、操作の組み合わせまで分ける。例えば、あるMCPサーバーの参照操作を許可しても、書き込みや削除まで同時に認める必要はない。モデルの利用、スキルの実行、プラグインの導入も同じ境界で判定する。

拒否時の挙動も事前に定義する。処理を停止するのか、承認済みの代替版を提示するのか、期限付き例外の申請へ進めるのかを資産種別ごとに決め、監査記録にはエージェント、プロジェクト、対象版、適用規則、判定結果を残す。認証情報やプロンプト全文など、判定に不要な機密データまで保存しない配慮も必要になる。

第四の境界：公開レジストリへの迂回路を閉じる

社内レジストリにポリシーがあっても、開発端末やエージェントが公開レジストリへ直接接続できれば審査を回避できる。発表されたTraffic Controllerは、Cloudflare、Netskope、ZscalerなどのSASE製品と連携し、公開パッケージレジストリへの通信をネットワーク層で遮断してArtifactoryへ振り向ける構成である。

Agent Package Resolutionは、AIエージェントによる通常パッケージの取得先をArtifactoryへ案内する。ただし、JFrog公式GitHubの利用ガイド では、この機能はプレビューであり、セッション開始時の誘導自体はインストールを強制遮断しないと明記されている。強制力を持たせるには、パッケージマネージャーの永続設定、サーバー側のポリシー、ネットワーク制御を組み合わせる必要がある。

また、Traffic Controllerについて公表されている中心対象は公開パッケージレジストリである。Gitリポジトリや任意のWebサイトから配布されるMCP、スキル、プラグインまで自動的に遮断されるとは限らないため、それらの経路にはミラーリング、取得先制限、ハッシュ検証、外向き通信制御を別途適用する。

発表済みの機能と実際の強制力を分けて確認する

導入順は、まず資産分類ごとの許可元を決め、次に不変の版またはハッシュを指定し、その後でプロジェクト単位の拒否規則を設定する。最後に、開発端末、CIランナー、コンテナビルド環境、遠隔実行型エージェントから公開レジストリへ抜ける経路を閉じる。この順序なら、特定製品の設定項目が変わっても管理境界は維持できる。

一方、JFrogの発表は新機能群を顧客が直ちに利用できるとしているものの、Agent Package Resolutionの公式ガイドはプレビューと位置付け、誘導と強制遮断の違いを示している。したがって、個々の機能について、対象エディション、対応する開発ツール、一般提供かプレビューか、どの層で拒否を強制するかを契約環境ごとに確認しなければならない。

現時点で確認できるのは、通常パッケージとAI固有資産を一つの供給網として扱い、取り込み時の検査、固定版の管理、プロジェクト別の拒否、ネットワーク経路の統制を組み合わせる方針である。今後は、APM関連機能の提供条件、Agent Guardが対応するツールと操作の範囲、パッケージレジストリ以外の外部配布経路に対する強制手段が判断材料となる。