セキュリティ研究者のJake Williams氏は今週、CUSTODYフレームワークを発表しました。これにより、企業は社内ネットワーク内で動作するAIエージェントに対して、明示的な実行時（ランタイム）権限と境界を設定できるようになります。このツールが重要な理由は、従来のソフトウェアとは異なり、AIエージェントは明確で強制力のあるポリシーなしに、動的にデータを取得したり、サービスを呼び出したり、モデルを変更したりできるため、攻撃者がすでに悪用し始めている隙間が生じているからです。

なぜAIエージェントに「フェンス」が必要なのか

現在の企業のAIスタックには、チャットボット、レコメンデーションエンジン、自律的な意思決定者、そして内部APIやサードパーティサービスからデータを取得する数十ものバックグラウンドエージェントが含まれています。既存のセキュリティスイートは、境界ファイアウォール、エンドポイント保護、ネットワークセグメンテーションに焦点を当てていますが、「このエージェントは顧客レコードを読み取ることができるが、財務データベースへの書き込みはできない」といった指示を行う標準的な手法が欠けています。このような実行時制御の欠如により、侵害されたエージェントがデータの持ち出しやモデルの重みの改ざんに利用されるといった事案がすでに発生しています。

CUSTODYがいかにしてその隙間を埋めるか

CUSTODYは、AIエージェントがネットワークに接続した後に許可される動作を記述する、ルールベースの言語を導入します。ポリシーでは以下を指定できます：

  • Resource access（リソースアクセス） – エージェントがクエリを実行できるデータベース、ファイルストア、またはAPI。
  • Action limits（アクションの制限） – エージェントが読み取りのみを行うのか、あるいは書き込み、削除、後続のジョブの実行も行うのか。
  • Execution context（実行コンテキスト） – CPU割り当てやコンテナの分離など、コンピューティング環境に関する制約。

実行時に、このフレームワークはエージェントの呼び出しをインターセプトし、設定されたポリシーと照合して、定義された境界を越える操作をブロックします。これにより、乗っ取られたエージェントが企業の環境内をチェックなしに徘徊することを防ぎます。

CUSTODYを既存のスタックに組み込む

このフレームワークは、現在のセキュリティツールと並行して動作します。人気のオーケストレーションプラットフォーム、コンテナランタイム、APIゲートウェイにフックすることができますが、具体的な手順は基盤となるエージェントプラットフォームによって異なります。組織は、AIインベントリをマッピングし、エージェントのクラスごとにポリシーファイルを記述し、本格的な導入前に強制レイヤーをテストする必要があります。数十のエージェントにわたってこれらのポリシーを拡張するには、モデルの進化に合わせてルールを最新の状態に保つための、専用の運用努力が必要となるでしょう。

注意点と反論

批判的な意見としては、CUSTODYはポリシーを自動生成しない点が挙げられます。セキュリティチームが手動で作成する必要があり、多大な労力を要する可能性があります。また、すべての呼び出しをリアルタイムで検査する場合、特にスループットの高い推論サービスにおいては、パフォーマンスのオーバーヘッドが発生するリスクもあります。最後に、このフレームワークの有効性は広範な採用にかかっています。ベンダーのAIプラットフォームが必要なフックを公開できない場合、CUSTODYの制御はバイパスされる可能性があります。

今後の注目点

  • ベンダーの対応 – 主要なAIプラットフォームプロバイダーが、CUSTODY互換のフックを組み込むか、独自の実行時ポリシーエンジンを提供するかどうか。
  • 標準化 – AIエージェントの権限に関する業界全体の仕様策定に向けた動きがあれば、CUSTODYが事実上の標準（デファクトスタンダード）となる可能性があります。
  • コミュニティのフィードバック – 初期導入者が、実際のポリシーの複雑さやパフォーマンスへの影響を明らかにし、将来のバージョン形成に寄与するでしょう。

AIエージェントに依存している企業は、今すぐCUSTODYを評価し、セキュリティスタックのどこに適合するかをマッピングし、次なるAI主導の攻撃がネットワークを襲う前に、ポリシーのパイロット運用を開始すべきです。