OpenClaw 安全配置完全指南：Docker 沙盒到权限控制的五层防御

凌晨三点，一位开发者在 Reddit 上发帖求助。他在自己的 MacBook 上装了 OpenClaw，用默认配置跑了两周，觉得挺好用。直到有一天，他让 OpenClaw “帮我整理一下最近的项目文件”——结果 AI 顺手读取了 ~/.ssh/ 和 ~/.aws/ 目录，并在回复中”贴心地”展示了他的私钥内容。

更要命的是，这次对话记录同步到了他的工作群组。

说实话，我第一次看到这个案例时，后背一阵发凉。OpenClaw 是个超强的 AI 助手，能执行 Shell 命令、读写文件、控制浏览器——但这也意味着，如果配置不当，它就像一个拿着你家钥匙的陌生人。

Railway - 现代化的部署平台，告别繁琐运维，让代码分钟级上线

立即开始 →推广

你可能会想：我就自己用，应该没事吧？

哎，问题就在这里。OpenClaw 的风险不只来自外部攻击，还有 Prompt 注入（有人在聊天中偷偷塞入恶意指令）、配置失误（一不小心暴露了 API 端口）、甚至 AI 自己的”过度热情”（你让它清理文件，它可能理解成删除重要数据）。

这些本可以避免，只要正确配置。

这篇文章会手把手教你如何给 OpenClaw 套上”安全笼子”——从 Docker 沙盒隔离到权限精细控制，五层防御让你安心使用这头”猛兽”。话说前面：配置看起来有点繁琐，但比起数据泄露和删库跑路，这点麻烦真不算什么。

为什么需要安全配置？

OpenClaw 的权限到底有多大？

先说个让人清醒的事实。OpenClaw 不是那种只能聊天的 AI 助手——它能干的事儿，基本等同于你在终端里能干的所有事：

• 执行任意 Shell 命令：rm -rf /？技术上可以。
• 读写整个文件系统：你的 SSH 密钥、AWS 凭证、数据库密码，只要在磁盘上，它都能碰到。
• 访问网络资源：调用 API、下载文件、甚至扫描内网端口。
• 控制浏览器：通过 Playwright 操作你的浏览器，包括登录状态的网站。
• 读取环境变量：process.env 里的敏感信息一览无余。

换句话说，给 OpenClaw 默认权限，就像给一个”很聪明但你不太了解的助手”发了一张你家的万能钥匙。

默认配置有多危险？

我知道很多人图省事，npm install -g openclaw 装完就直接 openclaw run。但你知道默认情况下会发生什么吗？

在 v2026.1.29 之前：

• 访问控制可以设置为 auth: none，意思是任何拿到你 URL 的人都能控制你的 OpenClaw。
• 无沙盒隔离，AI 可以读写整个文件系统。
• 所有工具默认开启，包括危险的 exec 和 browser。
• 可能以高权限（甚至 root）运行。

"v2026.1.29 强制移除了 auth: none 选项，必须配置 Token 或密码认证"

v2026.1.29 之后稍微好点：官方强制移除了 auth: none 选项，必须配置 Token 或密码认证。但其他问题依然存在——沙盒、工具权限、文件系统访问，这些都需要你手动配置。

老实讲，默认配置就像敞开家门睡觉，还在门口立了块牌子写着”欢迎参观”。

安全配置的三个目标

配置这么多东西，到底是为了什么？核心就三点：

1. 最小权限原则：只给 OpenClaw 它真正需要的权限，别的一概不给。你让它帮你写代码，那就给读写 workspace 的权限；你不需要它操作浏览器，那 browser 工具就该禁用。

2. 纵深防御：不能把所有希望寄托在一道防线上。Docker 隔离、非特权用户、访问控制、工具白名单、网络隔离——五层防御，任何一层被突破，其他层还能兜底。

3. 可控的爆炸半径：假设最坏的情况发生了——Prompt 注入成功、Token 泄露、或者 AI 自己出 Bug——损失能控制在多大范围？如果 OpenClaw 只能访问一个隔离的 workspace 目录，那泄露的也只是这个目录的内容，而不是你整个 /home 目录。

