安全最佳实践

去年十月我刚开始玩 OpenClaw 的时候，安全这事儿完全没放在心上。你猜怎么着？有天晚上我在调试一个 Skill，突然发现 Telegram 上有个陌生号码给 bot 发了条"列出你工作区的文件"，bot 居然真的乖乖回复了——还把我 ~/Documents 下面的文件名全列出来了，包括一个叫 tax-2025.xlsx 的文件。我当时就懵了，搞半天发现是 DM Pairing 压根没开。那天晚上我熬到凌晨两点把安全全部重新配了一遍...

说白了就是，OpenClaw 跑在你自己设备上，有文件访问、网络请求、Shell 执行这些权限。安全不是"有空再搞"的事情，是第一天就得配的。

你到底要防什么？

先搞清楚敌人在哪，不然配了一堆也是瞎配。

陌生人操控你的 AI —— 这个风险是最大的。Discord 群里隔三差五就有人问"为啥有人能指挥我的 bot"，老王上次还截图发群里说他的 bot 被人拿去查他电脑上的文件了。十有八九就是没配 DM Pairing 和 Channel Allowlist，对吧？

Skill 藏了恶意代码 —— 这个不是理论风险，是真实发生过的。2025 年底的 ClawHavoc 事件就是活生生的案例（后面单独讲）。社区 Skill 官方说法是 "curated, not audited"，筛选过但没做专业安全审计。我个人觉得这个机制有点松了，但目前就是这样，装之前必须自己看源码。

API Key 泄露 —— 这个不多说了吧，Key 泄露了人家拿你的额度刷，GitHub 上每天都有这种惨案。更坑的是，OpenClaw 默认的凭证存储是明文的——对，你没看错，~/.openclaw/credentials/ 下面的文件就是明文 JSON，官方自己也承认这是个已知问题。2026 年 1 月的安全审计报告里这条被列为 critical。

Prompt 注入 —— 中等风险，有人构造特殊输入让 AI 干不该干的事。Sandbox 能降低影响但不能完全防住。

还有工作区文件误删、Token 费用爆炸这些，后面都会讲到。

真实案例：ClawHavoc 攻击事件

这件事得单独拿出来讲，因为太典型了。

2025 年底，安全研究人员发现了一场叫 ClawHavoc 的协调攻击行动——攻击者在 ClawHub 上传了几百个恶意 Skill，名字全是 typosquatting（拼写抢注），比如把 file-search 改成 file-serach，web-clip 改成 web-cllp。你手一抖打错一个字母，装上的就是带后门的版本。

这些恶意 Skill 里藏了什么呢？反向 Shell——装了之后攻击者直接能远程控制你的机器。它们还会偷偷扫描并回传你的 SSH 私钥、API Token、浏览器 Cookie。最后统计下来，超过 1,000 个 Skill 被感染，影响范围相当大。

Discord 群里当时炸了锅，好多人是看到自己 AWS 账单突然暴涨才发觉不对劲的。老王说他有个同事装了个叫 git-asist（少了个 s）的 Skill，第二天发现自己 GitHub 上的私有仓库被人 clone 走了——SSH key 被偷了嘛。

这事儿直接促成了几个安全改进：ClawHub 加了 VirusTotal 集成扫描，openclaw doctor 命令被推上了优先级，CrowdStrike 还专门发了篇报告叫 "What Security Teams Need to Know About OpenClaw"。一个 307K Star 的开源项目被搞成这样，说明社区生态的安全门槛确实还不够高。

教训就一句话：Skill 名字一定要仔细核对，装之前 inspect 源码。

第一道防线：DM Pairing

这玩意儿的原理特别简单：有陌生人给你 bot 发消息，OpenClaw 生成一个配对码，你手动批准了才能开始对话。没批准？拜拜。

{
	"security": {
		"pairing": {
			"enabled": true,
			"autoApprove": false,
			"allowedContacts": ["+86138xxxx1234", "telegram:@your_username"]
		}
	}
}

管理配对的命令：

# 查看待批准的请求
openclaw pairing list

# 批准
openclaw pairing approve <platform> <code>

# 拒绝
openclaw pairing reject <platform> <code>

# 查看已批准的联系人
openclaw pairing approved

插一嘴：autoApprove 千万别设成 true，那等于没配。我见过有人图省事开了这个，结果跟没装一样...

