【ITニュース解説】A CVE About AI Agent Permissions Made Me Re-Check What Our Own Agent Could Touch

GitLabのAI Gatewayで発覚した、認証済みユーザーがゲートウェイ上でコマンドを実行できてしまう深刻な脆弱性（CVE-2026-90970）は、筆者に自身の会社のAIエージェントシステムを見直すきっかけを与えた。当初、筆者は自社には関係ないと考えていたが、念のため自社のシステムを詳細に調査することにした。

筆者の会社では、ログの読み取り、社内APIへの問い合わせ、コード変更の提案、問題のあるサービスの再起動といった業務を自動化するため、AIエージェントを導入していた。このエージェントは、内部ゲートウェイサービスを介して社内システムと連携していた。ゲートウェイはAIモデルからの指示を実際の操作に変換する役割を担い、インターネットには一切公開されず、社内ネットワークからのみアクセス可能で、VPNの背後に設置されていた。このため、外部からの攻撃を受ける心配はないと筆者は確信していた。

しかし、監査を進める中で、この安全だという認識が揺らぎ始めた。まず、筆者はゲートウェイにGitLabの脆弱性と同じような、不十分な認証でコマンドが実行されてしまう問題がないかを確認した。ネットワーク経路を再確認し、外部からのアクセスがないことを改めて確認したため、一旦はこれで問題なしと判断しかけた。次に、エージェントの役割ごとに許可されたツールを定義したpermissions.yamlファイルが存在し、これによって権限が管理されていると筆者は考えていた。設定ファイルには役割と許可/不許可が明記されており、いかにも機能しているように見えたが、実際の調査では、この権限が「肝心な場所」では全くチェックされていないことが判明した。

真の脆弱性は、権限チェックが「オーケストレーション層」と呼ばれる部分でのみ行われていたことにあった。この層は、AIモデルに対して「どのようなツールが利用可能か」という選択肢を提示する役割を担う。例えば、ある役割のエージェントに「サービス再起動」が許可されていなければ、このツールはモデルに提示されるリストに含まれない。しかし、ゲートウェイの「実際のコマンド実行エンドポイント」は、送られてきたリクエストがすでに上流でフィルタリングされていると信頼し、一切の再確認を行っていなかった。問題は、この権限チェックを行うオーケストレーション層を迂回してツール呼び出しが生成される経路が存在したことである。それは「リトライロジック」の中に潜んでいた。AIエージェントからのツール呼び出しがタイムアウトした場合、システムは応答時間を短縮するため、リトライハンドラーがこの呼び出しを「直接」ゲートウェイの実行エンドポイントに再送信していた。この時、権限チェックを行うオーケストレーション層のパスは完全に迂回されていたのである。これは、表面上はサーバー側で権限が強制されているように見えていたものが、実際にはAIモデルの指示に従うコンポーネントの「意図」に依存しているだけであり、システムによる強制が働いていなかったことを意味する。結果として、もしAIエージェントのセッションが（悪意がなくても）何らかの理由で混乱したり、巧妙な指示を通じて意図せず迂回経路を突いたりした場合、リトライパスを通じてゲートウェイ自身のサービスアカウントが持つ「あらゆる特権的な操作」を実行できてしまう状況にあった。これは、単にAIがサービス再起動を手伝う以上の、より広範囲で深刻な被害につながる可能性を秘めていた。

この脆弱性に対処するため、筆者のチームは二つの重要な修正を行った。一つ目は、権限チェックを「迂回できない唯一の場所」、すなわち「コマンド実行エンドポイント自体」に移動することだった。具体的には、すべての実行パス（リトライを含む）が必ず呼び出す関数を導入し、この関数が、呼び出し元の役割が指定されたツールを実行する権限を持っているか、ツール自体が存在するか、そして提供された引数が正規表現で定義されたパターンに合致しているか、という厳格なチェックを行うように変更した。これにより、権限の抜け道がなくなった。二つ目の修正は、より根本的な対策として、AIエージェントの各セッションに「共有された特権的な認証情報」を一切与えないことだった。単一のサービスアカウントを全てのエージェントセッションで共有していると、一つのバグや巧妙な指示によって、そのアカウントがアクセスできる全てのシステムに影響が及ぶリスクがある。このリスクを排除するため、筆者の会社は、エージェントの各タスクごとに「短命で使い捨ての独立したサンドボックス環境」を割り当てる方式に移行した。これは、エージェントの実行ごとに隔離された仮想マシンを立ち上げ、その仮想マシンは外部へのネットワーク接続のみを許可し、社内の実際のシステムには一切アクセスさせず、数分で使い捨てられる仕組みである。この方法により、もしエージェントが不正な動作をしたとしても、その影響は使い捨ての仮想マシン内に完全に閉じ込められ、社内の重要なインフラに被害が及ぶ心配がなくなった。

この経験から得られた教訓は非常に価値がある。まず、上流で一度だけチェックされ、下流で無条件に信頼される権限設定は、単なる「善意の提案」に過ぎず、真の「強制力」を持たない。次に、リトライ処理、フォールバック、高速パスなど、通常のリクエストフローを迂回するような経路は、システムの「第二の入り口」となりうるため、通常の権限チェックが適用されなくなる可能性がある。これらの迂回経路は特に注意深く監査し、セキュリティが確保されているかを確認する必要がある。さらに、「インターネットに公開されていないから安全だ」という認識は、システムの潜在的な危険性を過小評価する可能性がある。外部からのアクセスが不可能でも、一度内部からシステムに到達できてしまった場合、「それが何を実行できてしまうか」という問いは全く別のセキュリティ課題を生む。公になった脆弱性は、自社のシステムが持つ「全ての攻撃面」を見直す良いきっかけとなるだろう。そして、AIエージェントが意図しない、あるいは不正な動作をしてしまうリスクに対する最も現実的な解決策は、その影響範囲を、実際のインフラストラクチャではなく「使い捨ての隔離されたサンドボックス」に確実に閉じ込めることである。AIエージェントを実際のインフラで運用している場合、通常時だけでなく、リトライパスのような「想定外の経路」で何が起こるかを必ず確認することが極めて重要だと筆者は強調している。