共享上下文就是一份共享凭据

OpenAI 在 9 月 29 日交付的、后果最重的那样东西不是一个智能体。是一间屋子：ChatGPT Space——同事、ChatGPT、Codex 和一个常驻的 Dot 都从同一份上下文里读、也往同一份上下文里写。一份「多个主体可以写入、多个智能体会据以行动」的上下文，不是「一个文件夹外加一段聊天」——它是一份凭据，由大家共同持有，带着持有权限最多者的权柄，配着持有判断力最少者的判断。而摆在货架上的每一项权限控制，都对准了错误的边界。

一眼概览

DevDay 2026 带来了二十多项发布。其中四项组合成了一套架构，而改变威胁模型的是这个组合，不是其中任何单独的一块。

发布了什么	它是什么	为什么在这里重要
Dots	跑在 OpenAI 旗舰模型上的常驻智能体，每一个都配了自己的云端电脑和浏览器，可通过聊天、Slack 和 Teams 触达，并可连接数千个应用。	一个在没人看着时也在运行的智能体，带着持久状态和一个已登录的浏览器。「人在环中」这个假设是被设计掉的，不是被疏忽掉的。
ChatGPT Space	一个共享工作区，员工、ChatGPT、Codex 和 Dots 在同一份共享上下文上作业。	多个主体，一份上下文。这一部分在任何人已经部署过的权限模型里都没有先例。
Pages	一种为人与智能体共同撰写而设计的文档类型——文字、图表、图像、可视化。	一件同时既是输出、又是输入的可变制品。一个智能体写下的东西，下一个会当作上下文读进去。
Agents API 里的电脑操作	屏幕级的控制能力，现在对在平台上构建的开发者开放。	动作空间不再是一张工具清单。一个已登录的浏览器能够到的一切，现在都在范围之内。

这几样孤立地看，之前都在别处交付过。而这个组合——持久的自主执行、一份多写者的共享上下文，以及屏幕级的可达范围——没有；而一个组合的安全性质，并不是它各部分性质的交集。

把这套架构画成一个权限问题

五个写者、一个面，以及在右侧扇出的可达范围。被强制的边界在右边；真正起决定作用的那道在左边。

从右往左读，这个产品看起来很合理：每个连接器都有范围限制，每个动作都能归属到某个智能体，每个智能体都属于某个工作区。从左往右读，问题就显而易见了。五个写者把字节放进同一份存储。一个读者是一个自主进程，带着浏览器、文件系统和数千个应用授权。读取路径上没有任何标签说明哪些字节出自哪个写者，也没有任何机制会把「来自敌意来源的一段」与「团队负责人亲手打下的一段」区别对待。

这件事的一般情形，业界早有名字，而它在这个 wiki 上已经挂了好几个月：一个智能体的可达范围不是你挂上去的那张工具清单，而是「它能改变、且之后能被别的东西读到」的那批状态。共享上下文存储把它反过来了：一个写者的可达范围不是这个写者持有的权限，而是之后会去读他所写内容的那批智能体。

为什么「共享上下文」和「共享凭据」是同一句话

权柄取并集，判断力取交集

把四个成员和两个智能体放进一个 Space。这些智能体读 Space 里的一切，并以它们自己的授权去行动，而这些授权在实践中会被开成「覆盖团队集体所需」的样子。于是任何落进这份上下文的指令，能调用的有效权柄是这些智能体能力的并集——而把一条指令送进那里的门槛，是最不小心的那个成员的一次粘贴。权柄向上合成；谨慎向下合成。这就是共享凭据的定义性性质，也是安全行业花了二十年去消灭它们的原因。

写入路径相对于读者是未经认证的

工作区成员身份把写者认证给了平台。它并没有把写者认证给读者，因为读者是一个消费扁平上下文的语言模型——在那份上下文里，Codex 写的一段摘要、某人上传的一份 PDF，和一位外部协作者的评论，都是同一种对象。成员身份回答的是「这个人可不可以往这儿写」。而智能体需要被回答的问题是「我该多大程度上信任这一段」，而这个面上没有任何东西承载着答案。

持久性挪走了那个本来会察觉到的人

一个交互式助手做了怪事，是在某个人面前做的。一个按自己的节奏朝着常设目标工作的常驻智能体不是。把这一点和共享上下文叠起来，暴露窗口就不再是一次会话，而变成了文档的留存期：三月里写进一个 Page 的文字，到九月还在上下文里，还在被当成「指令形状」的输入读进去，还有能力去操纵一次没人在看的运行。

影响半径现在是组织级的，不是按用户的

真正要紧的失效不再是「一个智能体为它的用户做错了事」。而是「一个智能体为它的用户做错了事，因为另一个用户的输入里写了什么」。这越过了一条主体边界，意味着这次事件属于两个人，而审计轨迹谁都不属于——正是这种形状让归属之争变得昂贵。

五道边界，而真正要紧的那两道正是你买不到的两道

OAuth 授权范围对着错误的攻击很强。来源标注与出站控制对着正确的那一个很强，而两者在托管运行时上都拿不到。

