OpenClaw安全指南(一·认知篇):你的AI助手有多危险?

OpenClaw 安全指南（一·认知篇）：你的 AI 助手有多危险？

这是「OpenClaw 安全指南」系列的第 1 篇。在开始配置之前,我们先搞清楚一件事:你给 AI 助手开了多大的权限,它就有多大的破坏力。

适用版本:OpenClaw ≥ 2026.3.2(推荐 2026.3.31+)

1. 你的 AI 助手能做什么?

很多人装完 OpenClaw 就开始用,压根没想过一个问题:这个 AI 到底能在你的电脑上干什么? 

答案可能会吓你一跳:

简单说:不加限制的 AI 助手 ≈ 一个拥有你所有权限的远程用户。

你给它 root 权限,它就是 root。你给它你的聊天账号,它就能以你的名义说话。

2. OpenClaw 的安全哲学

2.1 个人助手不是多租户

OpenClaw 的定位是个人 AI 助手,不是企业级多租户平台。

这意味着:

• 你是唯一的管理员,不需要复杂的 RBAC 角色体系
• 信任边界很清晰:你信任自己,但不一定信任所有能跟 AI 对话的人
• 安全重点不同:不是防内部员工,而是防外部入侵和 AI 失控

这个定位决定了 OpenClaw 的安全模型–简单但有效。

2.2 三层安全模型

OpenClaw 的安全防护分三层,从外到内:

┌─────────────────────────────┐│  第一层:访问控制          │ ← 谁能连上来?│  Gateway 绑定 / 认证 / 配对  │├─────────────────────────────┤│  第二层:范围限制          │ ← 连上来之后能干什么?│  工具权限 / Exec 策略 / 沙箱  │├─────────────────────────────┤│  第三层:模型防护          │ ← AI 自己会不会被骗?│  提示注入防护 / 系统提示护栏  │└─────────────────────────────┘

每一层都独立生效。就算第一层被突破(有人拿到了你的 token),第二层还能限制他只能用安全的工具。就算第二层也没挡住,第三层的模型护栏还能兜底。

2.3 默认 fail-closed

OpenClaw 遵循一个核心原则:没有明确允许的,默认拒绝。

• 没配置 exec?→ 默认 deny(沙箱)或 allowlist(gateway/node),不能随意执行命令
• 没配置工具权限?→ 使用最严格的预设
• 没配置网络绑定?→ 默认只监听 127.0.0.1
• 没有沙箱时请求 host=sandbox?→ fail-closed,拒绝执行(2026.3.31 起)

这比大多数工具都安全。但问题是:很多人为了”方便”会主动放开限制,然后忘了收回来。

这就是为什么你需要这份指南。

3. 60 秒硬化基线

不废话,直接上配置。把下面这段 JSON 放进你的 openclaw.json:

