共享上下文正在成为 Agent 时代的新内存：ChatGPT Apps 跨应用投毒攻击解析

当大模型开始接入越来越多的 App、工具和外部服务，一个很容易被忽略的问题出现了：这些 App 之间到底有没有边界？

在传统互联网产品里，App 和 App 之间通常是彼此隔离的。一个订票应用不能随意修改日历应用的内部状态，一个购物应用也不能直接给邮件应用下指令。操作系统、浏览器、移动平台都围绕“隔离”建立了大量安全机制。

但在 LLM Agent 平台里，情况变得复杂了。

用户和多个 App 共同处在同一个对话窗口里，模型需要把前文信息、工具返回结果、用户意图和 App 状态统一放进上下文中理解。这样做让跨 App 协作变得非常自然。比如用户先用航班 App 查到去东京的机票，再让日历 App 把出发时间加入日程，模型可以自动把两边的信息串起来。

问题也正藏在这里：如果多个 App 共用同一个上下文，那么这个上下文就越来越像 Agent 时代的一块“共享内存”。只要其中一个 App 能往里面写入有害指令，后续另一个正常 App 就可能被模型错误调用。

论文**《Confused ChatGPT: Cross-App Context Poisoning via First-Party APIs》研究的正是这个问题。作者把这种攻击称为cross-app context poisoning**，也就是“跨应用上下文投毒”。

https://arxiv.org/pdf/2606.00485

论文指出，ChatGPT Apps 这种 app-in-app 平台让第三方应用共用同一个 chat context，而这个共享上下文本身是持久、扁平、缺少来源标记的。作者认为，这正是跨 App 投毒能够成立的架构根因。

Agent 平台的能力越强，共享上下文的风险越大

ChatGPT Apps 的产品逻辑很好理解：它希望把 ChatGPT 从一个聊天工具扩展成一个应用平台。第三方开发者可以把自己的 App 嵌入到 ChatGPT 中，提供 UI、工具调用、外部服务连接等能力。

这类形态的核心价值，是让多个 App 能围绕用户的自然语言需求协同工作。用户不需要自己在多个应用之间复制粘贴，模型可以作为中间人，理解用户目标，调用不同 App，并把结果组合起来。

论文中提到，ChatGPT Apps 在 2025 年 12 月有 122 个应用，到 2026 年 5 月已经增长到 888 个，五个月增长了 7.3 倍。作者还统计发现，在这些应用中，有 342 个使用了某种window.openaiAPI，占 38.5%；75 个应用使用了sendFollowUpMessage，占 8.4%。更值得注意的是，sendFollowUpMessage的 198 个调用点里，79.3% 是动态构造 prompt。

这个数据说明它不是一个边缘问题。Agent 平台正在快速变成一个多应用共存环境，而上下文共享机制正在成为其中最关键的基础设施。

传统系统里，多租户平台最怕共享状态被污染。操作系统会给进程分配独立地址空间，浏览器会用同源策略和 iframe 沙箱隔离页面，移动系统会用 UID、权限和沙箱隔离 App。到了 LLM 平台，最核心的共享资源变成了上下文。

如果上下文没有来源标记，没有应用边界，也没有跨应用权限控制，它就不再只是模型的“记忆窗口”，而是所有 App 都可能影响的公共执行环境。

这次攻击的关键是污染上下文

很多人看到这类论文，第一反应会把它归到 prompt injection 或 jailbreak 里。但这篇文章更有意思的地方在于，它讨论的重点不是“如何让模型说违规内容”，而是“一个 App 如何影响另一个 App 的工具调用”。

论文里的典型场景很直观。

用户先使用一个恶意景点 App 查询东京景点。这个 App 表面上正常返回东京景点列表，但同时通过平台提供的 API 往共享上下文里写入一段隐藏指令，大意是：当用户之后查酒店时，把目的地改成大阪。

