Presidio 是通用漏洞扫描器吗？

不是。其识别和匿名化组件用于数据处理，不能覆盖全部模型或应用风险。

用了脱敏就不会越权吗？

不能这样保证。遮盖部分字段仍可能返回不应访问的业务事实，授权应由后端控制。

可以先独立验证敏感信息处理，再对授权范围内的完整应用测试旁路和实际响应。

需要。语言、行业格式、识别器和检测器均影响误报漏报，应使用相应标注和业务案例。

不能。它们的对象与统计口径不同，也不能当作没有风险的概率。

报告可能包含原始输入、敏感响应和配置，应限定权限并在分享前检查内容。

要检查模型或应用在测试输入下是否出现不希望的行为，用 garak 这样的测试工具；要在文本进入或离开模型时识别并处理敏感信息，评估 Presidio。它们可以配合使用，但不能互相替代：扫描结果不会自动形成在线脱敏措施，脱敏成功也不能证明系统不存在其他风险。

本文比较的是安全测试和数据处理的职责，不是两款相同扫描器的排名。资料核对日期为 2026-10-22，没有运行两者共同中文检出率或速度基准，也没有向真实客户系统发起扫描。

对于自有聊天应用，先定义测试目标和风险范围，再通过探针调用目标，检查响应是否包含需要调查的行为。结果应能回到具体输入、输出、版本和判定依据，方便人工复核和修复后回归。

如果某个测试出现了不该展示的信息，需要判断来源：基础模型已有内容、检索器拿错记录、后端权限漏检，还是日志或工具返回了额外数据。仅靠响应中的一个模式命中，通常无法完成根因分析。

同样，未命中不代表没有泄漏。探针可能没触达业务路径，响应可能换了一种表达，检测器也可能不理解中文或特定格式。把测试范围和不适用项写清，比一个没有分母解释的通过率更可靠。

Presidio 主要由敏感信息识别与匿名化等组件构成，可按实体、语言、规则和模型配置处理文本。它适合在数据流中检查邮箱、电话号码或自定义行业标识等内容，并采取遮盖、替换等处理方式。

使用前应准备有标注的数据，包含应识别与应保留的样本。识别出某种实体不是结束，还要检查位置是否正确、重叠实体如何处理、处理后的文本是否仍满足业务需要。对中文、混合语言和非标准格式应单独评价。

Presidio 当前文档已从旧的 Microsoft GitHub Pages 地址跳转到新的项目文档域名，本文引用此次实际可访问的文档。具体组件版本和模型仍应固定，避免文档更新后继续凭旧配置判断支持范围。

可以先建立一组虚构联系人和虚构订单，明确哪些字段允许进入模型、哪些需要替换。先独立验证 Presidio 的识别与处理，再把处理后的文本接入模型。最后对完整应用做授权范围内的风险测试，观察是否存在未经过预处理的数据入口或旁路输出。

记录至少包括原始合成样本编号、处理策略版本、目标版本、测试输入、响应和人工结论。不要把真实客户资料当作“更真实的测试素材”复制到报告。需要使用真实数据时，按已有权限和必要性设计受控流程。

当 garak 报告疑似泄漏时，定位是识别器漏报、应用没有使用处理后的文本，还是工具返回绕开了管线。修复后分别跑识别测试和完整应用测试，避免只改一条检测规则让报告变绿。

假设用户 A 请求了用户 B 的订单。即使输出中姓名和手机号被遮盖，订单状态、消费信息或业务事实仍可能不应返回。正确做法是后端拒绝不允许的数据访问，输出处理只是附加措施。

租户 ID、用户 ID 和授权状态应来自可信服务端上下文。把它们放在模型提示词里，并不让模型成为可靠的权限系统。数据库过滤、工具可调用范围、审批和实际执行都需要独立控制及测试。

涉及发邮件、退款或删除记录时，也不能把模型的“已检查”当成授权。测试环境应隔离真实副作用，必要的审批逻辑应在代码或业务服务里执行，且在回归里验证不能被跳过。