OpenAI Workspace Agentsの脆弱性：1つのChatGPTリンクで不正なAIエージェントを作成可能

研究者らが、1つのChatGPTリンクによって被害者のアカウント内に攻撃者が制御するエージェントを作成できることを発見した後、OpenAIはWorkspace Agentsの脆弱性を修正しました。このエージェントは、既存のアプリへのアクセス権を継承し、承認プロンプトを無効化し、5分ごとに新しい指示を取得できました。信頼された作業を委任するために構築された機能が、永続的な内部オペレーターへと転用され得るという、極めて直接的な矛盾が生じていました。

Zenity Labsはこの攻撃をAgentForgerと命名し、2026年7月23日に調査結果を公開しました。同社は6月4日にOpenAIへこの欠陥を報告しました。Zenityの開示タイムラインによると、OpenAIは翌日に報告を受理し、6月8日に修正を適用しました。

現在、攻撃者がこの欠陥を実際に悪用したことを示す証拠はありません。実証された攻撃は、セキュリティ研究者が実施した概念実証でした。しかし、その仕組みは、企業向けAIエージェントが掲げる中心的な約束、すなわちエージェントが何を構築し、何にアクセスし、何を承認するかをユーザーと管理者が引き続き制御できるという前提に疑問を投げかけます。

OpenAI Workspace Agentsの脆弱性は、単なる悪意あるプロンプトではありませんでした。認証済みのChatGPTセッション、事前に承認されたコネクター、スケジュール実行、攻撃者が制御する指示を組み合わせたものでした。この組み合わせにより、生成されたエージェントは正規の職場自動化と同様の外観と権限を持つことになりました。

この違いは、OpenAI、Microsoft、Google、Salesforceなどのベンダーが提供するエージェントを導入する企業にとって重要です。セキュリティシステムは通常、ユーザー、デバイス、アプリケーションセッション、OAuth権限付与を追跡します。有効なユーザーと承認済みの接続を介して動作するエージェントは、こうした分類にうまく当てはまらない可能性があります。

直接的なバグは修正されました。しかし、より困難な問題は未解決のままです。組織は、自律型エージェントがユーザーの実際の意図を反映していることを、どのように検証すべきなのでしょうか？

OpenAI Workspace Agentsの脆弱性はどのように機能したのか

AgentForgerは、初期化機能を、認証済みChatGPTセッション内で不正にエージェントを構築するプロセスへと変えました。

OpenAI Workspace Agentsは、反復可能なビジネスワークフロー向けに設計されています。ユーザーはタスクを記述し、接続済みアプリケーションを選択し、承認を設定し、ワークフローをテストして公開し、スケジュールを設定できます。OpenAIのワークスペースエージェントガイドでは、人間が起動する実行とスケジュールによって起動する実行の両方が説明されています。

通常の状況では、これらの手順により、ユーザーにはエージェントを確認する機会が複数与えられます。ユーザーは指示を確認し、ツールを制御し、機密性の高い操作に承認を必須とし、公開するかどうかを決定できます。

Zenityは、エージェントビルダーがURLパラメーターを介して初期化状態を受け入れることを発見しました。1つのパラメーターはテンプレートを選択し、initial_assistant_promptと呼ばれる別のパラメーターはビルダーへの指示を提供していました。

重大な挙動は、2番目のパラメーターに関係していました。Zenityの技術分析によると、ページが読み込まれると、ビルダーはその内容を自動的に送信して実行しました。ユーザーが確認できるようにテキストを表示するだけではありませんでした。

そのため攻撃者は、正規のものに見えるchatgpt.comリンク内に操作指示を埋め込むことができました。対象となる被害者がリンクをクリックすると、ChatGPTはその人の認証済みセッション内でビルダーを開きました。攻撃者はChatGPTドメインを偽装したり、最初にユーザーのパスワードを盗んだりする必要がありませんでした。

実証された攻撃は、3つの重要な条件に依存していました。被害者がChatGPTにサインインしていること、Workspace Agentsを利用できること、そして少なくとも1つの事前承認済みコネクターがあることです。そのコネクターは、ChatGPTをOutlook、Gmail、Slack、Teams、Google Drive、SharePointなどのサービスに接続するものでした。

