你的需求文档，正躺在别人的服务器上：AI 开发平台的"黑色十月"

开篇：一周之内，三起平台级泄露

2026 年 10 月，安全厂商 Wiz 给 AI 开发平台领域起了个名字——"黑色十月"。

不是比喻，是实指：一周之内，三家主流 AI 开发平台接连出事。

先是 Zeabur。10 月 14 日到 15 日之间，攻击者通过该平台的私有配置仓库拿到了环境变量商店的访问权限，里面躺着明文 AWS 密钥、不过期的集群管理员令牌和明文 root 密码——等于直接拿到了整个客户环境的钥匙串。

紧接着是 PingCAP TiDB Cloud，账号记录和源码被公开暴露。

然后是 Andromeda，凭证失窃。

Railway、Lightning AI 在同一时间段也报告了安全事件。Fireworks、OpenCode、Warp 三家平台对外披露，他们正在追查一类前所未见的攻击形态——agent swarm，字面意思是"Agent 群"：不是人在攻击，是另一批 Agent 在打 AI 开发平台。

这件事该被每一家在用 AI 开发的企业认真对待。因为泄露的不是普通用户数据，是你的业务信息、技术资产和生产凭证——那些你喂给 AI 开发平台的每一段需求描述、每一行密钥、每一个架构决策，都躺在别人家的服务器上。

一、攻击形态变了，你还没跟上

这一轮事件最值得警惕的，不只是泄露本身，是攻击形态的升级。

过去 AI 开发平台的安全威胁，和传统云平台差不多——漏洞利用、权限配置不当、供应链攻击。但这一次，OpenCode 和 CommandCode 在事件报告里用了一个新词：蒸馏攻击（distillation）。

意思是：攻击者的 Agent 持续向平台发起大量请求，目标不是偷你的数据，是让平台替它免费炼模型。你的需求文档、代码片段、架构讨论——这些原本属于你的业务知识，被攻击者的 Agent 当作训练素材，悄悄"蒸馏"进了它自己的模型里。等你发现时，你的业务护城河可能已经在对手的模型里跑通了。

JetBrains Junie CLI 在 10 月 15 日披露的 CVE-2026-111091 更直接——漏洞存在于"项目的 MCP 配置文件"里。什么意思？只要你打开一个包含恶意 MCP 配置的项目，攻击者的代码就能在你的开发机上执行。AI 开发工具的攻击面，已经从平台层延伸到了你电脑上的每一个项目文件夹。

传统漏洞利用是"偷一把就走"，蒸馏攻击是"住着不走还把你家知识搬空"，MCP 配置漏洞是"进门的钥匙在你自己手里"——三种形态同时出现，说明 AI 开发平台的安全边界，比大多数企业想象的要模糊得多。

二、你的数据，到底在哪一层

要搞清楚风险有多大，先搞清楚你的数据在哪。

今天一家企业用 AI 开发，需求文档、API 密钥、业务逻辑这些东西，会落在三层里：本地环境（你的电脑、公司服务器）、AI 开发平台（Cursor、Copilot、Zeabur 这类 SaaS）、模型供应商（OpenAI、Anthropic、Google）。

黑色十月的事件，泄露面全部集中在中间那一层——AI 开发平台。Zeabur 的环境变量商店、TiDB Cloud 的源码、Andromeda 的凭证，全是平台侧的资产。

为什么这一层最脆？因为它天生就是"中转站"。你把需求文档喂给平台，平台转发给模型，模型返回代码，平台存一份。整个过程里，平台既是你的代理，也是你的仓库——但你对仓库里存了什么、存了多久、谁能拿到，通常没有完整的控制权。

画一张 AI 开发数据驻留地图，你会发现一个尴尬的事实：最敏感的东西——密钥、需求文档、业务规则——恰恰是在平台侧驻留时间最长、保护最弱的。模型供应商有合规压力，本地环境你自己能管，唯独中间这层，大家默认它是"安全的"，默认它"不会出事"。

三、三个自查问题，答不上来就该动了

黑色十月不是远在天边的行业八卦，它暴露的是一个通用问题：你的数据驻留方案，和你对风险的感知，是不是不匹配？

每家企业都该把这三个问题过一遍。

