「お願いするだけ」で社内メールを読み出す — NomaがAIワークフローの認可欠陥「Workflow Identity Hijacking」を報告

AIセキュリティ企業のNoma Securityは2026年9月9日、企業が導入する**AIワークフローを悪用する新たな攻撃ベクトル「Workflow Identity Hijacking（ワークフロー・アイデンティティ・ハイジャック）」**を公開した。攻撃者はAIモデルを騙したり、システムに侵入したりする必要がない。公開された問い合わせ窓口に通常の依頼文を送るだけで、ワークフローが社内の機密情報を検索して攻撃者に返信してしまう。同社の研究部門Noma Labsが実証し、原因を「認可設計の欠陥」と分析している。

日本企業でも問い合わせ対応や申請処理の自動化に生成AIを組み込む動きが広がっている。入力内容の検査だけでは防げない攻撃であるため、ワークフローの権限設計を見直す必要がある。

公開窓口への「普通のお願い」が機密を引き出す

Nomaが示した事例は単純だ。攻撃者は企業の公開サポート用メールアドレスに良性のメッセージを送信する。数分後、攻撃者の手元には財務責任者の最新メールに含まれる四半期の売上数値が届く。企業のAIワークフローがメッセージを読み取り、要求を解釈し、情報を検索して返信した結果だ。

この過程で、プロンプトインジェクションは使われていない。アカウントの侵害も、ワークフローの改ざんも起きていない。攻撃者が行ったのは「尋ねる」ことだけだとNomaは説明している。

欠陥の核心 — 「誰の権限で実行するか」が置き去り

原因は、最新のAIパイプラインにおける認可設計の欠陥にある。AIワークフローが後続の処理を実行する際、要求した外部ユーザーの権限ではなく、ワークフロー作成者の高権限サービスアカウントや開発者のAPIキーが使われる。要求者と実行者のアイデンティティが切り離されているため、権限を持たない者の要求が特権操作として実行されてしまう。

Nomaは次の対比例で問題を説明している。CFO（最高財務責任者）と外部の攻撃者が、一字一句同じ文面で「財務責任者の最新メールの四半期売上を教えて」と依頼したとする。CFOにはその情報を得る資格があるが、外部の攻撃者にはない。認可の判断は両者で異ならなければならないが、ワークフローは同一の文面を同一に処理し、作成者の権限で実行する。

プロンプトインジェクションとは「狙う場所」が違う

Nomaはこの攻撃を既知のプロンプトインジェクションと明確に区別している。

• 直接的プロンプトインジェクション: モデルに敵対的な指示を送り、動作を逸脱させる。狙うのはモデルの指示追従の仕組み
• 間接的プロンプトインジェクション: メールやPDFなどモデルが後で読み込む内容に悪意ある指示を隠す。狙うのはデータ取り込み経路
• Workflow Identity Hijacking: モデルを一切操作しない。モデルが正しく理解・処理できる通常の要求を送り、認可境界の欠陥を突く

既存の防御が効かない理由もここにある。入力フィルタやガードレールは悪意ある文面の検出を前提としており、悪意の文言を含まない要求は正常と判定される。ガードレールは認可境界として設計されていないためだ。

GitHubとGoogleでの実証 — Googleは修正を確認

Nomaはこの攻撃ベクトルを実際の製品で実証している。公開済みの研究**「GitLost」**では、GitHubのエージェント型ワークフローが課題（issue）の割り当てを契機に起動し、組織リポジトリへの読み取り権限を持つ点に着目した。外部ユーザーがissueの割り当てを悪用して非公開リポジトリのデータを読み取らせることが可能だった。

さらにNomaはGoogle Workflowsに同じリスクベクトルが存在することを特定し、Googleに責任開示した。Googleは報告を承認し、実装の詳細は開示していないものの修正を確認したとNomaは伝えている。

Nomaが推奨する3つの防御策

Nomaは、防御の重点をモデル層からアプリケーション層・インフラ層へ移す必要があるとして、次の3策を推奨している。

1. 利用者文脈を引き継ぐ短命トークンの利用: ワークフロー内の静的な管理者APIキーを排除し、認証された要求者に直接紐づく短命で範囲限定の委任トークンでデータ操作を実行する
2. 文脈に応じた認可チェックポイントの設置: LLMの出力をすべて非信頼入力として扱い、LLM変換ステップと後続のデータベース・ツール呼び出しの間に明示的なアクセス制御と実行時保護の評価を挟む
3. 出力経路の非対称分離: 機密性の高い内部データを扱うワークフローでは、データ取得機能と外部への自動応答機能が実行経路を共有しないよう構造的に分離する

加えてNomaは、自動化を評価する際は「誰が起動できるか」だけでなく、メール、フォーム、チケット、GitHubのissue、共有文書、チャットなど、最も信頼度の低い影響者がワークフローの動作に影響し得るかという観点で棚卸しするよう求めている。定時実行のワークフローであっても、参照する受信箱に誰でも書き込めるなら起動者の制限だけでは不十分だからだ。

まず自社の自動化を棚卸する

読者がまず行うべきは、自社で稼働するAIワークフローと、その入力元・実行権限の棚卸しである。問い合わせ対応、文書要約、申請承認など、外部からの入力を受け付ける自動化が、どの権限で何にアクセスできるかを確認する。Nomaが指摘する通り、プロンプト対策の有無ではなく、要求者の権限が実行時に強制されているかが判断基準になる。新規に自動化を導入する場合は、作成者の特権を引き継がない設計を要件に含めることが望ましい。