これらの要件により、脆弱性の影響を受ける対象は限定されます。Workspace Agentsや接続済みの業務アプリケーションを持たない一般のインターネットユーザーでは、同じ攻撃経路は成立しません。しかし、これらの機能が有効化された企業ワークスペース内では、アクティブなエージェントユーザーの間で条件が揃っている可能性があります。

事前承認により、攻撃はさらに目立ちにくくなりました。偽造されたエージェントは、被害者がすでに承認したコネクターを再利用したため、新しいOAuth同意フローを開始する必要がありませんでした。OAuthは、ユーザーがあるサービスに別のアカウントへのアクセス権を付与するための標準的なプロセスです。

概念実証のプロンプトは、利用可能なコネクターを接続し、それらの承認設定を変更するようビルダーに指示しました。さらに、新しいエージェントを公開し、複数の反復スケジュールを作成するよう指示していました。

これらのスケジュールは時間をずらして設定され、実質的に5分ごとに実行されるようになっていました。各実行では、特定の件名プレフィックスを持つ攻撃者からのメッセージが被害者のメールボックスにないか確認しました。エージェントは一致する各メールを新しい指示として扱い、結果をメールで返信しました。

公開後、エージェントはブラウザータブを常時開いておく必要がありませんでした。スケジュールに従って起動し、次の指示を読み取り、接続済みサービスを使用し、調査結果を返信できました。この設計により、1回のクリックが継続的な指令チャネルへと変換されました。

AgentForgerは、認証済みブラウザーに意図しない操作を実行させる攻撃である、クロスサイトリクエストフォージェリ、すなわちCSRFに似ています。違いは、作成される対象にあります。従来のCSRFは多くの場合1回の取引を引き起こしますが、AgentForgerは将来の取引を独立して実行できるシステムを作成しました。

Zenityによると、OpenAIは4日以内にこの脆弱性を解消しました。迅速な修正により、開示後の直接的な露出期間は短縮されました。ただし、研究者が報告する以前に、この挙動がどの程度の期間存在していたかは明らかになっていません。

5分間隔の指令ループが危険度を変えた

危険な結果は最初のブラウザー操作そのものではなく、最初のクリック後も変化する命令を受け入れられる自律型オペレーターが生まれたことでした。

従来のフィッシングリンクは通常、認証情報の窃取、マルウェアの配信、または即時の取引の実行を目的としています。防御側は、ページへのアクセスを調査し、アクセス先をブロックし、アカウントをリセットし、悪意あるプログラムを削除できます。

AgentForgerは異なるパターンに従いました。ChatGPTリンクは、OpenAI自身のドメイン上でエージェント作成ワークフローを開始しました。その結果生まれたエージェントは、被害者がすでに接続していたサービスを介して動作しました。

これにより、永続性は正規のクラウドプラットフォーム内へ移行しました。永続性とは、最初の侵害後も攻撃者がアクセスを維持する能力です。このケースでは、スケジュールされたエージェントの実行によって、エンドポイントにマルウェアをインストールすることなく、その継続性が確保されていました。

メールはコマンド＆コントロールチャネルとして機能しました。コマンド＆コントロールとは、攻撃者が侵害したインフラストラクチャに指示を送り、結果を受け取る仕組みを指します。偽造されたエージェントは指定されたメッセージを監視し、その内容を実行し、承認済みのメールコネクターを介して返信しました。

5分間隔の実行は、攻撃者の選択肢も変えました。悪意ある指示は、リンクを送信する前に有用な標的をすべて予測しておく必要がありませんでした。攻撃者は、組織についてより多くの情報を得た後でタスクを調整できました。

Zenityの概念実証では、エージェントを使用して、人物、役割、プロジェクト、会議、社内コミュニケーションチャネルを把握しました。その後、研究者らはファイル、メッセージ、認証情報、なりすましのシナリオへと対象を広げました。

あるテストでは、エージェントが接続済みストレージとメール内から機密性の高い業務資料を検索しました。Zenityによると、買収条件規定書、取締役会向けプレゼンテーション、従業員情報などの文書が特定されました。これらの例は、報告された顧客への侵害ではなく、研究者らの管理された環境から得られたものです。

