安全指南

WARNING

个人助理信任模型： 本指南基于每个 Gateway 一个受信 operator 的边界（单用户/个人助理模型）。 OpenClaw 不是多个对抗性用户共享一个 Agent/Gateway 的敌对多租户安全边界。若需要混合信任或对抗性用户隔离，请分割信任边界（独立 Gateway + 凭据，最好使用独立 OS 用户/主机）。

首先明确范围：个人助理安全模型

OpenClaw 的安全指南假设个人助理部署场景：一个受信 operator 边界，可有多个 Agent。

支持的安全态势：每个 Gateway 一个用户/信任边界（推荐每个边界使用独立 OS 用户/主机/VPS）。
不支持的安全边界：一个共享 Gateway/Agent 被相互不信任或对抗性用户共同使用。
若需要对抗性用户隔离，按信任边界分割（独立 Gateway + 凭据，最好使用独立 OS 用户/主机）。
若多个不受信用户可以向一个启用工具的 Agent 发送消息，视他们为共享该 Agent 的同等委托工具权限。

本页说明该模型内的加固措施。不声明在一个共享 Gateway 上的敌对多租户隔离能力。

快速检查：`openclaw security audit`

另见：Formal Verification (Security Models)

定期运行（尤其是更改配置或暴露网络面之后）：

bash

openclaw security audit
openclaw security audit --deep
openclaw security audit --fix
openclaw security audit --json

它会标记常见问题（Gateway auth 暴露、浏览器控制暴露、elevated 白名单、文件系统权限、宽松 exec 审批以及开放频道工具暴露）。

OpenClaw 既是产品也是实验：你将前沿模型行为接入了真实消息面和真实工具。没有"完全安全"的配置。 目标是对以下内容保持清醒认知：

谁可以和你的 bot 对话
bot 被允许在哪里行动
bot 能接触什么

从最小的可行访问权限开始，随着信心增长再逐步扩展。

部署假设（重要）

OpenClaw 假设宿主机和配置边界是受信的：

若有人能修改 Gateway 宿主机状态/配置（~/.openclaw，包括 openclaw.json），视他们为受信 operator。
不推荐为多个相互不信任/对抗性 operator 运行一个 Gateway。
对于混合信任团队，请使用独立 Gateway 分割信任边界（至少使用独立 OS 用户/主机）。
OpenClaw 可在一台机器上运行多个 Gateway 实例，但推荐方案倾向于干净的信任边界分离。
推荐默认：每台机器/主机（或 VPS）一个用户，该用户一个 Gateway，该 Gateway 下一个或多个 Agent。
若多个用户需要 OpenClaw，每个用户使用独立 VPS/主机。

实际后果（operator 信任边界）

在一个 Gateway 实例内部，经过认证的 operator 访问是受信的控制面角色，而不是按用户的租户角色。

具有读/控制面访问权限的 operator 可以按设计检查 Gateway 会话元数据/历史。
会话标识符（sessionKey、session ID、标签）是路由选择器，不是授权 token。
示例：期望 sessions.list、sessions.preview 或 chat.history 等方法在共享 Gateway 上提供按 operator 的隔离，超出了本模型的支持范围。
若需要对抗性用户隔离，按信任边界运行独立 Gateway。
一台机器上运行多个 Gateway 在技术上可行，但不是多用户隔离的推荐基线。

个人助理模型（不是多租户总线）

OpenClaw 设计为个人助理安全模型：一个受信 operator 边界，可有多个 Agent。

若多人可以向一个启用工具的 Agent 发送消息，每个人都可以驱动相同的权限集。
按用户的会话/内存隔离有助于隐私保护，但不会将共享 Agent 转变为按用户的宿主机授权。
若用户之间可能存在对抗性，请按信任边界运行独立 Gateway（或独立 OS 用户/主机）。

共享 Slack 工作区：真实风险

若"工作区中的每个人都可以向 bot 发消息"，核心风险是委托工具权限：

任何允许的发送方都可以在 Agent 策略范围内触发工具调用（exec、浏览器、网络/文件工具）；
一个发送方的提示/内容注入可能导致影响共享状态、设备或输出的行动；
若一个共享 Agent 持有敏感凭据/文件，任何允许的发送方都可能通过工具使用驱动数据泄露。

