一项5月1日发表于arXiv的安全评估，揭开了医疗AI最不愿面对的遮羞布。

用Chrome浏览器，拆穿医疗AI的安全神话

研究团队采用了一种极为简洁的方法：首先用Claude Opus 4.6进行探索性提示测试，提出漏洞假设；随后用Chrome开发者工具手动验证——没有任何专业黑客工具，不需要认证，只要打开浏览器就能完成。

结果令人不安：一个面向患者的医疗RAG聊天机器人，通过普通浏览器检查，就能收集到：系统提示词、模型和embedding配置、检索参数、后端API端点、API schema、知识库内容，以及最近1000条医患对话记录。

更讽刺的是：该平台公开承诺保护隐私，而实际上，全量对话记录（包括涉及健康的敏感查询）根本没有任何认证就能被提取出来。所谓的隐私承诺，不过是纸面上的幻觉。

RAG架构的原生缺陷，还是部署失误？

论文指出了关键漏洞：敏感的系统配置和RAG参数，本应限制在服务端访问，却意外暴露在客户端-服务端的通信中。这不是某个厂商的个别失误——这是RAG架构在医疗场景下安全设计的系统性缺失。

  • 系统提示词暴露：攻击者可了解AI的行为逻辑和边界
  • API端点和schema暴露：可直接构造恶意请求
  • 知识库内容暴露：专有医疗数据泄露
  • 千条医患对话暴露：HIPAA等隐私法规的重大违规

LLM做渗透测试：双刃剑的另一面

值得注意的是：这项研究本身就用Claude Opus 4.6辅助完成，且在虚假开发者身份下也获得了AI的积极配合。换言之，审计人员能获得的AI辅助，攻击者同样可以获得。LLM正在降低安全评估的门槛——但同时也在降低攻击的门槛。

为什么这件事值得关注

医疗AI是RAG落地最密集的场景之一，也是隐私法规最严格的领域。这篇论文的结论足够尖锐：没有独立安全审查，就不应该上线任何面向患者的医疗AI。医疗机构的合规团队，不能把AI供应商的自我声明当作安全背书。

部署RAG医疗应用之前，先问三个问题：系统提示词是否对用户可见？对话记录是否需要认证才能提取？知识库内容的访问权限是否做到了最小化？任何一个答案是肯定的，都是红色警报。

论文：When RAG Chatbots Expose Their Backend: An Anonymized Case Study of Privacy and Security Risks in Patient-Facing Medical AI

arXiv：2605.00796 | cs.CR | 2026-05-01

来源：arXiv | https://arxiv.org/abs/2605.00796