別のテストでは、パスワードらしき内容をSlackメッセージから検索するようエージェントに指示しました。Zenityの影響の実証によると、エージェントは一致した結果を整理し、攻撃者のメールアカウントへ返しました。

研究者らは、TeamsとSlackを通じた社内フィッシングもテストしました。メッセージは被害者の接続済みIDを介して送信されるため、受信者は信頼できる社内コミュニケーションだと認識する可能性がありました。

ここで、攻撃による潜在的な影響範囲は最初のユーザーを超えて広がります。偽造されたエージェントは、1人のIDを使用して同僚に接触し、共有リポジトリを検索し、使い慣れた社内チャネル内で説得力のある要求を作成できます。

Zenityは、不正な支払い要求を伴うビジネスメール詐欺のシナリオも実証しました。このテストは、完遂された金融犯罪ではなく、実行可能なワークフローを示したものです。AgentForgerが実際の送金を引き起こしたという公的な証拠はありません。

中核的なリスクは、情報の集約から生じました。人間の攻撃者がメール、ストレージ、カレンダー、チャットの内容を関連付けるには、それぞれへの個別のアクセスが必要になる場合があります。ワークスペースエージェントは、これらのシステムを統合された作業コンテキストとして横断的に推論するよう設計されています。

この能力は、正当なタスクにおいて有益です。エージェントは、ユーザーが各アプリケーションを手作業で検索しなくても、会議、メッセージ、文書からプロジェクト概要を作成できます。一方で、エージェントが悪意ある指示に従った場合、同じ連携能力が偵察活動を加速させる可能性があります。

OpenAIは、アプリケーションにアクセスするエージェントが機密情報に到達し、ユーザーに代わって操作を実行できると警告しています。同社のエージェント安全ガイダンスでは、プロンプトインジェクションをプライバシー上のリスクとして挙げ、確認、監視、拒否動作、監督付きブラウジングの制御について説明しています。

AgentForgerは、この問題の別の層を明らかにしました。悪意ある入力は、文書やウェブページを通じて、すでに実行中のエージェントに単に影響を与えただけではありません。エージェント自体の構築と設定を担うシステムに影響を与えました。

この違いにより、企業の購入者にとっての重大性が増しました。エージェントビルダーは、目的、権限、承認、スケジュールを確立する役割を担うはずでした。実証されたフローでは、攻撃者が提供した言語によって、その4つすべてが形成されました。

中心的な対立は能力と制御の間にある

Workspace Agentsは自律性が高まるほど有用になりますが、委任される能力が増えるたびに、誤った意図や偽造された意図による損害も大きくなります。

OpenAIはWorkspace Agentsを、承認済みツールと接続し、職場データを横断して動作し、スケジュールに従って実行できる再利用可能なシステムとして提示しています。これらの機能によって、エージェントはユーザーの現在のメッセージに回答するだけの従来型チャットボットとは区別されます。

その価値提案は、人間による反復的な介入を減らすことに依存しています。ユーザーが毎朝同じワークフローを一から組み立て直す必要はありません。スケジュールされたエージェントは、更新情報の収集、活動の要約、定型的な成果物の準備を自動的に行えます。

セキュリティ制御は、機密性の高い局面で人間による介入を復活させることがよくあります。エージェントはデータを自動的に読み取れる一方、メールの送信、スプレッドシートの編集、カレンダーイベントの追加を行う前に承認を求めることがあります。こうしたチェックポイントは、低リスクの作業における自律性を維持しながら、重大な影響を伴う操作を制限します。

OpenAI Workspace Agentsの脆弱性は、ビルダーがセキュリティ上重要な設定に関する自然言語の指示を受け入れていたため、この分離を損ないました。エージェントのタスクを定義するのと同じプロンプトによって、コネクターの承認設定を「今後確認しない」に変更できたと報告されています。

これにより、循環的な信頼の失敗が生じました。承認設定は、エージェントの将来の操作を制約するためのものでした。しかし、エージェント構築プロセスは、悪意あるURLから与えられた指示に従って、それらの設定を変更できました。

問題は、自然言語が本質的に安全ではないということではありません。会話形式の設定により、ワークフローコードを書けない従業員でもエージェントを利用できるようになります。その一方で、通常のタスク指示と管理上の変更との間に曖昧さも生じます。