对于团队工作流，使用具有最小工具集的独立 Agent/Gateway；将含个人数据的 Agent 设为私有。

公司共享 Agent：可接受的模式

当使用该 Agent 的所有人都在同一信任边界内（例如同一公司团队）且 Agent 严格限定于业务范围时，这种模式是可接受的。

在专用机器/VM/容器上运行；
为该运行时使用专用 OS 用户 + 专用浏览器/profile/账户；
不要将该运行时登录到个人 Apple/Google 账户或个人密码管理器/浏览器 profile。

若将个人和公司身份混合在同一运行时上，你就消除了隔离，增加了个人数据暴露风险。

Gateway 与 Node 的信任概念

将 Gateway 和 node 视为一个 operator 信任域，角色不同：

Gateway 是控制面和策略面（gateway.auth、工具策略、路由）。
Node 是与该 Gateway 配对的远端执行面（命令、设备动作、宿主机本地能力）。
对 Gateway 完成认证的调用方在 Gateway 作用域内是受信的。配对后，node 行动是该 node 上受信的 operator 行动。
sessionKey 是路由/上下文选择器，不是按用户的 auth。
Exec 审批（白名单 + 询问）是 operator 意图的护栏，不是敌对多租户隔离。
Exec 审批绑定精确的请求上下文和尽力而为的直接本地文件操作数；它们不会对每个运行时/解释器加载路径进行语义建模。使用沙盒和宿主机隔离实现强边界。

若需要敌对用户隔离，按 OS 用户/主机分割信任边界并运行独立 Gateway。

信任边界矩阵

分析风险时的快速参考模型：

边界或控制	含义	常见误读
`gateway.auth`（token/password/device auth）	对调用方到 Gateway API 的认证	"每帧都需要按消息签名才安全"
`sessionKey`	上下文/会话选择的路由 key	"Session key 是用户 auth 边界"
提示/内容护栏	降低模型滥用风险	"仅提示注入就能证明 auth 绕过"
`canvas.eval` / 浏览器 evaluate	启用时的有意 operator 能力	"任何 JS eval 原语在此信任模型下自动构成漏洞"
本地 TUI `!` shell	显式 operator 触发的本地执行	"本地 shell 便利命令是远端注入"
Node 配对和 node 命令	在已配对设备上的 operator 级别远端执行	"远端设备控制默认应视为不受信用户访问"

设计上不是漏洞

以下模式常被报告，通常在没有显示真实边界绕过的情况下被关闭：

仅提示注入链，无策略/auth/沙盒绕过。
假设在一个共享宿主机/配置上进行敌对多租户操作的声明。
将正常 operator 读路径访问（例如 sessions.list/sessions.preview/chat.history）在共享 Gateway 配置中归类为 IDOR 的声明。
仅限 localhost 部署的发现（例如仅限 loopback Gateway 上的 HSTS）。
Discord 入站 webhook 签名发现，针对此仓库中不存在的入站路径。
将 sessionKey 视为 auth token 的"缺少按用户授权"发现。

研究人员预检清单

提交 GHSA 前，请核实以下所有内容：

复现仍在最新 main 或最新版本上有效。
报告包含精确代码路径（文件、函数、行号范围）和已测试版本/commit。
影响跨越了已记录的信任边界（不仅是提示注入）。
声明未列在 Out of Scope 中。
已检查现有 advisory，避免重复（适用时复用权威 GHSA）。
部署假设明确（loopback/本地 vs 暴露，受信 vs 不受信 operator）。

60 秒加固基线

首先使用此基线，然后按受信 Agent 选择性地重新启用工具：

json5

{
  gateway: {
    mode: "local",
    bind: "loopback",
    auth: { mode: "token", token: "replace-with-long-random-token" },
  },
  session: {
    dmScope: "per-channel-peer",
  },
  tools: {
    profile: "messaging",
    deny: ["group:automation", "group:runtime", "group:fs", "sessions_spawn", "sessions_send"],
    fs: { workspaceOnly: true },
    exec: { security: "deny", ask: "always" },
    elevated: { enabled: false },
  },
  channels: {
    whatsapp: { dmPolicy: "pairing", groups: { "*": { requireMention: true } } },
  },
}

