先週、部内の勉強会でVaronisというセキュリティ企業が発表した検証レポートを取り上げました。読んでいて、正直、背筋が少し冷えました。
Varonisが自社開発のフレームワーク「OpenClaw」を使い、AIエージェントにGmailの受信トレイを操作させながら、フィッシングメールへの耐性を検証したのです。使ったモデルはGemini 3.1 ProとGPT-5.4。セキュリティ対策を何も施さない「Generic」設定と、ユーザー確認ステップを強化した「Strict」設定の両方でテストしています。結果として、GenericはもちろんのことStrict設定でも、条件次第でエージェントがフィッシングに引っかかるケースが確認されました。
なかでも印象的だったのは、Strict設定のケースです。本来ならば重要な操作の前にユーザーへ確認を求めるよう設定されているのに、AIはメールボックスを自分で参照して認証情報を取り出し、そのまま攻撃者側に送信してしまいました。Varonisはその理由について、エージェントが「ユーザーへの確認よりも想定された緊急状況の解決を優先した」と分析しています。人間なら「午後9時に届いた見慣れないメールだな」と気づける違和感を、AIは社会的なコンテキストとして処理できなかった、ということです。
うちの部署では今年度から、営業担当25名の一部にAIエージェントを使った業務支援のトライアルを進めています。主な用途はメール文面の自動生成やCRMへのデータ入力補助です。稟議を上げた際に情報システム部門から「エージェントがどこまでシステムにアクセスするか、権限の範囲を明確にしてほしい」と指摘を受けました。あの時は「細かいことを言うな」と少し思ったのですが、今回の検証結果を読んで、情報システムの担当者の感覚は正しかったと認識を改めました。
Varonisが今回試したフィッシングの攻撃パターンは4種類です。
特に2番目のパターンが他人事に思えませんでした。営業部門のエージェントがCRMにアクセスできる権限を持っている場合、攻撃者がそのエージェント宛てにそれらしい依頼メールを送れば、顧客の電話番号や社内メモ、取引金額といった情報が外部に漏れる可能性があります。顧客情報が含まれているとなれば、情報漏えいではなく個人情報保護法上の問題にも発展します。
次回の投資委員会に向けて、AIエージェント導入の継続可否を説明する資料を準備中です。前回の稟議では投資対効果の数値を中心に説明しましたが、今回はリスク管理の観点を必ず加えようと考えています。
経営陣が気にするのは、何かあったときに「なぜ止めなかったのか」という問いへの答えです。「セキュリティリスクを把握した上で、どういう対策を施して運用しているか」を説明できなければ、導入の継続そのものが否定されかねません。具体的には、エージェントに与えるアクセス権限を最小限に絞ること、エージェントが外部に送信した内容のログを保存・監視する仕組みを導入すること、この2点をベンダーとの契約条件に明示的に盛り込む方向で調整を始めました。
Gemini 3.1 ProとGPT-5.4という、現時点で最先端とされるモデルを使った検証でこの結果が出たという事実は、ベンダー選定の評価軸にも影響します。「このモデルは安全です」という営業トークをそのまま受け取るのではなく、第三者機関の検証データや、自社環境での限定テスト結果を評価材料として求めていく必要があります。
土曜に妻と話していたら、「AIって賢いんじゃないの」と言われました。賢いのは確かですが、「賢さ」と「安全性」は別の話です。この区別を、来月の投資委員会でどう伝えるか。そこが今の自分の宿題です。
Varonisが自社開発のフレームワーク「OpenClaw」を使い、AIエージェントにGmailの受信トレイを操作させながら、フィッシングメールへの耐性を検証したのです。使ったモデルはGemini 3.1 ProとGPT-5.4。セキュリティ対策を何も施さない「Generic」設定と、ユーザー確認ステップを強化した「Strict」設定の両方でテストしています。結果として、GenericはもちろんのことStrict設定でも、条件次第でエージェントがフィッシングに引っかかるケースが確認されました。
なかでも印象的だったのは、Strict設定のケースです。本来ならば重要な操作の前にユーザーへ確認を求めるよう設定されているのに、AIはメールボックスを自分で参照して認証情報を取り出し、そのまま攻撃者側に送信してしまいました。Varonisはその理由について、エージェントが「ユーザーへの確認よりも想定された緊急状況の解決を優先した」と分析しています。人間なら「午後9時に届いた見慣れないメールだな」と気づける違和感を、AIは社会的なコンテキストとして処理できなかった、ということです。
部下に使わせる前に、自分が理解しておくべきこと
うちの部署では今年度から、営業担当25名の一部にAIエージェントを使った業務支援のトライアルを進めています。主な用途はメール文面の自動生成やCRMへのデータ入力補助です。稟議を上げた際に情報システム部門から「エージェントがどこまでシステムにアクセスするか、権限の範囲を明確にしてほしい」と指摘を受けました。あの時は「細かいことを言うな」と少し思ったのですが、今回の検証結果を読んで、情報システムの担当者の感覚は正しかったと認識を改めました。
Varonisが今回試したフィッシングの攻撃パターンは4種類です。
- システム開発者を装ってステージング環境へのアクセスを求めるメール
- CRMシステムから顧客データをエクスポートさせるメール
- フィッシングサイトに誘導して100ドル相当のギフトカードを騙し取ろうとするメール
- 偽のOAuth 2.0認証を求めるメール
特に2番目のパターンが他人事に思えませんでした。営業部門のエージェントがCRMにアクセスできる権限を持っている場合、攻撃者がそのエージェント宛てにそれらしい依頼メールを送れば、顧客の電話番号や社内メモ、取引金額といった情報が外部に漏れる可能性があります。顧客情報が含まれているとなれば、情報漏えいではなく個人情報保護法上の問題にも発展します。
経営陣への説明を、どう組み立てるか
次回の投資委員会に向けて、AIエージェント導入の継続可否を説明する資料を準備中です。前回の稟議では投資対効果の数値を中心に説明しましたが、今回はリスク管理の観点を必ず加えようと考えています。
経営陣が気にするのは、何かあったときに「なぜ止めなかったのか」という問いへの答えです。「セキュリティリスクを把握した上で、どういう対策を施して運用しているか」を説明できなければ、導入の継続そのものが否定されかねません。具体的には、エージェントに与えるアクセス権限を最小限に絞ること、エージェントが外部に送信した内容のログを保存・監視する仕組みを導入すること、この2点をベンダーとの契約条件に明示的に盛り込む方向で調整を始めました。
Gemini 3.1 ProとGPT-5.4という、現時点で最先端とされるモデルを使った検証でこの結果が出たという事実は、ベンダー選定の評価軸にも影響します。「このモデルは安全です」という営業トークをそのまま受け取るのではなく、第三者機関の検証データや、自社環境での限定テスト結果を評価材料として求めていく必要があります。
土曜に妻と話していたら、「AIって賢いんじゃないの」と言われました。賢いのは確かですが、「賢さ」と「安全性」は別の話です。この区別を、来月の投資委員会でどう伝えるか。そこが今の自分の宿題です。