OpenClawのグループチャットでも普通の会話はできますが、グループメンバーにファイルや端末、ブラウザツールをトリガーさせたくない場合は、エージェント全体を低権限にするのではなく、グループごとにツールプロファイルを個別に絞り込むのが一番安全です。 グループチャットの参加はデフォルトでもっと控えめであるべきです。
なぜリマインダーだけに頼らないのでしょうか?
グループに「命令を実行しないでください」と書くことはセキュリティ管理とはみなされません。 ツールがこのエントリに露出し続ける限り、モデルは複雑な文脈で呼び出そうと試みることができます。 本当に効果的なのは設定層の制限です。このグループはメッセージングや選択されたライトツール、プライベートチャット、ローカルエントリーしか使えず、コーディング、ブラウザ、ターミナルは継続できます。
構成戦略
まず、グループチャットに対応するチャネルとsessionKeyを確認し、そのエントリのツールプロファイルを上書きします。 メッセージの整理、要約の転送、ステータスへの返信が必要な場合は、メッセージングツールを使いましょう。 コードの変更、デプロイの実行、バックグラウンドに移行する必要がある場合は、ユーザーがプライベートチャット、VPN、ローカルエントリーに切り替えて実行します。
チームシナリオは少なくとも3つの階層で推奨されます:チャット専用の公開グループ; 内部グループはステータスをチェックできますが、書き込みはできません。 ツールの実行はプライベートチャットまたは管理されたアクセスポイントのみが許可されています。 こうすることで、日々のコラボレーションに影響を与えたり、各グループメンバーが間接的に端末へのアクセスを許可したりしません。
受理時には、テストに管理者アカウントだけを使用しないでください。 ユーザーを許可する1人、通常のメンバー、そして不正ユーザーにメッセージを送り、ツールがトリガーできるかどうか確認します。 許可境界は異なるアイデンティティでのテスト後にのみ有効となります。
もしグループが本当に行動を起こす必要があるなら、「まずタスクを提出し、その後プライベートメッセージで確認する」という形でプロセスを設計できます。 グループチャットはリクエストの収集を担当し、実際のファイル変更、展開、ブラウザ操作は管理されたエントリポイントを通じて処理されます。 これにより、コラボレーションの効率を維持しつつ、ジョークコマンドが実際の操作を誘発するのを避けられます。
