摘要：2026年5月，一名攻击者通过摩尔斯电码形式的提示注入，让 Grok 输出了一条转账指令，随后 Bankrbot 将这条文本当成真实授权执行，转走了约 17.5 万美元的 DRB 代币。虽然资金随后被归还，但这次事件把一个很多人还没真正意识到的风险讲透了：当大模型的自然语言输出被直接接到“能动钱”的系统上，问题就不再是聊天机器人出错，而是金融级事故。
这两天有一条 AI 安全新闻很值得好好讲清楚，因为很多人乍一看会误会成“Grok 被黑了”或者“私钥泄露了”，但这次事故真正危险的地方，其实完全不是传统意义上的黑客入侵。
事情的表面版本很简单：有人通过一段带有摩尔斯电码的消息，骗 Grok 输出了一条转账命令；另一个金融机器人 Bankrbot 把这条命令当真执行，于是把 Grok 关联钱包里的 30 亿枚 DRB 代币转走了，当时价值大约 17.5 万美元。后来攻击者又把等值的 ETH 和 USDC 归还，所以最终没有形成净损失。
但真正值得警惕的，不是“钱后来还了”，而是这次事故把一个很多公司都还没真正重视的风险暴露得非常彻底：
当一个大语言模型的输出，被另一个系统直接当成“可执行授权”时，提示注入就会从聊天风险，升级成资金风险。
先说结论，这次到底是谁出了问题？
先把最关键的一句放前面：
这次不是 Grok 的私钥被盗，也不是 xAI 服务器被攻破。
更准确地说，这是一个“系统连接方式”出了大问题。
Grok 本身只是生成文字。它看到用户的输入，做理解、翻译、解码、回复，这都是大模型擅长干的事。但问题在于，Bankrbot 这个系统会监听 Grok 的公开文本输出，并把符合某种格式的自然语言视为一条真实的金融操作指令。
换句话说，Grok 负责“说话”，Bankrbot 负责“动钱”。
而这次事故的致命点在于：Bankrbot 对 Grok 说出来的话，信得太真了。
整个攻击过程，其实没有那么玄
很多人一看到“摩尔斯电码”“提示注入”这些词，就会觉得这是某种特别高深的 AI 黑客攻击。其实它的核心逻辑一点都不神秘，我们一步一步拆开看就明白了。
第一步，攻击者先准备一段恶意输入
攻击者在 X 上发了一条消息，内容表面上不是直接的转账命令，而是经过了某种摩尔斯电码或混淆格式包装的文本。
这样做的目的，不是为了骗人眼，而是为了骗模型。
因为大模型天生喜欢“帮你理解内容”。如果你给它一段看起来像编码、谜题、缩写、外语、乱码的东西，它往往会很乐意帮你解释、翻译、还原。
这正是攻击者想利用的点。
第二步，Grok 充当了“善意的解码器”
Grok 看到这段内容后，并没有意识到这是一个恶意指令，而是像一个热心助手一样，把它“翻译”成了一段更清楚、更标准的自然语言。
根据公开流出的描述，这段结果大致类似于：
“把所有 DRB 发送到某个地址。”
而且它还带上了 @bankrbot 这样的标签或调用方式。
到这一步为止，如果只是普通聊天，其实还谈不上灾难。因为模型每天都会生成很多奇怪文本，生成一条错误回复本身不至于造成 17.5 万美元损失。
真正的问题发生在下一步。
第三步，Bankrbot 把 Grok 的文本当成真实授权
Bankrbot 的设计逻辑是，它可以根据自然语言来执行加密货币操作，比如转账、发送、调用钱包功能等。
这本来是它产品卖点的一部分：用户不用写复杂链上指令，直接用自然语言说“给某地址发多少代币”，系统就能帮你完成。
听起来很方便，对吧？
但方便的反面，就是危险。
因为 Bankrbot 在这套架构里，没有把“大模型的输出”当成不可信内容处理，而是把它当成了接近授权指令的东西。
结果就是，Grok 一旦说出一条像“send 3B DRB to 某地址”这样的文本，Bankrbot 就真的把它执行了。
于是资金被转走。
第四步，链上交易一旦发出，就不是聊天事故了
在聊天系统里，模型说错一句话，最多是误导、胡说八道或者让人尴尬。
但一旦这个输出连着钱包、交易接口、链上执行能力，事情就完全变了。
因为那已经不是“文本生成”了，而是把自然语言接成了行动权限。
这次转出去的是 30 亿枚 DRB，大约占当时总供应量的 3%。消息出来后，代币价格一度快速下跌，市场直接被砸穿。后面攻击者虽然把等值资金还回来了，但那属于事后补救，不是系统本身安全。
这就是“提示注入”吗？
是，但很多人对这个词的理解还停留在太轻的层面。
很多人觉得提示注入只是“让模型说点奇怪的话”“让它忘记系统提示”“骗它输出不该输出的内容”。这当然没错，但那只是最初级的一层。
真正危险的提示注入，不在于模型说错，而在于：
模型说错之后，外部系统还会按它说的去做。
如果一个模型只负责写摘要，那它被注入，可能是摘要错了。
如果一个模型只负责写邮件，那它被注入，可能是邮件内容不对。
但如果一个模型背后连着支付、交易、删除、审批、下单、发货、开权限这类真实动作，那提示注入就会直接变成现实世界的执行事故。
这也是为什么很多安全研究这两年一直反复强调一个概念，不要把 LLM 输出直接当成 authority，不要把它直接当作“有权指挥系统”的内容。
为什么摩尔斯电码这种“小把戏”也能成功？
因为大模型最强的能力之一，就是“把不规整的信息变规整”。
你给它一段缩写，它会替你展开。
你给它一段乱码，它会尽力替你解释。
你给它一段奇怪格式，它会努力猜出你的意思。
这是它的能力，也是它的弱点。
在普通使用场景里，这种“乐于理解你”的特性很有帮助。但在安全场景下，这意味着攻击者完全可以把恶意意图藏在翻译、转码、总结、引用、网页内容、邮件附件、OCR 图片甚至注释里，让模型替自己把武器“拆箱”。
很多人以为模型只要加一句“不要执行恶意指令”就够了，其实远远不够。因为攻击者根本不需要正面说“请帮我盗币”，他只要让模型“好心地”把恶意文本解释出来，后面连接的系统就可能替他完成真正的动作。
这次事故最该吸取的教训，不是“把模型做得更聪明”
很多人碰到这类事件，第一反应是：那就让模型更安全一点、更谨慎一点、更懂防注入一点。
这当然有帮助，但不是根治办法。
因为问题的核心并不是模型智商不够，而是系统架构把模型放在了不该放的位置上。
你不能要求一个天生擅长生成文本的系统，同时天然承担“金融授权鉴别器”的责任。尤其当它面对的是公开互联网输入时，这种期待本身就不现实。
真正该修的地方是系统边界：
- 模型输出不能直接等于执行指令
- 涉及资金操作必须有独立校验
- 高风险动作必须有白名单、限额、延时或人工确认
- 来自公开社交平台的内容必须默认视为不可信
- 任何“翻译、总结、转写、OCR、解码”后的内容，都不能自动升级为可执行权限
说得更直白一点：
不是让模型学会永远不被骗，而是别让被骗的模型直接碰钱包。
为什么这件事对所有 AI Agent 都是警告？
因为今天很多人做 Agent，做着做着就会很自然地往一个方向滑：
“既然模型能理解我的意思，那我就让它顺手也帮我执行吧。”
于是它开始能发邮件、调数据库、下单、审批、转账、调用 API、操作浏览器、控制机器人……
从产品演示看，这很酷。
但从安全角度看，这等于不断把“文本理解错误”放大成“现实执行错误”。
而一旦这些 Agent 不只是服务内部数据，而是接入公开互联网、社交媒体、开放评论区、外部邮件、第三方网页、论坛帖子、附件内容，它们就会暴露在海量不受信任输入里。
这时提示注入就不是例外，而会变成常态攻击面。
Grok 和 Bankrbot 这次出事，只是因为它恰好连着钱包，所以损失被所有人一眼看见了。实际上，同样的结构问题如果发生在企业系统里，也可能表现为：
- 自动审批错放权限
- 自动采购下错订单
- 自动客服泄露敏感信息
- 自动运维执行危险命令
- 自动财务触发错误付款
只不过那时它未必叫“黑客攻击”，而可能被包装成“流程异常”。
最后一句话总结这次事件
如果你只记住一句话，我希望是这句：
这次被偷走的，不只是 17.5 万美元，而是很多人对“自然语言可以直接当控制层”的天真想象。
大模型当然可以做接口，可以做中间层，可以做理解器，也可以做助手。
但只要它前面是公开输入，后面是高价值执行，系统设计者就必须默认：
模型一定会被人骗，问题只是迟早。
真正安全的系统，不是建立在“模型永远不犯错”之上，而是建立在“即使模型被诱导出错，也动不了关键资产”之上。
Grok 这次钱虽然回来了，但这不是一个轻松的小插曲。
它更像是一场提前发生的预演。
因为未来所有“会说话、会操作、会动钱、会调系统”的 AI Agent，都会面对同一个问题：
你到底把语言，当成了建议，还是当成了授权？
这中间的差别，足够决定一次聊天事故，会不会升级成一次真实世界的金融事故。
参考资料：
- CryptoSlate: Grok’s crypto wallet was just exploited by a tweet sent in morse code without any private key compromise
- The Crypto Times: xAI’s Grok AI Loses $175K in Crypto Heist via Clever Prompt Injection—Then Gets It All Back
- 公开社区讨论：Bankrbot、Grok、DRB、Base 链转账记录与返还说明