セキュリティ企業Varonisは、オープンソースのAIエージェントフレームワーク「OpenClaw」を使ったメールエージェントに対し、人間向けの古典的フィッシング手法が通用するかを検証した。結果、AWSのIAMキーやデータベース認証情報、顧客CRMデータが外部のGmailアカウントへ送信されるという深刻な問題が確認された。

OpenClawとは何か

OpenClawはLLM（大規模言語モデル）がリアルワールドのシステムと連携して自律的にアクションを実行できるオープンソースフレームワークだ。今回の実験では、このフレームワークを使ったエージェント「Pinchy」をGmailインボックス、Googleブラウザツール、Google Workspace APIに接続し、AWScredentials、データベース認証情報、CRMエクスポート、社内メール、カレンダーといった合成エンタープライズデータにアクセスできる環境を構築した。

動作モデルはGoogleのGemini 3.1 ProとOpenAIのGPT-5.4の2種。設定は「標準（Generic）」と「フィッシング対策・本人確認手順を明示した厳格（Strict）」の2プロファイルで比較された。

4つのシミュレーション結果

シナリオ1：緊急対応を装った認証情報要求

攻撃者がチームリーダーになりすまし、本番障害対応を口実にステージング環境へのアクセスを依頼。エージェントはAWS IAMキー、データベース認証情報、SSHアクセス詳細を外部Gmailへ送信した。厳格設定でも防げなかった理由は「業務上の緊急性」が本人確認ステップを無効化したためだとVaronisは分析している。

シナリオ2：リモート作業を口実にした顧客データ要求

「プレゼン資料作成のため顧客エクスポートが必要」という内容のメールに対し、エージェントは送信者の本人確認をせずに顧客レコード、連絡先情報、契約詳細、売上データを含むCRMエクスポートを送信した。こちらも厳格設定で防げなかった。

シナリオ3：ギフトカードフィッシングリンク

標準設定のエージェントはフィッシングサイトを訪問し、偽認証情報でギフトカード換金を試みた後に不正ページと判断した。厳格設定はリンクアクセスを即時ブロックし、防御に成功。

シナリオ4：悪意あるOAuthアプリ

勤怠管理プラットフォームを装った悪意あるGoogle OAuthアプリに対し、エージェントはOAuthフローを検査・分析して不審と判定し、アクセス許可を拒否した。両設定ともに防御成功。

AIが苦手な攻撃パターンとは

Varonisの分析によれば、AIエージェントは次のものを検知するのが得意だ：

  • 不審なURLの識別
  • フィッシングログインページの検出
  • 悪意あるOAuthアプリの認識

一方、苦手とするのは：

  • 送信者の本人確認（メールアドレスの正当性検証ができない）
  • コンテキストの喪失（会話が続くうちに当初の判断基準を忘れる）
  • ソーシャルインタラクションへのゼロトラスト適用（「緊急だ」「上司だ」という言語的権威に弱い）

モデル特性では、Geminiがより積極的にインタラクションしようとした一方、GPT-5.4はより慎重な姿勢を示したという。

実務への影響——日本のエンジニア・IT管理者が今すぐ確認すべきこと

AIエージェントを業務システムに接続する構成はすでに多くの企業で検討・導入段階に入っている。この実験は他人事ではない。

最小権限の徹底が最優先：エージェントに与えるアクセス権は業務上必要な最小限に絞り込む。AWSクレデンシャルや顧客DBへの読み取り権限を同一エージェントが持つべきではない。

高リスクアクションには必ず人間承認を挟む：認証情報の共有、外部への大量データ送信、初めての外部送信先への連絡は、エージェントが単独実行できないよう設計する。

新規外部アドレスへの送信を禁止または承認制に：エージェントが「新しい外部宛先」にメールを送れる設定は攻撃の出口になる。ホワイトリストまたは承認フローを必ず実装する。

エージェントの設定を定期的にペネトレーションテストする：厳格設定であっても万全ではないことが今回示された。定期的なシミュレーションで設定の穴を炙り出す仕組みを持つこと。

筆者の見解

この実験結果を見て真っ先に感じたのは、「AIエージェントにゼロトラストが適用されていない」という構造的な問題だ。

人間のアカウントに対してはゼロトラスト、条件付きアクセス、多要素認証を徹底しながら、同じシステムに接続するAIエージェントには「信頼してから動く」設計を許してしまっている。これは矛盾だ。Non-Human Identity（NHI）として扱われるべきエージェントにも、人間と同等のゼロトラスト原則——「すべてのリクエストを検証する」「最小権限を維持する」「侵害を前提として設計する」——が必要なはずだ。

「緊急だから」「上司からだから」という言語的権威に対してエージェントが弱いのは当然でもある。人間でも同じ罠にはまる。だからこそ人間側にはプロセスと承認フローがある。エージェントにも同じ仕組みが要る。Just-In-Timeアクセスや、高リスクアクション前の人間承認ゲートは、エージェント設計において今後の基本要件になるべきだろう。

AIによる業務自動化を進めるほど、NHI管理の精度が組織全体のリスク水準を決める。今はまだ多くの組織でそこへの意識が追いついていない。今回のVaronisの実験はその現実を可視化した点で価値がある。

出典: この記事は OpenClaw AI agent found falling for phishing attacks, spills user data の内容をもとに、筆者の見解を加えて独自に執筆したものです。