说白了，安全配置不是为了防止攻击（那是不可能的），而是让攻击的代价足够高、损失足够小。

五层安全配置

好了，废话不多说，开始实战。我会按照从底层到上层的顺序，讲解五层防御配置。每一层我都会告诉你”为什么要这样做”和”怎么验证配置成功”。

第一层：Docker 沙盒隔离（必须级）

为什么用 Docker？

很多人觉得 Docker 只是为了方便部署。错。对于 OpenClaw 这种高权限应用来说，Docker 最大的价值是隔离：

• 文件系统隔离：AI 只能看到容器内的文件，你的 ~/.ssh 在宿主机上，它碰不到。
• 网络隔离：可以切断容器的外网访问，或者只允许访问特定域名。
• 资源限制：防止 AI 跑个死循环把你的 CPU 烧了。
• 快速恢复：出问题了？docker rm 删掉容器，几秒钟重建一个干净的。

有人会问：我在本地开发机上跑，需要这么麻烦吗？

需要。本地更危险——你的开发机上有 GitHub Token、数据库密码、各种 API 密钥，这些都是 Prompt 注入攻击的目标。

配置步骤

1. 创建安全的 Dockerfile

FROM openclaw/gateway:latest

# 创建非特权用户
RUN adduser --disabled-password --gecos '' clawuser

# 切换到非特权用户
USER clawuser

# 设置工作目录
WORKDIR /home/clawuser/openclaw

这里的关键是 USER clawuser。默认 Docker 容器以 root 运行，这意味着容器内的 OpenClaw 有 root 权限。创建专用用户后，即使有人突破了容器，也只是 clawuser 权限。

2. 使用 Docker Compose 配置安全参数

这部分是核心，我会逐行解释：

version: '3.8'
services:
  openclaw-gateway:
    build: .
    container_name: openclaw-safe

    # 安全配置
    security_opt:
      - no-new-privileges:true  # 防止容器内进程提升权限
    cap_drop:
      - ALL  # 移除所有 Linux capabilities
    cap_add:
      - NET_BIND_SERVICE  # 只添加绑定端口的能力

    # 只读根文件系统
    read_only: true

    # 临时目录（可写）
    tmpfs:
      - /tmp
      - /home/clawuser/openclaw/temp

    # 资源限制
    deploy:
      resources:
        limits:
          cpus: '2.0'
          memory: 4G
        reservations:
          cpus: '1.0'
          memory: 2G

    # 网络隔离
    networks:
      - openclaw-isolated

    # 卷挂载（最小权限）
    volumes:
      # 工作目录（读写）
      - ./workspace:/home/clawuser/workspace
      # 配置文件（只读）
      - ./config:/home/clawuser/openclaw/config:ro
      # 日志目录（只写）
      - ./logs:/home/clawuser/openclaw/logs

networks:
  openclaw-isolated:
    driver: bridge
    internal: true  # 不允许访问外部网络

为什么这样配置？

• no-new-privileges:true：防止通过 sudo 或 setuid 提权。即使攻击者在容器内找到了漏洞，也无法获得更高权限。
• cap_drop: ALL：Linux 的 capabilities 是细粒度的权限控制。移除全部，然后只加回必要的（比如绑定端口），这样攻击面最小。
• read_only: true：根文件系统只读。攻击者即使进来了，也无法安装后门、修改系统文件。需要写入的地方（比如 /tmp）用 tmpfs 挂载。
• internal: true：容器无法访问外部网络。如果你的 OpenClaw 不需要联网（比如只处理本地文件），这个配置能防止数据外泄。

3. 启用 OpenClaw 的 sandbox 模式

在 config/config.yaml 中：

sandbox:
  mode: "non-main"  # 所有群聊都在隔离容器中运行
  docker:
    enabled: true
    network: "none"  # 禁用沙盒容器的网络访问

这是 OpenClaw 自己的沙盒功能。mode: "non-main" 意思是：除了你的主要聊天窗口，其他所有对话都在独立的 Docker 容器中运行。这样即使某个对话被 Prompt 注入攻击了，它也只能在自己的小沙盒里折腾。

验证方法

