Clawdbotは「チャットでAIに指示すると、外部サービス連携やツール実行まで行える」エージェント型のOSSとして海外で注目され、
日本でも「自分だけのAI秘書」や「キャラクタを秘書に」と言った内容で注目されている。
そんな中、先日セキュリティに関してさらに話題になっている。
話題になったセキュリティ問題
報道では、インターネット上に 認証なしで公開されたClawdbot Gateway が900以上見つかったとされている。
公開状態だと、設定画面やログ/履歴に含まれる モデルAPIキー、各種ボットトークン（Slack/Telegram等）、チャット履歴が閲覧・悪用される可能性がある。
エージェントは権限が強いため、漏れる情報の価値も高い可能性がある。
最悪のケースを挙げると
・認証情報の窃取: LLM/各チャネルのAPIキー・トークン流出 → 外部サービスまで侵害が波及
・会話ログの漏えい: ~/.clawdbot/.../sessions/*.jsonl に保存される会話が読まれる可能性（公式に明記）
・操作の乗っ取り: Control UI/WS経由でツール実行や送信操作に繋がると、RCE相当の被害になり得る（公式は system.run を「remote code execution」と明記）
と言ったことが考えられる。
問題の原因
エンジニアでなくても導入できる
Clawdbotは導入体験が比較的シンプルで、手順通りに進めれば個人でもセットアップできます。Control UIも用意されており、「まず動かす」だけなら専門的な開発スキルがなくても到達しやすい構造です。
それ故に起こる設定・運用ミス
以下のような要素によって、初級者による設定・運用ミスから今回のような問題が起きたと考えられる。
- 公開までが簡単: リバースプロキシやトンネル、Tailscale等で“外から触れる状態”を作りやすい
-
ローカル前提の信頼モデルが崩れる: プロキシ配下で接続元が
127.0.0.1に見えるなど、設定次第で“ローカル扱い”になり得る -
安全確認の難しさ: 「動く」ことと「安全」なことは別で、認証や
trustedProxiesなどの理解不足で事故が起きやすい - スキャンで見つかりやすい: Shodan等でUIの特徴から発見され、露出が一気に可視化される
推奨される対策（公式が強く推していること中心）
露出面の最小化: gateway.bind: "loopback" を基本に、安易に 0.0.0.0 へ晒さない
Gateway認証を必須化: gateway.auth.mode を token または password で運用（パスワードは CLAWDBOT_GATEWAY_PASSWORD 推奨）
リバプロ利用時の必須設定: gateway.trustedProxies を正しく設定し、プロキシ側で X-Forwarded-For を上書き（spoof防止）
監査コマンド(特に、設定を変更した後は行う): clawdbot security audit --deep（必要に応じて --fix）で典型的な危険設定を検出・是正（公式）
もし監査コマンドで検出されたら
トークン/パスワード/各種APIキーをローテーションし、ログとセッション履歴を確認
（公式にIncident Response手順があります）
最後に
昨今、AIの普及により個人開発のしやすい環境が整いつつあるが、
一方でこのようなセキュリティ面についてはおざなりになりがちなため、
気を引き締めてなければならないと感じた。
参考（一次情報/記事）
- 公式セキュリティガイド:
https://docs.clawd.bot/security - 公式設定ドキュメント（trustedProxies等）:
https://docs.clawd.bot/gateway/configuration - 露出報道（900+）:
https://cybersecuritynews.com/clawdbot-chats-exposed