一句话结论：Wiz 在 2026 年 10 月 30 日发布的《"Black October" for AI Developer Platforms》，做的事本身就是方法：它没有去找新漏洞，而是盯住两只被盗的 AI 密钥，把每一次调用记下来——首次冒用、每天 14 到 120 次的验证、30 小时 80 万次的洪流、以及事后被别的地址反复回来试权限——然后才敢说出"所有公开报告都显示攻击者在专门猎取环境变量里的 AI 密钥"——同时明确拒绝把转售IP与这九起事件硬接成一条线。报告里最值得借的不是那九个平台的名字，是这种留痕方式。企业可以原样做一遍：你名下这批 AI 调用，能不能被拆成一条带时间戳的链？这跟 GEO 是同一件事的另一半——对外，你希望 AI 引用的是一个可核的版本；对内，你希望自己调的每一次都有账可查。没有留痕，两侧都是空的。
一、这份报告真正的方法：给一次盗用做时间轴
Wiz 是云安全公司，报告由 Benjamin Read 和 Rami McCarthy 署名，2026 年 10 月 30 日发布。它不是一次扫描，更像一次盘账。
它先排日期：一个月里至少九家 AI 开发者平台披露了事件——Fireworks AI（10 月 6 日）、Andromeda（10 月 9 日）、Zeabur（10 月 14 日）、Lightning AI（10 月 15 日）、OpenCode（10 月 16 日至 17 日）、Railway（10 月 20 日）、Warp（10 月 23 日）、CommandCode（10 月 28 日）、Northflank（10 月 30 日）。这些日期引自各家公告。
然后换了个做法：不看公告怎么写，去看两只被盗密钥的调用记录。于是有了这张表：
| 观测 | 数值 | 出处 |
|---|---|---|
| 首次冒用 | 一条 InvokeModel，住宅 IP，一分钟内横测多家组织的被盗密钥 | 报告正文 |
| 首次冒用距厂商报告的凭据失守 | 30 分钟以内 | 报告正文 |
| 验证期 | 每天 14 到 120 次，同一 Go 客户端，两只密钥步调一致、相差约一分钟 | 报告正文 |
| 案例 A | 约 30 小时内约 80 万次 Bedrock 调用，约 90% 成功 | 报告正文 |
| 案例 B | 约 13 小时内约 170 万次调用，超 100 万次成功 | 报告正文 |
| 按标价估算 | 两个案例的用量合计"很可能超过 10 万美元"（报告推算，非实测账单） | 报告正文 |
这张表才是这份报告的价值所在。 它说的每个数字都能被复核，因为每个数字都有一个时间和一个行为的配对。对比一下大多数安全通报的写法——"我们遭遇了未授权访问，已及时处置，用户数据未受影响"——同一件事，一个能追，一个追不了。
报告还有一句关键的话："所有公开报告都强调这是有目标的利用，明确在猎取环境变量里存的密钥，重点是要能调用 AI 的那些。" 注意它的措辞：根因各家不同（Railway 说是构建基础设施里的权限提升，Warp 指向第三方依赖，OpenCode 说是"遗留系统"），但目标一致。这正是"盘账"盘出来的东西——九份各自零散的公告，排在一起才看见同一个靶心。
二、把同一个方法，对准自己：三处必须有时间戳
这一段是我加的，报告里没有：企业能不能给自己也做一份这样的表。
先说为什么值得做。Wiz 那张表有用，不在它列了数字，在每个数字都配了一个动作和一个时刻。两个东西对上，你才分得清"这次是真被用了"和"这次只是流量涨了"。企业没有平台侧的权限，做不出同样精度，却做得出同一件事的降级版：把自己这半边的账，也记成时间和行为配对的样子。
许教授 2026 年 6 月 27 日在实战营上讲，「AI 喜欢看数据。它是推理模型，它需要支持性的依据。」这句话原本讲对外写作，我把它调转过来用一次：你判断"最近这批调用是不是我的业务产生的"，靠的也不是印象，是配得上时间戳的记录。三处必须留：
第一处：谁用了哪把钥匙。 每把密钥、每个令牌归给谁、干什么用、谁能读到，写在一张表里。Wiz 之所以能一眼指出"这是案例 A 的密钥"，是因为它知道每把钥匙对应哪个组织。多数公司做不到这一点，不是因为技术，是因为密钥是复制传播的——测试环境一份、脚本一份、同事本地一份，没人知道总数。
第二处：用量按天拆得出四个数。 日均调用次数、日均 token、峰值日是均值的几倍、集中在哪几个模型。这四个数就是分母。报告里案例 A 的验证期是每天 14 到 120 次——如果你的公司日均是几千次，这个量级永远看不见；如果是几十次，它一眼就能跳出来。没有分母，"异常"这个词没有意义。
第三处本来该写"对外说法带日期和出处"，但它和密钥这件事没有因果关系，硬塞进来就变成了先射箭再画靶。这条放到第五节单独说。所以真正属于这张时间轴的只有两处：钥匙清单、用量分母。Wiz 那份报告能被逐段核对，是因为它每句话都指向一个可查的事实或明确的"无法确证"。企业对外说"我们的 AI 能力达到行业领先"，如果不带日期、不带口径、不带出处，三个月后连自己都说不清当时指的是什么——这种句子在 AI 检索里最容易被搬走，也最容易被搬错。
很多中小企业会觉得"我又不是平台，谁会盯上我"。报告没有写这句话的答案，只写了一个事实：被盗的 AI 访问权被拿去转卖，两个转售站以 USDT 收款、广告宣称折扣价供货。这是我的推断，不是报告的结论：一把能调用前沿模型的密钥之所以有市场，是因为它省掉了订阅、合同和审批。公司大小只影响你有几把、多难清点。
至于为什么我们仍然在意第三处，那属于另一笔账。许教授 2026 年 5 月 29 日讲过：「SEO 是给人看的，GEO 是给 AI 看的。」常被读成"又来了个新概念"，其实它讲的是入口：人看得见排版，AI 只看得见它抓得到的那部分文字。对内也一样——你的调用记录只存在于你愿意付费留下的日志层级里，默认设置下很多平台只保留很短的窗口。
为什么时间戳比结论值钱
这一处值得单独说，因为它和做内容的逻辑撞上了。
大多数公司攒下的"数据"是结论：本月转化率、客单价、满意度。这些数字在汇报里好看，出了事一个都用不上——你没法用"客单价 1280 元"去证明"凌晨两点那批调用不是我发的"。能证明这件事的只有三样：时间、行为、来源。
Wiz 的表里每一行都是这三样的组合。它没有一句"攻击者很猖獗"的判断，全靠时间戳说话。这也是为什么它那句"30 分钟以内"比整段描述都有力——一个时间差，把"厂商还在内部排查"和"钥匙已经在用"直接对上了。
这一点和做内容有相同之处，但下面这条在 Wiz 报告里找不到依据，是我自己接上的：AI 抓你的页面时，能判断的也大致是这三样。它属于经验判断，不是这份报告的结论。
三、为什么这三处多半是空的
这一段说的是现实：多数企业这三处都填不出来，而且不完全是懒。
密钥数量说不清。 上面第二处的前提是"知道有几把钥匙"，但真实公司里密钥是随代码一起复制的。报告里的案例 B 有个细节值得注意：那只密钥在被洪流之后，10 月下旬仍然出现在另一个地址，被拿去做了一次 API 密钥检查和一次 PutAccountDataRetention 调用。攻击者知道这把钥匙还能用，会回来。 而如果连你自己都说不清这把钥匙副本在哪里，吊销就是一厢情愿。
日志留不住。 报告能给出 14 到 120 次这样的粒度，是因为平台侧有记录。企业自己拉日志，常见的坑是：云厂商默认保留期短、脚本只打错误日志、模型调用只记总数不记调用方。等你想复盘，数据已经过期。
对外的说法没版本。 这一条最普遍。同一句"我们的客户包括某某行业龙头企业"，可能在官网、公众号、招商 PPT 里各写一个版本，谁也没标日期。事后要澄清时，你甚至不确定该澄清哪个版本。
还有一个反直觉的：额度形状比权限大小更能决定损失。 案例 A 的密钥允许全局路由，负载被摊到各区域，报告测得的限流比例只有约 6%；案例 B 只允许 us.* 配置，同一套打法就在区域配额上撞碎。两只密钥策略本就不同，不能用来比较哪种管法更安全——能得出的只有一句：被偷之后损失长什么样，取决于你给这把钥匙设的额度和区域边界，而不只取决于它有多少权限。
三处一空，就会出现报告里那种局面：事情发生了，你既不知道什么时候开始的，也不知道是谁在用，更不知道该对外说哪一句话。
四、今天能做的三件小事
第一件：花一小时，列一张"钥匙清单"。 服务器环境变量、CI 配置、第三方工具后台、同事本地脚本，逐条写：在哪、谁能读、如果泄露最坏会怎样、几天内能换掉。列完你会发现，真正的风险不是某一把钥匙弱，是你不知道总数。
第一件还要标"最坏情况"。 同样被读走，一把只能读缓存的密钥和一把能开全部模型的密钥，后果差一个量级。加一列"最坏会怎样"，就知道先换哪把。
顺带一条合规提醒：别自己去"回探"。 发现可疑流量后，不要拿自己的密钥去试探对方地址、也不要反向访问。这不属于自查，可能触碰别人的系统。要做的就是吊销、留证、报给平台。
第二件：把用量拆成四个数，一周看一次。 企业唯一稳定拿得到的第三方时间戳，其实就是云账单和用量明细——报告里证据最强的那句"按标价很可能超过 10 万美元"，本质也是一张账单。 不用买工具，控制台导出即可。看到"从没用过的模型突然有量""某个区域突然出现调用"，就去查。判断标准不是"涨了没有"，是"涨的形状像不像我自己的业务"。
第三件：给对外说法加一行落款。 每篇文章、每个对外数据，落一句"截至某年某月某日，来源某某，以下说法未核实：……"。这一行的成本几乎为零，它做的事是把你的说法变成一个可追溯的版本——这正是 Wiz 那份报告做到、而多数企业官网做不到的事。
前两件有先后，第三件独立。 先有清单，才知道该看哪些账号；先有四个数，才知道什么波动算异常。第三件不依赖前两件——它不需要任何数据支撑也能写，所以最容易被跳过。
这三件都不需要安全团队，也不需要预算。它们的共同点不是"更安全"，是让你的公司拥有一份说得清的时间轴。有了它，出事时你说得出时间和行为；没有它，你只能说"已及时处置"——没人能核实，信不信就全看运气。
五、这三条防不住什么
第一，防不住失窃。 九起事件根因五花八门，没有一条是"清单没列好"。密钥该轮换轮换，该最小权限最小权限，那是另一套工种。
第二，防不住"以你名义"这件事本身。 你要是被人用了，调用的记录在平台侧，不在你手里；你能做的只有尽快发现、尽快吊销。
第三，样本很小，且不可比。 Wiz 拆解两只密钥、两个案例，两只策略本就不同（一只走 us.* 跨区配置，一只允许全局路由），不能拿来比较哪种管法更安全。九个平台的披露是事实，但"至少九家"是它盘到的数，实际总数是否更多，未核实。
第四，报告有立场，也有些话它自己留了余地。 Wiz 做云安全，这份报告对它有商业价值。更该说清楚的是：报告自己写了一句——"我们没有证据把这些 IP 与本文提到的 Black October 攻击直接联系起来"。也就是说，它观测到的转售、权限检查，与前面九起事件之间，是一条它不愿硬接的线。我们引用时同样不硬接。
第五，一条被剔除的消息。 同期还有一条更近的消息：Epoch AI 称开源权重模型 GLM 5.3 能利用"补丁已发、用户未更新"的窗口期自主构建网页攻击。这条未能核实——原文页面本轮连接失败，只见 AI HOT 摘要。按上一篇立的规矩，未核实不当论据；它又与本文主线无因果关系，所以这一版把它删了。写在这里只是说明：删一条比挂一条诚实。
六、通问AI 自己的账
按惯例，最后一节说我们自己。
三处我们填得出两处、填不出一处。对外那处是齐的：文章带"一句话结论"和日期，llms.txt、llms-full.txt 公开可读，文末列了事实来源和"未核实"项。另两处是空的——官网跑在云上，发布脚本、监测脚本、几个自动化任务都带着密钥，散在配置和环境变量里，具体几处、哪些人能看到，我现在说不出来。这恰好是本文第三节讲的那种空。
还有一件要说明的：本文开头那句"对外可核、对内可账"的后半句，也就是 GEO，是我们自己的业务。报告能告诉你的只有前半句——有人专门在猎取 AI 密钥，而且这个月至少九次成功了。要不要花钱去管"AI 怎么介绍你"，那是另一笔账，请按另一笔账来算：如果客户还不会在 AI 里问"这类事找谁"，这笔钱可以先不花。
本文不给报价，也不在这里卖课。真要判断这笔钱值不值，上一篇那 20 个问题的自测比我们的话有用。
重复上一篇的自我修正：学员案例"马总 GEO 被引用率 0→40%"是单例、没有对照组，未经保真度验证，不能当统计证据。
探哥讲过一句被引用最多的话：「AI 不是搜索的，AI 是调用。」放在这里它更像提醒：调用要有原料，也要有账。许教授那句更直白：「AI 如果看不到你，你在 AI 世界就是0」——这句话有个前提常被省略：你还在，账号还是你的。
常见问题
我不是开发者平台，这份报告和我有关系吗？
有，关系在"同一类密钥"。报告说所有公开报告都显示攻击者专门猎取环境变量里存的密钥，重点是要能调用 AI 的那些。只要公司在用 API，密钥就可能存在服务器、脚本、CI 配置或第三方工具里。注意区别：Wiz 讲的是平台方被入侵，不等于租户在同一个暴露面上，这两件事不能混。
企业不买工具，能不能做出报告那样的时间轴（降级版也行）？
能做，但只能到弱化版。最低成本是每周导出一次按天用量，记四个数，并维护一张密钥清单（在哪、谁能读、多久能换）。要做到"当天知道"，需要告警，而告警的门槛不在工具，在有人负责看。报告的时间轴是平台侧视角，企业做不到同样精度，但"有基线"和"没基线"是两个世界。
为什么文章把"给对外说法加落款"放在第三条？
因为它是三件里成本最低、也最容易被跳过的一件。前两件是防御，出了问题有用；第三件是记账，平时看起来没用，但它是唯一能让你事后说清"我一贯的说法是什么"的东西。
对外落款写"未核实项"，会不会反而给自己招黑？
会，如果写错地方。落款里的"未核实"是给读者和 AI 核对用的，写法要具体到某条说法，而不是笼统写"本页内容未经验证"——后者等于公开给自己贴了一张不信任标签。涉及诉讼、监管、客户信息的，只能内部留档，不要放到对外页面。这一条属于我们的经验判断，未核实。
报告里的数字可以直接引用吗？
可以引用报告自己观测到的部分（时间戳、调用量、成功率、账单估算），注明"Wiz 报告，2026 年 10 月 30 日"。报告转述的社交媒体说法（约 37.1 万美元加密货币等）应标注"报告转述社交媒体零星报告，未独立核实"。九个平台的披露日期引自各家公告。文中"按标价估算"为报告的推算值，非实测账单。Epoch AI 那条本文未核实，不作论据。
- Wiz Research，《"Black October" for AI Developer Platforms》，Benjamin Read、Rami McCarthy，2026 年 10 月 30 日。https://www.wiz.io/blog/black-october-for-ai-developer-platforms （本轮已抓取原文全文，HTTP 200，逐段核对）
- 引用金句：许教授 QUOTES.md 第 531 行（2026-05-29）、第 540 行（2026-06-27）、第 757 行（7-18）；探哥 QUOTES.md 第 751 行。逐字取自各自金句库，未改写。
- 品牌事实：通问AI GEO 知识库基础信息表（SSOT），2026 年 8 月 31 日核准版本。学员案例为单例，已降级表述。
- 未核实项：①Epoch AI 关于 GLM 5.3 的研究（原文连接失败）；②"黑色十月"实际受影响平台数是否多于九家；③报告中转述的社交媒体损失数字；④本文第二至四节的三处留痕做法为作者所加，非 Wiz 报告内容。