2026年6月，微软Build大会上展示了基于MXC（Microsoft Execution Containers）的Windows+OpenClaw演示，进一步提升了OpenClaw的关注度。如今，部分日本厂商已将OpenClaw作为应用轻松集成到NAS等嵌入式设备中，使其逐渐走入日常生活。本文基于OpenClaw的安全与运营理念“个人助理信任模型”，为首次接触OpenClaw的用户讲解应承担的责任。
用户判断与配置的重要性
首先必须明确，OpenClaw的风险多源于用户的判断和配置失误。
当然，也存在因漏洞或恶意软件导致的风险，例如著名的CVE-2026-25253漏洞，涉及Control UI认证令牌泄露，以及在OpenClaw的市场平台ClawHub上曾出现的多种恶意技能。
然而，这些漏洞已通过更新得到修复，ClawHub也在与安全厂商合作加强防护。当前的主要问题反而是OpenClaw知名度提升，安装环境简化，导致许多用户仅做最低限度配置便开始使用。
在多台可测试的NAS设备中发现，OpenClaw的安装方式虽统一为应用形式，但运行环境多样：有的仅运行Docker容器，有的将整个NAS卷挂载给Docker，还有的直接在NAS主机操作系统上运行OpenClaw。
不同厂商对OpenClaw与NAS结合的自由度与安全性的权衡不同，本文不对优劣做评判，但强调用户必须自行确认配置，明确允许的操作范围，否则可能产生意料之外的行为或后果。
接下来，我们回顾OpenClaw的基本概念，并介绍其强调的“个人助理信任模型”，以帮助用户在安装前理解其安全理念。
OpenClaw是什么？
OpenClaw由日本开发者Peter Steinberger创建，最初名为Clawbot，经过Moltbot阶段，最终定名为OpenClaw。
它是一款自主控制个人电脑的AI代理，能通过Telegram、Discord等消息应用执行邮件回复、文件整理、代码审查等多种任务，因其广泛的操作能力而迅速流行。
类似的AI代理还有Claude Code和Claude Cowork，但OpenClaw的特点是作为“万能个人助理”，拥有更广泛的操作权限和自由度，能控制文件和工具。
Peter Steinberger在微软Build 2026上曾幽默表示：“我设计OpenClaw可以访问一切”，并提及之前演示中OpenClaw试图删除Windows桌面所有文件的失败案例，称“几个月前这本来会成功”。
Windows原生版OpenClaw通过MXC实现“安全”运行，MXC是Windows/WSL上的策略驱动执行层，定义AI代理可访问的文件、网络、UI、剪贴板等权限，并由操作系统强制执行。
这可视为将零信任原则应用于AI代理执行环境的尝试。尽管未来面向企业的OpenClaw版本将采用此类设计，但OpenClaw本质上强调的是“可访问一切”的高度自由度。
因此，用户在使用OpenClaw时必须自行判断并配置允许的自由度范围。不同NAS厂商对开放权限的理解差异，导致公开的文件夹和执行环境各异。
跨越边界的操作员＝可信赖的机器人拥有者
未来AI代理或将普遍采用零信任的监控管理方式，但当前用户自行部署的OpenClaw及集成于NAS的OpenClaw应用仍采用边界安全模型。
OpenClaw的“个人助理信任模型”基于安全边界（网关访问），将可信区域与不可信区域区分开来。
类似于VPN连接企业内网后终端可访问内部系统，OpenClaw的网关通过认证和设备确认，将调用者视为“可信操作员”。
OpenClaw网关支持多种访问方式，包括内置的Control UI（网页）、Telegram等消息应用及本地命令操作。以网页Control UI为例：
- 若将Control UI暴露于包含互联网的广域网或局域网，能访问网关的用户或攻击者范围扩大，可信操作员数量增加。
- 知晓Control UI连接令牌或密码的用户均可能被视为可信操作员。
- 放宽或禁用设备认证及浏览器Origin限制，可能使本应限制访问的设备也能使用Control UI，进一步增加可信操作员。
换言之，放宽访问范围、用户和设备限制虽提升便利性，但必然降低安全等级。通过认证的操作员无论身份如何，均可从信任边界内操作代理、工具、认证信息和执行环境。
例如，OpenClaw的配置文件位于“~/.openclaw/openclaw.json”，其中明文存储连接令牌和API密钥。虽然可通过SecretRef隐藏配置文件中的凭证，但只要OpenClaw能访问内存或文件，或使用与网关相同的工具读取SecretRef，秘密信息仍可能泄露。
因此，OpenClaw本质上在信任边界内拥有强大权限，保护网关尤为关键。
值得注意的是，OpenClaw网关并非设计用于安全隔离多个互不信任的用户，换言之，不适合局域网内多用户共享访问。此设计理念与NAS等设备多用户访问的需求存在矛盾。例如，即使用户文件夹设置了访问权限，OpenClaw可能凭借管理权限自由访问所有数据。跨越边界的用户均被视为可信操作员，用户级访问控制与设计理念不符。
虽然部分NAS厂商可能采取措施，但目前大多数产品未见相关防护，用户应充分认识此风险。
理解OpenClaw的影响范围
安全使用OpenClaw不仅需限制网关入口，还需明确允许OpenClaw操作的范围。OpenClaw作为代替用户操作真实环境的软件，其高度自由度是优势，但权限越大，误操作、配置错误或漏洞带来的影响也越广。
影响范围可从三个方面理解：权限、文件系统和网络。
权限
OpenClaw以何种权限运行至关重要。若以专用普通用户身份运行，其操作范围受限于该用户权限。
若以UID=0（root）身份运行，或能访问sudo、Docker套接字、管理员API密钥，则可能影响整个系统。新版OpenClaw通过安全保护拒绝危险命令（如“rm -rf”或显示API密钥），但仍需警惕其潜在的全访问能力。
文件系统
若仅向OpenClaw开放工作目录，误操作影响可局限于该目录。若开放整个用户目录或NAS共享卷，影响范围扩大。
若本地安装且能操作系统区域，则不仅数据，连操作系统和服务配置也可能受影响。市售NAS厂商对开放区域的设计差异较大，可能仅限工作目录、共享卷或包含系统的整个主机，用户应确认具体开放范围。
网络
OpenClaw若能访问局域网内其他PC、NAS、路由器、虚拟机或云服务，若被误操作，影响可能超出本机。
例如，能访问同网管理界面、通过SSH连接其他服务器、认证访问NAS或云存储时，存在横向扩散风险。
缩小影响范围的措施包括：以专用用户运行OpenClaw、限制开放目录、避免存放不必要的认证信息、通过Docker或虚拟机隔离运行环境。
可将OpenClaw及网关整体封装于容器或虚拟机，或仅沙箱化Shell执行环境和浏览器操作。同时，应通过网络隔离和防火墙限制不必要的访问。
但需注意，Docker沙箱的安全性依赖于Docker Engine和守护进程配置。历史上存在针对Docker Engine 29.3.1以下版本的漏洞（CVE-2026-34040），攻击者可通过Docker API或套接字逃逸沙箱，影响宿主系统。
因此，评估OpenClaw安全性时，不仅要考虑“能否使用”，更要关注“出现问题时影响范围”和“与其他系统的组合风险”。合理配置权限、文件系统访问和网络访问是管理风险的基础。
安全配置不存在，避免危险配置
接下来介绍具体配置示例，但本文重点是帮助用户理解风险，自行判断是否使用OpenClaw。由于设计理念的差异，无法定义绝对安全的配置，只能提醒避免危险配置。
用户应检查“~/.openclaw/openclaw.json”文件，确认是否存在以下需注意的配置。
这些配置本身不一定危险，而是体现了高自由度。若用户愿意信任操作员并允许高自由度，则这些配置合理。
OpenClaw内置安全审计功能，运行“openclaw security audit --deep”可检测关键和警告配置。若用户明确理解配置，则无问题；若无意中存在，应评估其意义和应对措施。
还可通过特定提示让OpenClaw自身执行安全自检，体现其自由度和信任模型的重要性。
结语：必须亲自体验才能理解
本文介绍了OpenClaw的安全理念及关键配置注意点，未涉及技能等高级内容，供初学者参考。
OpenClaw的使用因人而异，自由度需求不同，故无绝对正确答案。个人认为，选择OpenClaw而非其他代理，意味着愿意承担风险以获得更高自由度，前提是理解并接受其“可访问一切”的设计理念和信任模型。
市面已有一键安装OpenClaw的环境，但用户应明白这背后承担的重大责任。
建议用户认真调研后再决定是否使用，而非盲目尝试。
