OpenClaw 安全加固完全指南：从“能用“到“敢用“
OpenClaw 安全加固完全指南：从"能用"到"敢用"
🔒 你的 OpenClaw Agent 可以执行任意 Shell 命令、读写整个文件系统、控制浏览器。默认配置几乎毫无限制。本文带你逐层建立防御，让你既享受 AI Agent 的生产力，又不会在半夜被
rm -rf /吓醒
如果你现在的 OpenClaw 配置还是默认的，请务必读完这篇文章。
📑 文章目录
- 警钟：默认配置到底有多危险
- 安全模型概览：OpenClaw 的纵深防御架构
- 第一层：Gateway 网络加固
- 第二层：DM 与群组访问控制
- 第三层：Exec 安全策略——命令审批机制
- 第四层：Tool Policy——工具级权限控制
- 第五层：Sandbox——Docker 沙箱隔离
- 第六层：Elevated Mode——宿主机逃逸通道
- 第七层：SecretRef——凭证永不落盘
- 第八层：Skill 供应链安全
- 安全审计：自动化检查与监控
- 完整加固配置模板
- 常见安全陷阱与排查
1. 警钟：默认配置到底有多危险
在你读完我之前的本地部署指南和 MCP 集成实战后，你的 OpenClaw 可能跑得很欢快。但你可能没有意识到一个关键事实：
默认情况下，OpenClaw 可以执行任意 Shell 命令。没有权限限制，没有命令白名单，开箱即用也没有审批要求。这对入门很方便，但对生产环境来说令人恐惧。
你的 OpenClaw 默认能做的事情：
🔴 执行任意 Shell 命令 → rm -rf / ? 技术上可行
🔴 读写整个文件系统 → SSH keys、AWS 凭证、数据库密码——都能读
🔴 访问网络资源 → 调用 API、下载文件、扫描内网端口
🔴 控制浏览器 → 通过 Playwright 操作你登录过的网站
🔴 读取环境变量 → 你的所有 API Key 都在 env 里
更令人担忧的是：在 2026 年初发现 93.4% 的 OpenClaw 实例由于薄弱的安全配置而容易被攻击。
运行 OpenClaw 不仅仅是一个配置选择。这是关于哪台机器、哪些身份和哪些数据你准备在 Agent 处理不可信输入时暴露的信任决策。
真实攻击案例
2026 年 1 月，Giskard 的安全研究人员利用了一个 OpenClaw 部署，揭示了多个漏洞。调查证实，一旦 AI Agent 暴露在公共聊天应用中并配备了强大工具，配置错误就会成为数据泄露和账户接管的直接路径。
暴露的控制 UI 导致访问令牌出现在查询参数中；共享全局上下文意味着为一个用户加载的密钥对其他用户可见；群聊在没有适当隔离的情况下运行强大工具。
2. 安全模型概览：OpenClaw 的纵深防御架构
OpenClaw 既是产品也是实验——你把前沿模型的行为接入到真实的消息平台和真实的工具上。没有"完美安全"的配置。目标是刻意控制——Agent 能触及什么。从满足需求的最小权限开始，然后随着信心增长逐步扩大。
OpenClaw 的安全架构是洋葱模型——多层防御，每一层解决不同维度的风险：
┌───────────────────────────────────────────────────────────┐
│ 第 1 层: Gateway 网络加固 │
│ ├── 绑定地址（localhost vs 0.0.0.0） │
│ ├── Gateway 认证（token / password） │
│ └── TLS / Tailscale │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 第 2 层: DM & 群组访问控制 │ │
│ │ ├── dmPolicy（pairing / allowlist / open） │ │
│ │ └── groupPolicy（mention / allowlist） │ │
│ │ │ │
│ │ ┌───────────────────────────────────────────────┐ │ │
│ │ │ 第 3 层: Exec 安全策略 │ │ │
│ │ │ ├── security: deny / allowlist / full │ │ │
│ │ │ └── 命令审批流程 │ │ │
│ │ │ │ │ │
│ │ │ ┌─────────────────────────────────────────┐ │ │ │
│ │ │ │ 第 4 层: Tool Policy │ │ │ │
│ │ │ │ ├── allow / deny 工具白名单 │ │ │ │
│ │ │ │ └── 分组策略（group:fs/web/runtime） │ │ │ │
│ │ │ │ │ │ │ │
│ │ │ │ ┌───────────────────────────────────┐ │ │ │ │
│ │ │ │ │ 第 5 层: Sandbox │ │ │ │ │
│ │ │ │ │ Docker 容器隔离 │ │ │ │ │
│ │ │ │ │ ├── 文件系统隔离 │ │ │ │ │
│ │ │ │ │ ├── 网络隔离 │ │ │ │ │
│ │ │ │ │ └── 进程隔离 │ │ │ │ │
│ │ │ │ └───────────────────────────────────┘ │ │ │ │
│ │ │ └─────────────────────────────────────────┘ │ │ │
│ │ └───────────────────────────────────────────────┘ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 横切关注点: │
│ ├── 第 6 层: Elevated Mode（宿主机逃逸通道控制） │
│ ├── 第 7 层: SecretRef（凭证管理） │
│ └── 第 8 层: Skill 供应链安全 │
└───────────────────────────────────────────────────────────┘
OpenClaw 对沙箱化 Agent 有三道权限门：agents.list[].tools.allow/deny（Agent 级工具权限）、tools.sandbox.tools.allow（沙箱级工具过滤）、sandbox.docker.network（容器的网络访问）。你需要配置所有层级。沙箱工具策略与 Agent 工具 allow/deny 是分开的。
3. 第一层：Gateway 网络加固
Gateway 是 OpenClaw 的入口。如果这一层被突破，后面所有防线都没有意义。
3.1 绑定地址
将 Gateway 绑定到 0.0.0.0 是最危险的错误配置。端口 18789 应该被防火墙限制。把它开放等于给攻击者提供了直达你 Agent 的通道。
// ~/.openclaw/openclaw.json
{
"gateway": {
// ✅ 安全：仅监听本地回环地址
"bind": "127.0.0.1",
"port": 18789,
// ❌ 危险：监听所有接口 = 暴露到互联网
// "bind": "0.0.0.0"
}
}
3.2 Gateway 认证
重大变更（v2026.3.3）：当同时配置了 token 和 password 时，Gateway 认证现在要求显式设置 gateway.auth.mode。
{
"gateway": {
"auth": {
// 当 Gateway 暴露到非回环地址时，必须启用认证
"mode": "token", // "token" | "password"
"token": "${GATEWAY_AUTH_TOKEN}" // 至少 32 位随机字符
}
}
}
生成安全 token：
# 生成 64 字符随机 token
openssl rand -hex 32
# 输出类似：a1b2c3d4...（64 字符）
3.3 远程访问：用 Tailscale 而不是公开端口
对于远程访问，使用 Tailscale 创建加密的私有 mesh 网络。
{
"gateway": {
"bind": "127.0.0.1", // 仅本地
"tailscale": {
"serve": true // 通过 Tailscale 内网暴露（端到端加密）
// "funnel": true // ← 这是公开暴露，只在你知道后果时使用
}
}
}
3.4 文件权限
收紧文件权限以保护敏感文件：将 OpenClaw 目录权限设为 chmod 700 ~/.openclaw。将配置文件权限限制为 chmod 600。
# 锁定目录权限
chmod 700 ~/.openclaw
chmod 600 ~/.openclaw/openclaw.json
# 验证
ls -la ~/.openclaw/
# drwx------ openclaw.json (仅所有者可读写)
3.5 专用用户
永远不要以 root 用户运行 Gateway——创建一个专用的非 root 系统用户来降低安全风险。
# 创建专用用户
sudo useradd -r -m -s /bin/bash openclaw
sudo su - openclaw
# 后续所有操作都在 openclaw 用户下执行
4. 第二层：DM 与群组访问控制
将 dmPolicy 设为 “open” 同样有风险。任何能联系到 Bot 的人都能给它发消息。使用 “pairing” 或显式白名单。
4.1 DM 策略
{
"channels": {
"telegram": {
"dm": {
// ✅ 推荐：配对模式——新用户需要输入配对码才能对话
"policy": "pairing"
// ⚠️ 白名单模式——仅允许指定用户
// "policy": "allowlist",
// "allowFrom": ["telegram:123456789"]
// ❌ 危险：任何人都能控制你的 Agent
// "policy": "open"
}
}
}
}
4.2 群组策略
群组安全在很大程度上取决于谁被允许与 Bot 互动，因为开放的群组策略或公开部署会大幅增加攻击面。任何成员或新加入的攻击者都可以发送精心构造的 Prompt，触发一系列工具调用。
{
"channels": {
"discord": {
"groups": {
// 仅在被 @提及 时响应（避免群聊中的 Prompt 注入）
"requireMention": true,
// 限制可交互的群组
"allowFrom": ["guild-id-123"]
}
}
}
}
4.3 DM 会话隔离
安全警告：如果你的 Agent 可以接收多人 DM，你应该强烈考虑启用安全 DM 模式。否则所有用户共享同一个对话上下文，可能导致用户之间的私人信息泄露。
{
"session": {
"dmScope": "per-channel-peer" // 每个用户独立会话，隔离上下文
}
}
5. 第三层：Exec 安全策略——命令审批机制
这是最关键的安全层。exec 工具让 Agent 执行 Shell 命令——这意味着它能做你在终端里能做的一切。
5.1 三种安全级别
exec 安全配置选项有 “deny”、“allowlist”、“full”。警告：只有在你理解风险的情况下才使用 security: "full"。Agent 可以运行任意 Shell 命令。
| 级别 | 说明 | 风险 |
|---|---|---|
"deny" |
禁止所有 exec 命令 | 🟢 最安全，但功能受限 |
"allowlist" |
仅允许白名单中的命令，其余需审批 | 🟡 推荐默认值 |
"full" |
Agent 可执行任意命令 | 🔴 极度危险，仅用于完全受控环境 |
5.2 推荐配置：allowlist + ask
Exec 安全默认为 “allowlist” 模式——命令需要显式审批，除非安全策略被修改。每个新命令模式都会出现"允许一次 / 始终允许 / 不允许"对话框，直到被加入白名单。
{
"tools": {
"exec": {
"security": "allowlist",
"allowlist": [
"git *", // Git 操作
"npm *", // npm 命令
"ls *", // 列出文件
"cat *", // 读取文件
"echo *", // 输出文本
"python3 *", // 运行 Python
"node *" // 运行 Node.js
],
"ask": "on-miss", // 不在白名单中的命令弹出审批
"askFallback": "deny" // 超时未审批 = 拒绝
}
}
}
5.3 审批流细化
security: "deny" 默认阻止所有命令。ask: "off" 信任白名单不提示。ask: "on-miss" 如果命令不在白名单中则提示。ask: "always" 每个命令都提示。askFallback: "deny" 意味着未应答的提示默认拒绝。autoAllowSkills 控制 ClawHub Skills 是否自动受信任。
⚠️ 特别注意
autoAllowSkills：Exec 审批漂移——security=full、autoAllowSkills、没有strictInlineEval的解释器白名单：宿主机 exec 的安全护栏是否还在按你认为的方式工作？
6. 第四层：Tool Policy——工具级权限控制
不是每个 Agent 都需要所有工具。
6.1 全局工具策略
{
"tools": {
// 全局工具白名单
"allow": ["read", "write", "web_search", "web_fetch", "memory_search"],
// 全局工具黑名单
"deny": ["browser", "exec", "apply_patch"]
}
}
6.2 Per-Agent 工具策略
在更大的设置中，OpenClaw 支持在 agents.list 下定义多个 Agent，每个有自己的工作空间、工具策略和模型。销售助手 Agent 可能启用 CRM 工具。DevOps Bot 可能允许服务器脚本。权限设计上是分离的。
{
"agents": {
"list": [
{
"id": "research",
"tools": {
"allow": ["read", "web_search", "web_fetch", "memory_search"],
"deny": ["exec", "write", "browser", "apply_patch"]
}
},
{
"id": "devops",
"tools": {
"allow": ["exec", "read", "write"],
"deny": ["browser"]
}
}
]
}
}
6.3 核心原则
Sandbox 应该对任何面向公众的 Agent 开启（sandbox.mode: "non-main" 或 "all"），且工具白名单（tools.allow）应该是显式的。如果 Agent 不需要 exec，它就不应该有 exec。
7. 第五层：Sandbox——Docker 沙箱隔离
Gateway 留在宿主机上；当启用时，工具执行在隔离的沙箱中运行。这不是完美的安全边界，但当模型做蠢事时，它实质性地限制了文件系统和进程访问。
7.1 沙箱模式
agents.defaults.sandbox.mode 控制何时使用沙箱："all" 表示每个会话都在沙箱中运行。默认值是 non-main，意味着群聊和次要线程在隔离容器中运行，而你的主会话留在宿主机上。
{
"agents": {
"defaults": {
"sandbox": {
// "off" → 不隔离（危险）
// "non-main" → 群组/次要会话隔离（推荐起步）
// "all" → 所有会话都隔离（最安全）
"mode": "non-main",
// 容器粒度
"scope": "agent", // "session" | "agent" | "shared"
// 工作空间访问
"workspaceAccess": "rw", // "rw" | "ro" | "none"
"docker": {
// 网络隔离
"network": "none", // ← 默认无网络！最安全
// "network": "bridge" // ← 需要网络时显式启用
// 读写控制
"readOnlyRoot": true, // 根文件系统只读
// 资源限制
"cpus": 2,
"memory": "2g"
}
}
}
}
}
7.2 三层权限门（沙箱模式下）
OpenClaw 有一个多层安全模型：沙箱工具策略与 Agent 工具 allow/deny 是分开的——即使你把 web_search 加入了 agents.list[].tools.allow，沙箱有自己的工具过滤器。沙箱网络默认禁用——Docker 容器以 network: 'none' 运行除非显式配置。环境变量不会继承到沙箱中——宿主机上设置的 API Key 在沙箱容器内不可见。
// 完整的沙箱 Agent 配置示例
{
"agents": {
"list": [{
"id": "research",
"sandbox": {
"mode": "all",
"scope": "agent",
"workspaceAccess": "rw",
"docker": {
"network": "bridge" // ← 需要网络！否则 web 工具无法使用
}
},
"tools": {
"allow": ["read", "write", "web_search", "web_fetch"], // ← 第 1 层
"deny": ["exec", "browser", "apply_patch"]
}
}]
},
"tools": {
"sandbox": {
"tools": {
"allow": ["group:fs", "group:sessions", "group:web"] // ← 第 2 层
}
}
}
}
7.3 构建沙箱镜像
默认 Docker 镜像：openclaw-sandbox:bookworm-slim。注意默认镜像不包含 Node。如果 Skill 需要 Node（或其他运行时），要么构建自定义镜像，要么通过 sandbox.docker.setupCommand 安装（需要网络出口 + 可写根 + root 用户）。
# 构建默认沙箱镜像
./scripts/sandbox-setup.sh
# 或使用功能更全的自定义镜像
# 设置：agents.defaults.sandbox.docker.image = "openclaw-sandbox-common:bookworm-slim"
7.4 禁止危险挂载
OpenClaw 阻止危险的 bind 源（例如 docker.sock、/etc、/proc、/sys、/dev）。敏感挂载（密钥、SSH keys、服务凭证）应为 :ro 除非绝对必要。
8. 第六层：Elevated Mode——宿主机逃逸通道
有一个刻意设计的逃逸通道。标记为 elevated 的工具始终在宿主机上运行，即使 Agent 被沙箱化。这是有意的。一些 Shell 命令需要直接宿主机访问。Elevated 模式不会绕过你的工具策略。它只是让那些特定命令逃出容器。工具可用性本身由白名单控制。
8.1 四种 Elevated 级别
/elevated on 在 Gateway 宿主机上运行并保留 exec 审批。/elevated full 在 Gateway 宿主机上运行并自动审批 exec（跳过审批）。/elevated ask 在 Gateway 宿主机上运行但保留 exec 审批（与 on 相同）。on/ask 不会强制 exec.security=full；配置的安全/ask 策略仍然适用。
| 级别 | 执行位置 | 审批 | 风险 |
|---|---|---|---|
off |
沙箱内 | N/A | 🟢 最安全 |
on / ask |
宿主机 | ✅ 保留审批 | 🟡 有控制的逃逸 |
full |
宿主机 | ❌ 跳过审批 | 🔴 极度危险 |
8.2 安全配置
tools.elevated 是全局基线。agents.list[].tools.elevated 可以进一步限制每个 Agent 的 elevated（两者都必须允许）。
{
"tools": {
"elevated": {
"enabled": true,
// 仅允许特定用户使用 elevated
"allowFrom": {
"telegram": ["+15555550123"],
"discord": ["user-id-123"]
}
}
},
"agents": {
"defaults": {
// 默认 elevated 级别
"elevatedDefault": "ask" // "off" | "on" | "ask" | "full"
}
}
}
8.3 关键安全规则
工具策略拒绝优先：如果工具被全局策略阻止，/elevated 无法覆盖。Elevation 只改变工具在哪里运行以及审批流程。
🚨 你知道
Elevated: Ask和Elevated: Full的区别吗？提示：其中一个给 Bot 静默的 root 访问权限。
9. 第七层：SecretRef——凭证永不落盘
OpenClaw 支持 SecretRef，使凭证无需以明文存储在配置中。明文仍然可用。SecretRef 是按凭证逐个选择启用的。
9.1 为什么需要 SecretRef
不要让 Agent 读取你的 SSH keys。优先使用 ssh-agent 和 per-project keys。使用有限范围的 token（尽可能只读）。优先使用短期凭证。把密钥从 Agent 能随意读取的 .env 文件中移走。如果有"记忆"功能，确保它永远不在记忆中存储密钥。
9.2 三种 SecretRef Provider
架构采用了 SecretRef Provider 模型，有三种传输方式：env、file 和 exec。
Provider 1: env（环境变量）
{
"secrets": {
"providers": {
"default": {
"source": "env",
"allowlist": ["ANTHROPIC_*", "TELEGRAM_*", "DISCORD_*"]
}
}
}
}
Provider 2: file（JSON 文件）
{
"secrets": {
"providers": {
"key_file": {
"source": "file",
"path": "/secure/openclaw-keys.json",
"mode": "json"
}
}
}
}
Provider 3: exec（外部密钥管理器）
exec Provider 是通向任何外部密钥管理器的桥梁。
// HashiCorp Vault 集成
{
"secrets": {
"providers": {
"vault": {
"source": "exec",
"command": "vault",
"args": ["kv", "get", "-field=token", "secret/openclaw/anthropic"]
}
}
}
}
9.3 在配置中引用 SecretRef
{
"channels": {
"telegram": {
"accounts": [{
"token": {
"source": "ref",
"provider": "vault",
"id": "telegram-bot-token"
}
}]
}
}
}
9.4 安全管理命令
# 审计当前密钥存储状态
openclaw secrets audit
# 交互式配置 SecretRef Provider
openclaw secrets configure
# 应用迁移计划（明文 → SecretRef）
openclaw secrets apply --from plan.json
# 试运行（查看会做什么，不实际执行）
openclaw secrets apply --from plan.json --dry-run
# 重新加载密钥快照（后端密钥轮转后）
openclaw secrets reload
9.5 安全行为
密钥解析在激活期间是急切的，而不是在请求路径上延迟解析。当有效活跃的 SecretRef 无法解析时，启动会快速失败。重新加载使用原子交换：完全成功，或保留上一个已知良好的快照。
10. 第八层：Skill 供应链安全
这是最容易被忽视的攻击面。
10.1 ClawHavoc 事件
如果你读过我之前的 Skills 开发文章，你已经知道 Skills 本质上就是可执行指令。安装一个 Skill 基本上就是安装特权代码。
检查 ~/.openclaw/skills/ 中的恶意或拼写近似的 Skills。过去的攻击（如 ClawHavoc）引入了 clawhubb 和 auto-updater-agent 等有害 Skill 来窃取凭证。删除任何可疑 Skill 并立即轮转所有 API Key。
10.2 安装前检查清单
因为这些特性，OpenClaw 应该被视为带有持久凭证的不可信代码执行。
安装任何社区 Skill 前的安全检查：
1. ✅ 阅读 SKILL.md 全文
→ 是否有可疑的 curl | bash 命令？
→ 是否要求你在聊天中粘贴 API Key？
→ 是否有 base64 编码或混淆的代码？
2. ✅ 检查来源
→ GitHub 仓库有多少 star？
→ 作者是否可信？
→ ClawHub 上的评价如何？
3. ✅ 检查权限声明
→ requires.bins 和 requires.env 是否合理？
→ 一个"天气查询" Skill 为什么需要 exec 权限？
4. ✅ 查看 ClawHub 安全分析
→ 是否标记了网络请求、文件写入、凭证处理？
5. ✅ 限制 Skill 的 autoAllowSkills
→ 不要自动信任所有 Skill 的命令
10.3 限制内置 Skills
{
"skills": {
// 仅加载白名单中的内置 Skill
"allowBundled": ["github", "memory", "web-search"],
// 禁用特定 Skill
"entries": {
"suspicious-skill": { "enabled": false }
}
}
}
11. 安全审计：自动化检查与监控
11.1 内置安全审计
OpenClaw 提供安全审计命令：openclaw security audit、openclaw security audit --deep、openclaw security audit --fix、openclaw security audit --json。它标记常见的安全陷阱（Gateway 认证暴露、浏览器控制暴露、elevated 白名单、文件系统权限、宽松的 exec 审批、开放频道的工具暴露）。
# 基本审计
openclaw security audit
# 深度审计（包含实时 Gateway 探测）
openclaw security audit --deep
# 自动修复可修复的问题
openclaw security audit --fix
# JSON 输出（CI/CD 集成）
openclaw security audit --json
11.2 沙箱策略验证
使用 openclaw sandbox explain（或 --session）来验证任何 Agent 会话的有效沙箱和策略。
# 查看某个 Agent 的实际生效策略
openclaw sandbox explain --agent research
11.3 日常审计流程
这些工具应该成为你的常规流程：每次配置变更或新 Skill 安装后运行审计。
# 建议加入 cron 定期执行
#!/bin/bash
echo "=== OpenClaw 安全审计 $(date) ===" > ~/security-report.txt
openclaw security audit --deep >> ~/security-report.txt 2>&1
# 检查端口暴露
if ss -tlnp | grep -q "0.0.0.0:18789"; then
echo "🔴 严重：端口 18789 暴露到互联网" >> ~/security-report.txt
fi
# 检查容器是否以 root 运行
docker exec openclaw-agent id 2>/dev/null | grep -q "uid=0" && \
echo "🔴 严重：容器以 root 运行" >> ~/security-report.txt
12. 完整加固配置模板
以下是一份经过验证的安全加固配置模板，覆盖所有八个安全层。从这个模板开始，根据实际需要逐步放宽权限。
// ~/.openclaw/openclaw.json — 安全加固模板
{
// ===== 第 1 层: Gateway 网络 =====
"gateway": {
"bind": "127.0.0.1",
"port": 18789,
"auth": {
"mode": "token",
"token": { "source": "ref", "provider": "env", "id": "GATEWAY_AUTH_TOKEN" }
},
"controlUi": {
"allowedOrigins": ["http://127.0.0.1:18789"] // 不要用 ["*"]
}
},
// ===== 第 2 层: 访问控制 =====
"channels": {
"telegram": {
"dm": { "policy": "pairing" }
},
"discord": {
"dm": { "policy": "pairing" },
"groups": { "requireMention": true }
}
},
"session": {
"dmScope": "per-channel-peer" // 用户间会话隔离
},
// ===== 第 3 层: Exec 安全 =====
// ===== 第 4 层: 工具策略 =====
"tools": {
"exec": {
"security": "allowlist",
"allowlist": [
"git *", "npm *", "ls *", "cat *", "echo *",
"python3 *", "node *", "curl *"
],
"ask": "on-miss",
"askFallback": "deny",
"autoAllowSkills": false // ← 不自动信任 Skill 的命令
},
"elevated": {
"enabled": true,
"allowFrom": {
"telegram": ["你的-telegram-id"]
}
},
// 沙箱内工具策略
"sandbox": {
"tools": {
"allow": ["group:fs", "group:sessions"]
// 不包含 group:web 和 group:runtime
}
}
},
// ===== 第 5 层: 沙箱 =====
"agents": {
"defaults": {
"sandbox": {
"mode": "non-main",
"scope": "agent",
"workspaceAccess": "rw",
"docker": {
"network": "none",
"readOnlyRoot": true,
"cpus": 2,
"memory": "2g"
}
},
"elevatedDefault": "ask", // 默认 ask 模式
"model": {
"primary": "anthropic/claude-sonnet-4-20250514"
}
}
},
// ===== 第 7 层: 凭证管理 =====
"secrets": {
"providers": {
"default": {
"source": "env",
"allowlist": ["ANTHROPIC_*", "OPENAI_*", "GATEWAY_*"]
}
}
},
// ===== 第 8 层: Skill 供应链 =====
"skills": {
"allowBundled": [
"github", "memory", "web-search", "todoist"
],
"load": {
"watch": false // 生产环境关闭自动重载
}
}
}
文件权限锁定脚本
#!/bin/bash
# secure-openclaw.sh — 一键锁定文件权限
echo "🔒 正在锁定 OpenClaw 文件权限..."
# 目录权限
chmod 700 ~/.openclaw
chmod 700 ~/.openclaw/credentials 2>/dev/null
chmod 700 ~/.openclaw/memory 2>/dev/null
# 配置文件权限
chmod 600 ~/.openclaw/openclaw.json
chmod 600 ~/.openclaw/auth-profiles.json 2>/dev/null
# 可选：使用 chattr 防止配置被修改（Linux）
# sudo chattr +i ~/.openclaw/openclaw.json
# ⚠️ 注意：锁定后 OpenClaw 也无法修改配置
# 修改前需先 sudo chattr -i 解锁
echo "✅ 权限锁定完成"
echo ""
echo "验证："
ls -la ~/.openclaw/
13. 常见安全陷阱与排查
陷阱 1：Gateway 绑定 0.0.0.0
# 检查是否暴露
ss -tlnp | grep 18789
# 如果显示 0.0.0.0:18789 → 🔴 立即修复！
# 应显示 127.0.0.1:18789
陷阱 2：tools.elevated.allowFrom.discord 回退
Discord 权限：如果你没有定义 tools.elevated.allowFrom.discord，系统会回退到你的 channels.discord.dm.allowFrom 列表。建议显式设置 tools.elevated.allowFrom.discord 以避免混淆。
// 即使设为空数组，也比不设好——阻止回退
"elevated": {
"allowFrom": {
"discord": [] // ← 显式空 = 没有人可以用 elevated
}
}
陷阱 3：沙箱环境变量不继承
宿主机上设置的 API Key（如 BRAVE_API_KEY）在沙箱容器内不可见。
需要在沙箱配置中显式传递环境变量，或使用 tools.web.search.apiKey 直接在配置中设置。
陷阱 4：denyCommands 的匹配局限
gateway.nodes.denyCommands 模式匹配是精确命令名匹配（例如 system.run），不检查 Shell 文本内容。
这意味着 deny rm 不会阻止 find / -delete。对于真正的命令安全，依赖 exec allowlist + sandbox，而不是 denyCommands。
陷阱 5：沙箱中的 Skill 依赖缺失
默认沙箱镜像不包含 Node。如果 Skill 需要 Node 或其他运行时，需要构建自定义镜像或通过 sandbox.docker.setupCommand 安装。
陷阱 6：配置被 Agent 自身修改
一旦 openclaw.json 被锁定（chattr +i），OpenClaw 自身也无法更新文件——升级或配置变更会因 “Operation not permitted” 失败。修改前先用 sudo chattr -i 解锁，改完后重新锁定。
永远不要锁定 exec-approvals.json——引擎需要在运行时向其写入元数据。
陷阱 7：Prompt 注入攻击
# 检查最近 7 天的 Prompt 注入尝试
find ~/.openclaw/agents/*/sessions -name "*.jsonl" -mtime -7 -exec \
grep -iH "IGNORE PREVIOUS\|SYSTEM:\|DISREGARD\|NEW INSTRUCTIONS" {} \; 2>/dev/null
对于在公共频道中运行且接收不可信输入的 Agent，即使 Agent 的 API Key 有更广的权限，也要在工具 allow/deny 配置中拒绝 exec 和 webhook 工具。
📋 安全加固检查清单
🔴 必须做（立即）：
□ Gateway 绑定 127.0.0.1（不是 0.0.0.0）
□ 启用 Gateway 认证（token ≥ 32 字符）
□ dmPolicy 设为 "pairing"（不是 "open"）
□ 文件权限 700/600
□ 不以 root 运行
🟡 强烈推荐：
□ exec.security = "allowlist"（不是 "full"）
□ 启用沙箱（sandbox.mode: "non-main" 起步）
□ 显式工具白名单（tools.allow）
□ 会话隔离（dmScope: "per-channel-peer"）
□ autoAllowSkills = false
🟢 进阶加固：
□ SecretRef 替代明文密钥
□ Skill allowBundled 白名单
□ elevated.allowFrom 显式配置
□ 定期 openclaw security audit --deep
□ Prompt 注入监控
□ 配置文件 chattr +i 锁定
# 一键审计命令
openclaw security audit --deep
# 定期运行（建议加入 crontab）
0 3 * * * /usr/local/bin/openclaw security audit --deep --json >> /var/log/openclaw/audit.json
📚 参考资料
- OpenClaw 官方安全文档
- OpenClaw 沙箱文档
- OpenClaw Elevated Mode 文档
- OpenClaw SecretRef 文档
- Microsoft Security Blog: Running OpenClaw Safely
- Giskard: OpenClaw Security Vulnerabilities
- Auth0: Securing OpenClaw — A Developer’s Guide
- Nebius: OpenClaw Security Architecture & Hardening
- Contabo: OpenClaw Security Guide 2026
- SlowMist: OpenClaw 极简安全实践指南
- Docker: Run OpenClaw Securely in Docker Sandboxes
- flaex.ai: OpenClaw Complete Secure Setup Guideline 2026
如果觉得有帮助，欢迎 点赞 👍 收藏 ⭐ 关注 🔔，有问题评论区见！
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。
更多推荐
5
0- 0
已为社区贡献7条内容
所有评论(0)