大数跨境
首页
>
OpenClaw 到底安不安全？一篇讲清楚它的风险、边界和正确用法
>

OpenClaw 到底安不安全？一篇讲清楚它的风险、边界和正确用法

OpenClaw 到底安不安全？一篇讲清楚它的风险、边界和正确用法 Jungle AI出海手记
2026-03-12
100
导读：这几天，OpenClaw 的安全问题，已经从技术圈讨论，慢慢变成了更大范围的关注点。
这几天，OpenClaw 的安全问题，已经从技术圈讨论，慢慢变成了更大范围的关注点。
公开报道显示，国内已经有媒体、行业机构和高校开始集中讨论 OpenClaw 的风险：包括公网暴露、权限失控、提示词诱导、供应链投毒等问题。有报道提到，相关部门发布了风险提示，强调默认或不当配置下，OpenClaw 可能带来信息泄露、系统被控制等风险；也有高校和单位开始提醒或限制在校内、内网环境中使用。
所以，今天真正值得聊的，不是“OpenClaw 是不是危险软件”，而是：
OpenClaw 到底危险在哪？它本身有哪些安全设计？个人和企业怎样用，才算相对安全？
这篇文章，我尽量不用太多术语。你可以把它当成一篇“OpenClaw 安全说明书”。
先说结论：OpenClaw 不是“天然不安全”，但它绝对不是“装上就能放心乱用”的工具
OpenClaw 和普通聊天机器人不一样。
它不是单纯回答你问题，它是一个 会收消息、会连渠道、会调用工具、会读写文件、会执行动作 的 AI Agent 网关。官方也把它定义成一个自托管的 agent gateway，通过消息渠道、工具和自动化来驱动代理工作。
这意味着什么？
意味着你面对的，不是一个“会聊天的 AI”，而是一个：


带执行能力的数字员工
而任何一个“能执行”的系统，安全问题都不再只是“它会不会说错话”，而是：
  • 谁能找到它？
  • 谁能给它发指令？
  • 它能动到哪些文件和账号？
  • 它会不会被诱导做危险动作？
  • 它装的插件和 skills 安不安全？
  • 它知道的秘密，会不会被套出来？
所以，OpenClaw 的安全，不是一个“有或没有”的问题。
它更像一台动力很强的机器——你如果有边界、有刹车、有围栏，它可以很好用；你如果把它当玩具随手接公网、乱装 skills、群里谁都能叫，它当然容易出事。

01
为什么最近大家会特别担心 OpenClaw 安全？

因为现实里，确实出现了两个非常典型的问题。
第一类问题：公网暴露
很多人把 OpenClaw 部署在 VPS 上，却没有意识到它是一个“控制面 + 执行面”系统。结果把本来应该只在本机监听的网关端口，直接暴露到了公网。
官方文档写得很明确：Gateway 默认端口是 18789 ，控制客户端和 Web 控制界面都通过这个网关工作。Gateway 默认推荐本地模式，远程访问推荐走 SSH 端口转发或 VPN/tailnet，而不是直接对公网开放。
说人话就是：


它本来应该只在“家里”开门，结果很多人把门直接开到了大街上。
这样一来，扫描器一探测到这个端口，就知道：这里可能有一只 OpenClaw。
第二类问题：高权限 agent 被共享
另一个更隐蔽，也更致命的问题，是很多人会把一个带工具权限的 OpenClaw agent 拉到群里，谁都能和它说话。
官方安全文档明确提醒：如果多名不完全信任的人都能给同一个 tool-enabled agent 发消息，他们实际上是在共享这套被代理的工具权限；而 session 和记忆隔离，只能帮助隐私隔离， 并不能自动等于系统级权限隔离 。
这句话非常重要。翻译成人话：


不要以为“群里每个人都是独立聊天”，就代表“他们不能驱动同一套系统权限”。
如果你把一个能读文件、跑命令、连浏览器、连账号的 agent 放进一个大家都能 @ 它的群里，那么别人就可以尝试诱导它：
  • 读本机信息
  • 打印环境变量
  • 泄露上下文
  • 甚至通过 skills 或恶意内容间接让它做不该做的事

02
OpenClaw 的安全设计，到底有哪些？

说完风险，我们也得客观看它本身做了哪些防护。
1. 默认并不是“完全开放”
官方配置参考里明确提到：


groupPolicy 的默认思路是 allowlist


如果某个 provider 的 group 配置缺失，运行时会回落到 allowlist ，属于 fail-closed（失败时默认收紧）


群聊通常还会受到 requireMention / mention policy 的约束，没有被提及，就不会回应。
这意味着，OpenClaw 不是一上来就默认“谁拉进群都能用”。
真正把它变成开放状态的，往往是后续的部署方式和配置选择。
2. 官方明确把 plugins / skills 当成“不可信代码”来对待
这是很多人最容易忽略的一点。
官方安全文档和 skills 文档都写得很直白：


安装第三方插件时，应该把它当成“运行不可信代码”


第三方 skills 也应当视为不可信代码


