Rovo被曝绕过权限导出数据

Rovo的权限承诺，遇上了Agent时代的新问题

Atlassian Rovo近日被曝存在一条可绕过既有控制、将企业内部数据带出受信边界的攻击路径。安全研究机构PromptArmor公开的测试显示，攻击者可以把恶意指令藏进Rovo能够检索的内容，诱导Agent利用当前用户的合法权限读取其他内部信息，再通过可用的输出或工具通道完成数据外传。

这不是传统意义上“低权限账号直接读到高权限文档”的简单越权。更准确地说，这是一次授权读取、非授权使用：Rovo读取的内容可能确实都在发起请求者的权限范围内，但触发读取的真正意图来自攻击者植入的文本，数据最终流向的地方也不一定经过用户明确同意。

截至2026年8月6日，现有公开材料尚未给出对应CVE编号、受影响版本边界、完整修复时间表或Atlassian的正式根因分析。因此，这起事件目前更适合被定义为经过演示的Agent安全缺陷，而不是已经确认遭到大规模利用的入侵事件。企业不应把研究演示直接等同于数据已经泄露，但也不能因为“权限系统本身没有失效”就忽略风险。

这条攻击链是怎么成立的

**间接提示注入是指攻击者把指令隐藏在网页、工单、文档、邮件或其他模型会读取的数据中，让模型在处理内容时把数据误当成命令执行。**它与用户直接输入“忽略之前指令”不同，受害者甚至不需要看到攻击文本，只要Agent检索或总结了被污染的内容，指令就可能进入模型上下文。

PromptArmor披露的核心结论是，Rovo可能同时扮演“阅读者”和“执行者”。当它读取一段被污染的企业内容时，大语言模型未必能稳定区分哪些文字是需要总结的数据，哪些文字是在试图重新安排任务的恶意命令；一旦后者被执行，Agent便可能继续搜索用户有权访问的资料，并尝试把结果写入攻击者能够接触的位置。

这条攻击链通常可以拆成五步：

1. **攻击者布置载荷。**恶意提示被放进Rovo可以连接、同步或检索的知识源，例如协作文档、工单内容或第三方应用中的文本。
2. **正常用户触发检索。**用户要求Rovo总结项目、调查问题或汇总资料，并不知道检索结果中混入了恶意指令。
3. **模型混淆数据与指令。**Rovo把外部内容送进模型上下文，恶意文本开始影响后续推理与工具选择。
4. **Agent借用用户权限。**Rovo按照当前调用者的身份读取更多Jira、Confluence或已连接应用中的内容。
5. **数据进入输出通道。**敏感内容被拼接到Agent回复、写入动作、外部请求参数或其他攻击者可观察的位置，形成外传。

这类攻击最麻烦的地方在于，五个步骤单独看都可能是“合法操作”。文档允许被检索，用户有权读取内部信息，Agent也获得了执行某种动作的许可；真正越界的是这些能力被一段不可信文本串了起来，而现有权限系统通常只检查“谁能访问”，不检查“为什么访问”和“访问后流向哪里”。

“Rovo看不到你看不到的内容”并不足够

**Rovo是Atlassian面向企业知识搜索、对话和自动化任务推出的AI协作平台。**它通过Teamwork Graph关联Jira、Confluence、Jira Service Management及外部SaaS数据，让Agent能够理解项目、人员、目标和工作项之间的关系。

Atlassian在Rovo数据与隐私指南中明确表示，Rovo会同步Atlassian应用及第三方应用的访问控制，使用户只能看到自己原本有权访问的内容。相关治理说明也强调，Agent能够执行的动作取决于触发它的用户，常见概括是“Rovo不能看到你看不到的东西”。

这句话描述的是读取权限，却没有完整覆盖Agent的数据使用边界。一个财务负责人本来就能读取预算，一个安全工程师本来就能查看漏洞报告，一个管理者也可能有权接触员工信息；如果Agent被恶意文档操纵，攻击者无需突破这些人的账号权限，只需要让Rovo代替他们完成检索和搬运。

