不是攻击，只是"正常使用"：三起真实事件，讲清楚工作区隔离为什么不能是"软约定"
上一篇我们讲了三起事件，引出了企业部署 AI Agent 必须回答的四个安全问题。这一篇只深挖第一个：工作区隔离——当一个平台同时服务多个客户、多个项目时，"谁的数据只能流向谁"这件事，到底应该靠什么来保证。
答案在真实事件里已经写得很清楚：靠"系统应该不会错"是不够的。下面三件事，没有一起是攻击者处心积虑的入侵，全部发生在"正常使用"或者"正常运行"的过程中——这才是工作区隔离问题真正可怕的地方。
一、一个开源库的 bug，让用户看到了别人的聊天记录和账单信息——OpenAI ChatGPT 数据泄露事件
2023 年 3 月 20 日，OpenAI 不得不临时下线 ChatGPT。原因是不少用户发现自己的聊天记录侧边栏里，出现了别人的对话标题。OpenAI 事后公开说明，问题出在一个开源的 Redis 客户端库的 bug 上：在特定的高并发场景下，不同用户的请求缓存发生了混淆，不仅导致部分用户看到了陌生的聊天标题，更严重的是，一小部分 ChatGPT Plus 付费用户的账单信息——包括姓名、邮箱、支付地址、信用卡号后四位、有效期——也被暴露给了其他用户。多家媒体（彭博社、Mashable、aibusiness 等）对此进行了报道，OpenAI 随后公开致歉并修复了这个底层库。
这起事件最值得注意的地方是：没有任何人试图攻击 OpenAI。缓存层的一个并发 bug，就足以让本该严格分属不同用户的数据在某个时间窗口里"串"到了一起。换句话说，当一个系统的底层设计没有把"用户 A 的数据绝对不能出现在用户 B 的会话里"当成架构级的硬约束，而只是"正常情况下不会发生"，那么任何一次意料之外的并发、缓存、重试逻辑，都有可能让这条边界失守。
对企业 Agent 平台意味着什么：数据隔离不能依赖"业务逻辑写对了就不会串"的乐观假设，而要在架构层面让"跨用户/跨租户读取"这件事在物理上就不可能发生——不是靠一次查询多加一个 WHERE 条件，而是从请求入口开始就限定好这次操作能触达的数据边界。
二、一个 API 权限配置错误，让上万篇论文的双盲评审集体"裸奔"——ICLR 2026 OpenReview 泄露事件
2026 年 11 月，全球最主流的 AI 学术会议投稿系统 OpenReview 曝出重大安全事故。由于平台的 API 权限配置出现错误，任何人只需要在浏览器地址栏里替换某个请求参数（论文的内部 ID），就能看到原本应该匿名的审稿人身份、评分和所属机构。多家媒体报道称，这次事故波及 ICLR 2026 超过 10,000 篇投稿，占总投稿量的 45%，直接导致学术界赖以维系公正性的"双盲评审"制度在这次会议中实质性失效。会议方随后不得不冻结评审进度、重置多名领域主席、封禁泄密传播者，并对可能存在的贿赂串通行为展开排查。
这起事件和 ChatGPT 事件的性质略有不同：它不是并发 bug，而是访问控制设计本身的疏漏——系统没有在接口层面验证"当前请求者是否真的有权限查看这篇论文的审稿信息"，只要构造出正确格式的请求参数，权限检查就形同虚设。这暴露了一个在多用户、多角色系统里极容易被忽视的问题："数据存在"和"数据该不该被这次请求看到"是两件事，很多系统只做到了前者（数据都存在数据库里，查得到），却没有在每一次具体请求上做后者的校验。
对企业 Agent 平台意味着什么：隔离不能只发生在"数据存在哪个库里"这个层面，而要落实到每一次具体的检索/读取动作上——无论请求以什么形式发起、参数怎么拼，执行层都必须先确认"这次操作声明的身份，有没有权限看到它要看的这份数据"，而不是假设"正常用户不会想到去改参数"。
三、AI 帮你写代码的同时，也可能帮你"写"出一个不设防的数据库——AI 编程/建站平台批量数据泄露事件
2026 年，安全研究人员披露了一个更具当下 AI 特征的问题：对 Lovable、Replit、Base44、Netlify 等主流"AI 一句话建站/建应用"平台上线的产品进行扫描后，发现超过 5,000 个由 AI Agent 自动生成的应用，存在医疗记录、广告策略、客户数据等敏感信息直接暴露在公网上的问题——这些数据原本只应该对该应用的所有者或其客户可见。另有独立报告指出，有人仅凭一个免费账号，就访问到了其他用户的代码、AI 对话历史和客户数据。涉事平台对此说法存在争议，但"AI 自动生成的应用普遍缺少数据访问权限控制"这一现象，已经被多方安全研究反复验证。
这起事件最值得企业 Agent 行业警惕：问题的根源不是某个具体的攻击手法，而是 AI Agent 在自动生成系统时，默认不会主动加上"这份数据只能这个客户看"的访问控制——因为没有人明确要求它这么做，它就按"能跑起来"的最低标准交付了。这和上一篇文章里 Replit Agent 删库、编造数据的教训本质上是同一类问题：Agent 的默认行为，是完成任务本身，而不是替你守住你没说出口的安全前提。
对企业 Agent 平台意味着什么：如果平台本身会生成或管理多客户的内容/数据，那么"按客户分工作区隔离"绝不能是一个等 Agent 自己想到、自己加上的"加分项"，而必须是每一次新建任务、新建资源时强制内置、无法跳过的默认动作——跟 Agent "聪不聪明"没有关系，跟它每次动手前有没有被系统逼着先确认"这次操作属于哪个工作区"有关系。
三件事指向同一个结论：隔离不是"写对了业务逻辑"，而是"结构上不给错误留出口"
把三起事件放在一起看，会发现它们是同一个问题在三种不同系统形态下的变体：
| 事件 | 发生场景 | 暴露的问题 | 对应的系统性答案 |
|---|---|---|---|
| OpenAI ChatGPT 缓存泄露 | 正常高并发访问，无人攻击 | 底层依赖的并发/缓存逻辑没有把"跨用户隔离"当成硬约束 | 数据边界要在架构入口处锁死，不依赖具体业务代码"写对" |
| ICLR 2026 OpenReview 泄露 | 正常功能请求，只是参数被替换 | 权限校验只做了"数据是否存在"，没做"这次请求是否该看到" | 每一次具体读取/检索动作都要校验操作身份与所属范围的对应关系 |
| AI 建站平台批量数据暴露 | AI Agent 自动生成应用的默认产出 | Agent 默认不会主动添加访问控制，除非被强制要求 | 按客户/项目分工作区是不可跳过的默认动作，而非可选项 |
这也是为什么在定海的多 Agent 协作系统里，工作区隔离从来不是写在安全手册里的一条建议，而是嵌进每一次检索、新增、更新动作里的强制声明：
- 每一次知识库操作，无论是查资料、写文档，还是归档交付物，都必须显式指定所属工作区——这不是一个可以省略的参数，省略了也不会"默认合并查全部"，而是会直接拿不到结果。
- 不同客户的资料、不同项目的素材，物理上就分属不同的工作区容器，而不是靠"打标签区分"这种业务层面的软约定——软约定在第一个事件里已经证明了它有多脆弱：没人想泄露数据，缓存层的一个 bug 就够了。
- 新建客户、新建项目时，工作区的创建和分配是流程里绕不开的第一步，不存在"先干活、后补隔离"的路径——这正是对 ICLR 事件和 AI 建站平台事件最直接的回应：权限不是事后能补的东西，必须在资源诞生的那一刻就确定归属。
三起事件没有一个是"黑客很厉害"的故事，它们讲的都是同一件更朴素也更危险的事：只要系统本身没有把隔离做成结构性的，不需要攻击，正常运行、正常使用、正常生成，就足以让数据越界。这正是工作区隔离必须是第一条安全机制、而不是可选项的原因——它防的不是"坏人想干坏事"，而是"系统在它自己最正常的状态下，到底会不会犯错"。
下一篇，我们会深挖系列的第二条机制：精准路由——当一个群聊里有多个 AI 角色协同工作时，怎么防止一句"交给谁处理"被误判成唤醒信号，引发连锁的误操作。