PII Tokenization

AI智能体通常需要处理涉及个人身份信息（PII）的工作流，例如电子邮件、电话号码、地址或金融数据。然而，将原始PII传入模型的context会带来隐私风险与合规性问题。企业需要智能体在不向LLM暴露敏感信息的前提下编排数据工作流。

在模型上下文协议（Model Context Protocol，简称MCP）客户端中实现一个拦截层，确保个人身份信息（PII）在抵达模型前自动完成标记化处理，并在后续发起工具调用时执行逆标记化处理。

架构：

graph LR
    A[工具响应] --> B[MCP客户端]
    B --> C{PII检测}
    C --> D[标记化处理]
    D --> E[模型上下文]
    E --> F[模型推理]
    F --> G[工具调用请求]
    G --> H[逆标记化处理]
    H --> I[实际工具调用]

流程：

1. 拦截：工具返回数据时，MCP客户端拦截响应内容
2. 检测：通过模式匹配或分类模型识别PII
3. 标记化：将真实值替换为占位符
   • john.doe@company.com → [EMAIL_1]
   • (555) 123-4567 → [PHONE_1]
   • 123-45-6789 → [SSN_1]
4. 模型推理：Agent基于标记化后的占位符开展工作
5. 逆标记化：当Agent携带占位符发起工具调用时，MCP客户端将占位符替换回真实值

示例工作流：

# 工具返回客户数据
customer = get_customer(id="C123")
# 原始数据：{"name": "John Doe", "email": "john@example.com", "phone": "555-1234"}

# MCP客户端在发送至模型前执行标记化
# 模型上下文接收到的内容：{"name": "[NAME_1]", "email": "[EMAIL_1]", "phone": "[PHONE_1]"}

# Agent基于标记后的占位符进行推理
"Send welcome email to [EMAIL_1] with link for [NAME_1]"

# MCP客户端为工具执行做逆标记化处理
send_email(
    to="john@example.com",  # 已替换为真实值
    body="Welcome John Doe, here's your link..."  # 已替换为真实值
)

适用场景：

• 处理客户数据、HR记录、医疗信息的工作流
• 涉及个人可识别信息（PII）的多步骤自动化流程
• 合规敏感环境（GDPR、HIPAA、CCPA）
• 无需“查看”原始PII即可协调数据流的Agent

实施要求：

1. PII检测层：

   • 针对常见PII（邮箱、电话、社会安全号码SSN、信用卡）的正则表达式（Regex）匹配模式
   • 用于识别姓名、地址的命名实体识别模型
   • 针对领域专属敏感数据的自定义规则

2. 令牌映射存储：

   • 令牌与真实值的安全映射机制
   • 会话作用域或请求作用域的生命周期
   • 若采用持久化存储则需启用静态加密

3. 工具调用中的反令牌化：

   • 扫描输出的工具调用参数
   • 在执行前将占位符替换为真实值
   • 维护引用完整性（同一占位符对应同一真实值）

集成要点： 在MCP客户端层实施时效果最佳，如此一来对Agent（仅可见令牌）和工具（可见真实值）均可保持透明。

优点：

• 防止原始PII进入模型上下文（model context）
• Agents可在不查看数据的情况下协调敏感工作流
• 支持不包含PII的审计追踪（audit trails）
• 降低合规风险与监管负担
• 对Agent推理过程透明（通过占位符实现）

缺点：

• 增加MCP客户端实现的复杂度
• PII检测必须精准（需避免误报/漏报）
• 无法防范PII推断（模型可能推导出敏感信息）
• 需要安全的令牌映射（token mapping）存储机制
• 可能增加调试难度（排查问题时需将令牌反向映射）
• 模式匹配可能遗漏新型PII格式

局限性：

• 无法阻止模型学习PII结构相关模式
• 若无自定义规则，无法识别特定领域的敏感数据
• 上下文相关PII（如“我的地址是……”）可能在令牌化前泄露
• 无法替代完善的访问控制与加密措施