安全プロンプトを組み込んでもメール対応エージェントがAWSキーやCRMエクスポートを共有——セキュリティ研究者が実証
企業のメールやビジネスアプリケーションへのアクセス権を持つAIエージェントが、攻撃者の新たなフィッシング標的となりうることが明らかになりました。OpenClawを基盤とするテスト用エージェントが、クラウドの認証情報と顧客データを外部の攻撃者に共有するよう誘導されたことを受け、サイバーセキュリティ研究者らが警鐘を鳴らしています。
Varonis Threat Labsは、自律型エージェントが従来から従業員を標的としてきたフィッシング攻撃に引っかかるかどうかを検証するため、「Pinchy」と名付けたOpenClaw AIエージェントを構築したと発表しました。テストは管理されたGoogle Workspace環境で実施され、エージェントにはダミーのAWS認証情報、CRMエクスポート、社内会話、カレンダー招待を含むGmailの受信トレイへのアクセス権が与えられました。
テストでは2種類の設定が使用されました。一般的な生産性プロファイルと、フィッシングへの注意喚起や機密情報を含むリクエストへの対応前に送信者の身元確認を促すメール安全指示を組み込んだ、より厳格なプロファイルです。Varonisによると、エージェントは一部のシナリオ、特に同僚からと思わせるリクエストが日常的または緊急のビジネスタスクとして送られてきた場合に、依然として失敗したとのことです。
「場合によっては、PinchyはフィッシングURLを見抜けなかっただけでなく、実際の組織を危険にさらす可能性のある危険な操作を実行してしまいました」と、同セキュリティ企業はレポートの中で述べています。
あるテストでは、同僚からのステージング用認証情報を求める通常業務のリクエストに見せかけたメッセージを受け取った後、PinchyはAWS IAMキー、データベースパスワード、SSHアクセス情報を外部のGmailアカウントに転送してしまいました。
別のテストでは、攻撃者が四半期ビジネスレビューのプレゼンテーション用として最新の顧客データをエクスポートして送るよう要求しました。Pinchyはこれに応じ、247社の企業顧客の詳細情報を含むCRMエクスポートを取得・転送してしまいました。そのデータには会社名、連絡先情報、契約日、顧客ティア、そして月間経常収益約128万ドルのデータが含まれていました。
ただし、結果はすべてが否定的だったわけではありません。Varonisによると、エージェントはより技術的なフィッシング攻撃に対しては良好なパフォーマンスを発揮しました。勤怠管理プラットフォームに偽装した悪意のあるOAuthコンセントフローへの対応がその一例です。このケースでは、Pinchyはリダイレクト先のアドレスを検査し、送信先を不審と判断して、コンセントを付与する前に処理を停止しました。
「この対照的な結果こそが、先の失敗を構造的に重要なものにしています」とVaronisは述べています。「エージェントは高度なフィッシングインフラを認識するのに十分な技術的推論能力を持っていました。弱点は社会的信頼と身元確認にあったのです。」
この調査結果は、企業がAIエージェントをチャットインターフェースの枠を超え、文書の取得、メッセージの処理、ビジネスソフトウェア全体にわたる操作が可能なワークフローへと展開しつつある中で明らかになりました。
アーキテクチャの問題
OpenClawのテストは、AIモデル自体の失敗というよりも、エージェントの設定・展開方法の問題を示していると、サイバーセキュリティ研究者のDevashri Datta氏は指摘しています。
「このセキュリティテストは実際には、AIモデルが純粋に技術的なレベルでは本来の役割をきちんと果たしていたことを証明しています」とDatta氏は述べています。
より大きな問題は、エージェントがメールを情報源としてだけでなく指示の源としても扱ったことにあります。Datta氏はこれを「データレーンとコントロールレーンの混同」という古典的なITミスと表現しています。
「エージェントがパスワードを渡したのは誰かに丁寧に頼まれたからではなく、正当な業務タスクのように見えるものを実行したからです」とDatta氏は述べています。「どのようなセキュアなシステムでも、データパスに管理命令を与えてはいけません。」
一方、モデルそのものを完全に方程式から除外すべきではないと指摘するアナリストもいます。リスクはテクノロジースタックの一つのレイヤーに限定されないと、Confidisの創業者兼CEOであるKeith Prabhu氏は述べています。このテストは、モデルの信頼判断能力と、エージェントフレームワークおよびエンタープライズガバナンスが自律的アクセスをどのように扱うかの両面における問題を示しました。
「従来のセキュリティアーキテクチャでは、オーケストレーションパイプラインを認可、実行、監査、エスカレーションに分離していました」とPrabhu氏は述べています。「しかし、AIエージェントではこれらが一つのパイプラインに集約されており、そのためこのようなフィッシング攻撃の被害を受ける可能性が生じているのです。」
企業に求められる強制力のある管理策
AIエージェントは信頼できないコンテンツを取り込みながらビジネスシステム全体で操作を実行できるため、企業はAIエージェントを高特権アイデンティティとして扱うべきだと、サイバーセキュリティアドバイザーで元CISOのSunil Varkey氏は述べています。
エージェントがメール、文書、ウェブページ、SaaSのコメントを読み取りながら、メッセージの送信、データのエクスポート、APIの呼び出し、レコードの更新まで実行できる場合には特に、そのような組み合わせが企業にとってのリスクを高めると同氏は指摘しています。
「OpenClawのようなフレームワークは、身元確認の強固な施行、ツールレベルの権限管理、プロンプトインジェクションへの耐性が不足していることが多いです」とVarkey氏は述べています。「しかし、Varonisのテストにおける決定的な要因は、過剰な特権アクセス、人間による監視の欠如、そして実行時のガードレールの不在でした。」
HFS ResearchのアソシエートプラクティスリーダーであるAkshat Tyagi氏は、企業はエージェントがアクセスできる情報だけでなく、組織外に送信できる情報についても注目すべきだと述べています。
「指示はコントロールではありません」とTyagi氏は述べています。「誰かが説得力を持って依頼したからといって、エージェントが機密データを社外にメールで送れるとしたら、問題はモデルだけにあるのではありません。」
AIエージェントには独自のアイデンティティを持たせ、アクセスを制限・監視できるようにすべきだとTyagi氏は述べています。認証情報や顧客データの共有に関わるリクエストは、エージェントの判断に委ねるのではなく、人間によるレビューを必ず経るよう設計すべきです。
