如今，生产环境中的大多数自主智能体会将原始 PII——姓名、电子邮件、社会安全号码、支付数据——直接发送给第三方 MCP 工具服务器，既没有令牌化，也没有审计追踪。解决方案不是一份政策备忘录，而是一个位于智能体与每个外部工具之间的拦截层，在数据离开你的边界之前先对其进行令牌化，并将每一次接触都记录在一个不可篡改的账本中。这就是 VeriSwarm Guard 处理这一问题的方式。
AI 智能体的 PII 保护是指防止个人身份信息通过智能体所经过的数据路径——提示词输入、LLM 上下文、MCP 工具调用、第三方服务以及外发响应——发生泄露，同时仍然允许工具对这些数据执行有用的工作。它是 LLM 输入编辑（redaction）的超集：在生产环境中危害最大的泄露点并非 LLM 本身，而是 LLM 决定发起调用之后的那次工具调用。
一个典型的智能体工作流是这样的：用户提供姓名、电子邮件、电话号码和一张信用卡信息。LLM 对其进行处理。随后智能体调用一个工具——日历 API、CRM、支付处理器——并通过 MCP 以明文形式转发这些数据。MCP 规范本身并不天然携带用户上下文；工具服务器无法区分不同用户，也无法实施按用户划分的控制。在默认情况下，每一类数据——PII、凭据、财务数据——都可能在单次工作流中以机器速度被转发到外部。
关于弥合这一缺口的具体步骤，请参见如何防止 AI 智能体数据泄露。
2026 年的数据并不好看：
数据防泄漏（DLP）技术是为一个人们靠复制文件和发送电子邮件的世界而构建的。智能体的工具调用打破了 DLP 所依赖的每一项假设：
一个智能体每分钟可以发起数百次工具调用。传统的 DLP 检查若想跟上这一速度，就必然成为瓶颈，反而抵消了自动化的意义。
DLP 策略通过已知渠道对静态或传输中的数据进行分类。而 MCP 工具调用是动态的、程序化的，会经过安全团队甚至不知道存在的端点。
模式匹配可以捕获已知格式（卡号、社会安全号码），但会遗漏依赖上下文的 PII，例如病情信息，或者被拆分到多个令牌中的标识符。这正是需要对结构化数据进行 NER 处理的地方。
真正有效的架构，是在智能体与其工具之间设置一个运行时拦截层。Guard Proxy 正处于这一位置。Presidio（微软的开源 NER 引擎）会在工具调用离开边界之前，检测并令牌化各类 PII——姓名、电子邮件、电话号码、社会安全号码、信用卡、IP 地址，以及金融或政府颁发的证件号码（银行账户、驾照、护照）。工具服务器看到的是[PERSON_1]，而不是“Jane Smith”。LLM 基于该令牌进行推理。原始值只会在返回给授权用户的最终响应中被还原。这不是事后扫描，而是内联转换。
转换器流水线按固定顺序运行四个内置转换器——先进行 PII 令牌化，再依次进行上下文注入、字段掩码和模式校验。关于每个转换器具体做什么、由什么触发，以及如何添加自定义转换器的完整拆解，见Guard Proxy 的四个转换器：各自拦截什么，按什么顺序。
三种部署模式（云托管、本地部署 Docker、本地 stdio）覆盖了从“把你的智能体指向一个 URL”到“数据永远不会离开你的 VPC”的整个范围。
令牌化属于假名化，而不是匿名化。根据 GDPR 第 4(5) 条，经过假名化处理的数据仍然属于个人数据——令牌加上查找表仍可重新识别出该个人身份，而且即便没有查找表，多个已令牌化的字段组合起来也可能暴露身份。这意味着经 Guard 令牌化处理的数据负载仍然落在 GDPR 的适用范围之内，只是所需的控制措施发生了转移。
在实践中，令牌化会缩小一次数据暴露事件的影响范围，并证明满足第 32 条所要求的“最新技术水平”控制措施——但它并不能消除数据主体权利、数据泄露通知义务，或者处理活动记录方面的要求。任何声称令牌化能让 PII“不再是个人数据”的厂商，要么是理解有误，要么就是在向你推销某种说辞。我们不会这样宣称。
每一次 PII 拦截都会记录在 Vault 的哈希链账本中——发送了什么、令牌化了什么、返回了什么、发生的时间、涉及哪个智能体身份、针对哪个工具。当审计人员问“这位客户的数据去了哪里？”时，答案是一条经过密码学验证的时间线，而不是某个监控工具的一张截图。链验证可以检测篡改；导出的数据直接对应 GDPR 第 30 条对处理活动记录的要求。
关于链验证失败那一天该怎么办的运行手册——包括对应的端点、响应结构、排查步骤——见验证 Vault 链：完整性被破坏那一天的运行手册。
医疗行业是智能体与工具边界上对 PII 保护要求最苛刻的场景。2025 年的 OCR 执法记录显示，风险分析方面的问题以 3:1 的比例主导了和解案件，平均罚款约为 291,000 美元，外加 2 年的监督义务。Guard 的令牌化、Vault 的账本，再加上智能体层面的评分闭环，共同构成了一种能够经受住这类审计的姿态——它已经被集成到医疗垂直场景之中，默认启用与 HIPAA 保持一致的默认配置。
是令牌。Guard Proxy 会在拦截边界对 PII 进行令牌化——包括姓名、电子邮件、电话号码、社会安全号码、信用卡、IP 地址，以及金融或政府颁发的证件号码（银行账户、驾照、护照）——然后 LLM 基于该令牌进行推理。工具服务器接收到的是令牌。原始值只会在返回给授权用户的最终响应中被还原；下游的任何环节都不会看到明文。
该映射表存在于租户自己的 Guard Proxy 部署内部，绝不会随令牌化后的数据负载一起通过网络发送。在云托管模式下，它由租户专属的加密机制保护；在本地部署 Docker 模式下，它永远不会离开你的网络。令牌格式只能通过那把密钥进行还原，因此，即便某次工具调用被截获，泄露的也只是令牌，而不是它背后的真实值。
这是众多控制措施之一。在工具调用边界进行令牌化，能让 PHI 远离 LLM 上下文，远离你无法控制的 MCP 工具服务器，并被记录进 Vault 的哈希链账本，使数据流转记录能够经受住审计。完整的 HIPAA 合规姿态还需要与下游工具服务器签订 BAA、在智能体自身上部署签名清单（Passport），以及围绕数据泄露响应建立运营流程。运行时令牌化弥补了最大的技术缺口；剩下的是文书工作和运营层面的事情。
编辑会销毁原始值（不可逆）——适合遥测和日志，但当工具需要该数据才能正常工作时就毫无用处。掩码只做部分遮蔽（例如仅保留卡号后 4 位）——适合面向人类阅读的界面。阻断会完全拦下该调用——适用于严重违反策略的情形。令牌化能够在移除敏感信息的同时保留数据的可用性——在这四种方式中，只有它能让工具服务器在看不到原始值的情况下继续完成有用的工作。Guard 同时支持这四种方式；具体选择哪一种，取决于数据类别和策略。
是的——这正是它的主要应用场景。Guard Proxy 是一个透明的 MCP 拦截层，提供三种部署模式（云托管、本地部署 Docker、本地 stdio）。你的智能体的 MCP 客户端会指向 Guard Proxy，而不是直接指向工具服务器；Guard Proxy 会转发去除 PII 后的调用，并返回响应。无需对智能体代码做任何修改。
是的——同一套令牌化机制同时覆盖两者。除了个人数据之外，检测器还能识别各种凭据格式——GitHub 令牌、OpenAI 密钥、AWS 密钥、Slack 令牌、GCP 密钥、Stripe 密钥、JWT，以及私钥数据块——并按照对姓名或社会安全号码令牌化的相同方式对它们进行令牌化。一旦有 API 密钥在被发往某次工具调用的途中发生泄露，它会在离开你的边界之前就被拦截下来，而不只是被泄露的社会安全号码才会被拦截。
令牌会在一个可配置的 TTL——默认为一小时——之后过期，并被限定在特定的租户和会话范围内，因此为某一次对话生成的令牌无法在另一次对话中被重放。原始值会在静态存储时被加密（采用 Fernet 对称加密），而每一次将其还原为明文的操作都会被记录下来以供审计。即使令牌本身泄露，如果没有同时具备加密密钥以及一个处于活动状态且范围受限的会话，它也毫无用处。
它会遍历整个数据结构。Guard 的令牌化器会递归遍历一次工具调用参数——以及响应体——中的每一个字典和列表，因此，无论 PII 是深藏在 `data.customer.email` 这样的路径中，还是位于某个记录列表内部，都会像顶层字段一样被令牌化。早期版本只检查顶层，这导致典型 MCP 负载结构中嵌套的 PII 会未经处理地直接通过——这一缺口已作为一项严重修复被彻底关闭。
Guard Proxy 不需要对你的智能体代码做任何修改。只需将你的 MCP 客户端指向 Guard Proxy，而不是直接指向工具服务器；Guard Proxy 会转发去除 PII 后的调用，并返回响应。Gate 的免费套餐会先让你看清库存与事件流的全貌——这样你就能在开启修复之前先看到问题所在。