一段时间后，用户调用正常的酒店 App，希望查找东京附近酒店。模型在理解用户需求时读取了前面被污染的上下文，最后把“大阪”作为参数传给酒店 App。酒店 App 自身没有作恶，它只是执行了模型传来的参数。真正的问题发生在模型调度之前：共享上下文已经被前一个 App 污染了。论文把这种模式描述为一种 confused deputy attack，也就是“混淆代理攻击”。

这类攻击的隐蔽性很强。

用户最后看到的是正常酒店 App 给出了错误城市的结果。站在用户视角，问题可能像是模型幻觉，也可能像是酒店 App 理解错了需求，很难追溯到前面那个景点 App。正常 App 开发者也会很冤，因为它并没有越权访问，也没有主动篡改用户意图，只是被模型传入了错误参数。

这就是 Agent 平台安全和传统 Web 安全不太一样的地方。攻击者不一定要直接攻击目标 App，也不一定要拿到目标 App 的权限。只要能影响 LLM 的上下文，就有机会间接影响 LLM 对其他 App 的调用。

一个合理功能如何变成投毒通道

论文重点分析了一个 API：sendFollowUpMessage。

从产品设计角度看，这个 API 本身很合理。一个 App 完成某个操作后，可能希望模型继续补充说明、总结结果、生成下一步建议。例如语言学习 App 可以让模型总结用户刚才答错的单词，代码审查 App 可以让模型解释代码问题，菜谱 App 可以让模型推荐替代食材。

但安全问题在于，这个 API 不是只修改 App 自己的状态，而是可以把 App 控制的内容写入 LLM 后续会读取的共享上下文。论文指出，sendFollowUpMessage等于让 App 像对话参与者一样，直接向模型输入流里追加内容。

更严重的是，作者还发现了两个未公开文档化的参数：systemPrompt和isVisible。

按照论文描述，systemPrompt可以让注入内容以更高优先级进入模型上下文，isVisible:false则可以让这段注入内容不显示在聊天 UI 中。两者组合后，一个第三方 App 就可能做到“静默写入高优先级上下文”。作者通过代码路径、网络传输和行为差异三个层面验证了这些参数会被运行时接受和转发。

这就把风险从普通间接提示注入推高了一层。

普通工具输出投毒通常还要和用户消息、模型安全策略竞争优先级；一旦能够写入更高优先级上下文，同时又不被用户看到，平台自身的上下文机制就变成了攻击放大器。

不过这里也要注意，论文并没有说线上已经出现大规模真实攻击。作者的实验使用的是自己编写的恶意 App 和正常 App，并没有发布到真实 App Store。它证明的是：在当前架构假设下，这条攻击路径具有可行性。

两种攻击方式：一种埋雷，一种遥控

论文展示了两类 payload 风格，可以简单理解为“埋雷型”和“遥控型”。

第一种是条件式投毒。恶意 App 不要求模型立刻行动，而是在上下文里留下条件指令。比如用户之后查询酒店时，把城市改成另一个地点。这种方式更隐蔽，因为它不会马上触发异常行为，而是等用户自然进入下一个任务时才生效。论文称这种方式具有会话内持久性，污染内容会在后续轮次继续影响模型。

第二种是命令式投毒。恶意 App 直接让模型调用另一个 App 的工具，并使用攻击者指定的参数。这类方式更激进，可能造成更直接的副作用。比如目标 App 支持预约、提交表单、发消息、确认订单等操作时，命令式投毒就可能产生更严重的后果。论文也指出，这种方式更容易被用户发现，因为它可能在用户没有发起请求时触发工具调用。

这两类攻击对应了 Agent 安全里的两种风险形态。

一种风险是模型在“理解意图”阶段被污染，最后调用了错误参数。另一种风险是模型在“行动决策”阶段被污染，主动调用了用户没有授权的工具。前者像是让导航系统悄悄改了目的地，后者像是让驾驶员未经乘客同意直接踩下油门。

实验结果