按连接器的授权范围与按智能体的凭据都是确实不错的控制，而它们瞄准的是智能体自己主动发起的一次调用。它们对一次敌意粘贴几乎无话可说，因为粘贴不是一次调用——它是改变智能体选择去做哪些调用的文字，而那些调用全都在授权范围之内。成员身份比什么都没有要好，但它只挡住外部人，而那是错的威胁：在这套架构里，危险的写者通常是一位善意的内部人，正在转发一封供应商的邮件。

真正能起作用的是那两行——按块的来源标注（一个随每一段上下文一起移动、并据以限制智能体可对它做什么的标签），以及智能体自身运行时上的出站策略。两者都没被提供。来源标注要求平台把作者身份穿过摘要环节一路追踪下去，而那正是今天标签丢失的地方。出站控制要求你有能力去约束一个不由你运营的沙箱，而那恰恰是智能体拿到「自己的云端电脑」时你交出去的东西。

同一间屋子的三种读法

第二栏与第三栏之间的那道缝，就是全部的故事。

三栏都是准确的描述。产品那一栏是这项功能被售出的方式，也是用户会用来推理的方式；强制那一栏是平台实际会检查的东西；行为那一栏是攻击者据以做计划的东西。安全工作的内容，就是在组织架构仍然运行在第一栏上时，把你自己的心智模型搬到第三栏；而在这里，这一步具体就是停止问「这个智能体能做什么」，开始问「谁能让这个智能体去做」。

请注意第三栏没有说什么。它没说这套架构不安全，也没说 Space 不该用；共享上下文确实就是协作工作得以完成的方式，生产力那一面的论证并无争议。它说的是：信任的单位是这个 Space，所以这个 Space 才是需要一份授权范围的那个东西——而它现在拥有的唯一授权范围，就是它的成员名单。

如果你要往里面部署，该做什么

下面这些控制都不需要平台再交付任何东西。它们全都是关于「你如何组织这份工作」的决定。

给 Space 划范围，不是给智能体划。先决定「这个 Space 能够到的一切之并集」拥有多少权柄是可接受的，然后把智能体开到那个水平之下。一个信任域一个 Space——按客户、按团队、按敏感级别——代价是便利，买到的是唯一可得的那份收容。
把外部来源的材料挡在共享上下文之外。供应商邮件、厂商 PDF、抓取的网页和支持工单，都是攻击者撰写的文字。如果必须处理它们，就在一个没有可写连接器的 Space 里处理，并把结论人工搬过去。
把一个常驻智能体的写权限当成一份生产凭据。像审一个服务账号那样去审它：它能改什么，谁复核这次改动，撤销路径是什么。一个常设目标加上一个可写连接器，就是一条没有审批人的发布流水线。
给每个 Space 指定一个具名的人类所有者。不是创建者——是所有者，对它的成员名单和连接器集合负责，并且会在这两样开始变大时察觉。
记录写入，不只记录动作。平台审计日志记的是智能体做了什么。你还需要它读了什么、以及是谁放进去的，因为那是唯一能回答一次跨主体事件的轨迹。如果平台不给你这些，那就在你自己的系统贡献内容的那个点上记下来。
假定摘要就是载荷。任何压缩这个 Space 的东西——一份摘要、一个状态 Page、一份每日简报——都是一条敌意指令被洗成「看起来可信、且没有作者」的一段的地方。不要让一个摘要器的输出被读得比它最差的那份输入更有权威。

常见问题

这是在专门批评 OpenAI 的设计吗？

不是。2026 年所有交付协作式智能体工作区的厂商都有同样的缺口，因为「穿过摘要环节的按块来源标注」是一个未解问题，而不是谁选择跳过的一项功能。DevDay 之所以是最清晰的标本，是因为那几块——持久性、共享上下文和屏幕级可达范围——一起到来，而且是规模化地到来。

OAuth 授权范围不是已经解决了这个吗？

它很好地解决了另一个问题。授权范围约束的是一次调用可以做什么；它无法区分「智能体为它的用户选择的一次调用」和「智能体因为共享上下文里某一段话而选择的一次调用」。按构造两者都在范围内——这正是为什么范围被满足了，而结果依然是错的。

单用户智能体能避开这个问题吗？

它把问题降回到普通的注入情形，那里唯一不可信的写者是智能体去取的那些来源。那仍然是一个真实的问题，但一条指令能调用的权柄是一个人的而不是一个团队的，而且事件有一个所有者。多写者的情形在这两点上都严格更糟。

效果最大的最小改动是什么？

一个信任域一个 Space，而且任何摄入外部材料的 Space 里都不放可写连接器。它花掉的是便利，不需要任何平台功能，并且移除了那个让其余一切变危险的组合。

我怎么发现这件事正在出错？

不是靠内容检查。请留意「工具调用序列开始不像它这类任务通常产生的序列」的智能体，以及「对 Space 里没有任何成员撰写过的上下文块的读取」。两者都是行为信号，而两者都需要读取路径被记录下来——那正是你必须提前安排好的事。