研究者らは、ユーザー権限が下流で適切に適用されない場合、信頼されたAIエージェントが特権アカウントの代理として悪用され得ると警告しています。
Noma Labsの調査によると、新たに特定されたAI攻撃手法により、認証を受けていないユーザーが特権ワークフローを引き起こし、企業システムにアクセスできる可能性があるといいます。この手法は、AIエージェントに対してIDおよびアクセス制御がどのように適用されるかという点に存在するギャップを浮き彫りにしています。
Noma Labsの主任研究者Sasi Levi氏が執筆したレポートでは、この問題を「ワークフローID乗っ取り（workflow identity hijacking）」と説明しています。攻撃者は、サポート用受信箱、GitHubのissue、Webフォーム、共有文書といった認証を経由しない入口から、一見普通で無害なリクエストを送信することで、標準的な制御を回避します。
「エンタープライズAIパイプラインは入力を読み取り、リクエストを解釈し、設計どおりにそのアクションを実行します」とLevi氏はレポートに記しています。「根本的な問題は、リクエストを行った者にそのリクエストを行う権限がそもそもなかったという点にあります」
ワークフロー層で崩れる認可の仕組み
この問題の核心にあるのは、Levi氏が「現代のエンタープライズAIパイプラインにおける認可設計上の欠陥」と表現するものであり、リクエストを行った者のIDと、アクションの実行に使われるIDが一致しないという点にあります。
「ワークフローを起動したユーザーのIDと権限は、それを実行するために使われるIDと権限から切り離されています」と同氏は記しています。実際には、ワークフローが起動元ユーザーのアクセス権を適用する代わりに、「高い権限を持つサービスアカウントや開発者用APIキーを使って」アクションを実行することを意味します。
その結果、AIワークフローは「特権アクションのための無認証な代理役、そして静かなデータ流出の経路」として機能しかねない、とレポートは指摘しています。
サイバーセキュリティ研究者でレッドチーム担当者でもあるVibhum Dubey氏は、この問題はよく知られている種類の認可の脆弱性を反映していると述べています。
「認証されていない入力が信頼されたワークフローを引き起こすことができ、かつそのワークフローが自身の権限を使ってアクションを実行するのであれば、そのワークフローは実質的に『混乱した代理人（confused deputy）』として振る舞うことになります」
同氏はさらに、多くの導入環境では「ワークフローが下流で機微なアクションを実行する際、元のリクエスト送信者の権限が必ずしも再評価されるわけではない」と付け加えています。
同じリクエストでも、権限はまったく違う
レポートでは、異なる主体から送られた同一のリクエストを例に、このリスクを説明しています。
「2つの同一の入力を考えてみましょう」とLevi氏は、幹部社員のメールから財務データを求める問い合わせを例に挙げて記しています。「プロンプトと要求されている操作は同一ですが、認可の判断はまったく異なるべきものです」
「CFOにはその情報を得る権利がありますが、外部の送信者にはありません」
入力そのものは無害であるため、「標準的なプロンプトインジェクション検知ツールやエージェントのガードレールは、これらの入力を同一のものとして分類してしまいます」と同氏は指摘します。「セキュリティ上のリスクはプロンプトにあるのではなく、認可の境界線にあるのです」
モデルは正しく動作しているのに、システムはそうではない
レポートによると、この手法はプロンプトインジェクション攻撃とは異なり、モデルの挙動を操作することに依存していません。
「攻撃者はモデルをまったく操作する必要がありません」とLevi氏は記しています。「モデルは指示どおりに正しく動作し、ワークフローもあらかじめ定義された実行経路どおりに正しく動作します」
問題が生じるのは、ワークフローが結果として生じたアクションを、「元のリクエスト送信者が権限を持っていたかどうかを確認しないまま、ワークフロー作成者のIDまたは権限を使って」実行してしまう時です。
この違いにより、問題の本質はモデルのセキュリティから、相互に接続されたシステム全体でIDと権限がどのように適用されるかという点へと移ります。
正当な活動に見えてしまう
アクションは有効な認証情報を用いて信頼されたワークフローを通じて実行されるため、こうした活動は従来型のセキュリティアラートを発生させない可能性があります。
「セキュリティ上のリスクはプロンプトにあるのではありません」とレポートは指摘し、むしろワークフローが「攻撃者が本来持っていない権限」をどう使うかにあるとしています。
Dubey氏は、これが防御側にとって検知上の課題を生むと述べています。
「個々のイベントは完全に正当なものに見えてしまいます。有用な兆候となるのは、元のリクエスト送信者、下流で使われたID、アクセスされたリソース、渡されたパラメータ、そして最終的なアクションを相関させることから得られます」
Dubey氏はさらに、こうした相関分析なしでは、不正アクセスが日常的な自動化処理に紛れ込んでしまう可能性があると付け加えています。
攻撃者がエージェント型ワークフローを取り入れることでリスクが拡大
この発見のタイミングも、その重要性を高めています。企業がAI主導の自動化を拡大する一方で、攻撃者側も同様の多段階ワークフローを使って攻撃を実行し始めているのです。
Google Threat Intelligence Groupは最近のブログ記事で、プロンプトベースの悪用から、環境をまたいでタスクを計画・実行できる、より自律的でエージェント駆動型の攻撃への移行が進んでいると説明しています。
この進化により、Nomaのレポートで強調されているのと同じ実行層、すなわちシステムを接続しユーザーに代わって動作するAIワークフローへの依存が高まり、IDと認可の適用における隙間が生む影響がさらに拡大することになります。
モデルの枠を超えた制御へ
Noma Labsは、このリスクを緩和するにはセキュリティ制御をモデル層の枠を超えて、アプリケーションおよびインフラの設計に組み込む必要があると述べています。
「こうしたAIワークフローのリスクを緩和するには、セキュリティ制御をモデル層からアプリケーション層およびインフラ層へとシフトさせる必要があります」とLevi氏は記しています。
レポートでは、アクションが実行される時点でIDを意識したアクセス制御を適用することを推奨しており、その中には「ユーザーコンテキストの伝播」や、AIが生成した出力と下流の操作との間に「明示的なアクセス制御・実行時保護の評価ステップ」を設けることが含まれます。
Dubey氏は、この問題を検証する一つの方法として、権限レベルの異なるユーザー間で結果を比較することを挙げています。
「下流のシステムがワークフローのIDしか見ていないために、権限の低いユーザーが管理者と同じ結果を得られてしまうようであれば、そこが調査すべきポイントだと考えます」
Gyana Swain is a seasoned technology journalist with over 20 years’ experience covering the telecom and IT space. He is a consulting editor with VARINDIA and earlier in his career, he held editorial positions at CyberMedia, PTI, 9dot9 Media, and Dennis Publishing. A published author of two books, he combines industry insight with narrative depth. Outside of work, he’s a keen traveler and cricket enthusiast. He earned a B.S. degree from Utkal University.