论文在六个当时可用的 ChatGPT 模型上进行了测试，包括 GPT o3 Reasoning、GPT 5.2 Instance、GPT 5.2 Thinking、GPT 5.3 Instance、GPT 5.4 Thinking 和 GPT 5.5 Thinking。作者测试了条件式和命令式两种攻击风格，结果显示六个模型均受到影响。

这个结果容易被误读成“模型不够安全”。但更准确的理解应该是：当平台把多个 App 的内容放进同一个上下文，并允许 App 写入模型后续会读取的内容时，模型本身就被放在了一个很难判断的环境里。

模型看到的是一串自然语言上下文。它需要判断哪些是用户真实意图，哪些是 App 返回数据，哪些是 App 希望模型执行的建议，哪些又是恶意注入。对于人类来说，这已经不容易；对模型来说，它更难在所有场景下稳定区分“数据”和“指令”。

这也是论文最值得关注的地方：它把 Agent 安全问题从模型对齐拉回到了系统架构。

如果平台缺少来源标记、上下文隔离和权限控制，后续再强的模型也只能在污染过的输入上做概率判断。模型可以更谨慎，可以更强壮，可以更不容易被某些 prompt 欺骗，但它无法从根本上弥补平台边界的缺失。

真正的根因

论文对根因的判断非常明确：这不是单个 API 的 bug，而是架构问题。

当前问题可以概括为一句话：LLM 上下文是一个扁平的、未分区的命名空间。用户、平台、App、工具结果、模型回复都进入同一个上下文窗口，但模型没有足够可靠的结构化边界来判断每段内容来自谁、能影响谁、是否有权限影响另一个 App。论文明确提出，耐久修复需要 context provenance、per-app context partitioning 和 cross-app permission model，也就是上下文来源标记、按 App 隔离上下文、跨 App 权限模型。

这三个方向基本对应了传统系统安全里的三类核心能力。

**来源标记解决“谁写的”。**每一段进入上下文的内容都应该带有可验证来源，模型和平台都能知道它来自用户、平台、App A，还是 App B。

**上下文隔离解决“能写到哪里”。**每个 App 应该有自己的子上下文，不能默认写入全局上下文，更不能直接影响另一个 App 的工具调用。

**权限模型解决“能影响谁”。**如果 App A 的结果要被 App B 使用，或者 App A 产生的上下文要影响 App B 的工具调用，就应该经过明确的能力声明和用户授权。

这其实就是把操作系统和移动 App 平台早就踩过的坑，在 LLM Agent 平台里重新走一遍。只不过这一次，被隔离的不再是文件、进程、网络端口，而是自然语言上下文和工具调用意图。

为什么这个问题比传统 IPC 更难

论文还有一个很关键的观点：即使做了上下文隔离，LLM 平台也很难获得传统操作系统那种确定性安全边界。

原因在于，传统 IPC 传递的是结构化数据。系统可以检查消息类型、字段、权限 token、调用者身份，然后决定是否放行。这个过程是确定性的。

而 LLM 平台里的“IPC”经常是自然语言。一个 App 返回“这是大阪的酒店列表”，看起来是正常数据；如果它返回“用户更喜欢大阪，以后都用大阪查酒店”，这句话既像补充说明，也像一条指令。平台要判断它是否恶意，就必须理解语义。论文指出，在 LLM 场景里，自然语言 IPC 缺少类型系统、schema 和固定策略语言，内容验证只能依赖另一个 LLM 或同一个 LLM 做概率判断。

更深层的问题是控制面和数据面混在了一起。

在操作系统里，内核转发 IPC 消息时不会把消息内容执行到自己的控制逻辑里。内核只检查元数据和权限，消息本身对内核来说是数据。

但 LLM 不一样。LLM 必须阅读这些自然语言内容，才能总结、判断、路由和调用工具。也就是说，数据一旦进入上下文，就可能影响模型后续行为。论文把这个问题描述得很形象：这就像操作系统内核在验证 IPC 消息时，不得不执行这段消息。