従来のエンタープライズソフトウェアでは、コンテンツと制御が分離されていることが一般的です。通常、文書内で変更について記述しただけで、アプリケーションの権限ポリシーが変更されることはありません。エージェントビルダーは意図的に記述内容を実際に動作する設定へ変換するため、この従来の境界が弱まります。

OpenAIによると、エンタープライズ管理者は、誰がエージェントを使用、構築、共有できるかを制御できます。同社の製品発表では、Compliance APIによってエージェントの設定、更新、実行を可視化できることも説明されています。

これらの制御は重要ですが、答えているのは別の問いです。ロールベースアクセスは、ユーザーにエージェントの構築が許可されているかどうかを判断します。AgentForgerが提起したのは、許可されたビルダー操作が実際にそのユーザーの意図を反映していたかという問題です。

被害者の有効なIDにより、偽造されたエージェントの分類は困難になりました。認証情報からは、ユーザーがサインインしていたことを確認できます。コネクタの記録からは、ユーザーが以前にアクセスを許可していたことを確認できます。プラットフォームのログからは、承認されたワークスペース内でエージェントが作成されたことを確認できます。

それぞれのシグナルは技術的には正確であっても、操作全体としては未承認のままである可能性があります。欠けていた特性は意図の完全性、つまり、その人物が生成されたエージェント、権限、スケジュールを認識したうえで承認したことを示す証拠でした。

この緊張関係はOpenAI以外にも当てはまります。Microsoft Copilot Studio、Googleのエンタープライズ向けエージェント製品、Salesforce Agentforceなどのプラットフォームも、モデルを業務データやアクションと接続しています。アーキテクチャはそれぞれ異なるため、AgentForgerを、同じ欠陥がほかの製品にも存在する証拠として扱うべきではありません。

しかし、より広範な設計上の課題は共通しています。エージェントには、ID、ツール、指示、トリガー、実行権限が必要です。セキュリティチームは各構成要素を個別に監視するだけでなく、その組み合わせを監視しなければなりません。

無害な指示と広範な権限を持つエージェントは、目的が変更されれば危険になり得ます。悪意のある指示を受けていてもツールを持たないエージェントは、影響範囲が限定されます。信頼できない入力、非公開データへのアクセス、外部への送信チャネルが同時に存在すると、リスクは急激に高まります。

セキュリティコミュニティでは、この組み合わせを「致命的な三要素」と呼ぶことがあります。AgentForgerは、攻撃者が制御する入力、承認済みコネクタ、メールによるデータ流出という3つの要素をビルダー経由で組み立てました。

これは、企業がエージェントによる自動化を放棄すべきだという意味ではありません。エージェントの作成は、アプリケーションのデプロイ、サービスアカウントのプロビジョニング、スケジュール済みジョブの作成と同様に扱う必要があるということです。いずれも組織内に永続的に動作する主体を生み出します。

ナレッジワーカーにとっても、教訓は同様に具体的です。アシスタントをより多くの職場情報に接続すれば、コンテキストが充実し、手作業での検索を減らせます。一方で、アシスタントのIDと設定の背後にアクセス権が集中します。

AIワークフローを構築するチームは、可能な限り情報収集と外部アクションを分離すべきです。承認済みの情報源を要約するエージェントは、メッセージの送信、記録の変更、ファイルの公開も行えるエージェントよりリスクが低くなります。

迅速なパッチだけではガバナンスの欠落は埋まらない

OpenAIは報告された脆弱性を修正しましたが、正当なものに見えながら所有者の利益に反して動作するエージェントに対し、組織は依然として制御策を必要としています。

Zenityが公開したタイムラインによると、OpenAIの対応は迅速でした。この問題は6月4日に報告され、6月5日にトリアージおよび受理され、6月8日に修正されました。Zenityが調査結果を公開したのは、それから6週間以上後です。

この流れは、研究者が技術的な詳細を公開する前に、ベンダーへ問題を解決する時間を与える協調的脆弱性開示を反映しています。これにより、プラットフォームの修正より先に公開手順が広まる可能性が低減されました。