配置完别急着用，先验证一下：

# 检查容器是否以非 root 用户运行
docker exec openclaw-safe whoami
# 应该返回：clawuser

# 检查文件系统是否只读
docker exec openclaw-safe touch /test.txt
# 应该返回：Read-only file system

# 检查网络隔离
docker exec openclaw-safe ping 8.8.8.8
# 应该返回：Network is unreachable

如果上面三个测试都通过了，恭喜，第一层防御就位了。

第二层：非特权用户运行（必须级）

Docker 容器内用了非 root，但容器是谁启动的？如果你在宿主机上用 root 跑 docker-compose up，那攻击者一旦逃逸出容器，还是能拿到 root 权限。

解决方案：创建专用低权限用户

在宿主机上配置：

# 创建专用用户组和用户
sudo groupadd -r openclaw
sudo useradd -r -g openclaw -d /opt/openclaw -s /bin/bash clawuser

# 创建目录结构
sudo mkdir -p /opt/openclaw/{workspace,config,logs,temp}

# 设置目录权限
sudo chown -R clawuser:openclaw /opt/openclaw
sudo chmod 700 /opt/openclaw/config  # 配置文件目录（只有 owner 可读写）
sudo chmod 755 /opt/openclaw/workspace  # 工作目录
sudo chmod 750 /opt/openclaw/logs  # 日志目录

# 限制用户权限
sudo usermod -L clawuser  # 锁定密码登录，只能通过 su 切换

为什么要 chmod 700？

chmod 700 意思是：只有文件所有者（clawuser）可以读写执行，其他人连看都看不了。配置文件里可能有 Token、密码，必须严防死守。

凭证文件权限（超级重要！）

如果你用 OpenClaw 连接 WhatsApp 或其他服务，凭证文件的权限要特别小心：