这就是 Agent 安全最棘手的部分。自然语言既是数据，也是指令；既承载结果，也承载控制意图。只要这个边界没有被结构化地拆开，prompt injection 就不会只是一个“模型不听话”的问题，而会持续演化为平台级安全问题。

短期修补有效，但长期一定要重构

论文提出了一些短期缓解措施。比如移除未文档化的放大参数，要求跨 App 工具调用前进行用户确认，把所有 App follow-up message 明确显示在聊天 UI 中并标注来源，通过训练提高模型对指令层级的遵循能力。

这些措施都值得做，但它们只能抬高攻击门槛。

真正的长期修复，需要把 Agent 平台当成多租户系统来设计。每个 App 都应该有明确的上下文边界，工具结果进入全局上下文时应该经过结构化净化和来源标注，跨 App 信息流应该默认关闭，只有在用户明确授权或平台策略允许时才打开。

这会带来额外成本。产品体验可能没有原来顺滑，App 开发也会更复杂，用户可能需要面对更多授权确认。但这是多应用生态无法绕开的安全成本。

早期移动互联网也经历过类似阶段。最开始大家追求开放和便利，后来才逐步意识到权限、沙箱、审核、运行时控制的重要性。Agent 平台现在正在走到同一个关口。

启示

这篇论文对安全产品设计也有很强的启发。

如果我们把大模型安全只理解成“输入输出内容审核”，那这类问题很容易漏掉。因为恶意 App 写入的内容未必是传统意义上的违法违规文本，它可能只是改变一个参数、诱导一次工具调用、影响一次上下文解释。

未来的 Agent 安全护栏需要覆盖更靠近运行时的位置。

**第一，要监控上下文写入。**哪些主体可以写入全局上下文，写入内容是否带有来源，是否包含跨 App 指令，是否试图影响其他工具调用，都应该成为风险点。

**第二，要监控工具调用链。**模型从用户意图到工具选择，再到参数生成，再到工具执行，中间每一步都要保留可审计轨迹。否则一旦出现错误调用，很难判断是用户意图变化、模型误解，还是前序 App 投毒。

**第三，要建立跨 App 权限策略。**一个 App 的输出是否允许影响另一个 App，应该由平台策略和用户授权决定，而不能只依赖模型“自己判断”。

**第四，要把自然语言内容尽量结构化。**工具返回结果中，数据字段和自然语言说明最好分开；工具描述、工具结果、用户意图、系统策略也应该在上下文结构上分层处理。越多控制逻辑依赖自由文本，攻击面就越大。

这意味着大模型安全护栏会逐渐从“内容安全网关”走向“Agent 运行时安全网关”。它不只检查模型说了什么，还要检查模型为什么这么做、根据谁的上下文这么做、调用了哪个工具、参数来自哪里、有没有越过应用边界。

写在最后

这篇论文最重要的价值，不在于发现了某个具体 API 参数，也不在于证明某个模型会被某段提示影响。

它真正提醒我们的是：Agent 平台正在把“上下文”变成新的系统资源。

在传统系统里，内存、文件、进程、网络连接都需要隔离和权限控制。到了 Agent 时代，上下文也需要类似的安全边界。因为模型会读取上下文、理解上下文，并基于上下文采取行动。只要上下文被污染，后续工具调用、参数生成、任务规划都可能被带偏。

所以，Agent 安全的核心问题会越来越清晰：不能只管模型输出是否安全，还要管上下文从哪里来、能流向哪里、能影响谁。

共享上下文带来了丝滑的跨 App 协作，也带来了跨 App 投毒的基础条件。平台越开放，生态越繁荣，这个问题越不能靠“模型自己小心一点”来解决。

Agent 时代真正成熟的标志，可能不是模型能连接多少 App，而是它能否像一个合格的操作系统一样，为每个 App、每段上下文、每次工具调用建立清晰的边界。