提示注入常被误认为只是针对玩具聊天机器人的实验室演示。PromptArmor 关于 Atlassian Rovo 的报告更值得企业关注，因为它展示的是一个实际边界问题：AI 助手能读取内部工作数据，又会处理不可信内容，同时还保留访问外部地址的能力。安全控制必须放在这个交汇点上。

AI 助手被安全网关阻止，无法把企业文档发送到外部网络

PromptArmor 在 2026 年 8 月 5 日发布报告。研究人员称，攻击者可以通过隐藏指令操纵 Rovo，把 Jira 工单和 Confluence 文档内容发送到攻击者控制的网站。报告还称，他们在 5 月 23 日向 Atlassian 披露问题，5 月 25 日收到案件编号，6 月和 7 月继续跟进，之后因两个多月没有公开修复或进一步沟通而发布报告。写作时，我没有找到 Atlassian 公开反驳该报告的说明。

这不等于所有 Atlassian 客户都已经发生数据泄露。公开材料描述的是一个已演示的攻击链，而不是大规模利用的证据。正确反应不是恐慌，而是把企业软件中的 AI 助手当作有数据权限和网络能力的软件来管理。

风险来自权限组合

Rovo 是 Atlassian 面向 Jira、Confluence 和连接服务的 AI 层。Atlassian 把它描述为了解企业业务、汇集人员、项目和代码上下文，并连接第三方 SaaS 应用的助手。连接器页面列出了 Google Drive、GitHub、GitLab、Microsoft SharePoint、Outlook Mail、Gmail、Zendesk、Box、Dropbox、Figma、Azure DevOps、ServiceNow、Slack 等来源。

这正是产品价值，也正是风险模型。Jira 和 Confluence 里常有产品路线图、客户问题、事故记录、安全讨论、研发计划、内部流程和其他系统链接。一个有用的助手需要这些上下文。一个安全的助手必须被限制：这些上下文能流向哪里。

Atlassian 的 AI 信任页面称，平台权限和第三方连接器权限在正确配置时会被遵守，也说明管理员管理的连接器默认不启用，并可对 Google Drive 或 SharePoint 等来源设置允许列表或阻止列表。这些控制很重要，但还没有完全回答 PromptArmor 提出的问题：助手能否把它本来有权读取的数据，放进由模型自己构造的外部请求里？

报告中的攻击链

首先，不可信内容进入助手可读取的范围。在 PromptArmor 的例子中，这是一个含有隐藏指令的文件；研究人员也指出，类似内容可能来自支持工单、外部文档、已连接应用，或在搜索开启时来自网页数据。

随后，用户让 Rovo 完成正常工作，例如整理工单。Rovo 会查看 Jira 和 Confluence，因为这正是它的功能。隐藏指令试图让助手把敏感内容拼入外部地址。接着，打开 URL 的工具访问这个地址，接收服务器就可能在日志中记录这些数据。

关键点是 URL 打开工具。PromptArmor 称，即使组织关闭了 Rovo 的网页搜索，攻击仍然有效，因为该设置没有移除打开搜索结果地址的工具。换句话说，关闭可见的搜索功能，不一定关闭了助手可使用的所有网络路径。

不能只责怪模型

把问题说成“模型听信了坏指令”过于简单。模型运行在工具系统之内。如果系统同时给它内部数据和外部通信能力，就不能把模型判断当作主要安全控制。

Simon Willison 的“三要素”很有用：私有数据、不可信内容、外部通信。任意两个因素通常还可管理，三个同时出现就形成数据外流路径。Rovo 不是唯一案例；浏览器代理、代码助手、办公助手、客服机器人和内部搜索系统都可能遇到同样模式。

防护必须是确定性的。打开地址的工具不应访问模型临时拼出的任意 URL。更安全的做法是只允许用户明确提供的地址，或可信组件返回的地址，并阻止可能携带内部数据的参数。Markdown 中的远程图片也应被视为网络请求，因为它也可能变成外发信号。

管理员应检查什么

先确认组织中是否启用了 Rovo 和 Atlassian 的 AI 功能。不要只看产品页面，要检查租户的真实管理控制台。

然后列出所有连接器。重点关注大范围文档库、代码平台、支持系统和邮件系统，例如 Google Drive、SharePoint、GitHub、GitLab、Zendesk、ServiceNow、Gmail 和 Outlook。一个适合搜索的连接器，如果被助手与不可信指令和外部请求混用，就会带来更高风险。

按最小权限配置数据源。不要在只需要少数文件夹时连接整个 Drive 或 SharePoint 根目录。检查用户组、访客、承包商和旧账号。

向 Atlassian 提出具体问题：网页搜索关闭后，Rovo 是否还能打开由模型构造的 URL？如果可以，管理员能否关闭这项能力、限制为可信来源，或者审计每一次请求？

尽可能阻止模型构造的外部地址。网络日志、代理和数据防泄漏规则可以帮助发现出站参数中的敏感信息。远程图片、预览和 Markdown 都应按网络请求处理。包含内部数据的外部通信应要求人工批准，并显示目标地址、数据类型和原因。

普通用户能做什么

不要把随机外部文件上传到同时连接敏感工单和文档的助手。让有权限的助手总结未知客户附件、供应商文档或网页时要谨慎。如果助手突然尝试打开外部链接、插入奇怪的图片地址，或输出像隐藏指令一样的文本，应报告给管理员。

核心教训很简单：“模型应该知道不能泄露数据”不是安全控制。边界必须在工具层：允许列表、数据类型检查、内容来源规则、人工批准、日志和安全默认设置。对于能读取 Jira、Confluence、邮件、文档和代码的助手，真正重要的问题是它能读什么、显示什么、调用什么、把数据发往哪里，以及谁能审计这些动作。