智能体通过三种方式泄露数据：通过它在工具调用中转发的参数，通过它写入对话内存的内容，以及通过它在响应中回显的内容。一份政策备忘录无法阻止这三者中的任何一个——它们看起来都只是智能体在正常完成自己的工作。真正能阻止它们的，是一个运行时令牌化层，它会在这三个点各自拦截文本，并在数据跨越你的边界之前剥离其中的 PII。下面就是这个层的工作原理。
对进入 LLM 提示词的内容进行脱敏只是最基本的要求，并不能填补这个缺口。智能体的数据路径上有三个地方，原始值可能从中离开边界，而这三个地方都不经过提示词。
智能体决定调用某个工具——日历 API、CRM、支付处理器等——并将它正在推理的数据作为调用参数转发出去。MCP 不携带按字段区分的敏感度元数据，因此在默认情况下，工具服务器收到的就是智能体发送的明文内容，不多不少。
对话历史会跨轮次持续存在，以便让智能体保有上下文。追加到该历史中的任何文本——包括在对话中途出现的客户社会安全号码或医疗细节——都会以明文形式留在那里，贯穿整个会话生命周期，除非有某种机制在追加发生之前先对其进行令牌化。
返回给调用方的最终响应，是基于智能体检索并推理过的上下文构建而成的。如果令牌化只在数据进入时执行一次，那么一个原本以令牌形式进入的值，仍有可能在发出的响应中以未令牌化的原始形态重新浮现。
关于为什么工具调用——而不是提示词——才是大多数生产环境泄露实际发生的地方，更深入的论证见于 你的 AI 智能体正在通过工具调用泄露 PII。这是证据。
VeriSwarm Guard 用同一个底层调用——POST /v1/suite/guard/pii/tokenize——关闭全部三个向量，该调用被应用在每个向量本来会发生泄露的那个点上。文本会经过一个基于 Presidio 的 NER 检测引擎（Presidio + spaCy NER，外加针对 Presidio 默认无法覆盖的标识符所定制的正则识别器），返回时每一段 PII 都已被替换为类型化令牌——[VS:EMAIL:a1b2c3]、[VS:SSN:f9e2d1] 等等。智能体、工具服务器，以及中间被记录下来的任何内容，看到的都只是令牌。原始值只有在确实需要时，才会通过一次单独的 POST /v1/suite/guard/pii/rehydrate 调用来还原，且该调用的作用范围限定在创建这些令牌的会话内。
Guard Proxy 是一个透明的 MCP 拦截层。把你的智能体的 MCP 客户端指向这个代理，而不是直接指向工具服务器，它就会对外发的工具调用请求和收到的工具调用响应两端的 PII 都进行令牌化——无需对智能体代码做任何修改。三种部署模式：云托管、本地部署 Docker、本地 stdio。
VeriSwarm 自己的智能体运行时会在该响应被追加到对话历史之前，以及在它被返回给调用方之前，对智能体的响应调用令牌化端点。写入内存的值和回显的值是同一份已令牌化的文本——而不是两个可能彼此脱节的独立控制点。
PII 保护支柱涵盖了更宏观的论证——为什么应该选择令牌化而不是提示词输入脱敏，为什么 DLP 覆盖不到智能体流量、GDPR 假名化的但书条款、Vault 审计追踪，以及医疗健康行业的定位。这个页面更窄、更偏操作层面：它是一张地图，标出智能体数据路径中实际发生泄露的三个具体位置，以及各自由哪种机制来关闭。想了解完整架构和合规论证，请阅读支柱页面；想知道具体应该把修复措施对准哪里，请阅读本页。
令牌化会降低上述三个向量的 PII 暴露面，并在启用 Vault 时为每一次拦截提供审计追踪——但它并不能保证数据永远不会泄露。绕过 Guard Proxy 的工具调用，或者在转发数据之前不调用令牌化端点的自定义集成，都是这一层永远看不到的泄露路径。Guard 只关闭它已经接入的向量；如果你构建出一条它尚未覆盖的泄露路径，第一次接入它就是你自己的责任。注入是一种相关但不同的风险——它是操纵调用哪个工具的精心构造的输入，而不是合法工具参数中的 PII——详见 AI 智能体的提示词注入检测。
通过工具调用参数——智能体把原始 PII 以明文形式转发给 MCP 工具服务器（日历 API、CRM、支付处理器等）。通过写入内存的内容——客户的社会安全号码或某个医疗细节被追加到对话历史中，并在整个会话期间一直留在那里。通过回显的内容——即便响应是基于已令牌化的上下文构建的，只要在输出时跳过了令牌化步骤，原始值仍可能重新浮现。这三者有一个共同点：没有一个看起来像是违反了策略，它们看起来都只是智能体在正常完成自己的工作。
不够——那只是堵住了危害最小的那个泄露点。LLM 从不接触 PII 是良好实践，但真正让数据离开你边界的，是 LLM 之后决定发起的工具调用。即便智能体在提示词内容上极度谨慎，也可能因为 MCP 规范本身并不携带按字段区分的数据敏感度元数据，而把客户的电话号码原封不动地转发给第三方 MCP 工具服务器。覆盖范围必须延伸到工具调用这一步，而不能止步于模型边界。
文本会被传给 POST /v1/suite/guard/pii/tokenize，该端点会让文本经过一个基于 Presidio 的 NER 检测引擎（Presidio + spaCy NER，外加针对 Presidio 未覆盖的标识符所定制的正则识别器），返回时每一段 PII 都已被替换为类型化令牌——[VS:EMAIL:a1b2c3]、[VS:SSN:f9e2d1] 等等。令牌到原值的映射按租户隔离，且从不随令牌化后的负载一起传输。令牌只能通过一次单独的 POST /v1/suite/guard/pii/rehydrate 调用还原，该调用的作用范围限定在创建这些令牌的会话内，专用于下游系统确实需要真实值才能完成工作的特定场景——例如写入 CRM 记录。
对于工具调用这个向量，不需要。Guard Proxy 是一个透明的 MCP 拦截层——你的智能体的 MCP 客户端会指向代理 URL，而不是直接指向工具服务器，它会在外发的工具调用和收到的响应跨越边界之前，分别对两者中的 PII 进行令牌化。三种部署模式覆盖了云托管、本地部署 Docker 和本地 stdio。对于内存和回显这两个向量，VeriSwarm 自己的智能体运行时早已在把响应追加到对话历史或返回给调用方之前调用令牌化端点——这部分线路是平台自带的，不需要你自己搭建。
Guard——PII 令牌化、Guard Proxy，以及与之并行运行的注入扫描——是 Max 套餐的功能。Gate 是 VeriSwarm 免费套餐提供的信任评分能力，能在你需要令牌化层之前，就先让你看清智能体行为和事件流；而真正开启强制执行的地方是 Guard。
不能，如果有厂商这么宣称，你应该保持怀疑。令牌化会在这里涉及的三个向量中分别降低 PII 暴露面，并在启用 Vault 时为每一次拦截提供审计追踪。但它并不覆盖这三者之外的泄露路径——比如绕过 Guard Proxy 的错误配置集成，或者不经过令牌化步骤的自定义工具调用路径，仍然需要你主动、刻意地把它们接入进来。
Guard 的 PII 令牌化是 Max 套餐的功能；Gate 的免费套餐会为你提供信任评分和事件可见性，让你在开启修复功能之前，先看清一个智能体的数据实际流向了哪里。