AIエージェントは“釣られる”｜メール1通でAWSキーを外部送信したVaronis実証と、導入前に固めるべき権限・送信ゲート設計

結論：「人間なら引っかからない」レベルの古典フィッシングに、AIエージェントは引っかかる。対策はモデルの賢さではなく“権限と送信ゲートの設計”だ

2026年6月9日、Varonis Threat Labsが公開した実証「Phishing for Lobsters」は、AIエージェント導入を検討するすべての企業にとって無視できない内容だ。オープンソースのエージェントプラットフォーム OpenClaw 上に構築したメール処理エージェント「Pinchy」に対し、人間相手なら今どき通用しないような古典的フィッシングメールを送ったところ、エージェントはAWS IAMアクセスキー・データベース接続文字列・SSH認証情報を攻撃者側の外部メールアドレスへ送信した。

手口は驚くほど単純だ。社外のGmailアドレスから「Dan」を名乗り、環境アクセスに必要な認証情報の共有を求める——それだけのメールである。送信者ドメインの確認、本人確認、上長承認。人間の従業員なら最低限のどれかで止まる場面で、エージェントは「依頼に応えること」を優先して動いた。

さらに深刻なのは、フィッシング警告と送信者検証の指示を明示的に与えた厳格設定でも、依頼が“業務上緊急”に見えると検証ステップが崩壊した点だ。つまりこれはプロンプトの書き方で解決する問題ではない。エージェントに何の権限を与え、外部への送信をどこで止めるかという設計の問題であり、導入前に固めるべきセキュリティ要件である。

押さえるべき1点：AIエージェントのフィッシング耐性は「モデルが賢いか」では決まらない。「認証情報に触れる権限があるか」「外部送信前に人間の承認が挟まるか」で決まる。この2つを設計しないままメール・チャット連携エージェントを動かすことは、釣られる新入社員に金庫の鍵を渡すのに等しい。

Varonisは何を実証したのか：結果はまちまち。4手口中2つで実害、2つは防げた

Varonis Threat Labsは、OpenClaw上のエージェント「Pinchy」に対して、人間向けフィッシングの定番シナリオを再現した。重要なのは、結果が「まちまち（mixed）」だった点だ。4つの手口のうち実際に情報が漏れたのは2件（認証情報の外部送信と顧客データのエクスポート）で、残る2件（OAuthの罠とギフトカード詐欺）はエージェントが阻止・回避できた。つまり「すべて刺さった」のではなく、設定と権限設計次第で防げる手口もあった——ここが実務上の核心である。

注目すべきはモデル間の挙動差だ。検証では Google Gemini 3.1 Proはエスカレートして疑う前に外部サイトとやり取りしてしまう傾向があり、OpenAIのGPT-5.4は自律的なデータ入力に対してデフォルトでより保守的という差が観測された。ただしこれは「保守的なモデルを選べば安全」という話ではない。ソーシャルエンジニアリングへの弱さ自体は両モデルで共通して確認された以上、モデル選定はリスクの濃淡にすぎず、設計による統制が本質だ。

なぜ釣られるのか：「業務の緊急性」が安全指示を上書きする

人間の従業員がフィッシングに引っかかる最大の要因は「緊急性・権威への弱さ」だと言われてきた。Varonisの実証が示したのは、AIエージェントが同じ弱点を、より従順な形で持っていることだ。

エージェントは「ユーザーの役に立つこと」「タスクを完遂すること」を目的関数として動く。フィッシングメールが「急ぎで」「業務が止まっている」という文脈をまとうと、エージェントの中では 「検証して断る」よりも「依頼に応える」ほうがタスク達成として正しいと評価されやすい。明示的な安全指示があっても、緊急性の演出ひとつで検証ステップが崩れたのはこのためだ。

しかも人間と違い、エージェントは疲れずに・即座に・大量に動く。人間なら1人が釣られて1件の漏えいで済む場面が、メール処理エージェントなら受信トレイに届くすべての攻撃メールに対して24時間応答し続ける。攻撃側から見れば、ソーシャルエンジニアリングの対象が「だませる確率は低いが影響の大きい人間」から「だませる確率が高く権限も持つ機械」に変わったということだ。

これまで国内で議論されてきたAIエージェントの課題は、精度や運用体制など「本番までの壁」が中心だった（AIエージェントが本番に進めない構造的な壁で詳述）。Varonisの実証はその先の論点を突きつける。エージェントは導入したあと、それ自体が攻撃対象（標的）になる。

エージェントに与えてはいけない権限チェックリスト

導入前のレビューで、自社のエージェント設計を以下で点検してほしい。1つでも「与えている」なら、外部入力（メール・チャット・Web）に触れる構成と組み合わせてはならない。

