AIエージェント、認証だけでは守れない理由

AIエージェントのセキュリティ対策として、多くの企業がまず「ゲートウェイ」と呼ばれる通信の入口を管理するツールを導入する。しかし、このゲートウェイはセキュリティ対策の出発点として選ばれやすい一方で、実際の運用に最も不向きなコントロールでもある。その根本的な理由は、ゲートウェイが前提とするはずの「誰がアクセスしているか」を識別する仕組みが、多くの現場でまだ整っていないことにある。

この問題が机上の話ではないことは、実際のセキュリティインシデントが示している。2025年6月、米サイバーセキュリティ機関CISAは、AIゲートウェイソフトウェア「LiteLLM」の脆弱性を「既知の悪用された脆弱性」リストに追加した。この脆弱性はゲートウェイ経由でホストOS上のコマンドを実行できるもので、別の脆弱性と組み合わせると認証なしで悪用可能だった。さらに、LiteLLMでは1カ月の間に合計7件のCVE（共通脆弱性識別子）が公開されており、多くの企業がAIエージェント保護の「最初の砦」として選んでいるゲートウェイ自体が、深刻な攻撃対象になり得ることが示された。

では、セキュリティ対策はどの順序で積み上げるべきか。ゲートウェイによる制御は「最初の一手」ではなく、「5番目の制御」として位置づけるべきだという考え方がある。AIエージェントのセキュリティは依存関係の連鎖で成り立っており、各制御は上流で生成された文脈（コンテキスト）に依存する。制御の基盤となるべき「どのエージェントが動いているか」「誰が作業を委任したか」「どのタスクを実行するか」「どの認証情報が使われているか」という情報が揃っていなければ、ゲートウェイは明白なポリシー違反しか弾けず、技術的には許可されていても業務上は不適切な操作を見逃してしまう。

具体的なリスクはこうだ。たとえば財務照合を担うエージェントが本番データのレコードを変更しようとした場合、ゲートウェイはユーザートークンを認証しAPIの呼び出しを確認できる。しかし、その要求がエージェント起点であること、エージェントが限定的な機能しか持たないこと、そしてその操作が信頼されていない外部データによって引き起こされたツールチェーンの一部であることは、ゲートウェイには見えない。認証情報は有効で、API呼び出しも許可されているにもかかわらず、操作の目的からは逸脱している。コストのかかる制御が、全体像のごく一部にしか機能していない状態だ。

また、エージェントの権限を担当する人間の権限以内に制限することは有効な原則だが、それだけでは十分ではない。20のエージェントが1人のユーザーの権限で動作しているケースでも、それぞれに固有のID、監査ログ、行動プロファイル、失効経路が必要になる。権限の上限を設けることと、個別の帰属（アトリビューション）を確立することは、まったく別の問題だ。

この課題は「既存システムへの後付け」という現実とも深く関わっている。多くの企業ではすでに何らかのIAM（アイデンティティ・アクセス管理）システムが稼働しており、そこにAIエージェントを組み込む順序が問われる。理論的なセキュリティ成熟度モデルは将来必要な制御を列挙しがちだが、現実の「既存環境への適用順序」という、より難しい問いに答えられていないという指摘がある。

AIエージェントの活用が広がる中で、セキュリティの議論は「何を導入するか」から「どの順序で積み上げるか」へと移りつつあると見ることができる。ゲートウェイは重要な制御のひとつだが、それが機能するための前提条件——エージェントの識別、委任関係の追跡、行動文脈の記録——が先に整備されていなければ、実効性は限られる。エージェントの本番運用に向けて、こうした「依存関係に基づいた段階的な展開」の視点が、今後のセキュリティ設計で重要になるという見方ができる。