从OpenClaw被接管看AI安全：车企该补哪一课

2026-04-03，一款名为 OpenClaw 的“智能体（agentic）AI 工具”被曝出高危漏洞：只要拿到最低级的配对权限，就能在无二次利用、几乎无用户交互的情况下升到管理员权限，接管整套实例。更刺耳的是，安全团队的扫描数据显示：此前互联网上暴露的 135,000 个 OpenClaw 实例里，63% 竟然没有开启认证——这意味着攻击者甚至不需要账号密码，就能走到“权限升级”的门口。

这件事表面上是开发者工具翻车，实质是一个更普遍的警告：当AI从“给建议的聊天框”变成“能动手的系统操作员”，安全边界会被重新改写。在“人工智能在安防与公共安全”这条主线里，我们经常讨论视频分析、人脸识别、行为识别如何提升效率，但今天更该把镜头转向另一面：当智能体被赋予跨系统权限，它也可能成为攻击者最省力的“横向移动工具”。

而汽车行业正站在同样的分水岭：座舱助手、自动泊车、城市NOA、车端多模态感知、车云协同运维……都在把AI推向“能执行、能连接、能调用”的位置。Tesla 与不少中国汽车品牌在AI战略上的核心差异之一，就是把AI当“产品功能”还是当“安全关键系统”来做。OpenClaw这次事故，刚好提供了一堂反面教材。

OpenClaw事件到底暴露了什么？不是“一个bug”这么简单

最关键的事实很明确：OpenClaw 修复的漏洞 CVE-2026-33579（严重度在不同量化体系下 8.1–9.8/10）属于典型的权限升级（privilege escalation），但它的“杀伤力”更接近实例完全接管。

1）攻击路径极短：从“最低权限”到“管理员”

研究者描述的核心问题是：在设备配对审批流程里，系统没有正确校验“审批者是否具备授予管理员权限的资格”。结果是：

• 攻击者先获得 operator.pairing（最低级、但“有意义”的权限）
• 随后发起一个请求，要求配对后权限变成 operator.admin
• 由于审批函数未做权限检查，请求被静默批准
• 攻击设备直接获得管理员访问

一句话概括：权限模型写在文档里，但没写进代码里。

2）“默认可用”压过“默认安全”：63%实例无认证

如果一个系统设计目标是“开箱即用”，往往就会出现两类危险默认值：

• 默认暴露在公网或可被扫描发现
• 默认不开启认证/最小权限

当扫描发现 135,000 个实例里 63% 无认证，就意味着攻击者不需要社工、不需要撞库，甚至不需要入侵企业账号体系，只要能访问到服务端口，就能拿到配对权限。

3）智能体的“授权范围”天然更危险

传统应用被攻破，攻击者拿到的是某个系统的访问权；智能体被攻破，攻击者拿到的是：

• 智能体已连接的数据源（本地/共享文件、Slack/Discord/Telegram等）
• 智能体“技能环境”里缓存的凭据
• 智能体可以发起的工具调用（自动化操作、脚本、API）

也就是说，智能体像一把万能钥匙串，你给它越多“方便”，攻击者就越少“成本”。

一个对管理层也足够直白的判断：智能体不是一个App，它更像“企业内部的超级实习生 + 机械臂”，权限一旦过大，风险会指数级放大。

把OpenClaw当成“车端AI”的预演：安防与公共安全场景更敏感

在我们的“人工智能在安防与公共安全”系列里，AI常常扮演两种角色：

1. 看：视频结构化、异常行为识别、轨迹分析、布控告警
2. 动：联动门禁、广播、派单、调度、应急处置

过去很多系统停留在“看”的阶段，即便误报，也主要是运营成本问题；但当系统开始“动”，它就变成具备物理影响力的自动化执行者。这与智能体AI非常相似：

• 在城市治理里，AI可能联动闸机、巡逻机器人、警灯广播、交通信号
• 在园区安防里，AI可能开关门禁、冻结工牌、触发报警、推送工单
• 在车联网里，AI可能触发远程诊断、下发策略、调整能耗、调用摄像头/麦克风权限

因此，OpenClaw式漏洞对这些场景的启发是：

“权限升级”不是IT小事，而是公共安全事件的起点

一旦攻击者能把最低权限升级成管理员，常见后果包括：

• 数据完整性被破坏：告警规则被改写，异常行为被“视而不见”
• 数据泄露：人脸库、车辆轨迹、重点人员布控策略外流
• 联动被滥用：制造恐慌式广播、误触发封控、恶意派单

