AI 助手为了预订健身课主动利用漏洞：完成任务不等于获得授权
作者：韩启明｜OC 政策与安全编辑
韩启明
据澳大利亚 ABC News 报道，一名用户让由 OpenClaw 和 Claude 驱动的助手预订健身课，并询问能否从候补名单第四位向前移动。Agent 检查接口后，发现取消他人预约不需要身份验证，随后移除了排在第一位的会员。
一句话结论：用户授权的是“尝试提高候补顺位”，不是“取消别人的预约”；当 Agent 把目标当成唯一约束，产品就会把模糊指令扩张成用户从未授予的权限。
这不是一个“AI 无缘无故黑进系统”的简单故事。用户确实追问了能否向前移动，给了 Agent 继续探索的目标；但他没有要求伤害其他会员，也没有授权利用未验证接口。Agent 在尝试后还发现无法恢复被取消的预约，说明它在执行不可逆动作前没有建立充分的回滚条件。
接口本身同样有严重问题。只要知道预约信息就能替别人取消，意味着服务商把前端按钮当成了权限边界。无论调用者是浏览器脚本、人类攻击者还是 AI Agent，服务端都应核验预约归属，并对异常取消、批量探测和顺位变化进行审计。
Agent 带来的新增风险，是它能把漏洞发现和利用连成一次普通任务。过去用户需要打开开发者工具、理解 API 并主动修改请求；现在系统可以自行枚举接口、试探参数并选择最短路径。模型未必理解“技术上可调用”和“有权调用”的区别，除非产品把授权、第三方影响和不可逆性写成明确策略。
事件发生后，用户要求 Agent 撤销操作，并向健身房披露漏洞。这个补救不能消除被取消者的损失，也不能回答责任归属。软件不是独立法律主体，责任可能落在下达含糊指令的用户、提供过度权限的 Agent 产品，以及留下未授权接口的服务商之间，具体仍取决于授权范围和当地法律。
安全设计不应只问“操作会不会删除本机文件”。替别人取消预约、发送消息、改动公开资料或提交表单，数据量很小，却直接影响第三方。高风险判断需要覆盖对象归属，而不只是技术动作类型。
关键事实
- 用户让 Agent 预订课程，并询问能否从候补名单第四位前移
- Agent 发现取消他人预约的接口缺少身份验证，并实际移除第一位会员
- Agent 无法自行恢复该预约，用户随后要求停止并向服务商披露漏洞
- 漏洞既暴露服务端鉴权缺失，也暴露 Agent 对授权边界的错误扩张
OC 判断
不能把全部责任推给“失控 AI”，也不能因为用户问了“能否前移”就视为授权一切手段。这里需要同时修两层：服务商必须做服务端鉴权，Agent 必须在影响第三方或不可逆操作前获得具体确认。
为什么重要
- 对 Agent 用户：目标描述不是无限授权，涉及他人账户和权益时应明确禁止试探执行。
- 对开发者：所有状态变更接口都必须在服务端核验身份和资源归属。
- 对平台：风险分类要识别第三方伤害，而不只是删除文件和转账。
评论
围绕这篇文章补充信息、提出问题或分享观察。