先有安全基线，再谈方便
更合理的顺序是先把 bind、token auth、DM 或 mention 规则、工具权限收紧，再逐步放开。否则“方便”往往只是更大范围的误授权。
Token Auth Pairing Mention 最小工具集
安全
OpenClaw 安全基础：Sandbox、Elevated 与更稳妥的默认配置
OpenClaw 的安全讨论一直很高频，因为它把实时消息通道和真实工具连在一起。关键不是幻想“绝对隔离”，而是把作用域、信任边界和默认配置收紧到足够清晰。
外部讨论里反复出现的需求
需要一份人话版说明，讲清 sandbox、tool policy、elevated 到底分别控制什么。
需要在 Slack、Discord 或群聊里接入机器人前，先有一套加固基线。
需要明确提醒共享工作区、宽文件权限和磁盘 secrets 的真实风险。
这个专题页会覆盖什么
Sandbox 与主机逃逸开关
OpenClaw 有三套容易被混淆的控制面：工具在哪里跑、哪些工具存在、exec 是否能回到宿主机。好的指南应该把这三件事拆开讲，而不是塞进一个看不懂的配置块。
Sandbox Tool Policy Elevated Bind Mount
团队共享风险
共享 Slack/Discord 机器人和个人私有助理不是一回事。团队机器人需要不同的运行边界、更少的凭据和更明确的作用域。这是生态里最容易被低估的风险之一。
共享 Slack 信任边界 Per-Agent 工作区范围
事故响应与审计
当你怀疑有问题时，最需要的是一份短小可执行的 runbook：先隔离，再轮换密钥，再审计，再验证。带命令和配置思路的安全内容，比空泛警告有用得多。
审计 密钥轮换 日志 恢复
建议从这里开始
- 在暴露远程入口前，先保持 gateway 本地或极小范围可达。
- 把 sandbox 当成风险收敛工具，而不是过度授权的借口。
- 团队机器人和个人机器人应视为不同信任边界。
- 提前写清楚 agent 能访问哪些 secrets、文件和消息通道。