何が起きたか
Zenity Labsは、OpenAIのWorkspace Agents(2025年に導入されたAgent Builder)で、URL 1本から自律型AIエージェントを密かに作成できる脆弱性を発見しました。同社はこれを「AgentForger」と名付けています。従来のクロスサイトリクエストフォージェリ(CSRF)が「1つのリクエスト」を偽造するのに対し、AgentForgerは「エージェントまるごと」を偽造する点が新しさです。
仕組みは単純です。Agent Builderのページ(chatgpt.com/agents/studio/new)はtemplate_nameとinitial_assistant_promptという2つのURLパラメータを受け取ります。問題は、initial_assistant_promptの値を入力欄に置くだけでなく、そのプロンプトを自動で送信・実行してしまった点にあります。
発動条件は、被害者がChatGPTにログイン済みで、Workspace Agentsにアクセスでき、Outlook・Gmail・Slack・Google Drive・SharePoint・Teamsなどのコネクタを1つ以上認可済みであること。既に接続済みのため、新たなOAuth同意画面は表示されず、被害者への警告は出ません。
偽造されたエージェントは何をしたか
デモでは、埋め込まれたプロンプトがBuilderに番号付きのタスクリストを実行させ、接続済みのnon-MCPコネクタをすべて統合したうえで、読み取り・書き込み・削除のすべての承認要件を「Never ask.(確認しない)」に変更しました。作られたのは「TASK Mail Operator」という名前のエージェントです。
このエージェントは5分ごとに起動し、件名に「TASK」を含む攻撃者からのメールをOutlookで確認、指示を実行して結果を送り返すよう設定されました。12個の時間差スケジュールを組み合わせて実質5分間隔を実現し、受信箱そのものを指令チャネル(C2)に変えたのです。ZenityはPreview Mode(プレビューモード)がドライランではなく、実際の接続アカウントに対し設定済みの承認ポリシーで実行されるため、初回から承認を求めず動いた点を指摘しています。
実際に抜き取られた情報
「TASK 1: RECON」の指示で、エージェントはOutlook・Slack・Teams・Drive・SharePoint・Calendarから組織図を作成。さらにM&Aのタームシート、未達の売上目標と人員削減計画に触れた取締役会資料、報酬情報を含む全社員名簿を発見しました。「DLP演習」を装った指示ではSlackを「pass:」で検索し、見つかったDBのユーザー名とパスワードを平文でメール送信。加えて$242,500の送金承認依頼やBEC(ビジネスメール詐欺)、SSO偽ログインページへの誘導など、被害者の信頼された身元を悪用した攻撃も再現されました。
なぜ起きたか
Zenityは原因を2つの設計判断に帰しています。1つはBuilderがinitial_assistant_promptを「確認が必要なユーザー入力」ではなく「実行可能な入力」として扱ったこと。もう1つは同じプロンプトが承認ポリシーや実行スケジュールなどのセキュリティ設定まで変更できたことです。同社はこれを「the lethal trifecta(致命的な三点セット)」——URLが信頼できない入力を供給し、コネクタが機密データへのアクセスを与え、メールが持ち出し経路になる構図——と表現します。
Zenityは2026年6月4日にOpenAIのBugcrowd経由で報告し、OpenAIは翌日に確認、6月8日に該当URLパラメータを削除して修正しました。
💼 事業会社視点：これは自社にどう効くか
日本企業でMicrosoft 365やGoogle Workspace、Slackを全社導入し、そこにChatGPTのエンタープライズ連携を重ねている組織は、修正までの間そのまま影響範囲でした。とりわけ情報システム部門がコネクタ認可を「一度許可すれば安全」と捉えているEC・SaaS・受託開発の現場は要注意です。今回の本質は、攻撃者が被害者の正規IDと既存の許可をそのまま使い、OAuth同意も承認画面も飛ばした点にあります。従来のセキュリティ製品は「ユーザーとエンドポイント」を守る設計で、Zenityが言う「agent trust failure(エージェントの信頼の破綻)」——正規IDで動く自律エージェントの逸脱——は検知しにくい。役員・事業責任者が今週動くべきは3点です。第一に、AIエージェント作成ツールが承認ポリシーやスケジュールを「プロンプトで書き換え可能」にしていないかの棚卸し。第二に、コネクタ認可の棚卸しと最小権限化、そして「Never ask」設定の禁止ルール化。第三に、送金承認や機密検索などの高リスク操作は、エージェントであっても人間の二重承認を必須にする運用設計です。SaaSを提供する側なら、URLパラメータを実行入力として扱わない設計監査が競争優位の防御線になります。