高风险工具和不可信输入，优先放在 sandbox 里跑。
这句话等于官方自己在提醒你：


Skill 不是“功能包”，而更像“别人写的一段代码，你准备让它进你家跑”。
所以你以后装 skill，心态不能是“顺手加个插件”，而应该是：


“我要不要把这段外部代码放进我的系统里？”
3. 官方推荐的生产部署，不是“随便跑起来”，而是“安全优先的整套方案”
OpenClaw 官方并不只提供 install.sh 这种“先跑起来”的方式。它明确把 openclaw-ansible 作为生产服务器推荐方案，并且直接用“security-first architecture”来描述。官方给出的生产部署思路包括：
  • UFW 防火墙
  • Tailscale / VPN
  • Docker sandbox
  • localhost-only bindings
  • systemd hardening 等。
这说明一件事：


官方自己也知道，真正安全地跑 OpenClaw，不是“装上就行”，而是要把整台服务器的安全基线一起做好。
那为什么还会有人说“OpenClaw 很危险”？
因为 安全设计存在 ，不等于 部署时一定有人照做。
OpenClaw 本身不是“故意不安全”，但它有两个天然特点：
  1. 它能力很强
  2. 它很容易被不懂安全的人快速装起来
这两个特点叠在一起，就会出现现在这种情况：
很多人能在 10 分钟内装好
但没有花 10 分钟想清楚：谁能连它、它能动什么、它知道什么、出了事怎么兜底
于是风险就不是“理论上的”，而是现实里的。

03

用最小白的话讲：OpenClaw 最大的 4 

类安全风险

风险一：门开到了公网
这类风险最简单，也最常见。
你可以把 OpenClaw 的网关端口想成一扇门。
如果这扇门只对本机开放，问题不大。
如果你把它开放到了公网，那全互联网都能来敲门。
怎么看自己是不是犯了这个错？
你至少要检查：
  • Gateway 绑定地址是不是 127.0.0.1 而不是 0.0.0.0
  • 云安全组有没有开放 OpenClaw 端口
  • 有没有做 Nginx/Caddy 反代
  • Docker 有没有直接把端口映射到公网
一句话就是：


不要让 OpenClaw 的控制面直接暴露在互联网。
风险二：共享高权限 agent
最典型的错误，是把自己的“主 agent”拉进一个很多人都能说话的群里。
这个 agent 可能本来就：
  • 连着浏览器
  • 有文件权限
  • 有一些 secrets
  • 有长期记忆
  • 会执行动作
如果大家都能叫它做事，那么本质上就是：


很多人共享了一把钥匙。
最容易出问题的场景
  • 公开群
  • 大团队群
  • 不同信任等级的人混在一个群里
  • 同一个 agent 既服务你的私聊，又服务公共群聊
这种情况下，别人当然会想办法“问出”不该问的内容。
风险三：提示词注入和内容诱导
这个词听起来高深，其实你可以理解为：


有人在用话术骗 OpenClaw 去做不该做的事。
比如：
  • 让它忽略原来的规则
  • 假装自己是管理员
  • 让它把“当前环境变量”打印出来
  • 让它“为了排障”读某个文件
  • 在网页、邮件、skill 文档里埋隐藏指令
但这里有一个很重要的判断：


真正决定有没有大事发生的，不是“别人能不能骗”，而是 这个 agent 原本就被允许做什么 。
如果一个 agent：
  • 不能读系统文件
  • 不能跑 shell
  • 不能访问 secrets
  • 不能直接发送高风险动作
那别人再怎么骗，它最多也只是多说几句错话。
真正危险的是：


一个本来就有很多权限的 agent，又处在容易被外部输入影响的环境里。
风险四：插件和 skills 供应链
很多人是从 ClawHub、GitHub、社区帖子看到某个 skill 很酷，就直接装。
但官方已经明确提醒：第三方 plugins / skills 都要当作不可信代码看待。
你可以把 skill 理解成：


别人写好的“功能包”


但它背后其实是“别人写好的可执行逻辑”
如果你没有审查、没有白名单、没有测试环境，直接在生产 bot 上装，那风险和“随便执行互联网上拷来的脚本”很接近。

04
个人和企业的安全防护方法

那我到底该怎么防？个人和企业分别说
一、个人用户怎么把 OpenClaw 用得相对安全？
如果你是个人用户，最重要的原则只有一句：


把 OpenClaw 当成“有权限的数字员工”，不要当成玩具。
个人用户的 7 条最小安全清单
  1. 不要把 OpenClaw 跑在你的主力生活/工作环境里
    最好用单独机器、单独 VM、单独 Docker、至少单独 OS 用户。官方安全文档也推荐 dedicated machine / VM / container / dedicated OS user。
  2. 单独账号，单独浏览器，单独 token
    不要让它直接共享你自己的主邮箱、主浏览器、主密码库。
  3. 群聊一律 allowlist + requireMention
    不要开 groupPolicy: open ，不要让群里谁都能叫它。
  4. 私聊 agent 和群聊 agent 分开
    别用一个高权限 agent 同时服务你自己和公共群。
  5. 不要把 API key、cookie、密码发给它“让它记住”
    秘密不要进聊天，不要进 MEMORY，不要进 prompt。
  6. Secrets 一律走环境变量、token 文件或 SecretRef
    官方文档支持 tokenFile 、SecretRef、env substitution 这类方式。
  7. 第三方 skills 只装可信来源，先读再用
