AIエージェント保護はゲートウェイより先にID管理を整備せよ

ゲートウェイを狙う攻撃

AIエージェント向けのゲートウェイは、API呼び出しを中継し、認証やポリシー適用を行うソフトウェアです。多くの企業がまずここに手を伸ばしますが、攻撃者も同じ場所を狙っています。記事は、そのゲートウェイが「最初に手を伸ばす制御だが、最も準備ができていない制御」だと指摘します。

実際、6月には、AIゲートウェイの一つであるLiteLLMにあった脆弱性が、米CISAの「既知の悪用脆弱性カタログ」に追加されました。この脆弱性は認証情報を必要とせず、別の脆弱性と連鎖させることで、ホスト上でコマンドを実行できたとみられます。同じ月に公開されたCVEは7件にのぼりました。

なぜゲートウェイが先では不十分か

認証情報が有効でも、そのAPI呼び出しが本当に許可された動作かどうかは、別の文脈がなければ判断できません。記事は、財務照合エージェントが本番データを書き換えようとする例を挙げます。ゲートウェイはユーザーのトークンを認証し、API呼び出しを検査できますが、その要求がエージェント由来か、委任された範囲内か、信頼できない成果物から呼び出されたツールチェーンかは見えません。

つまり、資格情報が有効でAPI呼び出しが許可されている場合、ゲートウェイはそれを止められない可能性があります。記事は、この問題の原因として、制御平面が、どのエージェントが動いているか、誰が委任したか、どのタスクを実行中か、どの認証情報を使っているかを把握していないことを挙げます。

6つのゲートで依存関係を整える

記事は、エージェントを本番運用するとき、セキュリティ制御を依存関係の連鎖として捉える「依存関係ゲート展開」という考え方を示しています。上流の出口テストを満たしてから、下流の制御を運用完了とみなす方式です。

具体的には、表の6つのゲートを順に通過する必要があります。実行時アクション強制は5番目に置かれ、ゲートウェイのような制御が最初ではなく5番目であると記事は説明します。

既存環境との整合が課題

記事が強調するのは、新規に制御を設計するのではなく、既に導入済みのID管理システムとどう組み合わせるかという「ブラウンフィールド」の問題です。既存のIAMがある企業では、どの順序で制御を重ねるかを決めるのが難しいとしています。

現時点で、この6つのゲートをどう実装するかという具体的な手順は記事には示されていません。各ゲートの運用証明として、例えば「完了したタスクを開始から影響先まで再構成できる」ことなどが挙げられています。導入事例や技術ガイドラインの公開が待たれます。