認証を通過したAIエージェントでも、ドリフト、データ漏洩、メモリ汚染のリスクがある

AIエージェントのデプロイメントにおいて、ゲートウェイは最初の制御層として導入されがちだが、準備が最も不足している層であることが明らかになった。これは、ゲートウェイがアイデンティティとアトリビューションのレイヤーの上に位置するが、それらが十分に整備されていないためである。実際に、LiteLLMの脆弱性が悪用され、CISAの既知の悪用脆弱性カタログに追加された。この脆弱性は、ゲートウェイ自体を通じてホスト上でコマンドを実行でき、別の脆弱性と組み合わせることで認証なしで悪用された。AIゲートウェイでは1ヶ月に7件もの共通脆弱性識別子(CVE)が報告されている。エージェントセキュリティアーキテクチャを検討する際、ゲートウェイ制御は最初の制御ではなく、5番目であるべきだ。多くの企業は、既存のアイデンティティおよびアクセス管理システムと連携した制御のレイヤリング順序を考慮せず、制御プレーンがどのエージェントが動作しているか、誰が委任したか、どのようなタスクを実行するか、どの認証情報を使用しているかを認識していない場合、コンテキストが不完全になる。ゲートウェイはポリシー違反をブロックできるが、正当なアクションと技術的に許可されているが運用上不適切なアクションを区別するのが難しい。この問題に対処するため、「依存関係で制御されたデプロイメント」というプロセスが提案されており、6つのゲート(エージェントインベントリと説明責任のある所有権、個別のエージェントIDと委任コンテキスト、タスクスコープの短期的な認証情報、属性可能なテレメトリ、実行時アクションの強制、行動ベースラインとクロスシステムキルパス)を定義している。これらのゲートは、エージェントのインベントリ作成から始まり、個別のID、タスクに限定された認証情報、追跡可能なテレメトリ、実行時アクションの強制、そして最終的に行動ベースラインとキルパスへと進む依存関係チェーンを形成する。既存のIAMシステムを置き換える必要はなく、エージェントレジストリの作成、短期的な認証情報の導入、ツールコールログへの識別子の含めることで対応可能である。最初の30日間で、10のプロダクションエージェントを対象に、所有者、目的、承認済みツール、認証情報を特定し、アトリビューションをテストすることが推奨されている。