SecurityWeekも独自にこの開示を報じ、AgentForgerを標的に合わせて作られたCSRF脆弱性と説明しました。同社のセキュリティ記事では、フィッシングリンクのクリック、認証済みセッション、Workspace Agentsへのアクセス、既存のコネクタ承認が必要だったことも指摘されています。

ただし、公開されている証拠には限界があります。Zenityは研究環境で攻撃を実施しました。外部の攻撃者がOpenAIの顧客に対してAgentForgerを使用した既知の事例はありません。

「不正なAIエージェント」という表現も、誤った印象を与える可能性があります。モデルが自発的にユーザーへ反逆することを選んだわけではありません。人間の攻撃者が目的を与え、プラットフォームの弱点によって、その目的が承認済みエージェントの動作を形成できるようになったのです。

この捉え方は、実用的な防御策につながるため重要です。このインシデントは、認可、設定の完全性、可視性、ソーシャルエンジニアリングに関するものです。機械が独立した意図を持つという仮定は必要ありません。

したがって、組織はパッチを唯一必要な対応と見なすべきではありません。将来の脆弱性は、別のビルダーフィールド、コネクタワークフロー、共有機能、トリガー機構を標的にする可能性があります。プラットフォームレベルのエクスプロイトがなくても、設定ミスによって同様の結果が生じる可能性があります。

管理者はまず、エージェントの信頼できるインベントリを必要とします。このインベントリには、各エージェントの所有者、指示、コネクタ、承認ポリシー、トリガー、共有範囲、最近のアクティビティを記録する必要があります。

作成イベントには特に注意が必要です。新しいエージェントが直ちに複数のアプリケーションへ接続し、承認を抑制し、自身を公開し、定期スケジュールを設定した場合は、精査の対象とすべきです。個々の選択は単独では正当であっても、その一連の流れは異常です。

スケジュール済みのアクティビティにも、責任を負う所有者が必要です。企業がサービスアカウントや自動化ジョブを定期的にレビューするのは、誰も監視していない間も動作し続けるためです。Workspace Agentsにも同じライフサイクル管理が必要です。

コネクタの権限は最小権限の原則に従い、各エージェントにはタスクに必要なアクセス権だけを付与すべきです。ユーザーが以前に承認したすべてのコネクタを再利用すると、不必要に影響範囲が広がり、インシデントの封じ込めが難しくなります。

プラットフォームが許す場合は、読み取りアクセスと書き込みアクセスを分離すべきです。要約のために情報を収集するエージェントが、外部メールの送信や共有文書の変更を行う権限まで自動的に必要とするわけではありません。

影響の大きいアクションには、独立した承認制御を維持すべきです。さらに重要なのは、通常のエージェント指示だけで、別途確認することなくこうした制御を弱められないようにすることです。

セキュリティチームにはランタイム検知も必要です。構築時のレビューだけでは、エージェントの将来の指示が安全であり続けることを保証できません。監視では、異常なデータアクセス、想定外の外部受信者、認証情報の検索、大量取得、新たな社内メッセージングパターンを特定する必要があります。

これらのシグナルでは、エージェント自体を動作主体として扱わなければなりません。人間のアカウントだけを記録すると、本人の対話的な操作と、自動化されたエージェントのスケジュール実行との違いが見えなくなる可能性があります。

インシデント対応手順では、従業員のアカウント全体を無効化せずにエージェントを停止できるようにすべきです。また、対応担当者は、エージェントが使用したコネクタ、アクセスしたデータ、送信したメッセージを特定できる必要があります。

ユーザー教育にも依然として役割がありますが、「不審なリンクをクリックしない」だけでは不十分です。AgentForgerのリンクには、本物のChatGPTドメインが使用されていました。従業員は、認証済みリンクにも状態が含まれ、重大な結果を伴うワークフローが開始され得ることを認識する必要があります。

より安全なインターフェースでは、その結果を可視化すべきです。リンクを開くことでビルダーがエージェントを作成、公開、スケジュールする場合、プラットフォームは攻撃者が制御するコンテンツとは別の場所で明示的なレビューを要求すべきです。

最も強力な確認方法は、信頼できるインターフェース上のテキストで、最終的な設定を要約することです。有効化する前に、エージェントの指示、アプリケーション、権限、承認ポリシー、スケジュール、共有範囲を表示します。

