はじめに
AIアシスタントOSSは「便利さ」と引き換えに、人間よりも強い操作権限を持つ存在になりがちです。
Clawdbotは Self-hosted / LocalLLM 前提という点で非常に魅力的ですが、その自由度は同時にセキュリティ設計を誤った場合の破壊力も大きくします。
本記事ではClawdbotの構造を踏まえ、どこにリスクが生じるのか、どの設計判断が被害を拡大させるのか、何から対策すべきかを整理した上で、特にSlack / Discordにおけるallowlist（購読チャネル制御）設計を深掘りします。
関連記事
Clawdbotの概要・利用事例については前編をご覧ください。
→ Clawdbot（clawd.bot）とは？LocalLLM前提のSelf-hosted AIアシスタント基盤を解説
1. Clawdbotの基本構造とセキュリティ前提
Clawdbotは以下のような構成を持ちます。
- Gateway（Node.jsで動作するコア）
- LLM（Local / Cloud）
- チャットチャネル（Slack / Discord / Telegram など）
- Skill（外部ツール・コマンド実行）
重要なのは、Clawdbotが単なるチャットボットではないという点です。
- ファイル操作
- 外部API呼び出し
- ブラウザ操作
- 自動化タスク
これらを人間の代わりに実行できる存在であり、「どこから指示を受け取れるか」は最重要のセキュリティ境界になります。
2. 脅威モデル全体像
Clawdbotをチャットツール連携で運用する場合、主な脅威は次の4つに集約されます。
| 脅威 | 内容 |
|---|---|
| 誤爆投稿 | 想定外のチャンネルでAIが反応・実行 |
| なりすまし | 攻撃者がBotを操作できる状態 |
| トークン漏洩 | Bot Token流出による不正操作 |
| DM経由侵入 | 個人DM / Group DMからの直接指示 |
これらはLLMの性能とは無関係に、設計だけで防げるものが多いのが特徴です。
3. なぜ「allowlist設計」が最重要なのか
Clawdbotにおけるallowlistとは、**「どのチャネルのメッセージを購読（＝命令として受け取る）するか」**をGateway側で明示的に制限する仕組みです。
重要なポイントは以下の2点です。
- Clawdbotは基本的に「受け取ったチャネルに返信する」
- 勝手に別チャンネルへ投稿する設計ではない
つまりセキュリティ上の本質は**「投稿先」ではなく「購読元」**にあります。
4. セキュリティ深掘り ― Slack / Discordにおけるallowlist設計
ここからはallowlistを脅威モデルとセットで見ていきます。
4.1 脅威①：誤爆投稿
何が起きるか
- Botをworkspace / server全体に参加させる
- allowlist未設定
- 結果：雑談チャンネルでAIが反応、社外秘情報を要約、自動化タスクが誤実行
設計指針
allowlistは「例外指定」ではなくデフォルト拒否とし、AI専用チャンネルを作ってそこだけ許可します。
Clawdbotでの設定例（~/.clawdbot/clawdbot.json）
{
"channels": {
"slack": {
"allowFrom": ["C0123456789"],
"groups": {
"*": { "requireMention": true }
}
},
"discord": {
"allowFrom": ["1234567890123456789"],
"groups": {
"*": { "requireMention": true }
}
}
}
}
1チャンネルだけでも効果は非常に大きい
全チャンネルを許可するのではなく、AI専用チャンネル1つに絞るだけで、誤爆リスクは劇的に低下します。
4.2 脅威②：なりすまし操作
攻撃シナリオ
- 攻撃者がBot Tokenを入手
- Botを別チャンネルに招待
- 内部操作を試みる
allowlistが効く理由
Gateway側でallowlistを設定していれば、Tokenが正規でも許可されていないチャネルは完全に無視されます。
allowlistは第二の認証境界として機能します。
4.3 脅威③：トークン漏洩
前提
トークン漏洩は「起こるもの」として考えます。GitHubへの誤commit、CIログ、開発者PCなど、漏洩経路は多岐にわたります。
allowlistの有無による違い
| 状態 | 被害範囲 |
|---|---|
| allowlistなし | 任意チャンネルからBot操作可能、被害範囲が無制限 |
| allowlistあり | 操作可能なのは許可済みチャンネルのみ、被害半径（blast radius）を大幅に限定 |
4.4 脅威④：DM / Group DM経由の侵入
なぜ危険か
- 権限境界が曖昧
- 監査ログが弱い
- ソーシャルエンジニアリングが成立しやすい
推奨方針
DMは原則無効とします。ClawdbotではdmPolicy設定でDMの扱いを制御できます。
{
"channels": {
"discord": {
"dm": { "policy": "pairing" }
},
"slack": {
"dm": { "policy": "pairing" }
}
}
}
"pairing"を設定すると、未知の送信者からのDMにはペアリングコードが返され、明示的に承認しない限りメッセージは処理されません。
どうしてもDMが必要な場合は、read-only設定、実行系Skillの禁止、操作ログ必須を検討してください。
公式のセキュリティ監査コマンド
clawdbot security audit を実行すると、危険なDMポリシーや設定ミスを検出できます。
参考: Security - Clawdbot Docs
5. allowlistは「最初にやるゼロトラスト」
allowlist設計は、複雑な実装不要、運用コストほぼゼロ、効果が非常に大きい、という点でClawdbotセキュリティの最優先項目です。
allowlistは、Clawdbotにおける最も安価で、最も効果の高いゼロトラスト実装
6. まとめ：最低限ここだけは守る
- allowlistは最小チャネル数に絞る
- AI専用チャンネルを用意する
- DM / Group DMは原則無効にする
- トークン漏洩を前提に被害範囲を限定する
- チャット側だけでなくGateway側で制御する
-
clawdbot security auditを定期実行する
おわりに
AIアシスタントOSSのセキュリティは、**高度な暗号や難しい理論より「設計の順番」**が重要です。
Clawdbotは自由度が高い分、最初の一手を誤ると危険ですが、逆に言えば正しく制限すれば非常に安全に運用できます。
次に考えるべきテーマとしては以下があります。
- Skill実行権限の分離（read / write / exec）
- 人間承認フロー（human-in-the-loop）
- 監査ログとフォレンジック
- LocalLLM × OSSにおけるsupply chain攻撃
これらについても、機会があれば記事にしたいと思います。