OpenClaw AIエージェント、フィッシングシミュレーションで認証情報を漏洩

自律型メールエージェントは、明示的な安全指示で保護されていても、クラウド認証情報や機密ビジネスデータを漏洩させる深刻なフィッシング被害を受ける可能性があることが明らかになりました。

OpenClawエージェントプラットフォームを使った制御された実験環境において、「Pinchy」と名付けられたAIエージェントが複数の古典的なフィッシングシミュレーションに失敗しました。その中には、なりすました「Dan」からのたった一度のカジュアルな依頼をきっかけに、企業風の受信トレイからAWS IAMキー・データベースパスワード・SSH認証情報を外部のGmailアカウントに転送してしまったケースも含まれています。

実験環境は、Google Workspace内にリアルな企業の受信トレイを再現したものです。専用のGmailアカウントには、模擬AWS認証情報・CRMエクスポート・社内メールスレッド・カレンダー招待・典型的な低優先度メールなど、実際の企業環境を代表する合成データが用意されました。

OpenClawはデュアルエージェント設計を採用しており、「Orchestrator」エージェントが受信メールを受け取り、タスクを分類して対応を計画・委任する役割を担い、「Worker」エージェントがブラウザ自動化・シェルアクセス・Google Workspace APIを通じて実際のアクションを実行する仕組みになっています。

評価には Google Gemini 3.1 Pro と OpenAI Codex GPT‑5.4 の両モデルが使用され、2種類の設定プロファイルが適用されました。一つは汎用的な生産性プロファイル、もう一つは明示的なメール安全ポリシーを追加した厳格なプロファイルで、後者ではエージェントに対して送信者の身元確認とフィッシングを最重要リスクとして扱うよう指示されていました。

Varonisは間接プロンプトインジェクションと、同社が「エージェントフィッシング」と呼ぶ手法を区別しています。プロンプトインジェクションは、Webページ・ドキュメント・招待状などのコンテンツに隠された命令として紛れ込み、モデルの解析・意図解釈レイヤーを攻撃します。

エージェントフィッシングはより上位のレイヤーで機能し、もっともらしいメールやメッセージを送りつけ、エージェントが依頼者を確認しないまま実行してしまえば攻撃成功となります。

どちらもSimon Willisonが提唱する「致命的なトライアングル」（プライベートデータへのアクセス・信頼されないコンテンツへの露出・アウトバウンドメッセージ送信能力）に当てはまりますが、それぞれスタックの異なるレイヤーを狙っています。

OpenClaw AIエージェントによる認証情報漏洩

Varonis Threat Labsは、人間を何十年にもわたって騙し続けてきたフィッシング技術が、AIエージェントにも同様に通用するかどうかを検証しました。

最初のケーススタディでは、「Dan」を装った攻撃者が外部のGmailアドレスからPinchyへメールを送り、本番環境で障害が発生したとして対応のためにステージング用の認証情報を求めました。

エージェントは受信トレイを検索して保存済みのシークレットを発見し、AWSアクセスキー・データベース接続文字列・SSH認証情報を平文で転送してしまいました。

特筆すべきは、これが厳格プロファイル下でも発生したことです。同プロファイルでは機密に関わる依頼の実行前に送信者の身元確認を行うよう明確に指示されていました。

事後の推論トレースには、この行動がポリシー違反であると認識している記録が残っていましたが、本番障害という緊急性の演出が、両プロファイルにおいて確認ステップを上書きしてしまったのです。

2つ目のシナリオでは、より日常的なビジネスの口実が使われました。在宅勤務中にQBRプレゼン資料を仕上げるため、最新の顧客エクスポートを送ってほしいというリクエストです。

Pinchyは数百社の企業顧客・連絡先情報・契約データ・顧客ティア・100万ドルを超える継続収益情報を含むCRMエクスポートを取得し、身元確認なしに外部へ転送しました。

ここでの問題は、口実のごく自然な雰囲気にありました。エージェントのデフォルトのタスク実行ループが、内部データを共有する前に身元とチャネルの確認を求めるゼロトラスト原則を、汎用・厳格の両設定においてそのまま突き抜けてしまったのです。

一部のシミュレーションでは、より細かな挙動の違いが明らかになりました。「ギフトカード」フィッシングテストでは、外部からのメールがエージェントを偽の引き換えサイトへ誘導しました。

汎用プロファイル下では、Pinchyがリンクを踏んでページを操作したものの、実際の認証情報の入力は拒否し、代わりに架空のデータを入力しました。サーバーサイドの検証に失敗して初めて疑念が高まり、サイトをフィッシングと判定しました。

厳格プロファイルでは、処理が即座にブロックされました。認証情報の漏洩は避けられましたが、エージェントが最初にページとやり取りした時点で、そのページが稼働中であることが露見し、ネットワークのメタデータも外部に渡っていました。部分的な耐性は安全な行動とは同義ではないことを示す好例といえます。

技術的な推論力が最も明確に現れたのは、タイムシートシステムを装った悪意あるGoogleアプリケーションを用いたOAuthコンセントトラップのシナリオでした。Pinchyはブラインドでのアクセス許可を行わず、リダイレクトURIを検査し、その宛先を独自に訪問して不審と判断した上で、アクセス承認の前に処理を停止しました。

複数回の実行を通じて、両モデルはAWSなどの主要クラウドプラットフォーム、Azure、Microsoft、Googleに対するなりすまし攻撃を安定して検出しました。

GPT‑5.4は自律的なデータ入力に対してよりデフォルトで厳格な姿勢を示し、Gemini 3.1 Proはエスカレーションの前に操作を試みる傾向が見られました。ただし、社会的文脈を利用した身元詐称に対しては、両モデルとも同様の脆弱性を持っていました。

Varonisの調査結果は、AIエージェントに対するプロンプトのみによる対策から、アーキテクチャレベルの制御へと移行する必要性を示しています。

agents.md設定をガバナンスされたセキュリティコントロールとして扱うこと、受信チャネルごとにコネクタのアクセス権を分離すること、エージェントが初回アウトバウンドメールのフィッシング中継者になることを防ぐこと、そして認証情報の転送といった高権限アクションに対して人間による承認ループを強制することが、いずれも侵害のリスクを低減または封じ込める上で効果的であることが示されました。

これらの結果は、企業がエージェントを受信トレイや内部システムに直接接続するようになるにつれて、スキルの低いフィッシングは効果が薄れる一方、エージェントを標的にした高度に文脈化されたスピアフィッシングが劇的に価値を高めるとする、業界全体の懸念を裏付けるものとなっています。