开源代理 Jnvoy：在 LLM 调用前拦截隐私与注入

当你的应用向 Claude 或 GPT-4o 发送请求时，用户数据究竟经过了哪些路径？大多数开发者对此并没有清晰的答案。姓名、邮箱、电话号码，甚至社保与金融数据，在未经脱敏的情况下就抵达了第三方服务器。一位开发者为此构建了开源代理 Jnvoy，试图在数据离开本地之前完成所有安全检查。

默认路径下的数据泄漏盲区

应用调用大模型 API 时，原始用户输入通常被直接拼进 messages 数组。开发者能控制的只有模型名称和温度参数，却对传输内容缺乏细粒度的拦截能力。这种模式下，三类风险同时存在：个人身份信息泄露、提示注入攻击、以及模型上下文协议中的工具投毒。

GDPR 和英国 FCA 合规要求对个人数据处理有明确约束，但多数团队在快速迭代阶段并不会主动搭建一套独立的检测层。Jnvoy 的切入点正是这个缺口——把安全层做成一个 HTTP 代理，开发者只需替换请求 URL，无需改动业务逻辑。

PII（个人身份信息） 是 GDPR 等法规中的核心概念，泛指可单独或结合其他信息识别到具体自然人的数据，包括姓名、邮箱、电话、身份证号、金融账户等。在大模型调用场景中，PII 风险的特殊性在于：数据一旦进入第三方推理服务，可能被用于日志留存、模型训练或后续检索，脱离原始控制域。因此合规实践的共识是“源头脱敏”——在数据离开本地网络之前完成检测与替换，而非依赖供应商的事后承诺。

提示注入（Prompt Injection） 是 LLM 应用特有的攻击面：攻击者在用户输入或外部内容中嵌入指令，诱使模型忽略系统提示、泄露机密或执行非预期操作。MCP（模型上下文协议） 则把这种风险从文本层扩展到工具层——当模型可调用外部工具时，恶意的工具描述或工具返回内容可能被当作可信指令执行，即所谓“工具投毒”。这三类风险叠加，使得单纯的输入校验难以覆盖全部路径。

一行 URL 替换背后的架构

从调用方式看，改动确实很小。原本使用 Anthropic SDK 的初始化代码，被替换为一次 httpx.post 请求，目标地址指向代理服务。请求体中多了 provider 字段，用于指定上游模型供应商。

这个设计的关键在于代理的职责边界。它在本地扫描请求内容，识别出 PII 实体后将其替换为可逆 token，再把脱敏后的请求转发给 LLM。模型返回结果后，代理在响应路径上还原原始值。整个过程对调用方透明，业务代码不需要感知 token 映射的存在。

这种可逆 token 机制的前提是映射表只存在于代理内部，不会随请求外泄。多租户场景下，每个 API key 对应独立的映射空间，避免不同租户之间的数据交叉。

可逆 token 替换 是一种在隐私与可用性之间取平衡的脱敏策略。与不可逆的哈希或删除不同，它把识别出的 PII 实体（如“张三”“138xxxx”）映射为占位符（如 [PERSON_1]），并维护一张双向映射表。模型在脱敏文本上推理，返回结果中若包含占位符，代理再依据映射表还原为原始值，从而保证下游业务拿到的响应与脱敏前语义一致。这种机制的前提是映射表严格留在本地：一旦外泄，攻击者可反向还原全部敏感数据。因此多租户隔离、映射表加密与最小权限访问是其安全基础。

检测能力覆盖哪些实体

Jnvoy 的 PII 检测基于 Microsoft Presidio，支持 20 多种实体类型。在此之上，它增加了英国本地化识别器，覆盖 NHS 号码、NI 号码、英国邮编和排序码。对于处理英国用户数据的团队，这些识别器比通用实体检测更实用。

提示注入检测则针对越狱、指令覆盖和系统提示提取三类攻击模式。MCP 安全模块额外检测工具投毒和工具响应中的密钥泄漏，这一点在当前 MCP 生态快速扩张的背景下值得关注。

审计日志写入 PostgreSQL，用于合规追溯。项目还提供一键生成 FCA 和 EU AI Act 合规报告的 PDF，把技术检测结果映射到监管框架。

Microsoft Presidio 是微软开源的 PII 检测与匿名化框架，结合正则、命名实体识别（NER）模型和上下文规则来定位敏感实体，支持自定义识别器与可插拔的 NLP 引擎，常被用作合规脱敏的工程底座。FCA（英国金融行为监管局） 是英国金融业的监管机构，其对客户数据处理、外包与记录留存有明确要求；EU AI Act 则是欧盟针对人工智能系统的风险分级监管框架，对高风险场景提出文档、审计与透明度义务。文章提到的合规报告生成，本质是把技术层的检测与日志数据映射到这些监管条款，降低人工举证成本。

缓存、测试与部署形态

成本优化方面，语义缓存据称可以节省 20% 到 40% 的 LLM 调用费用。对于高频重复查询的场景，这一比例会直接影响推理预算。

工程成熟度上，项目包含 164 个自动化测试，提供 Docker 一键启动栈，并包含一个 Slack 连接器用于保护 AI 机器人消息。这些组件表明作者在尝试把 Jnvoy 从实验脚本推向可部署的基础设施。

适用边界与待验证问题

代理模式并非没有代价。所有请求都经过本地代理，延迟增加不可避免；PII 检测本身需要计算资源，高并发下的吞吐表现是实际落地时的关键变量。可逆 token 映射表的安全性也依赖代理自身的防护水平——如果代理被攻破，原始值的还原能力反而会成为攻击面。

目前项目提供在线演示和 GitHub 仓库，作者表示愿意讨论架构细节。对于需要快速满足合规要求、又不想重写模型调用层的团队，Jnvoy 提供了一条低改造成本的路径，但生产环境下的性能与安全边界仍需独立验证。