AIエージェント基盤OpenClawに表示名なりすましの脆弱性5件、Slack/Discord連携で攻撃可能に

「AIエージェントの許可リストに表示名を入れていたけど、それで安全じゃないの？」
「Slack連携しているうちのAIにも、同じ問題があるかもしれない…」

チップス

ボス、AIエージェント基盤のOpenClawに、Slackなどでなりすましができる脆弱性が5件も見つかったって聞いたんでしゅけど、これって他のAI連携でも起こるんでしゅか？

ボス

その可能性は高いな。許可リストを表示名で組んでいる限り、同じ問題が形を変えて何度でも現れる。

AIエージェント運用に踏み出したばかりの組織にとって、なりすまし対策は盲点になりがちです。
本記事ではOpenClawで報告された脆弱性の中身、発見手法、自社のAIエージェント運用に取り入れたい対策を整理していきます。

読み終えたあとには、AIエージェント連携の許可制御を見直す具体的な道筋がつかめます。

OpenClawで見つかった5件のなりすまし脆弱性

まずは今回報告された脆弱性の中身と影響を整理します。

許可リスト照合の不備が招くなりすまし

OpenClawはSlack、Discord、Telegramといったプラットフォーム連携で「許可された相手」を設定する仕組みを備えています。
問題は、その許可リストの照合が表示名ベースで動いていた点です。
SlackやDiscordでは表示名（Aliceなど）が利用者側で自由に変更できるため、攻撃者が同じ表示名を名乗るだけで許可リストを通過できてしまいました。
結果として、AIエージェントへの指示・データ取得・他連携先への横展開などが可能になり、5つの連携先で同じ構造の欠陥が確認されています。

チップス

表示名を真似するだけで通っちゃうなんて、思ったより簡単でしゅね…

ボス

ふふ、設定する側からすると「人間が見分けやすい名前」を使いたくなる気持ちは分かる。しかし攻撃者はその直感の隙を突いてくるんだ。

過去Telegram修正時の根本原因が再発

注目すべきは、本件がTelegram連携の過去修正と同じ根本原因を抱えていた点です。
研究者はAI生成ツール「agentgg」で過去脆弱性パターンを自動検出し、似た構造を持つ他連携先に欠陥が残っていたことを発見しました。
つまり「ひとつ直したつもりが、横展開されていなかった」という典型的な拡大ミスです。
OpenClaw側はすでに修正済みで、公式ドキュメントでも「`dangerouslyAllowNameMatching`を無効化し、不変の数値IDで許可リストを組む」よう案内されています。

AIエージェント運用で取るべき対策

続いて、自社のAIエージェント運用に応用できる対策を整理します。

表示名ではなく不変IDで信頼境界を組む

OpenClawの公式ドキュメントは、許可リストの「主要な信頼アンカー」をユーザーIDに置くよう推奨しています。
ポイントは次の通りです。

類似脆弱性の横展開を防ぐプロセス

本件が示すもうひとつの教訓は、修正の横展開チェックです。
過去の脆弱性パターンを自社の他コンポーネントに当て直す仕組みを持たないと、同じ穴を別連携先に残してしまう危険があります。
取り入れたいプロセスは次の通りです。

チップス

ひとつ直すだけじゃなくて、似た構造の場所までまとめて直すんでしゅね！

ボス

そうだな。詳細はOpenClaw公式セキュリティドキュメントを読むと、設定例まで追える。

まとめ

OpenClawで報告された5件のなりすまし脆弱性は、AIエージェント連携で許可リストを表示名ベースに組むことの危うさを示しました。
Slack・Discord・Telegramなど可変な表示名を持つプラットフォーム連携では、不変の数値IDを信頼の起点にすることが防御の基本となります。
自社のAIエージェント設定を改めて棚卸しし、なりすまし対策を進めていきましょう。