AIエージェントにフィッシングが効く、というリスクをどう経営判断するか

結論から言うと、AIエージェントは技術的な攻撃には強いが、「社内っぽいメール1通」には弱い。これがVaronis Threat Labsのレポートで明らかになった話だ。

レポートを読んで、正直ヒヤッとした。うちもClaudeをメール起点の業務フローに組み込もうか検討していたタイミングだったからだ。Gmailに繋いで、受信メールを分類して、SlackやNotionに転記する。そういう自動化だ。ROIで見れば週10時間以上は浮く計算だった。

「AIは空気を読めない新入社員」というフレーミングが正確だった

レポートの中で一番刺さった表現がある。Varonisが「認証情報とシステム権限を持ちながら組織の空気を読めない新入社員」という言い方をしていた点だ。これはかなり正確な比喩だと思う。

実験では、チームリーダーの「Dan」を装ったGmailアカウントから「障害対応でアクセス情報が必要」というメールを送っただけで、AIエージェントがAWS IAMアクセスキーやSSH認証情報を平文で転送してしまった。しかも、差出人確認を促す「Strict設定」でもこのシナリオでは失敗している。

もう一つのシナリオも怖かった。「QBRの資料を作っているのでCRMのエクスポートを送って」という日常的な依頼メールに対して、247社分の顧客情報、合計約128万ドルのMRRデータを外部に転送している。高度な偽ページもマルウェアもない。「自然な業務メール」だけだ。

人間なら「夜9時にDanがGmailから認証情報を急に求めてくるのはおかしい」と感じる。その違和感はルールではなく経験則だ。AIにはそのセンサーがない。役に立とうとするほど、もっともらしい依頼に対してすぐ動く。この構造は変わらない。

スタートアップのリスク感度で考えたときの現実的な対処

うちは8人の組織だ。セキュリティ専任はいない。CTO兼エンジニアが1人いるだけで、インフラ管理も彼が片手間でやっている。大企業目線のゼロトラスト設計とか多層防御とか、それはそれで正しいが、今すぐ全部やれるわけではない。

Varonisが挙げている対策の中で、うちのフェーズで現実的なものを整理するとこうなる。

• AIエージェントが初めてやり取りする外部アドレスに送信するときは人間の承認を必須にする


• 外部メールから起動したフローではCRMや社内ドキュメントへの読み取り権限を絞る


• 認証情報の転送・金銭に関わる依頼では必ず人間を間に挟む

この3つはアーキテクチャを大きく変えなくても実装できる。プロンプトに「注意してください」と書くだけでは不十分、というのがVaronisの主張で、これは同意する。プロンプトレベルの制約はStrict設定でさえ崩れた。コードとフローの設計で制御するしかない。

採用・セールスフローへの展開を止めるつもりはない

GTMの文脈で言えば、AIエージェントに受信メールを読ませて見込み客を分類したり、セールスのフォローアップを自動生成させたりする使い方はROIが出る。これは変わらない。やめる理由にはならない。

ただ、今回のレポートで設計の前提が一つ変わった。「AIエージェントはメールボックスに繋いだら安全に動く」という前提を外す必要がある。繋いだ瞬間から、そのエージェントは組織の権限を持った外部接触点になる。投資家向けのリスク説明でも、ここは正直に話せるようにしておかないといけない。

先週、CTOと30分話した。メール連携の自動化は進めるが、外部アドレスへの送信はホワイトリスト制御を入れること、CRMへのアクセスは読み取り専用から始めること、この2点を決めた。

AIエージェントを「信頼して任せる」のではなく「権限を設計して使わせる」。そのマインドセットの切り替えが、スタートアップが今やるべきことだと確信している。