这将 Gateway 保持在本地，隔离 DM，并默认禁用控制面/运行时工具。

共享收件箱快速规则

若不止一个人可以向你的 bot 发送 DM：

设置 session.dmScope: "per-channel-peer"（或多账户频道使用 "per-account-channel-peer"）。
保持 dmPolicy: "pairing" 或严格白名单。
不要将共享 DM 与广泛的工具访问权限组合。
这加固了协作/共享收件箱，但在用户共享宿主机/配置写入权限时，不是针对敌对共租户的隔离设计。

audit 检查内容（高层概述）

入站访问（DM 策略、群组策略、白名单）：陌生人能触发 bot 吗？
工具爆炸半径（elevated 工具 + 开放房间）：提示注入能变成 shell/文件/网络操作吗？
Exec 审批漂移（security=full、autoAllowSkills、无 strictInlineEval 的解释器白名单）：宿主机 exec 护栏还在按预期工作吗？
网络暴露（Gateway bind/auth、Tailscale Serve/Funnel、弱/短 auth token）。
浏览器控制暴露（远端 node、中继端口、远端 CDP 端点）。
本地磁盘卫生（权限、软链接、配置 include、"同步文件夹"路径）。
插件（存在未显式白名单的扩展）。
策略漂移/配置错误（沙盒 Docker 配置已设置但沙盒模式关闭；无效的 gateway.nodes.denyCommands 模式（匹配仅限精确命令名，如 system.run，不检查 shell 文本）；危险的 gateway.nodes.allowCommands 条目；被按 Agent profile 覆盖的全局 tools.profile="minimal"；在宽松工具策略下可访问的扩展插件工具）。
运行时预期漂移（例如 tools.exec.host="sandbox" 而沙盒模式关闭，此时直接在 Gateway 宿主机上运行）。
模型卫生（配置的模型看起来是旧版时发出警告；不是硬性阻断）。

运行 --deep 时，OpenClaw 还会尝试尽力而为的实时 Gateway 探测。

凭据存储位置

审计访问权限或决定备份内容时使用：

WhatsApp：~/.openclaw/credentials/whatsapp/<accountId>/creds.json
Telegram bot token：配置/env 或 channels.telegram.tokenFile（仅限普通文件；拒绝软链接）
Discord bot token：配置/env 或 SecretRef（env/file/exec provider）
Slack tokens：配置/env（channels.slack.*）
配对白名单：
- ~/.openclaw/credentials/<channel>-allowFrom.json（默认账户）
- ~/.openclaw/credentials/<channel>-<accountId>-allowFrom.json（非默认账户）
模型 auth profiles：~/.openclaw/agents/<agentId>/agent/auth-profiles.json
文件支持的密钥载荷（可选）：~/.openclaw/secrets.json
旧版 OAuth 导入：~/.openclaw/credentials/oauth.json

安全审计优先级排序

audit 输出发现时，按此优先级处理：

任何"开放" + 工具启用：首先锁定 DM/群组（配对/白名单），然后收紧工具策略/沙盒。
公网暴露（LAN bind、Funnel、缺少 auth）：立即修复。
浏览器控制远端暴露：视同 operator 访问（仅限 tailnet，主动配对 node，避免公网暴露）。
权限：确保状态/配置/凭据/auth 不是 group/world 可读的。
插件/扩展：只加载你明确信任的。
模型选择：对任何有工具的 bot，优先使用最强的最新一代、防注入增强模型。

安全审计术语表

你在真实部署中最可能看到的高信号 checkId 值（非完整列表）：

