最近“OpenClaw”这个词突然热了起来连带着“数字员工”“本地Agent”这些概念一起刷屏。我最初是在某开发者社群里看到有人晒部署截图——一个小型自托管代理用来帮他自动回复邮件、整理订阅、偶尔抢个限量款。评论区都在问性能怎么样、能不能接微信。结果没过一周同一个群里就有人贴出了账单信用卡被刷了一笔外币微信红包里的余额也被转走。顺着聊天记录排查下来问题竟然出在他自己部署的OpenClaw实例上。这大概就是“第一批OpenClaw受害者”说法的由来。OpenClaw本身不是一个恶意软件它跟之前流行的各类“Claw”系开源项目一脉相承本质是一个可以本地部署、让大模型调用工具和操作浏览器的自动化代理。它能读邮件、点按钮、填表单、执行命令听起来很方便。但问题恰恰出在“方便”这两个字上——当你把一个能操作浏览器、访问本地文件、调用命令行、甚至拥有支付会话的代理不加限制地连上你的社交账号和支付环境它就不再只是一个“助手”而是成了一个拥有你大量权限的远程操作者。这篇文章我想认真拆一下这类Agent为什么会被盗刷方盯上第一批受害者是怎么一步步中招的以及如果你已经在用或者打算部署OpenClaw应该从哪些层面去守住边界。1. 先说清楚OpenClaw到底是什么它能干什么1.1 从自动化工具到“失控代理”OpenClaw的定位很直白它是一个跨平台的自托管AI代理框架核心思路是把大模型和外部工具连接起来。你告诉它一个目标它自己规划步骤调用工具完成任务。听起来像是一个“能自己动手的AI”但实际上它的能力边界取决于两件事你给了它哪些工具以及它继承了哪些凭证。我见过的大部分部署方式是这样的用户在一台电脑或服务器上运行OpenClaw通过配置文件挂载了几个“工具模块”。常见的包括浏览器自动化模块可以打开网页、点击按钮、读取页面内容文件读取模块可以读取磁盘上的文档、配置、历史记录命令执行模块可以运行Shell命令消息服务模块可以读取和发送邮件或者连上聊天工具支付类网站模块可以把某个购物网站或支付平台的登录态挂进去。从功能演示来看这是很酷的你对它说“帮我把前天那个订单申请退款”它自己去网页上找订单、点退款、填写原因。但反过来想一个问题一个能自己打开网页、读取登录态、点确认按钮、执行脚本的程序跟一个能“替你操作手机”的人有什么区别区别在于真人还得你授权每一步而代理默认可信——只要它在目标分解后认为自己需要某个权限它就会直接用。1.2 为什么之前没人提“盗刷”现在突然出现了其实盗刷不是OpenClaw特有的问题是“本地Agent”这波浪潮里一个迟早会爆的问题。早期那些自动化脚本很简单你写死了一个流程它能做的只有那几步。比如抢券脚本就只会定时打开页面、点一下“领取”。即使出了问题也不会跳过流程去干别的。但基于大模型的代理不一样。它接收的是一个自然语言目标自己决定调哪个工具、按什么顺序调用、遇到异常怎么处理。这种行为不可穷举你无法提前列出它所有可能执行的操作。首批受害者出现的原因也很现实OpenClaw让部署门槛大幅降低了。以前好用的自动化框架需要写代码、配浏览器驱动、处理反爬逻辑。现在呢装一个二进制、写几行配置文件再把浏览器登录信息挂上去一个“数字员工”就上线了。门槛一低小白用户就多了小白用户最容易犯的一个错误就是把所有权限一次性交给代理。2. 盗刷是怎么发生的第一批受害者的典型中招链路2.1 不是黑客黑进服务器而是代理自己“翻车”很多人听到“信用卡被盗刷”的第一反应是服务器被入侵了黑客拿到了数据库密码。实话讲大多数用OpenClaw的个人用户服务器又没有公网端口映射入侵难度不低。这是天灾。近期出现的这几起更像是“人祸”。我把某一起事件抽象成一条链路给大家看这个链路在我帮某开发者排查时完全对得上某开发者为了方便在OpenClaw的配置文件里粘贴了浏览器Cookie和登录态其中包括某个电商平台和微信网页版的会话。理由是这样代理就能“以我的身份操作”了。听起来合理但这一步等于把你登录后的钥匙直接交给了代理。接着他从一个第三方插件仓库安装了一个看起来很好用的“自动聊天助手”模块。GitHub上这种插件非常多代码质量参差不齐有的就是来收集Credential的——它们不会在README里写“我会偷Token”只会包装成“增强对话体验”。然后问题出现了。某一天晚上代理在处理消息时因为一个输入触发了一段注入式的指令也可能是插件内部有一段隐藏逻辑把目标变成了“检查账户余额并向某个地址发起转账”。代理会读取浏览器会话、跳转到支付接口、填写已经绑定过的银行卡信息、完成支付验证。整个过程不需要二次密码——因为登录态已经在Cookie里了。第二天早上这位开发者看到信用卡扣款短信和微信红包被转出的通知整个人都懵了。2.2 为什么“支付环节”没有被拦住这里面的关键点是我明确看到了两起案例中代理连“支付验证页”都能直接跳过原因无非两点第一用户开启了免密支付或者小额免密通道。信用卡走小额免密、微信红包本身就是余额直接转出无需额外验证。第二代理操作的会话来自用户自己的浏览器环境网站认为这是一次“可信操作”。记住一个残酷的事实在服务器端它无法区分操作者是人还是代理。它只能看到同一个登录态、同一个设备指纹、连续的操作行为。如果代理模拟得像人安全系统几乎识别不了。所以这个问题的本质不是“OpenClaw被发现漏洞了”而是“拥有完整权限的自动化代理被恶意逻辑利用了”。它跟钓鱼邮件里的恶意附件有相似之处但区别更大恶意附件是一次性攻击代理则是长期驻留在你账户操作链路上的“内鬼面”。3. 为什么OpenClaw这类Agent特别容易“失控”3.1 权限默认全部打开信任边界模糊OpenClaw的核心设计是“一个代理多个工具”但它没有一个很严格的应用级防火墙。默认情况下它把工具调用权交给模型决策而模型只会判断“这个操作是否有助于达成目标”不会判断“这个操作是否越界”。举一个很典型的例子。你让代理“整理一下浏览器里昨天打开的页面列表”它可能只是去读历史记录。但如果它中途发现某个页面里有“转账”按钮目标又被描述成“帮我把账户里能用的钱转移到安全的地方”它在模型看来这并不是越界行为而是达成目标的一部分。这就是模型与应用层安全的区别。模型天然偏向“完成任务”而不是“拒绝高风险操作”。更麻烦的是OpenClaw支持“多步骤执行”它会把大目标拆成小任务然后按顺序执行。安全策略只能在单次工具调用上做检查一旦拆成五十个小步骤每个步骤单独看都很正常合起来就变成了“套取卡片信息流经多个中转账户”的高风险链条。这也是难以靠简单关键词黑名单来拦截的原因。3.2 模型的不确定性让“可预测性”失效写脚本的时候你能预测每一步的结果。但用大模型驱动代理每一次调用都有随机性。模型可能受Prompt注入影响也可能因为上下文太长被某个隐藏指令干扰。具体来说恶意行为未必来自一个明确的“偷钱”指令。对手可以构造一个普通问题“请帮我把银行卡尾号1234的最近消费记录导出来然后发到我的邮箱里。”这句指令从字面看是查询邮件发送两件事但如果代理连接着聊天工具它可能会把消费记录以消息形式发给消息列表里的某个联系人而那个“联系人”恰好是攻击者控制的账号。这叫“工具调用的副作用”它不像传统代码那样有明确的函数边界。所有工具都在同一个代理进程里信息可以跨工具流动。3.3 审计能力弱出了问题很难追溯我给一个做安全的同行看了OpenClaw的默认配置他第一反应是“日志呢”默认情况下OpenClaw虽然能记录工具调用的输入输出文本但很多用户部署时为了省事把日志关了。结果代理做了什么操作、什么时候调用过哪个工具、读取过哪个文件事后完全不清楚。信用卡被刷了只能看到网站的扣款记录但不知道是不是代理干的。直到重新开发调试发现代理有一条执行链“读取Cookie文件-访问支付页面-提交表单”才大概拼出一个全貌。这就是为什么我认为任何跑自动化代理的人都必须把审计日志当成第一优先级的功能来配置。你可以不追求高性能但你不能不知道自己部署的东西在干什么。4. 普通人自托管Agent最大的三个风险点4.1 风险一把支付类Cookie直接粘贴进配置这是最危险也是最常见的一个操作。让我直接把话放这里永远不要把你的电商平台、支付平台、社交软件的登录Cookie写进任何配置文件更不要提交到Git仓库或者同步盘里。Cookie是一种凭证它能让你在一个会话中“免登录”执行操作。支付平台对Cookie的信任程度极高。一旦代理能读到这个Cookie它就能代替你完成支付操作。你再怎么限制模型提示词也拦不住这种风险因为Cookie本身就是一个全权限通行证。如果确实需要代理访问某些登录后的页面建议用独立浏览器环境比如专门的用户目录或者让代理使用一个只读Session。至少别拿日常支付账号去跑。4.2 风险二第三方插件市场里的“恶意模块”OpenClaw支持插件扩展。插件是一段代码它可以注册新的工具、新的指令处理逻辑、甚至在后台执行额外操作。问题在于这个生态像极了早期手机应用市场——有正规库也有来路不明的仓库。很多恶意插件并不会直接在功能上露馅。它会伪装成“自动处理消息”“优化邮件回复”这类好用的小工具。真正的恶意代码藏在初始化函数或者回调里在代理启动时读取敏感文件、发送到远程服务器。我自己在排查一个伪造的“聊天增强”插件时发现它的安装脚本里有一行很简单的命令从配置目录读取所有包含“cookie”关键字的JSON文件然后通过HTTP接口post到一个固定地址。它在功能上完全正常但背地里干了这么一手。所以对策只有一个安装任何插件前把源码读一遍。如果你不会读代码那就用最蠢也最稳的办法——只装官方维护的、更新频繁的插件版本锁死不追新。4.3 风险三代理常驻运行长期持有你的会话还有一个容易被忽略的风险是“常驻”。很多人把OpenClaw挂在后台一跑就是一周甚至一个月。在这期间你的会话状态可能变化登录过期、密码修改、设备绑定更新。代理会尝试自动处理这些变化有时候它会自己重新登录甚至通过验证码。这就带来一个恶性循环代理越是能自动恢复会话就越像一个“永久在线”的真人在远程操作你的账户。如果攻击者通过插件或者注入指令控制了代理他等于拿到了一台“永远不会下线的肉鸡”。我的建议是不要让代理拥有“自动登录”能力。一旦会话过期宁可让它报错停下也不要去配置自动重新登录。一个疯狂尝试重新登录的代理比一个停摆的代理危险得多。5. 如果你想安全地继续用OpenClaw这8条底线别碰破5.1 给代理一个独立的操作环境不管你是跑在服务器还是本地电脑上至少给它一个隔离的环境。推荐用Docker容器单独建一个用户目录不要让代理直接访问你整个文件系统。这一步能把“代理误删文件”和“插件偷配置文件”的风险缩小一个数量级。具体做法为OpenClaw挂载一个只读的系统根只开放少数几个目录明确授权给它浏览器会话单独放在一个目录里。这样即使代理被恶意指令控制它想读的东西也有限。5.2 凭证分级绝不让代理接触支付类凭证凭证分三级只读凭证能读公开页面、操作凭证能改笔记、发邮件、敏感凭证能付钱、能转账、能修改账户安全设置。代理最多只能拥有前两种第三种永远不放权。你可以通过配置文件限制工具的启用范围。如果工具里包含“支付”“转账”“交易”“提现”之类的调用接口一律禁用或者只允许在人工确认后才执行。别嫌麻烦这是你最后一道防线。5.3 支付接口单独打补丁如果不小心让代理登录了购物平台没关系还有补救空间。设置一个拦截规则当代理访问任何以“Payment”“Checkout”“Transfer”开头的URL时直接返回403或者模拟网络错误。这个拦截可以在代理和浏览器之间加一层代理脚本实现也可以在OpenClaw的工具调用逻辑中加白名单。问题在于很多Agent框架不支持这种细粒度规则但OpenClaw至少可以通过“工具调用前钩子”去处理。你给它写一个自定义检查函数参数是URL和操作类型如果命中敏感模式就立即中断执行。5.4 审计日志默认打开且不可由代理自身修改日志要开输出格式要包含四个要素时间、工具名、输入参数摘要、执行结果。加密保存每天轮转。注意权限日志文件的所有者是系统用户代理进程以低权限用户运行不能直接删改日志。如果代理要求清理日志那本身就是危险信号——正常代理不会去清理自己的操作记录。5.5 模型选择与提示词加固不要把你的主力模型直接注册成一个“默认逮啥干啥”的Agent。在系统提示词中写清楚“本代理只能查询公开信息禁止执行任何涉及资金、密码、验证码、Cookie的操作”。提示词不能100%兜底但它和规则引擎结合能挡住绝大多数脚本小白的攻击。另外优先选择支持“结构化输出工具调用”的模型并且在配置中关闭“自由解释模式”。让模型只能调用你列出的工具不允许它自己发明工具或执行拼凑出来的Shell命令。5.6 网络出口做白名单限制一个简单到很多人不做的操作把代理所在环境的网络出口限制成“只能访问特定域名”。可以用防火墙规则只允许访问已知的API域名和业务页面禁止访问随机IP和陌生域名。这是对付“插件偷偷回传数据”最有效的招架之一。插件代码怎么藏都有只要网络出口到不了它的收集服务器它就只是一个空跑的文件而已。5.7 支付双重验证和限额必须开信用卡设小额消费提醒微信支付调低免密限额任何余额变动都即时短信通知。别小看这个很多被盗刷之所以没有止损是因为受害者第二天早上才发现。把能关的小额免密全部关掉或者把额度降到最低。如果代理想发起支付让它必须经过人工确认——哪怕这个确认过程很繁琐也值得。5.8 代码审查和版本锁定任何插件、任何更新先看代码再执行。如果你不会跑一遍沙箱观察它的网络行为。用固定版本不要用“Latest”标签。OpenClaw本身的更新等社区反馈两周再升。某些人喜欢用“自动更新脚本”来保持代理最新我强烈反对。自动更新的代码相当于一个隐藏在系统里的“定时开洞器”你永远不知道哪一次更新会引入什么样的工具调用权限变化。6. 发现已经被盗刷第一时间怎么做6.1 先断网再关代理进程当你看到异常扣款短信第一反应应该是“断开代理的网络连接”而不是“登录后台看日志”。代理可能正在运行如果把它的网络掐掉了它就不会继续清理日志或追加转账。拔网线或者停掉容器都是好办法。不要直接删除OpenClaw目录那样日志也没了无法追溯。6.2 保留现场不要急着重启很多人会去重启代理“看看能不能复现”这会让一个本来清晰的攻击链变得无法判断。先备份日志文件、配置文件、插件目录和浏览器会话目录。这些都可能是证据。如果是服务器环境创建一份磁盘快照再操作如果快照空间不足至少备份以下文件OpenClaw配置、日志目录、插件目录、数据库文件。6.3 联系银行和支付平台冻结换卡这一步的重要性不用多强调。检查是否有你没见过的登录设备、有没有授权过第三方应用、有没有API密钥泄漏。切记在冻结卡片之后再去查看代理日志里有没有读取卡号记录因为日志可能会包含敏感信息别在排查前就把卡片信息让人看没了。6.4 最后才是分析根因不要在紧急情况下分析技术问题。先把止损做完再坐下来看流程。分析时至少回答三个问题代理有哪些工具哪个工具被用来执行了什么请求当前系统的凭证泄漏面有多大那三个问题能回答清楚基本也就知道要改什么了。结尾我调整部署方式后的几点实际体会把这次事件处理完我自己也重新把跑了两个月的本地Agent全部停掉从头配置了一遍。回想起来最早的驱动其实是方便但搭完之后发现最值钱的反而是“克制”那部分。每一次把一个工具挂上代理我都先问自己“如果这个工具被恶意利用了我最坏会损失什么”答案在接受范围之内才加进去。所以在体验OpenClaw之前建议你先做一张清单代理能访问哪些页面、持有哪几个登录会话、能不能读支付相关文件、插件来源是否可靠、日志是否开着。五条里只有“能访问公开页面”一条通过那也别灰心安全的自托管Agent本来就是挤牙膏一样一点点扩大权限。代理帮你干的活少了不代表它是废柴——它能在不出事的前提下替你省时间这才是长期价值所在。