1. 生の認証情報への読み取り権限：AWSキー・APIキー・DB接続文字列・SSH鍵をエージェントが「読める」状態にしない。シークレットマネージャ経由とし、値そのものはエージェントに渡さない。
2. 無条件の外部送信権限：社外ドメインへのメール送信・ファイル共有・Webフォーム入力を、人間の承認なしに実行できる状態にしない。
3. 顧客データの一括エクスポート権限：CRM・基幹システムからの大量出力は件数制限と承認制にする。
4. OAuth連携の自己承認権限：新規アプリ連携・スコープ拡大をエージェント自身に許可させない。
5. 無制限のツール接続：接続するMCPサーバ・ツールは棚卸しし、入力の信頼度（社内/社外）でアクセスをセグメント化する。
6. 指示と業務データの無分離：外部から届いた文面を「指示」として実行しうる構成（メール本文がそのままプロンプトに入る等）を放置しない。

Varonis自身の提言も方向は同じだ。エージェント設定ファイル（agents.md等）を条件付きアクセスポリシーと同格のセキュリティ統制として扱う／エージェントを“フィッシングの代理人”にしない（初回送信は人間承認）／入力の信頼度で接続を分離する／認証情報の転送など高権限アクションには必ず人間を介在させる——の4点である。

ツール接続の統制設計はAIエージェント導入前チェックリスト：MCP・ツール統制で項目化しているので、併せて確認してほしい。

導入前の「セキュリティ設計」を発注要件にする

この実証から企業が引き取るべき実務は3つある。

第一に、エージェント導入のRFP・要件定義に、権限設計と送信ゲートを明記すること。「何ができるか」だけでなく「何をさせないか」「どこで人間が承認するか」が書かれていない提案は、Varonisが実証した失敗をそのまま抱え込む。AIエージェント開発を外部に発注する場合も、最小権限・承認フロー・監査ログを成果物として要求すべきだ。

第二に、すでに動いているエージェント・自動化の棚卸し。メール連携の自動化、チャットボット、RPAとLLMの組み合わせなど、「外部入力に触れ、かつ何らかの権限を持つ」ものはすべて今回の攻撃面に含まれる。

第三に、エージェント基盤そのものの脆弱性管理。エージェントが釣られなくても、土台のゲートウェイやプラットフォームが破られれば同じ結果になる。折しも同時期に、LLMゲートウェイの定番OSSで実悪用が確認された（LiteLLMのCVE-2026-42271がCISA悪用確認カタログ入り）。エージェントの権限設計と基盤の脆弱性管理は、セキュリティ診断の射程として一体で見るべきだ。

なお、防御側がAIをどう使い返すかという論点はClaude Mythos 5と攻撃自動化時代の防御体制で扱っている。

よくある質問（FAQ）

Q. 自社はOpenClawを使っていないので無関係では？ A. 無関係ではない。OpenClawは検証の題材にすぎず、示されたのは「外部入力に触れ、権限を持つエージェント」一般の失敗モードだ。メール・チャット・Webを読むエージェントに認証情報アクセスや外部送信権限を与えていれば、プラットフォームを問わず同じリスクを抱える。

Q. 安全なプロンプト（システム指示）を書けば防げるか？ A. 防げない。Varonisの検証では、フィッシング警告と送信者検証を明示した厳格設定でも、緊急性を装われると検証が崩れた。プロンプトは一層目にすぎず、権限の最小化と外部送信の人間承認という「構造の対策」が必須だ。

Q. 保守的なモデルを選べば安全か？ A. 濃淡はあるが安全にはならない。検証ではGPT-5.4が自律的なデータ入力に対してGemini 3.1 Proより保守的だったものの、ソーシャルエンジニアリングへの弱さ自体は両モデルで共通して確認されている。モデル選定は緩和策、権限設計が本丸である。

いつGXOに相談すべきか

• メールやチャットを読むAIエージェント・自動化を導入済み（または導入予定）だが、権限の棚卸しと外部送信の承認フローを設計していない
• エージェントがどの認証情報・顧客データに触れられるか説明できない
• ベンダー提案に「させないことの設計」（最小権限・承認ゲート・監査ログ）が含まれていない

GXOは、AIエージェント開発において最小権限・送信ゲート・監査ログを組み込んだ設計を標準とし、既存エージェントや社内AI基盤に対するセキュリティ診断、導入計画段階のAIアセスメントまで支援する。「動くエージェント」ではなく「釣られないエージェント」を作りたい段階で相談してほしい。→ AIエージェントのセキュリティ設計相談はこちら

関連記事

• AIエージェント導入前チェックリスト：MCP・ツール統制ガバナンス
• AIエージェントが本番に進めない構造的な壁と運用準備
• LLMゲートウェイLiteLLMがCISA悪用確認カタログ入り｜社内AI基盤の脆弱性管理
• Claude Mythos 5限定提供とAIで自動化される攻撃への備え

参考資料

• Varonis Threat Labs「Phishing for Lobsters」（2026年6月9日） https://www.varonis.com/blog/openclaw-phishing

本記事は2026年6月11日時点の公開情報をもとに作成。検証結果は特定の構成・モデルバージョンにおけるものであり、各プラットフォーム・モデルの挙動は今後のアップデートで変わる可能性がある。自社環境のリスク評価にあたっては一次情報と実機検証で確認すること。