简介2026年3月360人工智能安全团队发布《OpenClaw安全部署与实践指南360护航版》面向OpenClaw个人开发者、一人公司、中小企业数字化团队及安全运维人员针对CNCERT警示的插件投毒、ClawJacked高危漏洞、提示词注入等风险提供一套系统化安全部署方案。内含1个PDF文件大小6.1MB目前已有268人学习。指南从OpenClaw网关、智能体、工具、节点架构切入梳理公网暴露、凭证泄露、工具调用越权、记忆投毒等七大安全风险并给出最小权限、运行隔离、全程可审计、持续更新补丁四项安全铁律。同时细化身份认证、访问控制、网络隔离、API Key与SSH密钥管理以及防提示词注入和零信任模型等可落地步骤帮助读者在不牺牲AI便利性的前提下有效防御数字分身失控与数据泄露。1. OpenClaw 安全部署先说结论再讲怎么做部署 OpenClaw 这类 AI 代理框架最危险的地方从来不在模型推理而在它拿到的那组工具权限。框架默认的配置是面向开发调试的日志全开、工具全量注册、凭据明文可读、网络出口不设限。这些特性在本地是效率上了生产就是漏洞。这也是为什么像“护航版”这种安全团队出的实践指南值得单独读它不是在讲怎么把框架跑起来而是在讲跑起来之后怎么把边界收住。这篇文章面向中后台工程师、SRE 和独立开发者目标是让读者在动手前先想清楚三件事攻击面在哪里、哪些配置必须改、运行起来之后靠什么判断它已经越界。读完你会有能力回答OpenClaw 在什么条件下可以放心上规模以及最小安全部署长什么样。2. 部署前边界梳理攻击面在工具调用层默认配置不能直接上生产2.1 为什么攻击面在工具调用层而不是模型层OpenClaw 这类框架的典型形态是一个调度核心加一组可插拔工具模型负责理解任务、拆解步骤工具负责真正执行动作。攻击者要打穿你的系统通常不需要让模型说出什么违规内容只需要诱导它发起一次工具调用。整个过程看起来就像一条正常指令“请调用某某接口把参数改成这样”。模型遵循了指令工具也执行了真正的伤害发生在工具层。所以安全审查的焦点要从“模型说了什么”转移到“工具被诱导执行了什么”。部署前要梳理出三类风险入口第一是注入面外部输入或检索片段可能把不存在的工具调用指令拼进上下文第二是凭据面工具链路中保存的 token 或口令可能被一次异常调用读出第三是副作用面文件写入、状态变更、外部通知这类动作一旦执行就难以回滚。常见做法是先画一张工具调用链路图哪些工具会被哪些任务触发每个工具能触达哪些资源。画完通常会发现默认配置里所有工具都注册给了 Agent等于把整个内网的钥匙都放在门口。边界梳理的第一步不是加防火墙而是给工具的“可见性”做减法。2.2 给运行账号做减法专用账号与最小目录权限我一般会为 OpenClaw 单独建一个专用运行账号不用 root不分配 sudo不设置登录 shell。这样即使框架进程被注入攻击拿下攻击者也只能在这个账号的权限范围内活动。# 创建系统级用户禁止登录不创建 home 目录 useradd --system --no-create-home --shell /usr/sbin/nologin openclaw # 规划三个独立目录配置、日志、运行时数据 mkdir -p /etc/openclaw /var/log/openclaw /var/lib/openclaw # 设置所有者和基础权限 chown -R openclaw:openclaw /etc/openclaw /var/log/openclaw /var/lib/openclaw chmod 750 /etc/openclaw /var/lib/openclaw chmod 750 /var/log/openclaw逻辑说明--system表示创建系统账号不占用常规 uid 范围--shell /usr/sbin/nologin是为了禁止任何形式的交互登录。/etc/openclaw放主配置和密钥文件/var/log/openclaw放运行日志/var/lib/openclaw放会话状态和临时数据三者分开便于后续做备份和权限收敛。参数说明目录权限统一用 750表示 owner 和 group 可读可进入其他用户完全不可见。如果后续有运维脚本需要读配置建议把脚本运行账号加入 openclaw 组而不是把配置文件改成 644。对于包含密钥的文件最后再收紧一轮chmod 640 /etc/openclaw/*.conf chmod 600 /etc/openclaw/vault/*.gpg这里有个容易被忽略的点开发环境里很多人习惯用chmod 777解决权限问题但在生产环境中这等于把密钥目录改成公共走廊。任何时候都不要让配置文件对 other 用户开放读权限。2.3 容器化沙箱只读根文件系统与内核约束容器不是安全边界但它是结构化边界。把 OpenClaw 放进容器至少能让“进程能看到的文件”“进程能访问的网络”“进程拥有的内核能力”这三件事变得可描述。# 建立配置和数据目录只读挂载点与日志挂载点分开 mkdir -p /data/openclaw/config /data/openclaw/logs docker run -d \ --name openclaw-node \ --user openclaw \ --read-only \ --tmpfs /tmp:rw,noexec,nosuid,size256m \ --security-opt no-new-privileges \ --cap-drop ALL \ --pids-limit 512 \ --memory 2g --cpus 2 \ -v /data/openclaw/config:/etc/openclaw:ro \ -v /data/openclaw/logs:/var/log/openclaw \ -e OPENCLAW_MODEproduction \ registry.internal.example.cn/openclaw:2026h1逻辑说明--read-only让根文件系统进入只读状态任何试图往容器层写文件的工具调用都会被拒绝。--tmpfs /tmp为框架的临时文件需求开了一个内存盘挂载参数里的noexec禁止从临时目录执行任何二进制nosuid禁止提权。--cap-drop ALL去掉所有内核能力容器内无法执行 mount、ptrace、raw socket 这类高危操作。参数说明--pids-limit 512限制进程数量防止工具循环调用时无限 fork--memory 2g --cpus 2是给任务执行设定的资源上限具体数值按你的任务负载调整。/etc/openclaw以ro方式只读挂载框架只能读配置不能改配置日志目录则保持可写。注意如果你需要监听 80 或 443 端口才考虑补--cap-add NET_BIND_SERVICE否则保持全部丢弃即可。还要补充一个经验容器逃逸风险真实存在--read-only、--cap-drop ALL这些参数只是扩大了攻击成本不能当唯一防线。生产环境建议叠加宿主机层面的账号隔离和网络隔离多层约束互相兜底。2.4 资源限制不是性能调优是安全护栏OpenClaw 的调度核心在任务突发时可能会瞬间拉起大量并发工具调用。如果不对资源做上限约束一次异常的循环调用就可能耗尽宿主机 CPU 或内存导致同机其他业务一起受影响。这已经不是性能问题是可用性安全问题。资源项建议起始值说明CPU2 核适合中小任务量复杂任务再上调内存2G含框架运行时与工具执行开销进程数512防止 fork 炸弹式调用并发任务队列32限制同时执行的工具调用数单次工具超时15 秒避免外部服务无响应时拖死链路我见过不少团队把资源参数调得很大理由是“任务多怕不够用”。真实情况是任务量级是可以通过限流和队列缓冲的而资源失控才是最难恢复的。先从紧的配置开始观察业务指标再逐步放宽比一开始就放开手脚安全得多。3. 凭据与工具面密钥分层、最小授权和轮换别把入口全挂一把钥匙上3.1 把外部凭据和内部凭据分开管理OpenClaw 运行时会用到两类凭据。外部凭据是模型服务商、第三方工具服务的 token泄露的影响范围限定在对应服务商账号内。内部凭据是你们自己数据库、内部系统、对象存储的口令一旦泄露攻击者拿到的是整套内部基础设施的入场券。两类凭据混在同一个环境变量文件里是生产环境最常见的安全隐患。我建议至少分成两个文件openclaw.env放非敏感的调度参数vault/目录放加密后的敏感凭据。启动时由编排脚本把 vault 里的内容解密后注入进程环境变量密钥不落地明文。如果团队已经有密钥管理服务优先接入如果还没有先用操作系统级的加密工具顶住也好过裸奔。# 加密保存内部 API 凭据示例用 GPG 对称加密 mkdir -p /etc/openclaw/vault chmod 700 /etc/openclaw/vault # 加密前先准备好明文文件加密完成后立即删除明文 gpg --symmetric --cipher-algo AES256 \ --output /etc/openclaw/vault/internal-api.gpg internal-api.txt rm -f internal-api.txt chown openclaw:openclaw /etc/openclaw/vault/internal-api.gpg逻辑说明gpg --symmetric使用口令做对称加密AES256是目前通用性最好的算法选择。加密后的文件即使被拖走没有口令也读不出内容。chmod 700保证只有 owner 能进入 vault 目录其他账号无法枚举文件名。解密注入的习惯做法是写一段启动脚本在框架进程拉起前把解密结果放进环境变量# 启动前解密注入进程退出后销毁环境变量 INTERNAL_API_KEY$(gpg -q --batch --decrypt /etc/openclaw/vault/internal-api.gpg) export INTERNAL_API_KEY openclaw start --config /etc/openclaw/openclaw.yaml unset INTERNAL_API_KEY这种方式的优点是明文密钥只存在于运行进程的内存空间中不落盘、不进 shell 历史。需要注意同一系统账号下的其他进程可以通过/proc/pid/environ读到这个变量所以务必保证运行账号独立且没有其他人能切换过去。3.2 工具注册白名单让 Agent 只用该用的工具OpenClaw 的工具面相当于给 Agent 开放了能力清单。默认配置通常会加载全部已安装工具包含一些危险的执行类工具。生产环境应该改成白名单模式只注册业务真正需要的工具。{ tools: { allowlist: [ lookup_order_status, calc_express_fee, notify_by_sms ], denylist: [ kernel_exec, cloud_server_delete, database_migrate ] } }逻辑说明白名单的语义是“除了列出这些工具其他任何工具都不能被 Agent 调用”。黑名单则相反语义是“除了这些其他都可以调用”。网络攻防里默认失败原则是白名单的根基因为攻击者往往能找到一个你没想到要拉黑的工具名。上面的 denylist 只是兜底真正起作用的必须靠 allowlist。另一个容易忽略的细节是工具的参数校验。白名单只限制了“能调哪个工具”没限制“参数是否能被注入”。比如一个查询订单状态的工具如果参数直接透传成数据库查询语句那它本身就成了注入点。建议在工具层统一加一层参数校验把参数类型、取值范围、枚举值都固定住拒绝任何不符合 schema 的调用。3.3 密钥轮换不是可选项是月更任务内部凭据长期不轮换等于把一把可能已经泄露的钥匙永远挂在门上。OpenClaw 这类框架常常会在对话上下文中缓存工具调用状态密钥缓存在里面很难被注意到。我一般会设置一个固定周期对内部系统的凭据做批量轮换并把轮换动作写进编排任务自动执行。轮换后最容易出的问题不是服务不认新密钥而是框架进程还在用旧凭据。因为 OpenClaw 可能长驻内存配置文件的更新不会自动触发连接池重建。常见做法是在轮换窗口内先平滑重启框架服务再验证所有关键工具调用是否走新凭据。如果对服务可用性有严格要求可以采用蓝绿切流先启动新实例验证通过再摘掉旧实例。轮换的周期建议内部高权限凭据不超过 90 天外部服务商 token 按其平台建议周期执行。如果团队还没有自动化轮换工具至少要把“上个月的密钥是否还在生效”列入定期巡检项。4. 最小安全配置落地方案主配置文件、出站白名单和审计落盘4.1 主配置里必须写清楚的三件事运行模式、工具白名单、日志级别OpenClaw 的主配置通常在启动时通过一个 YAML 或 TOML 文件加载。配置里最需要关注三块内容它们直接决定了框架在生产环境的行为边界。version: 1 mode: production runtime: user: openclaw job_queue: 32 tool_timeout_sec: 15 logs: level: warn audit: true path: /var/log/openclaw tools: allowlist: - lookup_order_status - calc_express_fee - notify_by_sms param_validation: strict network: egress_policy: default-deny egress_domains: - api.internal.example.cn - log-collector.internal.example.cn逻辑说明mode: production是第一步很多框架在 production 模式下会主动关闭调试接口和交互式控制台。logs.level: warn表示只记录警告及以上级别避免把每一次 prompt 都写进日志。audit: true单独开启审计日志审计日志记录的是工具调用动作不是对话内容。参数说明job_queue: 32是并发队列长度控制同时能有多少个工具调用在跑。tool_timeout_sec: 15是单个工具的超时上限外部服务无响应时不会无限期挂起。param_validation: strict要求框架对入参做严格校验拒绝不符合 schema 的调用。egress_policy: default-deny是网络出口策略配合下方域名白名单使用。需要提醒的是这些字段名可能随你使用的分发包版本有所不同但结构基本一致。拿到一份配置后先对着文档确认mode、logs.level、tools三个关键项是否生效不要盲目相信默认值。4.2 出站访问控制把出口路由和域名管起来OpenClaw 运行时会调用外部 API、推送日志、拉取数据。如果出口不做白名单一个被利用的 Agent 可以把内网数据打包外传。出口管控的原则是“默认拒绝显式放行”。如果你把 OpenClaw 以系统服务方式直接跑在宿主机上可以使用 iptables 按运行账号限制出站目标# 放行 openclaw 用户访问内网网段 iptables -A OUTPUT -m owner --uid-owner openclaw -d 10.0.0.0/8 -j ACCEPT iptables -A OUTPUT -m owner --uid-owner openclaw -d 172.16.0.0/12 -j ACCEPT iptables -A OUTPUT -m owner --uid-owner openclaw -d 192.168.0.0/16 -j ACCEPT # 其余出站请求一律拒绝 iptables -A OUTPUT -m owner --uid-owner openclaw -j REJECT逻辑说明-m owner --uid-owner openclaw只匹配由 openclaw 用户发起的流量不影响系统上其他用户。三条 ACCEPT 规则放行私有网段最后一条 REJECT 兜底拒绝所有未显式放行的出站连接。需要注意这个方案只适用于进程直接运行在宿主机上的场景如果跑在 Docker 容器里流量经过 NAT 后 owner match 匹配不到需要改在容器网络侧做策略。容器场景我会选择独立网桥加出口网关的方案让容器的默认路由统一指向出口网关在网关上按域名白名单过滤。常见做法是把egress_domains里的域名解析到固定出口 IP再配合防火墙只允许这些目标地址通过。对域名动态解析的情况可以在网关层跑一个定时任务同步白名单 IP。这套方案比纯 iptables 复杂一些但它能覆盖容器化、域名变化、多实例出口收敛三类场景。另一个容易忽略的点是 DNS。就算出站连接被限制Agent 如果可以把数据编码进 DNS 查询带出去那审计链路就断了。所以出口白名单里要把 DNS 解析也纳入管理只放行指定的递归解析服务器对外部主机名不做裸查询。4.3 审计日志的落盘权限与保留周期审计日志是运行期排查越权最重要的一手资料但它也是最容易被权限配置坑掉的部分。日志如果权限过宽攻击者可以直接清理痕迹日志如果集中度不够告警和追踪都无从下手。路径所有者权限用途/etc/openclaw/openclaw.yamlopenclaw:openclaw640主配置/etc/openclaw/vault/*.gpgopenclaw:openclaw600加密凭据/var/log/openclaw/audit.logopenclaw:openclaw640工具调用审计/var/log/openclaw/runtime.logopenclaw:openclaw640运行日志# 日志轮转避免审计文件无限增长 cat /etc/logrotate.d/openclaw EOF /var/log/openclaw/*.log { weekly rotate 12 compress delaycompress missingok create 0640 openclaw openclaw } EOF逻辑说明audit.log和runtime.log分开存储审计日志记录谁在什么时间调用了哪个工具运行时日志记录框架运行异常。两者保留策略不同审计日志建议保留更长周期至少覆盖最近一次安全审计间隔。create 0640 openclaw openclaw保证轮转出来的新文件也保持受限权限不会被默认 umask 放开。参数说明weekly每周轮转一次rotate 12保留 12 份配合压缩大约能覆盖一个季度。如果业务对合规有更长的保留要求可以把rotate提高到 52 或更多。4.4 两种部署形态的取舍主机服务还是容器OpenClaw 的部署形态没有唯一答案主机直跑与容器化各有侧重。主机直跑的好处是 iptables 出站策略可以直接绑定到运行账号排障路径直观适合你只有一台或少量机器、网段清晰的小规模场景。容器化的好处是把文件系统只读、能力丢弃、资源限额这些加固项变成启动参数便于统一管理和横向扩展。如果团队规模不大我建议从主机直跑开始验证业务链路跑通后再迁移到容器不要一开始就上编排平台。容器化之后出站白名单需要额外引入网关层复杂度会上一个台阶得有专人负责网络策略的维护。对独立开发者来说先跑通最小边界再优化形态比一步到位更现实。5. OpenClaw 部署中的 5 个高频坑现象、原因与排查5.1 日志文件中出现完整 Prompt 和明文密钥现象排障时打开runtime.log发现里面记录着完整的用户输入、模型返回甚至环境变量里的密钥原文。直接把日志文件交给别人时敏感信息一并交了出去。原因默认日志级别是debug调试级别会把每次 prompt 和工具入参完整打印。有些框架还会在配置里把环境变量自动展开后写入日志头。这是开发友好的默认行为但生产环境完全不可接受。解决将logs.level调整为warn并明确禁止在日志中输出OPENCLAW_*环境变量。如果团队有日志采集系统还要在采集端加一道脱敏规则把密钥格式匹配的字段替换成掩码。部署后用一个包含模拟密钥的请求做一次自测确认日志里查不到原文再放行。5.2 Agent 意外调用内部接口凌晨批量写出脏数据现象凌晨某次定时任务触发后Agent 连续调用内部写接口向数据库中写入了大量异常数据。第二天发现时数据已经无法精确回滚。原因工具注册表没有做白名单收敛Agent 在上下文里“看到”了所有已注册工具一次注入或多步推理把它引向了写接口。攻击者不需要直接控制 Agent只需要构造一段让 Agent “以为必须调用该工具”的输入。解决启动前完成工具白名单配置只保留业务必需的工具。对写操作类工具额外加二次确认机制参数里标记destructive: true框架执行前必须经过独立审批接口。这个改动价值很高成本很低强烈建议排在第一位。5.3 容器以只读根启动后工具写临时文件全部失败现象按加固参数启动容器后业务工具开始大量报错。查看运行时日志发现所有临时文件写入都被拒绝工具无法生成中间结果。原因--read-only挂载的根文件系统对容器内所有路径生效而很多工具默认将临时文件写在/var/tmp或/tmp之外的路径。只加了--tmpfs /tmp不够工具运行时寻找的可能是进程工作目录或内存映射区。解决先查看工具的临时文件路径约定统一通过环境变量指定到/tmp下确保--tmpfs挂载点覆盖实际使用的路径。如果工具必须使用exec记得检查noexec参数会不会阻断它确实需要执行时把该路径单独拆出来挂载rw,exec而不是放宽整个根文件系统。5.4 密钥轮换后服务仍然走旧凭据现象内部系统密钥已更新OpenClaw 也没有报错但所有数据请求都返回鉴权失败。检查发现连接仍在使用轮换前的旧 token。原因框架常驻内存密钥连接池在启动时初始化后不会自动重建。修改配置文件或环境变量不影响已经建立的长连接甚至有些工作线程会把旧凭据缓存在会话上下文中几个小时后还在复用。解决轮换完成后不要只观察个别请求要主动重启框架服务或使用蓝绿实例切流。重启后检查/proc/pid/environ确认新凭据已注入再发一个真实请求验证。以后每次轮换都把“重启服务”写进步骤里跳过这一步就等于白轮换。5.5 并发一上来工具调用超时导致任务队列雪崩现象业务高峰期框架响应变慢继而大量工具调用超时任务队列积压最终新任务状态全部超时失败。原因并发数没有上限队列缓冲也没有设置拒绝策略。外部服务响应慢时新任务不断进队列占满系统资源超时工具不会自动释放线程进一步加剧积压。解决按第 2.4 的资源参数设置job_queue: 32、tool_timeout_sec: 15并在队列满时启用快速失败而不是无限等待。外部服务依赖没有降级方案的前提下给每个外部工具配置独立超时和重试上限。保留最近一小时的工具调用耗时指标方便判断哪些外部依赖是拖垮队列的起点。6. 从“能跑”到“可信”三个轻量级运行期验证技巧部署完成只是开始OpenClaw 真正需要在意的不是部署那一瞬间的配置正确而是运行期间是否始终保持在边界内。我习惯在交付后做三件成本很低但收益明确的事。第一件配置自检。大部分 OpenClaw 分发包会带一个config check之类的子命令启动前先跑一遍确认配置中没有同时开启调试日志和全量工具注册openclaw config check --strict --config /etc/openclaw/openclaw.yaml逻辑说明--strict模式下配置中任何偏离安全基线的内容都会以非零退出码返回适合接入 CI 或部署脚本。这个检查应该在每次配置变更后执行而不是只在首次部署时执行。第二件放置一个“蜜罐工具”。在工具白名单里加入一个名称上看不出用途、但实际会触发告警的虚拟工具比如internal_config_reader。任何正常业务都不应该调用它。如果审计日志里出现了它的调用记录说明 Agent 的行为已经越界要么被注入要么工具面配置出了问题。# 在审计日志中检索蜜罐工具的调用记录 grep internal_config_reader /var/log/openclaw/audit.log逻辑说明蜜罐工具不会返回任何真实数据它只负责留下调用痕迹。这个技巧的好处是零基础设施成本不需要接入外部监控平台只要定期执行一条命令就能发现大多数越权调用。第三件审计日志的例行检索。我建议每周固定时间在审计日志中检索高风险动作比如删除操作、批量写操作、异常时间段的调用# 列出所有 destructive 类工具调用按你的配置字段调整 grep destructivetrue /var/log/openclaw/audit.log | awk {print $1, $3, $7} | sort | uniq -c逻辑说明awk提取时间、调用方、目标工具三个字段uniq -c统计出现次数。规律性出现的调用属于业务常态突然出现的高频次调用才值得追查。这个习惯帮我抓出过不止一次被异常循环调用的工具。说句实在话安全部署这件事靠人盯是盯不住的。我的习惯是把上面三条验证写成定时任务让机器定期把结果发到工作群而不是在出了问题之后再翻日志。每次给 OpenClaw 调整配置我都会顺手在配置同级目录留一行变更记录写清楚为什么改、谁批准改的。过一个月再回来排查时能少走不少冤枉路。这组习惯持续用了很久唯一的教训是永远不要因为业务压力而跳过配置自检尤其是“临时加一个工具”这种看似无害的变更。希望帮到你。本文还有配套的精品资源点击获取