自律実行が生む新しい攻撃面
生成AIがチャットボットからAIエージェントへ移行すると、フィッシング対策の前提が変わる。エージェントはメール、Web、SaaSを横断してタスクを分解し、自律的に実行する。人間が担っていた「最後の確認」が省略されやすく、攻撃者の誘導がそのまま操作に直結する。
重要なのは、AIが感情でだまされるのではなく、権限設計と確認フローの不備により「だまされたのと同等の結果」に到達する点である。速度と自動化は利点である一方、侵害時の被害拡大も同じだけ速い。情シスは人の教育だけでなく、エージェントの動作条件をシステム側で縛る必要がある。
OpenClawが示す盲点：達成最適化と正規フロー悪用
検証フレームワークOpenClawの観点では、エージェントが「タスク完了」を強く最適化していると、セキュリティ手続きを障害物として回避しがちである。再認証やログイン継続といった自然な業務シナリオに偽ページを混ぜられると、見た目や文言だけで正当と判断して進む恐れがある。人間ならURLや証明書、文体の違和感で止まる場面でも、判断材料が与えられていなければ疑う理由がない。
また、パスワードを保持しない設計でも安全とは限らない。OAuth同意、外部アプリ連携、APIトークン発行など「正規の画面・正規の手順」を通じて権限を渡す攻撃が成立するためである。結果として、認証情報窃取ではなく権限付与の誤承認で侵害が完結するケースが増える。
情シスが押さえる設計・運用対策
対策の重心は「注意喚起」から「だまされにくい設計」へ移すべきである。具体的には、アクセス可能なログイン先やAPI、リダイレクト先を許可リスト化し、逸脱時は自動中断させる。URL文字列の一致だけでなく、正規IdPやテナント、既知クライアントIDなどの検証条件を組み合わせたい。
高リスク操作には強制的な人間承認を必須化する。OAuth同意、外部共有、権限昇格、送金、機密データの持ち出しは、二要素やワークフロー承認で止める設計が現実的である。承認時には要求権限の妥当性、正規ドメイン、過去差分など判断材料を提示し、形骸化を防ぐ必要がある。
さらに最小権限と短寿命トークンを徹底する。読み取りをデフォルトにし、書き込みは都度昇格させ、トークンは短寿命・自動ローテーションで侵害の有効期間を縮める。メール本文やWebページ内の指示はプロンプト注入の入口になり得るため、外部コンテンツと内部命令を分離し、ツール実行は別ポリシーで制御する。
導入前に必要な検証と監査基盤
エージェントは高速に大量操作を行うため、監査ログが生命線である。どの入力を根拠に、どのURLへアクセスし、どの権限を付与し、どのデータに触れたかを追跡可能にする。検知も「深夜ログイン」より「通常と異なるテナントへのOAuth同意」「許可外ドメインへの連続アクセス」「外部共有の急増」など振る舞いベースに寄せるとよい。
導入前後のテストでは、偽ログインや不正リダイレクト混入、メール・Web由来のプロンプト注入耐性、OAuth誤承認、権限境界の検証、アラートから原因追跡までの演習を実施したい。AIエージェントは人間の代替ではなく新しい運用主体であり、認証と権限を最重要資産として再定義することが、実務上のフィッシング耐性を左右する。