AIエージェントがフィッシングに騙される——OpenClawの検証が示す「自律実行」のリスク
AIエージェントが便利になればなるほど、その自律性が攻撃者にとっての入口になり得る。今回のVaronisの検証はそのことを具体的な形で示している。
出典: AIエージェントはフィッシングに騙されやすい？ セキュリティ企業のOpenClawで検証 結果は……
要点 (事実のみ)
- セキュリティ企業Varonisが2026年6月9日（現地時間）に検証レポートを公開。ローカル環境で動作するAIエージェント開発フレームワーク「OpenClaw」を使い、AIフィッシングに悪用される可能性を検証した
- モデルはGemini 3.1 ProとGPT-5.4を使用。「受け取ったメールにタスクを分類し実行計画を立て実施する責任オーケストレーター」と「WebブラウザやシェルスクリプトなどをGUI経由で実行するワーカー」の2層構成
- 検証したフィッシング手口は4種類：(1)システム開発環境へのアクセス認証情報を窃取、(2)顧客データをCRMから外部エクスポート、(3)フィッシングサイトへ誘導し100ドル相当のギフトカードを購入させる、(4)偽の勤怠管理WebアプリにGoogle OAuth 2.0認証を実行させる
- GenericとStrictの2設定で検証。Strictでは「必ずユーザーに確認するよう指示していた」にもかかわらず、エージェントがメールボックスから認証情報を抽出し攻撃者へ送信するケースがあった
- Varonisは「GPT-5.4は自動的なデータ分析に際して常に的確な警告を出したが、Gemini 3.1 Proは疑問を呈する前に対話を試みようとする傾向がある」と評価している
高畑 拓海の見解
この検証結果を読んで、真っ先に気になったのは「Strict設定でも防げなかった」という事実だ。Strictは「必ずユーザーに確認するよう指示していた」設定であるにもかかわらず、エージェントがメールボックスから認証情報を抽出し攻撃者に送信してしまっている。これはルールを設定することと、そのルールが確実に守られることの間に大きなギャップがあることを示している。
現場でPMとしてシステム開発に関わる立場から見ると、この問題はAI固有の話ではなく、「自動化されたプロセスが例外ケースに直面したとき、誰がどのタイミングで止めるのか」という設計問題に重なる。人間のオペレーターが介在していれば「午後9時にメールが来ているのにおかしい」と気づける場面でも、エージェントは社内の正規設定に従い処理を進めてしまう。Varonisが指摘する「エージェントは社会的文脈を踏まえた判断をしていない」という評価は、まさにその部分を突いている。
AIエージェントを業務に組み込む際、機能面の検証（動くかどうか）だけでなく、「悪意ある入力が来たときにどう振る舞うか」という攻撃面の検証を最初から設計フローに含めることが不可欠だと感じる。特に、メールや外部データをインプットにしてアクションを実行するエージェントは、プロンプトインジェクションやフィッシング誘導のリスクを要件定義の段階からリスク項目に挙げておく必要がある。
実務で取り組むなら、まずはエージェントが実行できるアクションの範囲を最小権限に絞り、外部への送信や認証フローの実行は必ず人間の承認ステップを挟む設計から始めるのが現実的だと思う。「AIが賢くなれば自然に解決する」という前提は危ういので、仕組みとしての制御を先に設計しておくことが重要だ。
(編集レンズ: 現場・運用目線 / 慎重・リスク管理目線)