第一问：你的密钥怎么存？ 明文写在代码仓库里？存进平台的环境变量商店？还是有专门的密钥管理服务、有过期机制、有轮换策略？Zeabur 泄露事件里，最致命的就是那些"不过期"的令牌——拿到一次，永久可用。如果你的密钥也是常驻的，那平台出事那天，你出事的时间也被锁死了。

第二问：平台出事，你的什么跟着出事？ 想想平台侧存了你的哪些东西——需求文档、架构决策、用户数据片段、生产环境密钥、正在跑的 Agent 任务清单。把这些列出来，每一项乘以"泄露后的影响"，就是你对平台的真实依赖深度。

第三问：断网之后还能不能干活？ 如果 AI 开发平台突然断了、封了、被收购了，你的团队能不能继续写代码？需求文档在不在自己手里？代码生成能不能脱离平台？这一问看似极端，其实是在测你的"可替代度"——可替代度越低，平台出问题的代价越大。

三个问题全答不上来，或者答上来之后自己心里没底，那就该重谈部署方案了。

四、工程解法：按敏感度选层，不是一刀切

安全事件之后，最容易走的弯路是两个极端：要么"全不用了，退回手写代码"，要么"全私有化，把一切搬进内网"。前者不现实，后者成本太高。

实际可行的做法是分层保护，按敏感度选层。

第一层，最小化平台侧驻留。密钥不放进平台的环境变量商店，用专门的密钥管理服务；需求文档不存一份完整副本在平台，只存必要的上下文片段；项目配置里去掉不必要的 MCP 服务器定义。平台是中转站，不是仓库——让它干它该干的活，别让它替你保管家当。

第二层，代码本地生成。方案文档写好之后，在自己的电脑或内网服务器上生成代码，生成过程不经公网，代码从诞生那一刻就属于自己。实现细节不经过平台，平台替你管流程，但不替你管产物。

第三层，私有化部署。整栈进内网——文档、模型、生成链路全在自己的环境里跑。这层成本最高，但合规敏感的行业（制造、政务、医疗）别无选择。

三层不是互斥的。一家企业可以把通用需求放在第一层，核心业务走第二层，合规敏感的系统上第三层。关键是别把所有鸡蛋放在同一个篮子里，更别把篮子交给陌生人看管。

五、优创的答卷

对着这三层解法，我们把优创平台的能力逐条对了一遍。

文档是平台侧结构化存储，但支持私有化部署——客户可以选择把整套文档搬进自己的环境；代码生成走本地导出链路，方案文档导出后在客户自己的环境里生成，实现细节不经公网；我们不托管客户的密钥，所有密钥相关的操作都在客户侧完成。

也得如实交代一句：平台侧的文档结构化存储，在默认配置下是 SaaS 形态，客户的需求文档确实会经过我们的服务器。私有化部署能彻底解决这一层，但部署成本对小团队来说不低。今天我们能交付的，是"代码本地生成 + 密钥不托管 + 私有化可选项"这个组合，能不能满足你的安全诉求，取决于你的敏感度在哪里。

写在最后

黑色十月不是"别用 AI 开发"的理由，是"想清楚怎么部署"的理由。

这一周里倒下的三家平台，没有一家是因为"技术太烂"才出事——它们都是行业里被广泛使用的工具。问题出在：用户默认平台是"安全的"，默认它"不会出事"，但平台本身既没有足够的动力去加固，也没有义务去提醒你该怎么保护自己的东西。

把这篇文章看完之后，做一件事：打开你的 AI 开发平台，把它存了你什么列出来，然后重新审一遍你的部署方案。密钥要不要换个存法？哪些东西该搬回自己环境？哪些流程该脱钩？

平台出事之前没人通知你，但出事之后你该做什么，是可以提前想清楚的。

优创平台｜AI 驱动的"需求到代码"一体化开发平台

信源：Wiz《"Black October" for AI Developer Platforms》（Zeabur/TiDB Cloud/Andromeda 事件综述、Railway/Lightning AI 同期事件、agent swarm 攻击形态）；pranava0x0.github.io Vibe Coding 安全追踪站（Zeabur 明文 AWS 密钥与不过期集群管理员令牌、JetBrains Junie CVE-2026-111091 细节）；OpenCode 与 CommandCode 公开事件报告（蒸馏攻击归因）；JetBrains Junie CLI 26.8.3 之前版本漏洞公告（CVE-2026-111091，CVSS 7.8，2026-10-15）；同一事件报道口径不一致处，文中已并列标注；优创数据为平台实录。