`checkId`	严重级别	为何重要	主要修复键/路径	自动修复
`fs.state_dir.perms_world_writable`	critical	其他用户/进程可修改完整 OpenClaw 状态	`~/.openclaw` 的文件系统权限	是
`fs.config.perms_writable`	critical	其他人可更改 auth/工具策略/配置	`~/.openclaw/openclaw.json` 的文件系统权限	是
`fs.config.perms_world_readable`	critical	配置可能暴露 token/设置	配置文件的文件系统权限	是
`gateway.bind_no_auth`	critical	远端 bind 无共享密钥	`gateway.bind`、`gateway.auth.*`	否
`gateway.loopback_no_auth`	critical	反向代理的 loopback 可能变为未认证	`gateway.auth.*`、代理配置	否
`gateway.http.no_auth`	warn/critical	Gateway HTTP API 在 `auth.mode="none"` 下可达	`gateway.auth.mode`、`gateway.http.endpoints.*`	否
`gateway.tailscale_funnel`	critical	公网暴露	`gateway.tailscale.mode`	否
`gateway.control_ui.allowed_origins_required`	critical	非 loopback 控制 UI 没有显式浏览器来源白名单	`gateway.controlUi.allowedOrigins`	否
`gateway.control_ui.device_auth_disabled`	critical	禁用设备身份检查	`gateway.controlUi.dangerouslyDisableDeviceAuth`	否
`tools.exec.security_full_configured`	warn/critical	宿主机 exec 以 `security="full"` 运行	`tools.exec.security`、`agents.list[].tools.exec.security`	否
`security.exposure.open_channels_with_exec`	warn/critical	共享/公开房间可以访问启用了 exec 的 Agent	`channels..dmPolicy`、`channels..groupPolicy`、`tools.exec.*`	否
`security.exposure.open_groups_with_elevated`	critical	开放群组 + elevated 工具形成高影响提示注入路径	`channels..groupPolicy`、`tools.elevated.`	否
`security.trust_model.multi_user_heuristic`	warn	配置看起来是多用户，而 Gateway 信任模型是个人助理	分割信任边界，或共享用户加固	否

HTTP 上的控制 UI

控制 UI 需要安全上下文（HTTPS 或 localhost）来生成设备身份。gateway.controlUi.allowInsecureAuth 是本地兼容性开关：

在 localhost 上，当页面通过非安全 HTTP 加载时，允许控制 UI 在无设备身份的情况下完成 auth。
不绕过配对检查。
不放宽远端（非 localhost）设备身份要求。

推荐 HTTPS（Tailscale Serve）或在 127.0.0.1 上打开 UI。

仅在紧急情况下，gateway.controlUi.dangerouslyDisableDeviceAuth 完全禁用设备身份检查。这是严重的安全降级；除非正在主动调试且能快速恢复，否则保持关闭。

openclaw security audit 在此设置启用时发出警告。

反向代理配置

若在反向代理（nginx、Caddy、Traefik 等）后面运行 Gateway，应配置 gateway.trustedProxies 以正确检测客户端 IP。

当 Gateway 检测到来自不在 trustedProxies 中的地址的代理 header 时，它不会将连接视为本地客户端。若 Gateway auth 已禁用，这些连接会被拒绝。这防止了代理连接看起来来自 localhost 并获得自动信任的认证绕过。

yaml

gateway:
  trustedProxies:
    - "127.0.0.1" # 若代理在 localhost 上运行
  # 可选，默认 false
  # 仅当代理无法提供 X-Forwarded-For 时启用
  allowRealIpFallback: false
  auth:
    mode: password
    password: ${OPENCLAW_GATEWAY_PASSWORD}

配置 trustedProxies 后，Gateway 使用 X-Forwarded-For 确定客户端 IP。除非显式设置 gateway.allowRealIpFallback: true，否则默认忽略 X-Real-IP。

推荐的反向代理行为（覆盖传入的转发 header）：

nginx

proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Real-IP $remote_addr;

不推荐的反向代理行为（追加/保留不受信的转发 header）：

nginx

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

HSTS 与来源说明

OpenClaw Gateway 以本地/loopback 为主。若在反向代理处终止 TLS，在代理侧的 HTTPS 域名上设置 HSTS。
若 Gateway 本身终止 HTTPS，可设置 gateway.http.securityHeaders.strictTransportSecurity 让 OpenClaw 响应中输出 HSTS header。
详细部署指南见 Trusted Proxy Auth。
对于非 loopback 控制 UI 部署，默认需要 gateway.controlUi.allowedOrigins。
gateway.controlUi.allowedOrigins: ["*"] 是显式的允许所有浏览器来源策略，不是加固默认值。在严格控制的本地测试之外避免使用。