**混淆代理问题是指一个拥有合法权限的系统，被低信任输入诱导，代表攻击者执行高权限操作。**Rovo在这里更像一名拿着员工门禁卡的助理：门禁系统正确识别了这张卡，助理也没有进入持卡人无权进入的房间，但把房间里的文件交给谁，并不是门禁系统能够回答的问题。

| 控制层 | Atlassian公开设计 | 本次披露暴露的缺口 | 实际风险 | |---|---|---|---| | 应用访问控制 | 继承Jira、Confluence及连接应用权限 | 只验证用户能否读取，不判断读取目的 | 高权限用户成为更有价值的攻击跳板 | | Rovo检索 | 基于用户身份返回可访问内容 | 被污染内容可能影响后续检索 | 单个恶意文档可触发跨知识源搜索 | | Agent身份 | 动作通常依赖触发者权限 | Agent缺少独立、可约束的运行身份 | 人的全部权限可能被临时借给Agent | | Agent可见性 | 新建Agent默认可被组织内所有人看到和使用 | 默认开放扩大误触发和滥用范围 | 未经评审的Agent更容易进入生产环境 | | 编辑权限 | 提供Editor和Manager两类角色 | 当前不支持按特定群组或团队限制，需要逐个添加用户 | 大型组织难以规模化实施最小权限 | | 工具与输出 | Agent可根据配置执行动作 | 读取权限与写入、发送能力缺少统一数据流策略 | 敏感数据可能从合法读取链路流向低信任目标 |

Atlassian文档中的另一个关键细节是，新建Rovo Agent默认对组织内所有人可见并可使用。管理员可以控制谁能在Studio中创建Agent，也能为具体Agent设置Editor和Manager，但按官方治理说明，针对特定群组或团队的访问限制目前并不完善，部分场景需要逐个添加用户。

这种设计对产品增长很友好，却不适合高敏感企业环境。把Agent做得像创建Confluence页面一样容易，确实能降低自动化门槛；但页面通常只承载内容，Agent还会检索、推理和执行动作，两者不应该采用相同的默认开放逻辑。

真正失守的是数据流，不只是ACL

**访问控制列表（ACL）是用于规定某个身份能否读取、修改或管理资源的权限规则。**传统SaaS安全体系围绕ACL建立，而企业Agent增加了三个ACL难以表达的新变量：输入是否可信、调用目的是否合法、输出目标是否安全。

Rovo事件再次说明，Agent安全不能只画“用户—资源”的二维权限表。完整模型至少要覆盖“用户—Agent—数据源—工具—输出目标”五个对象，并记录数据从哪一级敏感源进入、经过哪个模型处理、最终被写到哪里。

| 安全问题 | 传统SaaS通常检查什么 | 企业Agent还需要检查什么 | |---|---|---| | 谁在操作 | 用户身份、角色、群组 | 用户与Agent各自的独立身份 | | 能读什么 | 页面、项目、空间权限 | 检索结果的敏感级别与来源可信度 | | 能做什么 | 创建、读取、更新、删除 | 工具调用顺序、参数及连续动作组合 | | 能发到哪里 | 单次写入目标是否有权限 | 数据是否从高信任域流向低信任域 | | 为什么执行 | 通常不判断业务目的 | 指令来自用户、系统还是检索内容 | | 谁来批准 | 登录和角色即视为授权 | 高风险动作是否需要再次确认或双人审批 |

数据外泄防护的核心并不是列出几个禁止词。模型可以改写、摘要、编码或拆分内容，单纯扫描“机密”“密码”等关键词很容易漏报；更可靠的做法是给检索结果附带敏感标签，并让标签沿着Agent执行链传播。