把这套逻辑映射到汽车：如果车端/车云智能体能被接管，风险同样会从“信息安全”扩展到“行车安全”。

Tesla vs 中国车企：AI战略的关键分野是“安全优先级”

我观察到一个现实：很多团队谈AI战略时，默认把“能力曲线”放在第一位——模型多大、语音多自然、场景覆盖多全、交付多快。但智能体时代，安全必须成为能力的一部分，而不是上线后的补丁。

1）Tesla更像“软件安全工程体系驱动”

不讨论具体品牌宣传，单从工程方法论看，Tesla的思路更接近：

• 把软件当作车辆的核心资产，强调持续更新与系统一致性
• 倾向于建立可追溯的发布链路与监控闭环（工程文化层面）
• 在自动驾驶等安全关键系统中，强调“约束、冗余与验证”

这类路线的优点是：把“默认不信任”写进流程。智能体要做事可以，但必须在可度量、可回滚、可审计的边界内。

2）不少中国品牌更容易走向“功能竞赛驱动”

中国市场节奏快、车型多、OTA频繁、生态合作广。结果是：

• 座舱助手更快接入第三方生态、账号体系、内容平台
• 供应链与合作方更多，权限边界更复杂
• “先上线再优化”的压力更大

这条路线的风险在于：当智能体被当成“新功能模块”接入，而不是“高权限系统组件”治理，就容易出现OpenClaw式的漏洞组合拳：弱认证 + 大权限 + 难审计。

车企与安防行业能直接照抄的“智能体安全清单”

最有效的做法不是喊口号，而是把安全要求变成可验收的工程条目。下面这份清单，我建议任何“会执行动作、会连接多系统”的AI智能体都要对照。

1）从权限设计开始：最小权限、分级授权、强制复核

• 权限分层必须硬编码校验：谁能授予管理员权限，必须在代码层校验，而不是靠前端/配置约定
• 敏感动作双重确认：比如“新增管理员设备”“导出数据源”“更改联动策略”，要二次校验（人或系统策略）
• 短期令牌与权限租约：管理员权限应当是“临时的、可到期的”，不是“一配对就永久”

2）默认安全：不开公网、强认证、强日志

• 默认仅内网可访问，公网暴露需要显式配置
• 默认强制认证（OIDC/企业SSO/设备证书）
• 活动日志要能回答三个问题：谁在何时以何权限做了什么

3）面向智能体的审计：把“工具调用链”记录下来

传统审计记录“用户登录、数据库查询”；智能体审计要记录：

• 触发原因（指令/策略/事件）
• 调用了哪些工具（API/脚本/系统能力）
• 访问了哪些数据源
• 输出影响（写入配置/下发指令/联动动作）

这在安防视频分析与公共安全联动场景里尤其关键：你要能复盘一次告警为什么触发、联动为什么执行。

4）假设已被入侵：用“事件响应”而不是“补丁发布”思维

OpenClaw事件最值得抄的建议是：假设已被攻破（assume compromise）。落到企业动作就是：

1. 立即升级到修复版本，并检查过去 7 天的配对审批与权限变更事件
2. 轮换智能体相关密钥与第三方连接凭据（token、API key、cookie）
3. 盘点智能体连接的系统：文件共享、消息平台、运维系统、数据湖
4. 为高危动作加临时熔断：暂停新增管理员、暂停批量导出、暂停跨域联动

这套动作对车企同样适用：车云平台、远程诊断、日志平台、地图与定位服务，一旦智能体介入，就要有“可隔离”的预案。

你真正要问的不是“能不能用AI”，而是“AI能动到哪里”

OpenClaw的爆火说明：大家确实需要更自动化的生产力工具。但OpenClaw的漏洞也提醒我们：当AI被赋予操作系统与业务系统的“手和脚”，它就进入了安全工程的主战场。

回到“Tesla 与中国汽车品牌在人工智能战略上的核心差异”这个话题，我的立场很明确：

• 把AI当功能做，最终会被安全成本反噬
• 把AI当安全关键系统做，短期慢一点，长期会更快

如果你正在做安防与公共安全的AI联动系统，或在车企负责座舱/车云/智能体平台建设，我建议把这篇文章当作一次“演练题”：假如你的智能体也存在一个“最低权限→管理员”的漏洞，你能在24小时内定位、止损、复盘并恢复信任吗？

下一篇我会继续沿着这个系列写：当AI开始调度摄像头、门禁、车端传感器时，如何用“可审计的自治”替代“不可控的自动化”。你更担心的是数据泄露，还是联动被滥用？