OpenClaw 在 2026 年的增长让它成为供应链攻击者会盯上的目标：扩展、MCP server、模板、复制粘贴的 shell 命令。正确反应不是恐慌，而是把爆炸半径缩小到“重建一次 runner”就能解决。
这份清单面向需要马上加固的 OpenClaw 用户。Office Claws 不是原生 OpenClaw runtime；它是 Codex-first 的桌面管理器，用来在隔离 VPS 上运行编码 agent。这个区别很重要：下面讲的是诚实的缓解模式，而不是不存在的集成承诺。
要防的攻击链
大多数木马不需要 zero-day。它只需要通过一个被信任的扩展或脚本进入 runner，拿到文件和网络权限，读取 .env、shell history 或 token，然后用 agent 自己的工具持久化、外传数据或消耗 API 额度。
所以 OpenClaw 木马缓解主要是架构问题。
缓解清单
| 控制项 | 最低要求 | 更强做法 |
|---|---|---|
| Runner 隔离 | 每个 workspace 一个项目 | 高风险任务使用一次性 VPS |
| 密钥 | .env 不放长期 key | Keychain 或短期 token |
| 扩展 | 固定版本 | 审查 diff，拒绝过宽权限 |
| 网络 | 记录 egress | 按任务配置域名 allowlist |
| 花费 | Provider 限额 | 每个 agent 每日预算 |
| 恢复 | 干净分支 | 从 snapshot 重建 runner |
1. 把 agent 放在可以销毁的地方
如果木马落在没有浏览器 cookie、个人 SSH key 和无关 repo 的 host 上，危害会小很多。严肃的编码任务应该用容器或小 VPS。如果 runner 不对劲，销毁它、轮换 token、从 snapshot 重建。
2. Provider key 不要进 runner
最危险的默认值是把强权限 API key 放在项目 .env 里。把它移到系统 keychain，或用本地 broker 发短期任务 token。迁移到 Codex 编码工作流时，Office Claws for OpenClaw users 可以帮助保持桌面端与 runner 的边界。
3. 把扩展当作生产依赖
固定版本，避免 auto-update，升级前阅读 diff。对文件权限过宽、访问陌生域名、安装时下载二进制文件的扩展要直接阻止。
4. 让网络 egress 可见
很多木马最终都要向外连接。DNS 或 firewall 日志就是好的开始。更强的做法是只允许 Git 托管、包 registry、模型 provider 和你的 control plane。
5. 花费限额必须有
泄露且没有限额的 key 就是一张空白支票。在 provider 侧设置每日限额，并按 runner 监控 token 消耗。我们的 OpenClaw cost comparison 解释了为什么 Codex 订阅更容易预算，但可见性仍然必要。
6. 审计日志必须在 agent 外部
被攻陷的进程不能是唯一事实来源。Prompts、tool calls、shell 命令和 git diffs 都应持久化到 runner 外部。
什么时候转向 VPS 上的 Codex
如果 OpenClaw 主要用于广泛探索，本地小 sandbox 就够了。如果工作是 repo-centered coding、长时间测试和多分支协作，隔离 VPS 上的 Codex 往往更清晰。先读 OpenClaw vs Codex comparison。Office Claws 提供 provisioning、monitoring 和 multi-agent visibility，但不声称原生运行 OpenClaw。
15 分钟加固计划
- 从
.env移除 provider keys。 - 设置 provider 每日花费限额。
- 固定 OpenClaw 扩展版本并关闭 auto-update。
- 使用新分支和窄 workspace。
- 长任务放到 disposable host。
- 在 runner 外保存 logs 和 diffs。
木马缓解不是魔法扫描器，而是一组无聊但有效的边界：runner 上没有长期 secret，没有无限花费，没有不可见网络，也没有舍不得删除的 host。