# 凭证文件必须是 600（只有 owner 可读写）
chmod 600 ~/.openclaw/credentials/whatsapp/*/creds.json
chmod 700 ~/.openclaw

我见过有人把凭证文件设成 644（所有人可读），结果被同服务器的其他用户偷看了。这种低级错误千万别犯。

验证

# 检查 OpenClaw 进程的用户
ps aux | grep openclaw
# 应该显示 clawuser，而不是 root

# 检查文件权限
ls -la /opt/openclaw/config
# 应该是 drwx------ clawuser openclaw

为什么这一层重要？

假设最坏的情况：攻击者突破了 Docker 容器、突破了 OpenClaw 的沙盒、执行了任意代码——但他还是只有 clawuser 权限：

Vultr - 高性能 NVMe 云服务器，32 个全球节点可选，支持一键部署 Docker

查看定价 →推广

• 无法访问其他用户的文件
• 无法安装系统级软件（没有 sudo 权限）
• 无法修改 /etc 下的系统配置
• 无法读取 /root 目录

这就是纵深防御的意义：一层被突破，下一层继续保护你。

第三层：访问控制与身份验证（必须级）

前两层解决的是”OpenClaw 能干什么”，这一层解决的是”谁能使用 OpenClaw”。

v2026.1.29 重大变更

以前 OpenClaw 允许 auth: none（完全不验证），这简直是灾难。好在官方终于醒悟了，v2026.1.29 强制移除了这个选项，现在必须配置 Token 或密码认证。

配置 Gateway Token 认证

Token 认证比密码好在哪？你可以给不同的人/应用分配不同的 Token，每个 Token 有不同的权限。某个 Token 泄露了？撤销它，不影响其他 Token。

在 config/config.yaml 中：

gateway:
  # 强制 Token 认证
  auth: token

  # Token 配置
  tokens:
    - name: "admin-token"
      value: "${OPENCLAW_ADMIN_TOKEN}"  # 从环境变量读取，不要硬编码！
      permissions:
        - "admin"  # 完整权限

    - name: "readonly-token"
      value: "${OPENCLAW_READONLY_TOKEN}"
      permissions:
        - "chat"  # 只能聊天
        - "read"  # 只能读文件
      # 注意：不包含 exec、browser 等高危权限

生成安全 Token

千万别用 123456 或 mytoken 这种弱 Token。用这个命令生成 256 位随机 Token：

# 生成随机 token
openssl rand -base64 32

# 设置环境变量（不要硬编码在配置文件中！）
export OPENCLAW_ADMIN_TOKEN="你生成的 token"
export OPENCLAW_READONLY_TOKEN="另一个 token"

为什么不能硬编码？因为配置文件可能会被提交到 Git、被日志系统记录、被备份到云端。环境变量相对安全一些。

访问控制白名单

Token 解决了”谁能访问”，但还不够。你可能只想让特定的 WhatsApp 用户或群组使用 OpenClaw：

# DM（私聊）策略
dmPolicy: allowlist  # 白名单模式
allowFrom:
  - "user_id_1"  # 只有这些用户可以私聊
  - "user_id_2"

# 群组策略
groupPolicy: allowlist
allowFrom:
  - "group_id_1"  # 只有这些群组可以使用

# Mention gating（群聊中只响应 @ 提及）
mentionGating: true

# 禁止公开访问
publicAccess: false

mentionGating: true 特别有用。想象一下：你在一个 100 人的工作群里部署了 OpenClaw，如果不开启这个，群里每条消息 OpenClaw 都会处理（费钱不说，还容易被恶意 Prompt 攻击）。开启后，只有 @ 它的时候才会响应。

验证

# 测试未授权访问（应该被拒绝）
curl -X POST http://localhost:3000/api/chat \
  -H "Content-Type: application/json" \
  -d '{"message":"hello"}'
# 应该返回：401 Unauthorized

# 测试有效 token
curl -X POST http://localhost:3000/api/chat \
  -H "Authorization: Bearer ${OPENCLAW_ADMIN_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{"message":"hello"}'
# 应该返回：200 OK

为什么这一层关键？

没有访问控制，前面的隔离和权限限制都是白搭——攻击者直接通过 API 入侵，根本不需要突破 Docker 或提权。

这一层是守门员，把不该进来的人挡在外面。

第四层：工具权限控制（推荐级）

现在 OpenClaw 已经被关在笼子里了，但笼子里它还是有很多工具可以用。是时候没收一些危险工具了。

问题：默认所有工具都可用

OpenClaw 自带了几十个工具：exec（执行 Shell 命令）、browser（控制浏览器）、write_file（写文件）、web_fetch（抓取网页）…默认全部开启。

但你真的需要所有这些吗？如果你只是让 OpenClaw 帮你写代码、查资料，browser 和 exec 完全可以禁用。

配置工具白名单

tools:
  # 只允许安全工具
  allowlist:
    - "read_file"      # 读文件
    - "write_file"     # 写文件（限定目录）
    - "web_search"     # 网络搜索
    - "git"            # Git 操作
    # 注意：不包含 exec、browser 等高危工具

  # 高危工具需要显式授权
  exec:
    enabled: false  # 默认禁用 shell 执行

  browser:
    enabled: false  # 禁用浏览器控制

  web_fetch:
    enabled: true
    # 域名白名单
    allowedDomains:
      - "github.com"
      - "api.anthropic.com"
      - "*.npmjs.com"

如果必须启用 exec，用命令白名单

有时候你确实需要 OpenClaw 执行命令（比如跑测试、build 项目）。那就用白名单：

tools:
  exec:
    enabled: true
    sandbox: true  # 在沙盒中运行

    # 白名单优于黑名单
    allowCommands:
      - "git"
      - "npm"
      - "yarn"
      - "pytest"
      - "curl"

    # 危险命令黑名单（双保险）
    denyCommands:
      - "rm -rf"
      - "sudo"
      - "chmod 777"
      - "dd if="
      - "mkfs"
      - "> /dev/sda"

为什么白名单优于黑名单？因为攻击手段千变万化，你永远列不完所有危险命令。但安全命令是有限的，列出来就行了。

文件系统访问限制

filesystem:
  # 允许访问的目录
  allowedPaths:
    - "/home/clawuser/workspace"
    - "/home/clawuser/projects"

  # 禁止访问的目录
  deniedPaths:
    - "/home/clawuser/.ssh"
    - "/home/clawuser/.aws"
    - "/home/clawuser/.config"
    - "/etc"
    - "/root"

  # 默认权限
  defaultPermission: "readonly"  # 默认只读

  # 写权限需要显式授予
  writablePaths:
    - "/home/clawuser/workspace/temp"

这样配置后，即使有人通过 Prompt 注入让 OpenClaw “读取 ~/.ssh/id_rsa”，也会被拒绝。

验证

在 OpenClaw 聊天界面测试：

• 你：“帮我执行 sudo apt update”

  • OpenClaw 应该回复：无法执行该命令，已被安全策略阻止

• 你：“读取 ~/.ssh/id_rsa 文件”

  • OpenClaw 应该回复：Access denied

第五层：网络隔离与监控（高级）

如果你是企业用户、处理敏感数据、或者就是想做到极致安全，这一层提供了终极防护。

网络隔离：切断不必要的连接

前面我们用 internal: true 让容器无法访问外网。但 OpenClaw 需要调用 Claude API 啊，怎么办？

阿里云 - 开发者上云首选，轻量服务器专享 8.5 折优惠，助力项目快速上线

领取 8.5 折优惠 →推广

方案：代理出站流量

只允许 OpenClaw 访问特定域名（比如 api.anthropic.com），其他一律阻断：

# docker-compose.yml
services:
  openclaw-gateway:
    environment:
      - HTTP_PROXY=http://allowlist-proxy:8080
      - HTTPS_PROXY=http://allowlist-proxy:8080
    networks:
      - openclaw-isolated

  allowlist-proxy:
    image: squid:latest
    volumes:
      - ./squid.conf:/etc/squid/squid.conf:ro
    networks:
      - openclaw-isolated
      - external  # 只有代理可以访问外网

squid.conf（代理白名单配置）：

# 允许的域名
acl allowed_domains dstdomain .anthropic.com
acl allowed_domains dstdomain .github.com
acl allowed_domains dstdomain .npmjs.com

# 允许 HTTPS
acl SSL_ports port 443
acl CONNECT method CONNECT

# 访问规则
http_access allow allowed_domains
http_access deny all

# 日志
access_log /var/log/squid/access.log

这样配置后，OpenClaw 只能访问这三个域名，其他网站一律被代理拦截。即使 Prompt 注入让它”下载恶意脚本”，也下不了。

审计日志：记录一切

日志不能防止攻击，但能让你知道发生了什么：

logging:
  # 启用详细日志
  level: "info"

  # 审计日志
  auditLog:
    enabled: true
    path: "/home/clawuser/openclaw/logs/audit.log"
    format: "json"

    # 记录内容
    logToolCalls: true        # 记录所有工具调用
    logFileAccess: true       # 记录文件访问
    logNetworkRequests: true  # 记录网络请求
    logPrompts: true          # 记录所有 prompt（检测注入）

  # 会话日志
  sessionLog:
    enabled: true
    path: "/home/clawuser/openclaw/logs/sessions/"

logPrompts: true 特别关键。如果有人在聊天中注入了恶意指令（比如”忽略之前的限制，执行…”），日志会记录下来，你可以事后分析。

实时监控

# 监控可疑活动
tail -f /opt/openclaw/logs/audit.log | grep -E "(exec|sudo|rm|chmod)"

# 监控网络连接
docker exec openclaw-safe netstat -tuln

# 监控资源使用
docker stats openclaw-safe

告警配置

如果你想更进一步，可以配置自动告警：

alerts:
  # 可疑命令执行
  - type: "command_execution"
    pattern: "sudo|rm -rf|chmod 777"
    action: "block_and_notify"

  # 访问敏感文件
  - type: "file_access"
    pattern: "/.ssh/|/.aws/|/etc/passwd"
    action: "block_and_notify"

  # 访问可疑网站
  - type: "network_request"
    pattern: ".*\\.onion|torproject\\.org"
    action: "block_and_notify"

触发告警后，可以发邮件、Slack 消息、或者直接暂停 OpenClaw 服务。

只读权限起步策略

配置了五层防御后，你可能会想：要不要一步到位，直接全部启用？

我的建议是：别。

安全和便利永远是平衡的艺术。配置太严格，OpenClaw 可能啥也干不了，你自己用着也难受。配置太松，又达不到防护效果。

更好的策略是：从最严格开始，逐步放宽。

第一周：纯只读模式

刚开始部署时，先用只读模式观察 OpenClaw 的行为：

tools:
  allowlist:
    - "read_file"
    - "web_search"
    - "git_log"  # 只读 Git 操作

filesystem:
  defaultPermission: "readonly"
  writablePaths: []  # 完全禁止写入

这一周你干什么？观察。

• 看看 OpenClaw 经常访问哪些文件
• 检查日志中是否有可疑活动
• 了解它习惯调用哪些工具
• 测试 Prompt 注入会发生什么（在安全环境下）

如果这一周风平浪静，说明基础配置没问题。如果发现了异常（比如频繁尝试访问 .ssh 目录），赶紧检查是配置问题还是真有人在搞事。

第二周：添加受限写入

观察期过了，可以逐步放开写权限：

filesystem:
  writablePaths:
    - "/home/clawuser/workspace/temp"  # 只允许写临时文件

tools:
  allowlist:
    - "write_file"  # 限定在 writablePaths 内
    - "git_commit"  # 允许提交代码

注意，这里只开放了临时目录的写权限。重要项目文件依然是只读，OpenClaw 不能直接修改。

这样做的好处：即使 AI 误操作（比如你让它”清理一下项目”，它理解成删除所有文件），也只能删临时文件，源代码安全无虞。

第三周及以后：按需启用工具

根据实际使用需求，逐步启用工具：

tools:
  exec:
    enabled: true
    sandbox: true
    allowCommands:
      - "git"  # 先只允许 git
      - "npm test"  # 需要跑测试时再加

关键原则：

• 每次只放宽一项权限：别一下子开放 exec、browser、write_file，万一出问题你都不知道是哪个环节的锅。
• 每次放宽后观察 24 小时：检查审计日志，看有没有异常行为。
• 有问题立即回滚：发现可疑活动？立刻撤销刚才的配置更改。

实际案例：我的配置演进

分享一下我自己的经历。

刚开始我也想一步到位，参考官方文档配置了”完整安全方案”。结果呢？OpenClaw 连基本的代码补全都做不了，因为我把 write_file 禁用了。

后来我学乖了：

Railway - 现代化的部署平台，告别繁琐运维，让代码分钟级上线

立即开始 →推广

• 第一周：只读模式，让 OpenClaw 帮我查文档、解释代码。没出问题。
• 第二周：开放 workspace/drafts 目录的写权限，让它帮我写草稿。工作顺利。
• 第三周：启用 git 命令，让它帮我提交代码。这里踩了个坑——我忘了配置 Git 的用户信息，OpenClaw 每次提交都报错。修好后一切正常。
• 第四周：启用 npm test，让它跑单元测试。至此基本满足日常需求。

browser 和无限制的 exec？从来没开过，也不需要。

教训：不要为了”安全感”配置你根本用不到的权限。宁可麻烦点，按需开放。

安全检查清单

好了，配置了这么多，怎么确认没有遗漏？这里给你一份清单，部署前过一遍，能避免 90% 的低级错误。

部署前检查（必须全部打勾）

容器安全：

• ☐ 已创建非特权用户（容器内不是 root）
• ☐ Docker 配置了 no-new-privileges:true
• ☐ 移除了所有 Linux capabilities（cap_drop: ALL）
• ☐ 根文件系统设置为只读（read_only: true）
• ☐ 配置了资源限制（CPU、内存）
• ☐ 启用了 OpenClaw 的 sandbox 模式

身份验证：

• ☐ 设置了强 Token 认证（不是 auth: none）
• ☐ Token 足够复杂（≥32 字符，随机生成）
• ☐ Token 保存在环境变量中，不在代码里
• ☐ 配置了访问白名单（DM/Group policy）
• ☐ 如果部署在 VPS，配置了 IP 白名单

权限控制：

• ☐ 工具使用白名单模式
• ☐ 禁用了高危工具（exec/browser，或配置了命令白名单）
• ☐ 配置了文件系统访问限制
• ☐ 敏感目录（.ssh、.aws 等）在禁止列表中
• ☐ 凭证文件权限设置为 600

审计与监控：

• ☐ 启用了审计日志
• ☐ 配置了会话日志
• ☐ 日志目录有足够的磁盘空间
• ☐ 知道如何查看和分析日志

运行时检查（定期执行）

每周检查：

• ☐ 查看审计日志，有无异常活动
• ☐ 检查资源使用情况（CPU、内存、磁盘）
• ☐ 检查是否有未授权访问尝试
• ☐ 备份配置文件

每月检查：

• ☐ 更新 OpenClaw 到最新版本
• ☐ 轮换 Token（如果是长期运行的服务）
• ☐ 检查 Docker 镜像安全漏洞（docker scan）
• ☐ 审查权限配置，移除不再需要的权限

应急响应准备

万一真出事了，你知道怎么办吗？

准备紧急停止脚本：

#!/bin/bash
# emergency-stop.sh

echo "紧急停止 OpenClaw..."

# 停止容器
docker stop openclaw-safe

# 撤销所有 Token（如果用的是动态 Token 系统）
# curl -X DELETE https://your-auth-server/tokens/revoke-all

# 发送告警
curl -X POST https://your-webhook-url \
  -H "Content-Type: application/json" \
  -d '{"text":"OpenClaw 已紧急停止"}'

echo "已停止。请检查日志: /opt/openclaw/logs/audit.log"

Token 泄露应对：

1. 立即撤销泄露的 Token
2. 检查审计日志，看 Token 被用来干了什么
3. 生成新 Token，通知合法用户更新
4. 如果有数据泄露，启动数据泄露应急预案

发现可疑活动：

1. 不要立即关闭服务（会打草惊蛇）
2. 先保存当前日志和容器快照
3. 分析攻击路径和影响范围
4. 再决定是隔离、重启还是重建

结论

写了这么多，核心其实就一句话：OpenClaw 很强大，但只有在安全的笼子里，这头”猛兽”才能真正为你所用。

回顾一下五层防御：

1. Docker 沙盒隔离：把 OpenClaw 关在容器里，限制它能碰到的文件和网络
2. 非特权用户：即使被攻击，攻击者也只有低权限，无法搞破坏
3. 访问控制：Token 认证 + 白名单，把不该进来的人挡在门外
4. 工具权限控制：禁用危险工具，只给必要的权限
5. 网络隔离与监控：切断不必要的连接，记录所有操作

这五层，前三层是必须级——不管你怎么用 OpenClaw，这三层防御都应该到位。后两层是推荐级——如果处理敏感数据或企业部署，强烈建议配置。

说实话，配置这些确实有点麻烦。你可能会想：我就自己玩玩，真的需要这么谨慎吗？

我的回答是：需要。

不是因为 OpenClaw 不安全（它本身没问题），而是因为 AI 的能力太强了。你让它”帮我整理项目文件”，它可能理解成”删除所有临时文件”——包括你忘了备份的重要草稿。你让它”查一下最近的提交记录”，它可能顺手读取了 .git/config 里的凭证信息。

这些不是恶意，只是”过度热情”。但后果可能一样严重。

安全配置不是为了防止 OpenClaw 作恶，而是为了限制意外的爆炸半径。即使出了问题，损失也可控。

最后给你三条行动建议：

1. 现在就检查你的 OpenClaw 配置：如果你正在用默认配置，请立即停下来，至少实施前三层防御。
2. 从严格开始，逐步放宽：别怕麻烦，用只读模式观察一周，确认安全后再开放权限。
3. 定期查看审计日志：每周花 5 分钟翻翻日志，看有没有异常。早发现早处理。

OpenClaw 是个好工具，真的。但就像核能一样——用好了造福人类，用不好就是灾难。

配置看起来很麻烦，但比起数据泄露、删库跑路、或者在 Reddit 上发帖求助，这点麻烦不算什么。

对吧？

18 分钟阅读 · 发布于: 2026年2月4日 · 修改于: 2026年2月5日

Easton

AI与智能