例如，Rovo一旦读取标记为“仅财务团队”的预算文档，后续任何写入公共工单、第三方连接器或低权限空间的动作都应被默认阻断。即使模型把预算总结成三句话，这三句话也仍然继承原始数据的敏感级别，而不是因为经过模型改写就变成普通文本。

Teamwork Graph既是优势，也是爆炸半径放大器

**Teamwork Graph是Atlassian用于关联人员、项目、目标、工单和企业知识的组织数据图谱。**它让Rovo不必只依靠关键词搜索，而能理解“这个故障属于哪个服务、由谁负责、关联哪个季度目标”之类的关系。

图谱带来的上下文越完整，Agent受骗后的搜索能力也越强。传统提示注入可能只污染一份文档，连接企业图谱的Agent却能根据文档中的项目名继续找到负责人、相关工单、事故复盘和客户记录，攻击半径因此从单个知识源扩展为跨系统的数据链。

这并不意味着企业应该停用所有连接器。真正的问题是连接器通常被当成搜索覆盖率配置，而不是安全边界配置；管理员关注“还能接入哪些数据”，却很少同时定义“这些数据能否与哪些工具共同出现在一次Agent会话中”。

一个更合理的做法是建立能力分区。面向全员的知识问答Agent可以连接低敏感文档，但不应同时拥有外部写入能力；能够读取安全事件和客户信息的Agent则应运行在受限身份下，并将可写目标限定在同一安全域内。

企业现在应该做什么

企业当前最重要的动作不是禁止员工使用所有AI，而是先缩小Rovo Agent的默认能力。PromptArmor披露的是一类架构性问题，等待模型“更聪明地识别恶意提示”并不能替代权限、审批和审计。

管理员应在24至48小时内完成的检查

• **盘点全部Rovo Agent。**记录创建者、可见范围、知识源、可调用工具、外部连接器和最近使用者。
• **收紧Agent创建权限。**不要继续沿用“组织内所有人均可创建”的默认思路，生产Agent应经过安全评审。
• **检查默认公开状态。**没有明确业务需要的Agent不应向全组织开放，尤其是同时连接高敏感知识源的Agent。
• **拆分读取与执行能力。**总结文档的Agent没有必要同时创建外部内容，执行工作流的Agent也不应默认搜索全部企业知识。
• **审计异常查询链。**重点寻找一次会话内跨多个空间、项目或连接器的大范围检索，以及读取后立即写入低信任位置的行为。
• 暂停高风险组合。“高敏感读取+外部发送”“人员数据检索+公共写入”“安全报告读取+第三方工具”应优先关闭或增加人工确认。

安全团队应持续监控的四类信号

1. Agent突然搜索与用户原始问题无关的项目、人员或文档。
2. 同一会话在短时间内读取多个不同敏感域的数据。
3. 检索内部内容后紧接着调用外部写入、发布或发送工具。
4. 输出中出现异常长参数、编码文本、不可见字符或与任务无关的链接结构。

人工确认也必须展示足够上下文。只弹出一句“是否允许Rovo继续”几乎没有安全价值，确认页面至少应列明即将调用的工具、目标位置、涉及的数据来源以及可能暴露的敏感字段，否则用户只是在机械点击另一个同意按钮。

Atlassian需要补上的不是一条过滤规则

Atlassian若要真正修复这类问题，第一步应当是把检索内容明确视为不可信输入。来自网页、工单、评论和第三方连接器的文字只能作为数据参与回答，不能直接改变系统指令、工具权限或任务目标。

第二步应当是为Agent提供独立于调用者的服务身份。企业可以选择授予Agent一个受限权限集合，而不是让它在每次运行时完整继承用户权限；即使高管触发了Agent，Agent也只能读取完成既定任务所必需的数据。

第三步应当是引入跨工具的数据流策略。系统不仅要判断某个动作能否执行，还要判断前一步读取的内容能否进入下一步输出，并对高风险跨域流动实施阻断、脱敏或人工审批。