エージェントのセキュリティは人間のIDの枠を超える

このインシデントにより、セキュリティチームは、エージェントを従業員アカウント配下で動作する単なる機能ではなく、永続的なデジタル主体として管理することを迫られています。

IDおよびアクセス管理では従来、ユーザーやサービスにリソースへアクセスする権限があるかどうかを確認してきました。エージェント型システムでは、別の問いが加わります。その権限を使用している自律的プロセスは何か、どのような目的で使用しているのか、現在誰の指示下にあるのかという問いです。

従業員がOutlookを承認するのは、ChatGPTがメールの要約を支援するためかもしれません。その承認は、今後作成されるすべてのエージェントがメールを読み、メッセージを送信し、メールで届いた指示をレビューなしで実行してよいことを必ずしも意味しません。

継承されたアクセス権によって、この区別が曖昧になる可能性があります。偽造されたエージェントが被害者として動作すると、接続先のアプリケーションには、承認済みの連携機能から送られた有効なリクエストに見える場合があります。そのリクエストが新たに作成された自律型ワークフローから発生したことを、接続先が認識できない可能性があります。

エンドポイントを中心に構築されたセキュリティ製品にも、同様の死角があります。エージェントは従業員のノートPC上ではなく、ベンダーのクラウド内で実行される可能性があります。エンドポイント検知では、最初のブラウザアクセスは観測できても、その後の各スケジュール済みアクションは観測できない場合があります。

ネットワーク制御でも、コンテキストを見落とす可能性があります。信頼されたクラウドサービス間の接続は、通常の通信に見えることがあります。不審な要素は、明らかに悪意のあるネットワーク送信先ではなく、エージェントの目的、スケジュール、アプリケーション横断的な動作にあります。

これにより、エージェント固有のテレメトリの必要性が高まります。管理者は、作成記録をランタイムイベント、コネクタ呼び出し、承認変更、外部への出力結果と結び付ける必要があります。

OpenAIのドキュメントによると、Workspace Agentsは公開前にテストでき、チームと共有でき、Slack経由で使用できるほか、スケジュール実行やAPIによるトリガーも可能です。それぞれの実行経路には、異なる監視要件があります。

手動でトリガーされるエージェントでは、開始時にユーザーがその場にいます。スケジュール済みエージェントは、所有者がオフラインでも実行できます。APIでトリガーされるエージェントは、別の自動化システムから指示を受け取る可能性があります。

組織は、こうしたトリガーに応じてリスクを割り当てるべきです。長時間動作するエージェントや外部からトリガーされるエージェントには、アクティブなユーザーリクエスト中にのみ動作する単純なアシスタントより厳格なレビューが必要です。

共有によって、さらに別の層が加わります。ある人物のIDで作成されたエージェントが、同僚やより広いワークスペースで利用可能になる場合があります。セキュリティチームは、共有先のユーザーが作成者のアクセス権を継承するのか、それとも各自の権限で動作するのかを把握しなければなりません。

ガバナンスでは、指示の変更も考慮すべきです。ある目的で承認されたエージェントでも、プロンプト、コネクタ、スケジュールが変更されると、実質的に別物になる可能性があります。重大な変更が行われた場合は、再レビューを実施すべきです。

このアプローチは、本番ソフトウェアの変更管理に似ています。一度レビューされたデプロイであっても、将来のすべてのバージョンが恒久的に承認されるわけではありません。セキュリティに関わる変更があれば、新たな判断が必要になります。

エンタープライズ製品の購入者は、こうした制御についてベンダーに直接質問すべきです。管理者はすべてのエージェントを一覧化できるか。指示やトリガーを確認できるか。自然言語による指示を通じてエージェントが承認設定を変更することを防止できるか。

また、ログで人間のアクションとエージェントのアクションを区別できるかも確認すべきです。有用な監査記録には、どのエージェントが動作したか、どの指示が実行を開始したか、どのコネクタを使用したか、どの承認が適用されたかを記録する必要があります。

調査時には保存期間も重要です。詳細なエージェントのアクティビティが短期間で消去されると、不審なワークフローを発見した後に、対応担当者がデータアクセスや外部通信を再構築できなくなる可能性があります。