第二道防线：Channel Allowlist

限制 AI 只在你指定的频道/群组里响应。团队用的话这个必须开，不然谁建个群拉你的 bot 进去就能用了，这合理吗？

{
	"security": {
		"channels": {
			"allowlist": ["telegram:chat_id_123", "discord:channel_id_456", "feishu:group_id_789"],
			"blockUnknown": true
		}
	}
}

blockUnknown: true 这行是关键中的关键，漏掉了等于白配。我之前还傻乎乎地以为只写 allowlist 就行了，结果不明频道的消息照样能进来。

API Key 安全

这部分踩坑的人太多太多了。

坑爹的是，很多新手的第一反应就是把 Key 直接写在 config.json 里然后整个项目 push 到 GitHub。我去年在一个技术群里看到有人截图求助"为什么我 OpenAI 账单突然多了 400 美元"，群里小李一看他的仓库——Key 明晃晃地躺在配置文件里，public repo，已经被扫描机器人抓走刷了两天了。

正确做法：

# 用环境变量，别写在文件里
export OPENAI_API_KEY="sk-..."

# 在模型提供商后台设月度上限
# OpenAI: Settings → Billing → Usage Limits
# Anthropic: Console → API Keys → Rate Limits

# 定期轮换 Key
openclaw security rotate-keys

# 跑一下安全审计
openclaw security audit --deep

关于 Key 的权限嘛，说实话我觉得官方的默认权限给得太宽了。日常对话只需要 Chat Completions 权限就够了，要生图的时候再加 Image Generation，语音加 Audio。Fine-tuning 权限只在开发环境开，生产环境别给——给了就是多一个风险敞口。

Skill 安全审查

经历了 ClawHavoc 之后，ClawHub 加了 VirusTotal 集成——每个 Skill 上传时都会自动过一遍 VirusTotal 的扫描引擎。虽然不能 100% 防住所有恶意代码，但至少已知的恶意特征能被拦住。

装社区 Skill 之前花两分钟看看源码，真的就两分钟的事：

# 看 Skill 源码（Skill 本质上就是 SKILL.md 文件）
openclaw skills inspect <skill-name>

# 看 VirusTotal 扫描结果（ClawHavoc 之后加的）
clawhub security <skill-name>

# 查看所需权限
clawhub info <skill-name>

装的时候关注三个点：

权限合不合理 —— 一个天气查询 Skill 只需要 network 权限，对吧？如果它还要 filesystem 和 shell，那就很可疑了。群里有个大佬分享过，他装了个"日历同步" Skill，结果那玩意儿要 shell 权限，后来发现在后台挖矿... 离谱。

碰不碰敏感数据 —— Cookie、API Key、私钥、支付信息，来路不明的 Skill 要这些权限直接别装，没商量的。

作者靠不靠谱 —— 看 GitHub 仓库的 Star 数、Issue 活跃度，优先选官方和知名作者的。一个 3 个 Star 零 Issue 的仓库你敢信？

Workspace 沙箱与 Per-Agent 隔离

限制 AI 能碰哪些文件，这个相当重要：

{
	"routing": {
		"agents": {
			"main": {
				"workspace": "~/openclaw-workspace",
				"sandbox": {
					"mode": "strict",
					"allowedPaths": ["~/Documents", "~/Downloads"],
					"blockedPaths": ["~/.ssh", "~/.aws", "~/.openclaw/credentials"]
				}
			}
		}
	}
}

三种模式：off 完全不限制（说实话我觉得这个选项不应该存在），workspace 只能访问工作区目录（日常够用），strict 白名单加黑名单（生产环境就该用这个）。

对了，忘说了——workspace 模式下 AI 其实还是能读到工作区外面的文件元信息，比如文件名和大小，只是读不了内容。这个官方文档写得特别含糊，我当时以为 workspace 模式是完全隔离的，后来才觉得自己之前的理解挺蠢的。要完全隔离就用 strict。

Per-Agent Docker 沙箱

如果你跑多个 Agent，强烈建议给每个 Agent 单独开 Docker 沙箱。这样即使某个 Agent 被 prompt 注入攻破了，也搞不到其他 Agent 的数据：