第四步应当是补齐群组级治理与私有默认值。企业软件中的Agent默认面向全组织开放，会把试验性自动化直接变成生产攻击面；更稳妥的默认值应该是仅创建者可见，再由管理员按团队、群组或业务域逐步授权。

第五步应当是提供可用于调查的完整审计链。日志需要关联用户身份、Agent版本、检索来源、模型决策、工具参数、输出目标和审批记录，否则企业在发现异常后只能看到“某用户使用过Rovo”，却无法判断数据到底经过了哪些步骤。

这不是Rovo一家会遇到的问题

企业Agent的共同弱点是模型既阅读不可信内容，又拥有执行真实动作的能力。Microsoft Copilot、Google Workspace中的AI功能、各类企业搜索产品和自建Agent，只要同时连接内部知识与外部工具，就会面对类似的间接提示注入和混淆代理风险。

| 产品形态 | 常见能力 | 主要风险 | 更合适的控制方式 | |---|---|---|---| | 只读企业搜索 | 搜索、摘要、问答 | 敏感内容出现在回答中 | 继承权限、结果脱敏、会话审计 | | 工作流Agent | 创建工单、更新状态、发送通知 | 恶意内容触发非预期动作 | 工具白名单、参数约束、人工确认 | | 跨SaaS Agent | 检索多个应用并执行动作 | 跨安全域组合导致数据外传 | 独立身份、数据标签、出口控制 | | 自主任务Agent | 多步规划和连续调用工具 | 单次误判被放大为完整攻击链 | 步数限制、阶段审批、实时行为检测 |

Rovo的问题之所以值得关注，是因为Atlassian本身处在企业协作数据的中心。Jira里有研发计划和漏洞信息，Confluence里有产品路线、会议纪要和内部制度，JSM里还可能存在客户、事故与运维数据；一旦Agent能够跨这些系统规划动作，传统的页面权限正确并不等于整体流程安全。

ISO/IEC 27001:2022或SOC 2等合规认证也不能直接回答提示注入问题。认证能够证明组织建立了相应的管理与控制流程，却不代表每一条Agent执行链都不存在设计缺陷，更不代表模型能够可靠识别藏在业务内容里的恶意指令。

我们的判断

Rovo这次暴露的核心问题不是“AI偶尔会胡说”，而是企业把概率性模型放进了确定性的权限系统，却没有为二者之间增加足够强的数据流隔离。ACL仍然在工作，但它只守住了入口，没有守住数据被Agent读取后的去向。

这类缺陷的危险程度取决于三个条件：Agent能看到多少敏感数据、能调用多少写入或通信工具、企业能否发现异常执行链。只读且知识源受限的Rovo部署风险相对可控；连接多个高敏感系统并开放自动执行的部署，则应该按高风险生产系统重新评估。

短期看，企业应把Rovo Agent从“增强版聊天机器人”提升到“拥有员工权限的软件主体”来治理。长期看，Agent平台需要从身份权限管理升级为持续的数据流管理，否则每增加一个连接器、一个工具和一段自主规划能力，都可能同步增加一条新的外传路径。

这次事件也再次提醒企业：所谓“Agent遵循现有权限”，只是上线门槛，不是安全结论。真正合格的企业Agent必须同时回答四个问题——它代表谁、为什么读取、可以做什么，以及数据最终去了哪里。

参考来源

• Reddit：关于Atlassian Rovo Agent身份与治理盲点的社区讨论：包含企业管理员对沙箱、生产审批、机器人账号和权限治理的实践讨论。
• PromptArmor《Atlassian Rovo Exfiltrates Data, Bypassing Controls》：本次数据外传攻击演示的主要披露来源，受域名限制不附链接。
• Atlassian Support《Rovo agent permissions and governance》：说明Agent默认可见性、Editor与Manager角色以及群组限制现状，受域名限制不附链接。
• Atlassian Support《Rovo data, privacy, and usage guidelines》：说明Rovo继承Atlassian及第三方应用权限的官方材料，受域名限制不附链接。