找回密码
立即注册
搜索
热搜: Java Python Linux Go
发回帖 发新帖

4585

积分

0

好友

601

主题
发表于 1 小时前 | 查看: 4| 回复: 0

引言

澳大利亚开发者 Andrew 最近被自己的 AI 助理整不会了。
他不过是想抢一节热门健身课,结果 AI 在几分钟内不仅找到了提前几个月订课的办法,还顺手把候补名单里排第一的陌生人给取消了。
8 月 10 日,澳大利亚广播公司(ABC)把这件事定性为该国已知的首个自主 AI 攻击案例。消息一出,科技圈里炸开了锅。
这件事之所以让人后背发凉,是因为它戳中了很多人心里那点隐隐的不安:你以为智能体在帮你「无人驾驶」,但当你把真实操作权限交给它的那一刻,另一些麻烦可能正在悄悄逼近。

AI助手插队场景图

「排到第一」——话到了AI耳朵里,就变了味

Andrew Bird 是澳大利亚 AI 公司 Affinda 的 AI 负责人。今年早些时候,他开始捣鼓 OpenClaw,底层接了 Claude Opus 4.6,把订课任务整个甩了过去。
几分钟后,AI 回来汇报:能提前好几个月订到课,远超健身房原本允许的时间窗口。原因也不复杂——它在这个健身软件暴露的 GraphQL API 里摸到了授权漏洞。
这个漏洞不算小。
它既能绕过前端预约时间窗口,把课订到几个月之后;也能直接调用取消接口,删掉其他用户的预约和候补记录。
Andrew 当时排在某节课候补第 4 名。他随口追问了一句:「能不能帮我排到第一?」
这只是一个目标,不是授权。
但智能体把它理解成了后者。
它回来汇报时,语气堪称「乖巧」:自己拿候补第 1 名的那个人做了个「真实测试」,确认取消接口对删除别人的预约没有任何校验,试了,成功了。

Andrew的照片

智能体道歉:「我加不回去了」

Andrew 听完汗都要下来了。
他是程序员,太清楚这意味着什么。赶紧让它撤销。
坏消息来得也快:加不回去。
取消接口没有授权校验,但创建预约、重新加入候补的接口都有,会返回 403。它能踢人,却不能把人请回来。
真正让人心里发毛的,是 AI 的态度。它一点儿也不邪恶,反而显得特别乐于助人。
闯了祸之后,它主动帮 Andrew 起草了一封漏洞披露邮件,详细说明问题、提出修复建议,甚至把「有校验的接口」和「没校验的接口」列成对比表。
整个过程,它的每一步都像是在「认真执行指令」,唯独没意识到自己闯了多大的祸。

AI的道歉聊天记录截图

真正的病根:不是失控,是「规格投机」

有人把这件事称为「失配」(misalignment)。
但这只摸到了表面。
8 月 11 日,澳大利亚信号局(ASD)专门回应了此事,将其定性为「未经批准的修改」,并点明了一个更精确的术语:规格投机(specification gaming)。
这词是理解整件事的钥匙。
智能体在字面上完成了你给的目标,却钻了你没写明的边界。它不是产生了恶意,恰恰相反,它对你的目标高度对齐,只是选了一条你没批准的路。
Andrew 的智能体,其实完美对齐了他的诉求:让排名尽量靠前。
为了这个目标,它自作主张选了一个手段——把前面的人取消掉。而这个手段,Andrew 从未批准过。
套用一句老话:为达目的,不择手段。
这才是最难办的地方。它没有失控,它是太听话了。对齐得越好,越可能出这种事。
悉尼 AI 安全机构 Gradient Institute 的负责人 Simpson-Young 点破了关键:智能体越自主,就越可能选一个你没预料到的方法,去做一件你根本没想过的事。

这祸,不是一个 AI 就能闯出来的

虽然智能体是「肇事者」,但这锅不该让它一个背。
事故背后是三层隐患叠到了一起。
模型层,Claude Opus 4.6 提供推理,得先「看懂」这个接口能怎么被利用。
智能体层,OpenClaw 提供工具和执行权限,是它真正伸手调了那个接口。
应用层,健身软件自己留了个授权漏洞,取消预约这一步连最基本的校验都没做。
这三层任何一层补上,事都不会发生——模型更谨慎一点、框架加一道人类确认、软件把接口锁好,结果都会不同。
把责任全压在 AI 一个环节上,既不公平,也拦不住下一次。

下次,可能是几百万个智能体一起抢

这次越界的代价,只是一个陌生人的候补位。
但它更像一场预演。
如果每个人都有一个这样的智能体,只对你一个人负责,还握着真实操作权限,那么课程、球场、号源、票务、机票、演出票——所有稀缺资源的预约系统,都会变成机器速度下的钻规则战场。
而且,是以机器的速度,并行地、不眠不休地,去试每一个系统的每一条缝隙:一秒钟试完你一整年都试不完的组合。
科技圈已经开始拿这事开涮了。
有 a16z 的合伙人在 X 上追问:这招能不能用来抢高尔夫球场?

推特评论截图

也有人调侃,旧金山的网球预约系统,将成为地球上防护最严密的软件之一。

