为什么 OpenClaw 需要高权限？

因为 OpenClaw 可以执行 shell 命令、管理文件、控制浏览器和调用外部服务，要实现真正可用的自治能力，通常就需要较高的本地系统权限。

在 VPS 上运行 OpenClaw 安全吗？

可以通过隔离、防火墙、最小权限和访问控制把风险降下来，但绝不能把它默认当成天然安全的服务。

OpenClaw 最大的安全风险是什么？

提示词注入是最大的风险之一，因为恶意网页、邮件或文档可能诱导 Agent 泄露数据或通过工具执行危险动作。

应该怎样加固 OpenClaw 部署？

使用专用机器或容器，避免公网暴露，把敏感服务绑定到 localhost，限制高风险工具，保护凭证，并持续监控日志和网络边界。

OpenClaw 安全警告：为何它需要 Root 权限以及如何保护你的 VPS

直面问题

让我们开门见山：社区对 OpenClaw 需要 root 权限的担忧是完全合理的。

来自 Cisco、VentureBeat 和 Vectra AI 的安全研究人员都发布了评估报告。共识是什么？用 Cisco 的话说，运行一个具有 shell 访问权限的自主 AI 代理，从安全角度来看是"一场噩梦"。

但事实是：工具本身是中性的。安全取决于你如何使用它。

为什么 OpenClaw 需要这么高的权限？

OpenClaw 不是一个聊天机器人。它是一个电脑操控（Computer Use）代理——可以：

执行 shell 命令和脚本
读取、写入和管理系统中的文件
安装软件包和配置环境
控制浏览器和桌面应用程序
代表你访问消息平台

要自主执行这些任务，它需要提升的权限。这是无法避免的。

官方文档对此非常坦诚：

"在你的机器上运行一个具有 shell 访问权限的 AI 代理……很刺激。以下是如何避免被黑的方法。"

已知漏洞

在讨论解决方案之前，先了解风险：

1. 提示词注入（Prompt Injection）

OpenClaw 读取的任何恶意内容（邮件、网页、文档）都可能强制它执行命令。安全研究人员演示了通过发送一封恶意邮件，在 5 分钟内提取私钥。

2. 明文凭据

API 密钥和 OAuth 令牌以明文形式存储在 ~/.openclaw/ 配置文件中。

3. 暴露的管理端口

默认情况下，OpenClaw 在端口 8080 上打开无需认证的管理界面。如果暴露在互联网上，攻击者可以窃取你的凭据。

4. 无限制的 Shell 访问

一个已记录的事件：一个助手将整个主目录结构转储到了群聊中。

行动指南：如何保持安全

1. 绝不在生产服务器上运行

这是不可妥协的。 不要在包含以下内容的服务器上运行 OpenClaw：

客户数据
生产数据库
敏感业务逻辑

使用专用的、隔离的机器或 VPS。

2. 使用 Docker 进行隔离

Docker 容器提供了安全边界。这是一个最小化的配置：

docker run -d \
  --name openclaw \
  --restart unless-stopped \
  -v openclaw-data:/data \
  -p 127.0.0.1:8080:8080 \
  ghcr.io/openclaw/openclaw:latest

关键： 始终绑定到 127.0.0.1，永远不要用 0.0.0.0。

3. 锁定防火墙

在 Ubuntu/Debian 上：

# 只允许 SSH，拒绝外部访问 8080
sudo ufw allow ssh
sudo ufw deny 8080
sudo ufw enable

4. 永远不要泄露 API 密钥

尽可能使用环境变量而不是配置文件
如果必须使用配置文件，限制权限：chmod 600 ~/.openclaw/config.json
如果怀疑泄露，立即轮换密钥

5. 限制高风险工具

在 OpenClaw 配置中，限制危险功能：

{
  "tools": {
    "exec": { "allowlist": ["git", "npm", "docker"] },
    "browser": { "enabled": false },
    "web_fetch": { "allowlist": ["api.github.com"] }
  }
}

6. 使用 Claude Opus 4.5

模型选择很重要。Anthropic 的 Opus 4.5 在识别和拒绝提示词注入攻击方面明显优于旧模型。

FAQ：读完这篇安全警告后，运维团队最先要做的三个决定

如果业务上还是得上 VPS，最安全的起步线应该是什么？

先从专用机器或容器开始，把管理面只绑定到 localhost，用防火墙彻底关掉外部访问，并默认这台机器上不应该放无法承受泄露的核心秘密。如果连这套最低线都做不到，更安全的答案通常不是硬上，而是先留在本地环境。

如果这周只能先修一件事，什么动作最能立刻降风险？

先去掉公网暴露，再谈别的优化。关闭未认证入口、缩小 shell 可达范围、减少凭证裸露，通常比“以后再慢慢整理配置”更能实质降低风险。

如果团队说“先跑起来，后面再加固”，这句话通常会导致什么？

通常会导致高风险部署先变成默认状态，而隔离、监控、回退纪律永远排在后面。更稳的做法是把加固纳入首次上线条件，而不是当成未来某次清理任务。

安全落地前的最小上线清单

如果这篇是你的安全入口页，上线前至少把下面四项写进变更单：

入口边界：确认 Gateway、反向代理和管理面分别监听在哪里，公网只暴露必须入口。
凭证边界：确认 API key、OAuth token、SSH key 不落在可被 agent 随手读取的目录里。
工具边界：给 exec、浏览器、文件写入和外部请求设置最小可用范围。
回滚边界：准备一个能在 10 分钟内执行的停机、撤回端口或恢复旧配置方案。

这份清单的目的不是追求“绝对安全”，而是避免把高权限 agent 直接放进一个无边界、无审计、无回滚的生产环境。

结论

OpenClaw 之所以强大，正是因为它对你的系统有广泛的访问权限。这种力量伴随着责任。

官方立场：

"不存在'完美安全'的设置。"

这不是推脱——而是透明。如果你不熟悉：

服务器加固
反向代理信任边界
最小权限访问控制

……那么在公共 VPS 上运行 OpenClaw 可能不适合你。考虑在专用的本地机器上运行它。

工具是中性的。你的配置决定了你的安全态势。

详细的安全配置，请参阅 OpenClaw 官方安全文档。