多用户 AI 会话：没人在设计阶段考虑的上下文归属问题

2024 年 8 月，安全研究人员发现 Slack AI 在回答查询时会将公开频道和私密频道的内容同时拉入同一个上下文窗口。公开频道中的攻击者可以精心构造一条消息，当 Slack AI 摄取该消息时，就会将指令注入受害者的会话——由于 Slack AI 不引用来源，由此导致的数据外泄几乎无从追踪。这种攻击甚至可以泄露私信中嵌入的 API 密钥。Slack 在负责任披露后修复了这一问题。

这并不是传统意义上的漏洞。它是将上下文视为无用户访问控制的共享可变资源所带来的后果。而这正是大多数正在构建共享 AI 助手的团队现在都在犯的错误，只是更加悄无声息而已。

当你为单个用户构建 AI 功能时，你大多可以不去考虑上下文归属。会话属于一个人；上下文窗口中的任何内容都是他的。但当你部署一个团队 Slack 机器人、共享工作空间助手或实时协作 AI 层时，你就引入了一个仅靠身份验证无法解决的问题：多个用户、多种意图，以及一个不知道自己属于谁的上下文窗口。

为什么应用层的授权还不够

工程师们倾向于用身份验证和授权来思考多用户安全：检查 JWT、验证权限，然后继续。对于传统 API，这种思维模型是成立的。对于 AI 系统，它在上下文层就失效了。

原因如下：在大多数共享 AI 实现中，上下文窗口在请求时一次性组装完毕后交给模型。这个组装步骤从对话历史、记忆存储、检索到的文档和当前会话状态中提取信息。如果组装逻辑在每个步骤都没有执行每用户边界，就会产生交叉污染——而模型对此毫不知情，它只是对窗口中的内容进行推理。

这就是 Giskard 研究所称的跨会话泄漏：模型向错误的用户返回了有效数据，因为运行时在推理之前未能强制执行边界，而不是因为模型本身出了问题。事后用输出过滤器来修复，无异于覆水难收。

到 2025 年上半年，仅 Microsoft Copilot 就通过这类失败在每个组织中暴露了约 300 万条敏感记录——不是因为身份验证被破坏，而是因为该工具在上下文组装步骤中没有对每用户进行范围限定地访问了共享组织数据存储。

生产环境中出现的三种失效模式

用户间的上下文泄漏是最明显的失效。用户 A 的对话历史或记忆泄漏到用户 B 的上下文中。当会话状态按团队或工作空间 ID 而不是用户 ID 存储时，当对话摘要被写入共享池时，或者当检索系统使用组织级嵌入而没有用户范围过滤时，就会发生这种情况。结果是用户 B 的 AI 响应被用户 A 的私有数据微妙地（或明显地）影响。

共享历史中的意图竞争更为隐蔽。当一个团队机器人维护共享对话线程时——大多数 Slack 机器人默认如此——模型将所有先前的轮次读取为一段连贯的历史记录。但线程中不同的用户有不同的目标、不同的领域知识和不同的期望。模型将它们混淆了。线程后期用户 A 的提问会被三轮之前用户 B 所说的内容所解读。这种叠加效应意味着共享线程机器人随着团队规模的扩大，使用价值往往会下降，而且没有人能说清楚为什么。

跨会话的个性化污染是持续时间最长的失效。保存用户偏好、学习行为和对话上下文的记忆系统是最有价值的 AI 功能之一——也是多用户环境中最危险的功能之一。当记忆的范围过于宽泛时，用户的偏好会污染组织级上下文。更糟糕的是，对抗性记忆投毒——将指令注入持久存在于会话终止后的共享记忆存储——可以影响所有未来用户的体验。Microsoft Security 在 2026 年记录了这种攻击模式：注入 AI 记忆中的指令在会话终止后仍然存在，并重定向了后续用户的交互。

真正有效的隔离模式

基本设计原则是：上下文是投影，而不是存储。持久状态存储在以 userId 为键的存储中。每次推理调用通过从该用户的基础加上当前会话投影来组装上下文窗口。上下文窗口本身是短暂的，永远不会写回共享状态。将 sessionId（当前对话）与 memoryId（用户身份）分离，是大多数团队跳过的第一步。

双层记忆架构将此正式化。私有记忆按用户隔离敏感、个人和会话特定的数据。共享记忆支持受控的知识传输——团队规范、代码库上下文、项目历史——并有明确的访问策略来控制可以检索什么以及由谁检索。协作记忆系统的研究通过动态访问控制将此正式化：对共享记忆的读写在继续之前会检查策略层，而不是在全局存储上自由操作。

加载中…