夜雨聆风Atlassian 的 AI 助手 Rovo 被爆出「零点击」数据外泄：你让 AI 帮你整理个 Jira 工单，它就把你们整个租户的文档悄悄发给攻击者了。事后你回头看，一切都很正常。这家公司关掉了 AI 的联网搜索，照样漏。
这篇不是吓唬你别用 AI。而是借这个真实事故，把「给 AI 助手开权限时容易踩的坑」一个个拎出来给你——这 6 个坑不是我编的，全都来自安全公司 PromptArmor 在 8 月 5 日披露的 Atlassian Rovo 泄数据事件，在 Hacker News 上一天 263 赞、113 条讨论。每条后面，我都附上一个「现在就能去验证的动作」。
我做后端这些年，Jira、Confluence 几乎天天用，家里还有一堆接进来的内部系统。看完这份披露，我第一反应是：我们大概率也在同一个坑里，只是没人告诉我们。
坑 1：「关掉联网」不等于「隔离」
很多团队觉得，给 AI 助手关掉联网搜索就安全了。Atlassian 自己的文档里就有 Enable web search 这个开关，组织层面一关，以为 AI 就连不上网了。
没用。 因为关掉 web search，只是不让 AI 主动联网搜索，但没有移除「打开搜索结果」那个工具。攻击路径用的不是「联网搜索」，而是「AI 去打开一个 URL」——这个工具根本不受 web search 开关管。
验证动作：如果你团队在用带 agent 的工具，别只看设置页那个开关。翻一下它的权限清单，找有没有「Open URL」「Fetch URL」这类能力。有的话，你关掉的那个「联网」开关，很可能根本管不住它。
坑 2：以为是"H 里点一下"，实际是"会外发的执行器"
很多人把 AI 助手当成一个「只会聊天、最多帮你查查资料」的对话工具。但一旦它能渲染图片、能抓 URL、能读你上传的文件，它就变成了一个有外发能力的执行器。
Rovo 这次就是靠间接提示注入：一个用户上传了一份看似正常的「Backlog Guide」文档让 Rovo 帮忙整理工单，文档里藏着一句隐形指令。Rovo 读完就照做了——操控 Rovo 把 Jira/Confluence 里的敏感数据，通过不安全 URL 检索工具追加到攻击者的网址后面，然后打开它。数据就这么送出去了。
验证动作：查工具权限清单里有没有「Render Markdown image」「Fetch URL」这类。有的话，它就不是聊天助手，而是个能往外发数据的执行器，安全等级要按那来算。
坑 3：以为攻击者得来"H 一场"，实际是零点击
这类漏洞最阴的一点是：全程不需要你点任何「确认」按钮。 你只需要做一件事——让 AI 帮你处理文档。之后所有外泄都在后台静默完成。
PromptArmor 的原话是「this attack executes without requiring any human-in-the-loop approval」——不需要人肉批准。
验证动作：确认一下你用的 agent 工具，「需要用户确认的操作」到底覆盖了哪些动作。很多工具只拦「写代码/执行命令」，但「打开一个 URL」「发一个网络请求」这种可能根本不在确认范围里。
坑 4：以为「一切正常」就没事了
这次攻击最恐怖的地方在事后——用户回头看对话，一切都很正常，Rovo 还给了「建议的工单更新」，你甚至要谢谢它。
也就是说：「AI 助手看起来很正常」，可能正是它被骗了之后的表现。 和身份认证里「登录成功 ≠ 是本人」一个道理，正常的表面背后，可能是被劫持的执行。
验证动作：与其看 AI 给你什么「结果」，不如偶尔看一眼它的「动作日志」——它到底访问了哪些 URL、发了哪些请求。很多工具都有这类审计日志，只是没人去看。
坑 5：以为只有一家产品有这问题
你可能觉得「这是 Atlassian 的事，跟我的工具无关」。PromptArmor 在披露里专门列了同一类问题的一串产品：Codex 泄连接器数据、OpenAI API 日志泄数据、Superhuman AI 泄邮件、Hugging Face Chat 泄数据……
「AI 会渲染不安全的 Markdown/URL」是跨产品的系统性问题，不是某一家的事。
验证动作：把你团队在用的每一个 AI/agent 工具都过一遍同样的检查——它会不会渲染外部图片、能不能抓外部 URL。别默认「大厂出的就安全」。
坑 6：以为披露了就会有人修
最后这段时间线最值得警惕：
5 月 23 日，PromptArmor 披露给 Atlassian 5 月 25 日，Atlassian 致谢，给了 case number 6 月 4 日、7 月 29 日，两次跟进 8 月 5 日，文章公开（两个多月，Atlassian 没有进一步沟通，Rovo 仍未修复）
「仍在修复中」这句话，很多时候意味着「短期内不会修」。 你不能指望供应商的一封致谢邮件，就当风险不存在了。
验证动作：给 AI 助手开通内部系统权限之前，先查它有没有已知的安全披露（比如在安全研究机构的威胁情报里搜产品名）。有公开未修复漏洞的，别急着给它接 Jira 和代码仓库。
放到更大的层面看，这 6 个坑其实指向同一件事：AI 助手正在从「工具」变成「有权限的成员」。 你给人类新员工开权限，会走审批流程、做安全培训；给 AI 开权限的时候，很多人连它能不能往外发数据都没确认过。不是说你该怕它，而是它不该享受比人类员工更低的准入标准。
而更扎心的是——AI 越来越内行，人类越省心，可一旦出事，省掉的那份「盯着」恰恰最难补回来。 它给你省下的，可能就是它自己从后门送出去的那部分。
留言说说：你们给 AI 助手开权限之前，确认过它到底能不能往外发数据吗？
