文章总结： 文档以moltbook数据泄露为例，揭示了AI代理、集成或OAuth授权桥接多个应用时形成的跨应用权限叠加风险，即有毒组合。传统单应用访问评审难以发现此类问题，因为信任关系在运行时形成且未被治理目录察觉。为应对风险，文档建议采取非人类身份清单、跨应用范围授权审查、桥梁创作回顾等程序性措施，并提及动态SaaS安全平台可通过持续监控运行时图表来自动化发现和治理这些跨应用权限链条。 综合评分： 85 文章分类： 应用安全,AI安全,安全运营,云安全,数据安全

有毒组合：当跨应用权限叠加成风险时

HackSee安全团队 HackSee安全团队

HackSee安全生活

2026年4月23日 17:55 北京

在小说阅读器读本章

去阅读

2026年1月31日，研究人员披露，为人工智能代理打造的社交网络Moltbook公开了其数据库，公开了77万名活跃代理中的3.5万个电子邮件地址和150万个代理API令牌。

更令人担忧的是私信里。其中一些对话包含明文第三方凭证，包括代理间共享的OpenAI API密钥，存储在与劫持代理自身所需令牌相同的未加密表中。

这是一种有毒组合的形态：两个或多个应用之间的权限崩溃，通过AI代理、集成或OAuth授权桥接，而单个应用所有者从未将其作为自身的风险表面。

Moltbook的代理人坐在那座桥上，携带着主机平台和用户连接的外部服务的凭证，而这两个平台所有者都无法看到。大多数SaaS访问评审仍然一次只关注一个应用，这正是攻击者正在学习的盲点攻击目标。

有毒组合的形成

有毒的组合很少是单一错误决定的结果。当AI代理、集成或MCP服务器通过OAuth资助、API范围或工具使用链桥接两个或多个应用时，它们就会出现，桥的每一侧单独看起来都很好，因为桥本身没有人评审过。

举个例子，想象一个开发者安装了一个MCP连接器，以便他们的IDE可以根据请求将代码片段上传到Slack频道。Slack管理员批准了机器人;IDE管理员会批准该外站连接;双方都没有认可源编辑与业务信息之间存在的信任关系，这种信任关系在双方实时存在。它双向运行：IDE 内的提示注入将机密代码推送到 Slack，Slack中植入的指令流在下一次会话中回传到 IDE 上下文中。

无论AI代理连接Drive和Salesforce、机器人将源代码库接入团队渠道，还是任何中介通过一个看起来正常的资助让两个应用相互信任，都会出现同样的形状。

为什么单一应用的评价总是让人忽略它们

常规访问审查很少能捕捉到这种形状。这在现代SaaS开辟的领域中显得压力很大：非人类身份如服务账户、机器人和AI代理，背后没有人类支持，信任关系在运行时而非配置时形成，OAuth和MCP桥接在应用之间却未被治理目录察觉。

回答“谁持有这个范围加上另外两个范围，这些范围能共同实现什么”，一旦这些范围存在于一个没有人通过任何身份系统配置的令牌上，这个问题就变得更加困难。

遥测差距正在迅速扩大。

AI代理、MCP服务器和第三方连接器默认分布在两到三个相邻的应用之间，而在大多数SaaS环境中，非人类身份数量超过了人类。云安全联盟2025年SaaS安全现状报告发现，56%的组织已经担心其SaaS到SaaS集成中API权限过高的问题。

值得深思的事情

缩小差距主要是调整审核地点，从每个应用内部转移到它们之间。以下是一些值得考虑的事项，以应对这类问题：

| 需要复习的区域 | 实际操作中的样子 | | — | — | | 非人类身份清单 | 每个AI代理、机器人、MCP服务器和OAuth集成都作为用户账户存放在同一个登记簿中，拥有所有者和审核日期。 | | 跨应用范围资助 | 在一个身份上新写作用域，而该身份在其他应用中已经持有已读示程，是在批准前被标记，而不是在批准后。 | | 桥梁创作回顾 | 每个连接两个系统的连接器都有一条审查轨迹，标明双方的名称以及它们之间的信任关系。 | | 长寿象征性卫生 | 活动范围偏离原授权范围的代币可被撤销，而非续期候选。 | | 运行时漂移监控 | 跨应用范围的异常和新应用组合中的身份是有毒组合形成的迹象。 |

这些更多是程序性学科，而非产品选择，且它们与现有的访问审查工具配合使用。现实是，没有一个持续监控运行时图表的平台，很难大规模看到这些联系。手动审核不会超过前几十次集成。

动态SaaS安全平台的定位

动态SaaS安全平台自动化了程序审查所建立的跨应用视图。IGA会为已接入系统盘点角色，而动态SaaS安全则持续监控运行时图表：哪些身份存在，哪些应用被触及，哪些范围依赖哪些令牌，以及在上次配置审查后建立了哪些信任关系。

监控必须持续运行，因为这些平台需要接通的桥接速度相当于MCP安装或OAuth同意点击。

Reco就是这一类别的一个例子。其平台连接了整个SaaS环境中的身份、权限和数据流，因此Slack、Drive和Salesforce中的多个范围组合被视为一个曝光，而非三个独立审批。

第一步是发现环境中运行的每一个AI代理、集成和OAuth身份，确保任何跨应用评测所依赖的库存都真实存在。安保团队不知道存在的特工，或在初次入职后悄悄建立新关系的特工，都会与被授权的特工一同出现。

| | | — | | Reco 的 AI 代理清单，显示已发现的代理与 GitHub 关联。 |

一旦对代理进行清点，Reco的知识图谱会将每个人类和非人类身份映射到它访问的应用及其间的桥梁。当MCP服务器将IDE连接到消息通道，或AI代理将文档存储接入CRM时，图表会自动显示组合，并标记为未被单个应用所有者授权的权限拆解。

| | | — | | Reco的知识图谱展示了Slack和光标之间的有毒组合。 |

从那时起，Reco会抓住集成开始超出批准范围的行为，并在任何人使用之前撤销高风险访问权限。链条，而不是应用，成为你审查的对象，这种转变正是让有毒组合显现的原因。

大多数组织的下一次泄露不会通过新的零日漏洞来宣布。看起来就像特工完全按照授权执行任务，直到撤离。这是否会在审批时被发现，还是在事后审查中被记录，关键在于是否有人能看到完整的链条。

看到完整的链条正是Reco动态SaaS安全平台的初心。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：HackSee安全生活 HackSee安全团队 HackSee安全团队《有毒组合：当跨应用权限叠加成风险时》