{  "gateway": {    "mode": "local",    "bind": "loopback",    "auth": {      "mode": "token",      "token": "你的随机强密码-至少32位"    },    "trustedProxies": []  },  "session": {    "dmScope": "per-channel-peer"  },  "tools": {    "profile": "messaging",    "deny": ["group:automation", "group:runtime", "group:fs", "sessions_spawn", "sessions_send"],    // 注:messaging profile 本身包含 sessions_send,这里额外 deny 是为了基线最严格;按需从 deny 中移除    "fs": { "workspaceOnly": true },    "exec": {      "security": "deny",      "ask": "always"    },    "elevated": { "enabled": false }  },  "channels": {    "defaults": {      "dmPolicy": "pairing",      "groupPolicy": "allowlist"    }  },  "discovery": {    "mdns": {      "mode": "minimal"    }  }}

这是最严格的起点–禁用命令执行、文件操作、自动化工具,仅保留消息通信能力。然后根据实际需要逐步放开:

• 需要文件读写?→ 把 profile 改为 "coding",移除 deny 中的 "group:fs"
• 需要执行命令?→ 把 exec.security 改为 "allowlist",ask 改为 "on-miss"(⚠️ Windows 用户见下方说明)
• 需要定时任务?→ 移除 deny 中的 "group:automation"

各配置项说明:

配置完之后,跑一下安全审计:

openclaw security audit

如图，总结：CRITICAL(严重):0 ● WARN(警告):5● INFO(信息):0 。一般对于WARN，可按需对待，对于CRITICAL，请谨慎对待，需要修复的按FIX(提示)修复。

4. Gateway 网络安全

Gateway 是 OpenClaw 的”大门”。所有请求–不管是你自己的、手机 App 的、还是 Discord Bot 的–都要经过这道门。

门没锁好,后面的安全措施全白搭。

4.1 绑定模式

Gateway 的 bind 参数决定了谁能连上来:

黄金法则:能用 loopback 就不用 lan。

4.2 认证配置

Gateway 支持 token 认证。配了 token,所有请求都必须在 Header 里带上它:

{  "gateway": {    "auth": {      "mode": "token",      "token": "a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0"    }  }}

生成一个强 token 的方法:

# PowerShell[System.Convert]::ToBase64String((1..32 | ForEach-Object { Get-Random -Maximum 256 }) -as [byte[]])# 或者用 opensslopenssl rand -hex 32

请求时这样带 token:

curl -H "Authorization: Bearer a1b2c3d4e5f6..." http://localhost:18789/api/chat

不配 token = 裸奔。 谁都能调你的 API,让你的 AI 干任何事。

4.3 反向代理配置

如果你用 Nginx 做反向代理,需要配置 trustedProxies,否则 OpenClaw 拿不到真实客户端 IP:

{  "gateway": {    "trustedProxies": ["127.0.0.1", "10.0.0.0/8"]  }}

对应的 Nginx 配置:

server {    listen 443 ssl;    server_name openclaw.example.com;    ssl_certificate     /etc/ssl/certs/openclaw.pem;    ssl_certificate_key /etc/ssl/private/openclaw.key;    location / {        proxy_pass http://127.0.0.1:18789;        proxy_set_header Host $host;        proxy_set_header X-Real-IP $remote_addr;        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;        proxy_set_header X-Forwarded-Proto $scheme;        # WebSocket 支持        proxy_http_version 1.1;        proxy_set_header Upgrade $http_upgrade;        proxy_set_header Connection "upgrade";    }}

⚠️ trustedProxies 千万别设成 ["0.0.0.0/0"],那等于信任所有人,任何人都能伪造 IP。

4.4 Tailscale 接入

Tailscale 是远程访问 OpenClaw 最安全的方式之一。两种模式对比:

推荐用 Serve,不用 Funnel。 除非你有明确的理由需要公网暴露。

4.5 mDNS 信息泄露

OpenClaw 默认会通过 mDNS 在局域网广播自己的存在,方便手机 App 发现。但这也意味着同一网络的任何人都能看到你跑了 OpenClaw。

在公共网络(咖啡厅、酒店)或者对安全要求高的环境,建议关掉或者改成最小模式:

{  "discovery": {    "mdns": {      "mode": "minimal"    }  }}

4.6 Docker 网络隔离

如果你在 Docker 里跑 OpenClaw,别忘了 Docker 默认会绕过 iptables/ufw 规则直接暴露端口。

用 DOCKER-USER 链来限制:

# 只允许局域网访问 OpenClaw 的 18789 端口iptables -I DOCKER-USER -p tcp --dport 18789 -s 192.168.0.0/16 -j ACCEPTiptables -I DOCKER-USER -p tcp --dport 18789 -j DROP

或者更简单的方法:不映射端口到 0.0.0.0。

# docker-compose.ymlservices:  openclaw:    ports:      - "127.0.0.1:18789:18789"  # ✅ 只映射到本机      # - "18789:18789"           # ❌ 别这样,等于暴露给所有人

5. Windows vs Linux 安全差异

OpenClaw 的安全配置在两个平台上大部分一致(Gateway 绑定、认证、通道策略、工具权限、会话隔离、mDNS、定时任务、密钥管理等),但有几个关键差异必须注意:

核心结论:如果你用 Windows,最大的影响是 exec allowlist 不可用。建议用 deny(最安全)或 full + ask: "always"(每条审批)替代。其他配置项两个平台通用。

后续篇章中涉及平台差异的地方,会用 ⚠️ 标注。

6. 小结

这篇讲的是”认知”–先搞清楚风险在哪,然后把最基础的防线拉起来。

下一篇我们聊入口控制–就算 Gateway 锁好了,谁能跟你的 AI 说话,说了之后能干什么,也得管起来。

系列导航:

• ✅ OpenClaw 安全指南(一·认知篇):你的 AI 助手有多危险?
• OpenClaw 安全指南(二·入口篇):谁能跟你的 AI 说话?
• OpenClaw 安全指南(三·执行篇):让 AI 在笼子里干活
• OpenClaw 安全指南(四·进阶篇):密钥、注入与应急

_👋 我是路人甲甲,公众号「AI 打怪升级」,专注 AI 工具实战。_

_觉得有用?点个在看,分享给需要的朋友。_