把“装 skill”当成“运行外部代码”。
二、企业用户怎么把 OpenClaw 用得相对安全？
企业最容易犯的错，不是“端口忘关”，而是：


想用一个 OpenClaw 机器人，服务所有人、所有群、所有系统。
这是最危险的思路。
企业用户的 8 条核心原则
  1. 按信任边界拆
    官方安全文档明确说，不要把它当成天然支持敌对多租户的系统。多人共享时，最好按 trust boundary 拆 gateway / OS 用户 / 主机。
  2. 私聊 agent 和群聊 agent 分开
    老板私聊大脑，和团队公共助手，不应该是同一个 agent。
  3. 高权限 agent 不要进公共群
    有 shell / 浏览器 / 文件权限的 agent，只服务极少数可信入口。
  4. 共享入口先用低权限 profile
    先让它只会消息、检索、摘要，不要一上来就能跑命令。官方安全基线就是这么建议的。
  5. Docker / sandbox / 专用 OS 用户要一起上
    OpenClaw 的沙箱不是为了防扫描，而是为了防它直接动到整个主机。
  6. Secrets 管理不能靠“写在 prompt 里”
    应该走环境变量、专用 token 文件、SecretRef，且避免进入日志。官方 skills 文档还特别提醒：keep secrets out of prompts and logs。
  7. 插件/skills 建白名单
    不要让员工在生产 bot 上随便装社区 skill。
  8. 公网暴露面必须收缩
不直连公网，优先 loopback + SSH 转发 + VPN / tailnet。官方部署文档明确推荐这条路。

05
常见问题解答

密码、Cookie、API Key 到底怎么安全地交给 OpenClaw？
这是很多人最关心的。
大白话讲：


要让 OpenClaw“用到秘密”，但不要让它“看见秘密并记住秘密”。
错误做法
  • 把密码发到聊天里
  • 让它“帮我记住这个 cookie”
  • 在 MEMORY.md 写 token
  • 在 AGENTS.md 里直接贴 API key
正确做法
  • 用环境变量
  • 用 tokenFile
  • 用 SecretRef
  • 用单独配置文件/secret 文件
让工具运行时拿到它，但不把它放进自然语言上下文里
如果一句话总结：


秘密要交给系统配置层，不要交给对话层。
Docker 沙箱到底是做什么的？
很多人听到“Docker 更安全”，但不知道它到底在安全上帮了什么。
最简单的比喻是：


Docker 沙箱不是防止别人找到你，而是防止 AI 一旦出错，直接碰到你整台机器。
如果不用沙箱，OpenClaw/agent 就像在你家客厅里自由走动。
如果用了 Docker 沙箱，它更像被安排在一个独立工作间里，只给它那间屋子的钥匙。
所以 Docker 沙箱主要解决的是：
  • 文件系统隔离
  • 依赖隔离
  • 宿主机污染减少
  • 失控时影响范围缩小
但它不能单独解决：
  • 公网暴露
  • 插件供应链
  • 权限设计错误
  • 群聊共享高权限 agent
所以正确理解是：


Docker 是围栏，不是万能护身符。
你怎么知道自己是不是“危险用法”？
下面这 10 个问题，你只要有 3 个答“是”，就该赶紧收紧配置。
  1. 你的 OpenClaw 端口能从公网直接访问吗？
  2. 你把高权限 agent 拉进了公共群吗？
  3. 群聊里谁都能 @ 它吗？
  4. groupPolicy 是不是开的 open ？
  5. 你把 cookie / token / 密码发给它“让它记住”过吗？
  6. 你装过自己没读过的第三方 skills 吗？
  7. 你让很多人共享同一个 tool-enabled agent 吗？
  8. 你没有专用 OS 用户 / Docker / 沙箱隔离吗？
  9. 你还没搞清楚 OpenClaw 在哪些目录、日志里会留下数据吗？
  10. 你还没跑过官方推荐的 security audit / status 检查吗？
06
最终判断

现在很多人讨论 OpenClaw 安不安全，很容易走向两个极端：
极端一：
“这玩意太危险了，不能碰。”
极端二：
“这就是媒体危言耸听，根本没事。”
我更倾向于第三种说法：


OpenClaw 不是不能用，而是不能“像装普通聊天机器人一样用”。
你必须把它当成：
  1. 一个有执行能力的系统
  2. 一个需要门禁的入口
  3. 一个需要最小权限的数字员工
  4. 一个需要插件白名单、秘密管理和运行隔离的生产组件
你这样用，它就不是“天然危险”。
你不这样用，它就一定会让你焦虑。

【声明】内容源于网络
0
0
Jungle AI出海手记
1234
内容 27
粉丝 0
Jungle AI出海手记 1234
总阅读1.0k
粉丝0
内容27