本地会话日志存储在磁盘上

OpenClaw 在磁盘上的 ~/.openclaw/agents/<agentId>/sessions/*.jsonl 下存储会话记录。这是会话连续性和（可选）会话内存索引的必要条件，但同时也意味着任何有文件系统访问权限的进程/用户都可以读取这些日志。将磁盘访问视为信任边界，锁定 ~/.openclaw 的权限（见上方审计部分）。若需要 Agent 之间更强的隔离，在独立 OS 用户或独立主机下运行它们。

Node 执行（system.run）

若已配对 macOS node，Gateway 可以在该 node 上调用 system.run。这是在 Mac 上的远端代码执行：

需要 node 配对（审批 + token）。
在 Mac 上通过设置 → Exec approvals控制（安全级别 + 询问 + 白名单）。
审批模式绑定精确的请求上下文，以及在可能的情况下一个具体的本地脚本/文件操作数。若 OpenClaw 无法为解释器/运行时命令确定唯一一个直接本地文件，则拒绝基于审批的执行，而不是承诺完整的语义覆盖。
若不需要远端执行，将安全级别设为 deny 并移除该 Mac 的 node 配对。

动态技能（watcher / 远端 node）

OpenClaw 可在会话中途刷新技能列表：

技能 watcher：SKILL.md 的变更可在下次 Agent 轮次更新技能快照。
远端 node：连接 macOS node 可使 macOS 专属技能变为可用（基于二进制探测）。

将技能文件夹视为受信代码，限制可修改它们的人员。

威胁模型

你的 AI 助理可以：

执行任意 shell 命令
读/写文件
访问网络服务
向任何人发送消息（若你给了它 WhatsApp 访问权限）

向你发送消息的人可以：

试图欺骗 AI 做坏事
社会工程访问你的数据
探测基础设施详情

核心概念：访问控制先于智能

大多数失败不是花哨的漏洞利用——而是"有人向 bot 发了消息，bot 照做了"。

OpenClaw 的立场：

身份优先：决定谁可以和 bot 对话（DM 配对/白名单/显式"开放"）。
作用域其次：决定 bot 被允许在哪里行动（群组白名单 + 提及门控、工具、沙盒、设备权限）。
模型最后：假设模型可能被操控；设计时确保操控的影响范围有限。

命令授权模型

Slash 命令和指令仅对已授权的发送方生效。授权来自频道白名单/配对加上 commands.useAccessGroups（参见 Configuration 和 Slash commands）。若频道白名单为空或包含 "*"，命令对该频道实际上是开放的。

/exec 是已授权 operator 的会话级便利功能，不写入配置也不改变其他会话。

控制面工具风险

两个内置工具可以进行持久的控制面变更：

gateway 可调用 config.apply、config.patch 和 update.run。
cron 可创建在原始聊天/任务结束后仍继续运行的定时任务。

对于任何处理不受信内容的 Agent/面，默认拒绝这些工具：

json5

{
  tools: {
    deny: ["gateway", "cron", "sessions_spawn", "sessions_send"],
  },
}

commands.restart=false 仅阻止重启操作，不禁用 gateway 的配置/更新操作。

插件/扩展

插件在进程内与 Gateway 一起运行，视为受信代码：

只安装你信任来源的插件。
优先使用显式的 plugins.allow 白名单。
启用前审查插件配置。
插件变更后重启 Gateway。
若使用 openclaw plugins install <package> 安装插件，视同运行不受信代码：
- 安装路径为 ~/.openclaw/extensions/<pluginId>/（或 $OPENCLAW_STATE_DIR/extensions/<pluginId>/）。
- OpenClaw 使用 npm pack 然后在该目录运行 npm install --omit=dev（npm 生命周期脚本在安装期间可能执行代码）。
- 优先使用固定的精确版本（@scope/pkg@1.2.3），并在启用前检查磁盘上解包的代码。

详情：Plugins

DM 访问模型（配对/白名单/开放/禁用）

所有支持 DM 的频道都支持 DM 策略（dmPolicy 或 *.dm.policy），在处理消息之前对入站 DM 进行门控：

pairing（默认）：未知发送方收到简短配对码，bot 忽略其消息直到审批。码在 1 小时后过期；在创建新请求之前，重复 DM 不会重新发送码。待处理请求默认上限为每频道 3 个。
allowlist：未知发送方被阻断（无配对握手）。
open：允许任何人 DM（公开）。需要频道白名单包含 "*"（显式选择加入）。
disabled：完全忽略入站 DM。

通过 CLI 审批：

bash

openclaw pairing list <channel>
openclaw pairing approve <channel> <code>

详情与磁盘文件：Pairing

DM 会话隔离（多用户模式）

默认情况下，OpenClaw 将所有 DM 路由到主会话，以便你的助理在设备和频道间保持连续性。若多人可以向 bot 发送 DM（开放 DM 或多人白名单），考虑隔离 DM 会话：

json5

{
  session: { dmScope: "per-channel-peer" },
}

这防止跨用户上下文泄漏，同时保持群组聊天隔离。

这是消息上下文边界，不是宿主机管理员边界。若用户相互对立并共享同一 Gateway 宿主机/配置，请改为按信任边界运行独立 Gateway。

提示注入

提示注入是攻击者构造消息操控模型执行不安全操作（"忽略你的指令"、"转储你的文件系统"、"访问此链接并运行命令"等）的攻击方式。

即使有强系统提示，提示注入问题尚未解决。系统提示护栏只是软性引导；硬性执行来自工具策略、exec 审批、沙盒和频道白名单（operator 可以按设计禁用这些）。实践中有帮助的措施：

锁定入站 DM（配对/白名单）。
群组中优先使用提及门控；避免在公开房间使用"始终在线"bot。
默认将链接、附件和粘贴的指令视为恶意。
在沙盒中运行敏感工具执行；将密钥放在 Agent 可访问的文件系统之外。
将高风险工具（exec、browser、web_fetch、web_search）限制为受信 Agent 或显式白名单。
模型选择很重要： 旧/小/遗留模型对提示注入和工具滥用的抵抗力显著更弱。对于启用工具的 Agent，使用最强的最新一代防注入增强模型。

模型强度（安全说明）

提示注入抵抗力在模型层级间不均匀。较小/较便宜的模型通常更容易受到工具滥用和指令劫持的影响，尤其是在对抗性提示下。

建议：

对任何可运行工具或接触文件/网络的 bot，使用最新一代最佳层级模型。
不要在启用工具的 Agent 或不受信收件箱上使用旧/弱/小层级模型； 提示注入风险过高。
若必须使用较小模型，降低爆炸半径（只读工具、强沙盒、最小文件系统访问、严格白名单）。

配置加固示例

1）DM：默认配对

json5

{
  channels: { whatsapp: { dmPolicy: "pairing" } },
}

2）群组：处处要求提及

json

{
  "channels": {
    "whatsapp": {
      "groups": {
        "*": { "requireMention": true }
      }
    }
  },
  "agents": {
    "list": [
      {
        "id": "main",
        "groupChat": { "mentionPatterns": ["@openclaw", "@mybot"] }
      }
    ]
  }
}

3）安全基线（复制即用）

json5

{
  gateway: {
    mode: "local",
    bind: "loopback",
    port: 18789,
    auth: { mode: "token", token: "your-long-random-token" },
  },
  channels: {
    whatsapp: {
      dmPolicy: "pairing",
      groups: { "*": { requireMention: true } },
    },
  },
}

沙盒（推荐）

专题文档：Sandboxing

两种互补方案：

在 Docker 中运行完整 Gateway（容器边界）：Docker
工具沙盒（宿主机 Gateway + Docker 隔离工具）：Sandboxing

浏览器控制风险

启用浏览器控制后，模型可以驱动真实浏览器。若该浏览器 profile 已包含登录会话，模型可以访问这些账户和数据。将浏览器 profile 视为敏感状态：

优先为 Agent 使用专用 profile（默认的 openclaw profile）。
避免将 Agent 指向你的个人日常使用 profile。
对于远端 Gateway，视"浏览器控制"等同于对该 profile 可访问内容的"operator 访问"。
不需要时禁用浏览器代理路由（gateway.nodes.browser.mode="off"）。

事件响应

若你的 AI 做了坏事：

控制

停止它： 停止 macOS 应用（若它在监管 Gateway）或终止 openclaw gateway 进程。
关闭暴露： 在了解发生了什么之前设置 gateway.bind: "loopback"（或禁用 Tailscale Funnel/Serve）。
冻结访问： 将风险 DM/群组切换为 dmPolicy: "disabled" / 要求提及，并移除 "*" 允许所有条目。

轮换（若密钥泄漏，假设已被入侵）

轮换 Gateway auth（gateway.auth.token / OPENCLAW_GATEWAY_PASSWORD）并重启。
轮换任何可调用 Gateway 的机器上的远端客户端密钥（gateway.remote.token / .password）。
轮换 provider/API 凭据（WhatsApp 凭据、Slack/Discord token、auth-profiles.json 中的模型/API key，以及使用时的加密密钥载荷值）。

审计

检查 Gateway 日志：/tmp/openclaw/openclaw-YYYY-MM-DD.log（或 logging.file）。
审查相关记录：~/.openclaw/agents/<agentId>/sessions/*.jsonl。
审查近期配置变更（任何可能扩大访问权限的内容：gateway.bind、gateway.auth、dm/群组策略、tools.elevated、插件变更）。
重新运行 openclaw security audit --deep，确认 critical 发现已解决。

报告安全问题

在 OpenClaw 中发现漏洞？请负责任地报告：

邮件：security@openclaw.ai
公开披露前等待修复
我们将致谢（除非你希望匿名）

安全指南 ​

首先明确范围：个人助理安全模型 ​

快速检查：openclaw security audit ​

部署假设（重要） ​

实际后果（operator 信任边界） ​

个人助理模型（不是多租户总线） ​

共享 Slack 工作区：真实风险 ​

公司共享 Agent：可接受的模式 ​

Gateway 与 Node 的信任概念 ​

信任边界矩阵 ​

设计上不是漏洞 ​

研究人员预检清单 ​

60 秒加固基线 ​

共享收件箱快速规则 ​

audit 检查内容（高层概述） ​

凭据存储位置 ​

安全审计优先级排序 ​

安全审计术语表 ​

HTTP 上的控制 UI ​

反向代理配置 ​

HSTS 与来源说明 ​

本地会话日志存储在磁盘上 ​

Node 执行（system.run） ​

动态技能（watcher / 远端 node） ​

威胁模型 ​

核心概念：访问控制先于智能 ​

命令授权模型 ​

控制面工具风险 ​

插件/扩展 ​

DM 访问模型（配对/白名单/开放/禁用） ​

DM 会话隔离（多用户模式） ​

提示注入 ​

模型强度（安全说明） ​

配置加固示例 ​

1）DM：默认配对 ​

2）群组：处处要求提及 ​

3）安全基线（复制即用） ​

沙盒（推荐） ​

浏览器控制风险 ​

事件响应 ​

控制 ​

轮换（若密钥泄漏，假设已被入侵） ​

审计 ​

报告安全问题 ​

安全指南

首先明确范围：个人助理安全模型

快速检查：`openclaw security audit`

部署假设（重要）

实际后果（operator 信任边界）

个人助理模型（不是多租户总线）

共享 Slack 工作区：真实风险

公司共享 Agent：可接受的模式

Gateway 与 Node 的信任概念

信任边界矩阵

设计上不是漏洞

研究人员预检清单

60 秒加固基线

共享收件箱快速规则

audit 检查内容（高层概述）

凭据存储位置

安全审计优先级排序

安全审计术语表

HTTP 上的控制 UI

反向代理配置

HSTS 与来源说明

本地会话日志存储在磁盘上

Node 执行（system.run）

动态技能（watcher / 远端 node）

威胁模型

核心概念：访问控制先于智能

命令授权模型

控制面工具风险

插件/扩展

DM 访问模型（配对/白名单/开放/禁用）

DM 会话隔离（多用户模式）

提示注入

模型强度（安全说明）

配置加固示例

1）DM：默认配对

2）群组：处处要求提及

3）安全基线（复制即用）

沙盒（推荐）

浏览器控制风险

事件响应

控制

轮换（若密钥泄漏，假设已被入侵）

审计

报告安全问题