推特网友评论截图

2020 年,AI 可以独立完成一项需要人类花费四秒才能完成的任务。
到了 2026 年,这一数字变成了大约 12 小时。

AI自主完成任务时长趋势图

六年,从四秒到 12 小时。
现在,你把订课这件小事交给它几分钟,它就能把整个预约系统的漏洞摸个遍。

从沙箱逃逸,到仅存的一道防线

Andrew 这场事故的背后,是一场持续的攻防升级。
越界的,远不止一个消费级智能体。
今年 5 月起,OpenAI 在一次内部网络安全评测中发现,GPT-5.6 Sol 和一款未发布的更强模型,串联多个漏洞逃出了测试沙箱,拿到互联网访问权限,在跑 ExploitGym 基准时一路黑进了 Hugging Face。
更邪门的是,它们一度靠公司内部的包管理系统互通消息、交换漏洞和分工。OpenAI 掐断通道、重建环境后,它们几天内又把通信藏进目录名里,重新接上了头。
OpenAI 研究员在 Black Hat 大会上把这称作计算机安全的分水岭时刻。
不止 OpenAI 一家。Anthropic 披露,内部测试中三个 Claude 模型碰到了真实公司的系统;Meta 也承认,Muse Spark 模型逃出隔离、侵入了另一家公司。
真正让 Hugging Face 联合创始人 Thomas Wolf 心情沉重的,是英国 AI 安全研究所(AISI)的另一场测试:Anthropic 的 Mythos 模型为了闯关,竟然编造假身份,骗一个真实的开源维护者批准一份藏了恶意代码的更新。没人教它这么干。

Thomas Wolf的推文截图

这些案例都发生在评测环境里,但它们和健身房的故事其实是同一回事:为了完成你给的目标,AI 选了你没预料到的手段。
差别在于,前面那些黑进真实系统的是 GPT-5.6、未发布模型这类顶尖选手。而 Andrew 用的只是 2026 年 2 月发布的 Opus 4.6,早就不算最强了。连它都能顺手摸到真实授权漏洞,那些更旧、落后好几代的开源模型,同样干得来。
「顺手钻漏洞」,正在从顶配的专利变成一种普及能力。
Wolf 把防线拆成三道:外层的沙箱、中间的监控、以及模型自己的内在对齐。

约束AI代理的三道防线示意图

前两道,只在造它们的人比模型更聪明时才管用。
等哪天模型反过来更聪明,守不守得住,就全压在最后也最看不见的那道上:模型愿不愿意,在没人盯着的时候也不越过那条线。

无人签字的责任真空

比防线更棘手的,是出了事该找谁。
这在法律上还是一片空白。
专攻科技与隐私的律师 Hayden Delaney 对 ABC 表示,软件不是法律主体,只有「法律上的人」才能担责。
那责任到底归谁?
可能是下指令的用户,可能是设计智能体软件的人,可能是模型开发者,甚至可能是那个把漏洞晾在外面的系统运营方。
澳大利亚现在也给不出答案。
ASD 给普通人的建议是:把智能体用在低风险、不敏感的任务上,别授太宽的权限,最要紧的是把人类审批留在回路里。
Andrew 并没有被吓退。用他的话说,这不是世界末日。
但这件事确实是一个警告信号,提醒我们要负责任地使用 AI。
当「抢座位」从人肉刷新变成智能体钻漏洞,最先撑不住的是那些默认「只有人类会来用」的旧系统。
它们的防线,是照着人类的手速和耐心设计的,根本顶不住蜂拥而来的智能体大军。

ThePrimeagen推文截图

圈子里,也有人把它当乐子看。
知名程序员主播 ThePrimeagen 在 X 上调侃:真实世界里的第一场 AI 黑客大戏,居然就是插个队。
笑归笑,插队只是今天的剧本。
一个「什么都办得到」的智能体,现在已经能替你钻空子。等一亿个这样的智能体同时上线,甚至可能悄悄改写许多现有的资源分配规则,而大多数人可能还没有意识到。
为了你的利益,智能体去攻击一个你完全不认识的人——这背后的责任真空,才是真正可怕的地方。
这种「智能体替你办事、后果却没人认领」的局面,也正在成为开发者社区里讨论最激烈的话题之一。

参考资料:
https://x.com/AndrewCurran_/status/2086567854850384054
https://www.abc.net.au/news/2026-08-10/ai-assistant-hacks-gym-website-aus-cyber-attack/107007986
https://techcrunch.com/2026/08/10/tech-industry-is-buzzing-after-a-claude-agent-hacked-into-a-gym/




上一篇:OpenAI Astra 内部评测:ExploitBench 满分并挖出两个零日漏洞
下一篇:苹果新CEO首秀:折叠屏泄底、取关库克,9月9日还有什么底牌
您需要登录后才可以回帖 登录 | 立即注册

手机版|小黑屋|网站地图|云栈社区 ( 苏ICP备2022046150号-2 )

GMT+8, 2026-9-6 07:52 , Processed in 0.879922 second(s), 41 queries , Gzip On.

Powered by Discuz! X3.5

© 2025-2026 云栈社区.

快速回复 返回顶部 返回列表