複数のプラットフォームを横断するエージェントでは、この問題がさらに難しくなります。単一のエージェントが、メール、メッセージング、ストレージ、カレンダー、業務システムを組み合わせることができます。個々のアプリケーションからは、一連の動作全体を把握できません。

したがって、エージェントプラットフォームには、意図とオーケストレーションを示す最も有力な証拠が存在する可能性があります。アプリケーションベンダーにも、自動化されたリクエストを識別し、独自のポリシーを適用するために十分なメタデータが必要です。

規制当局や監査人も、いずれ同じ帰属の問題に直面するでしょう。エージェントが具体的な手順を選択した場合でも、企業は自社が承認したシステムを通じて実行された行為に対する責任を負います。

AgentForgerは、被害者が報告されていなくても有益な警告となります。これは、攻撃者が接続された各アプリケーションを個別に侵害する必要がない可能性を示しています。オーケストレーション層を制御すれば、それらをまとめて危険にさらすことができます。

AgentForger以降に注視すべき点

次の試金石は、エージェントプラットフォームが意図を検証可能にし、エージェントの活動を可視化し、継承されるアクセス権をデフォルトで必要最小限にできるかどうかです。

最初に注視すべき兆候は、OpenAIがエージェントの作成や設定変更をどのように扱うかです。公開、スケジュール設定、アプリケーションへの接続、または承認要件の緩和を行う前には、より厳格な確認が必要です。そうなれば、同社がエージェントの意図を独立したセキュリティ境界と捉えているという結論が裏付けられるでしょう。

2つ目の兆候は、管理者向けの可視性の向上です。OpenAIによれば、管理者はWorkspace Agents向けのガバナンス管理機能とコンプライアンスデータを利用できます。購入企業は、完全なインベントリ、検索可能な設定履歴、エージェント単位の活動記録、直接的な停止機能が提供されるかを注視すべきです。

可視性が向上すれば、組織は偽造された、あるいは設定を誤ったエージェントが反復的な操作を実行する前に発見できます。ログが限定的であれば、顧客が次の攻撃チェーンを独自に検出できるという信頼性が損なわれるでしょう。

3つ目の兆候は、競合する企業向けエージェントプラットフォームがどのように対応するかです。Microsoft、Google、Salesforceなどのベンダーは、同様の問題に直面するのに同じURLの欠陥を抱えている必要はありません。各社の対応では、ビルダーが外部入力をどのように検証し、承認設定を保護し、人間の意図と自動設定を区別するのかを明確にすべきです。

組織は、こうした変更を待つ必要はありません。エージェント構築へのアクセスを制限し、コネクターの権限範囲を縮小し、定期実行されるエージェントを見直し、外部への送信や破壊的な操作について承認ゲートを維持できます。

さらに、自社の検出に関する前提を検証することもできます。複数のコネクターを備えた新たに公開されたエージェントは、アラートに表示されるでしょうか？スケジュール実行による外部へのメールの反復送信は、通常の従業員の活動とは異なるものとして認識されるでしょうか？

OpenAI Workspace Agentsの脆弱性は修正されており、悪用されたことを示す公開情報はありません。しかし、エージェントプラットフォームが単なる会話型インターフェースではなく実行環境になりつつあるため、そこから得られるより大きな教訓は今なお重要です。

信頼できるドメインであっても、埋め込まれたすべての指示が信頼できるとは限りません。有効なアイデンティティがあっても、すべてのエージェントが所有者の意図を反映していることは証明できません。承認済みのコネクターであっても、その権限が将来どのように使用されても正当化されるわけではありません。

開発者、企業の購入担当者、ナレッジワーカーにとって、実務上の問いは今やシンプルです。自分のアカウントを通じて動作するすべての自律型エージェントを把握し、それぞれが各権限を持つ理由を説明できるでしょうか？

別のシステムを接続する前に、そのインベントリを確認してください。スケジュール、承認ポリシー、外部の受信者、休眠状態のエージェントをチェックしてください。そのうえで、エージェントの作成をセキュリティイベントとして扱う管理機能をベンダーに求めてください。

それこそが、次のワークスペースエージェントのリリースが満たすべき基準です。