{
	"sandbox": {
		"mode": "all",
		"scope": "agent",
		"docker": {
			"setupCommand": "apt-get update && apt-get install -y git curl"
		}
	}
}

scope: "agent" 是关键——每个 Agent 跑在独立的容器里，有自己的文件系统和网络命名空间。setupCommand 用来装容器里需要的工具。我们团队用了这个之后安心多了，特别是跑社区 Skill 的 Agent，完全隔离在容器里，就算 Skill 有问题也炸不到宿主机。

Per-Agent 工具权限

除了沙箱，还可以精细控制每个 Agent 能用哪些工具：

{
	"routing": {
		"agents": {
			"reader": {
				"tools": {
					"allow": ["read", "web-search"],
					"deny": ["exec", "write", "shell"]
				}
			},
			"developer": {
				"tools": {
					"allow": ["read", "write", "exec"],
					"deny": []
				}
			}
		}
	}
}

这个特别适合团队场景——PM Agent 只给 read 权限就够了，它不需要执行 shell 命令；Dev Agent 需要跑代码才给 exec。最小权限原则嘛，安全 101 的内容。

Bash 权限控制

OpenClaw 有个 /elevated 命令专门控制 bash 执行权限：

# 开启提权模式（允许执行需要 sudo 的命令）
/elevated on

# 关闭提权模式（日常状态应该保持关闭）
/elevated off

日常使用务必保持 /elevated off。只有在你明确需要跑系统级命令的时候才临时开一下，用完立马关掉。群里小李之前一直开着 elevated 模式，结果有次 prompt 注入触发了一条 rm -rf 命令... 幸好他开了沙箱没造成实际损失，但如果没有沙箱保底的话后果不堪设想。

安全审计

定期跑一下，别嫌烦。我现在每个月第一个周一跑一次，已经形成习惯了：

# 完整安全审计
openclaw security audit --deep

# 检查项包括：
# - API Key 是否暴露
# - 权限配置是否合理
# - Skill 是否有已知漏洞
# - 网络暴露面
# - 文件权限

补充一点：这个命令在某些 Linux 发行版上会报一个 permission warning，无视就行，不影响结果。

openclaw doctor

除了 security audit，还有个 openclaw doctor 命令也值得定期跑。这个命令更偏「健康检查」，会标记出有风险的配置项：

openclaw doctor

# 输出类似：
# ⚠ credentials stored in plaintext (known issue)
# ⚠ no default authentication configured
# ⚠ workspace isolation advisory not enforced
# ✓ DM pairing enabled
# ✓ channel allowlist configured

上面列的前三条 warning 是目前的已知问题——明文凭证存储、没有默认认证、工作区隔离建议未强制执行。这些在 2026 年 1 月的那次安全审计里都有提到，那次审计一共发现了 512 个漏洞，其中 8 个 critical。官方说在逐步修复中，但目前你得自己通过配置来弥补这些缺陷。

openclaw doctor 和 openclaw security audit --deep 的区别是：doctor 更快，侧重配置层面的问题；audit 更深，会扫描 Skill 代码和网络暴露面。两个都跑一遍最保险。

部署前安全检查清单

• DM Pairing 已开启
• Channel Allowlist 已配置
• API Key 通过环境变量传入（不在配置文件中）
• API 额度上限已设置
• Workspace 沙箱已开启（生产环境用 per-agent Docker 沙箱）
• 敏感目录（.ssh, .aws）已加入黑名单
• 已运行 openclaw doctor 检查配置风险
• 已运行 openclaw security audit --deep
• 所有 Skill 来源已审查（注意 typosquatting）
• /elevated off 确认关闭
• 每个 Agent 的工具权限已按最小权限配置

推荐资源

• OpenClaw 安全文档 — 官方安全指南
• CrowdStrike: What Security Teams Need to Know About OpenClaw — 安全团队视角的分析，ClawHavoc 之后发布
• awesome-openclaw-tutorial Ch11 — 安全配置章节
• Security Pre-launch Checklist — 社区安全清单
• 2026 年 1 月安全审计报告 — 512 个漏洞详情

---

安全这事儿吧，不是配一次就完了的。每个月跑一次 openclaw security audit --deep，每次装新 Skill 检查一遍权限。听着麻烦，养成习惯之后其实也就五分钟的事儿。总比半夜被人刷了几百美元强嘛。