KENSAI 研究：RAG 后端暴露是架构失误，不是提示词意外

RAG 系统泄露，并不是因为某个提示词偶尔跑偏，而是因为团队把后端布线、调试痕迹和会话残留暴露给客户端层，还把这叫做实现细节。

为什么这个信号今天很重要

一项针对医疗 RAG 聊天机器人的最新审计很有价值，因为它证明了：普通、对客户端可见的表面就可能泄露提示词、配置细节、模式、元数据，甚至附近的会话历史。根本不需要戏剧化的越狱。只要好奇心加浏览器检查就够了。

真正坏掉的是什么

关键失败点不只是模型输出。产品把后端工件暴露在客户端可检查的路径上，于是原本私有的运行细节变成了公开线索。到这一步，攻击者就能学会系统如何检索、路由和保存敏感上下文。

为什么这是架构 bug

如果提示词、路由规则、检索元数据和最近会话痕迹离前端太近，用户看到的就会超过界面本来想展示的范围。这不是措辞问题，而是状态边界问题。松散的 plumbing 会给后续的 prompt injection、操控和数据外流创造机会。

团队下一步该做什么

减少客户端可见元数据，把调试表面从用户交付链路里拆开，让临时痕迹快速过期，并把浏览器可见 payload 当作敌对泄露来检查。如果某个字段对用户动作并非必要，就不该为了方便而顺带发给客户端。

KENSAI 的结论

代理隐私赢在接口、头部、payload 和状态边界上。如果浏览器能看到超过用户所需的信息，系统就已经太松。安全的 RAG 会以正确的方式显得“无聊”：更少暴露、更紧接缝、更少意外。