跳转到主要内容
你的应用发往模型的任何一条提示词都可能携带它本不该携带的 个人数据——粘进工单的一个邮箱、CRM 备注里的一个 SSN、用户在 聊天框里输入的一个卡号。一旦那段文本到达上游提供商，它就脱离 了你的掌控：被记录、被缓存，甚至可能被用于训练。模型的响应 也可能把 PII 泄露回来，回显或推断出某些细节，进而落入你应用 自己的日志。 本页展示如何在网关上用一条 PII 防护栏拦下一次 llm pii leak——一条工作区限定的规则，在模型见到请求之前 就对其中的敏感实体进行 mask 或 block。它是 智能体防火墙 在内容层的对等物，且无需 修改你的应用代码。
一条 PII 防护栏筛查提示词和响应的文本。要治理一个智能体 对数据所采取的动作——抓取工具、egress 主机——参见 数据外泄。这两个平面 可以组合；大多数团队两者都用。

​
1. 暴露是如何发生的

PII 通过普通的、出于善意的流量到达上游提供商：
  • 一个用户把自己的联系方式粘进聊天，而你的应用原样转发了整条 消息。
  • 一条 RAG 流水线检索到一份包含客户记录的文档，并把它塞进提示词 作为上下文。
  • 一个智能体读取一行数据库记录，并把原始字段放进一个工具参数 或一条后续提示词里。
  • 模型的响应复述或推断出 PII，而你的应用随后又把它写进了 自己的日志。
这些都不是攻击——它们正是 LLM 应用的正常形态。解决办法是一条 在单一咽喉点上筛查每一个请求和响应的策略，而不是去审计你代码 里的每一处调用点。

​
2. 用 PII 防护栏防御 llm pii leak

一条防护栏是一个工作区限定的、命名的 内容策略。其中的一条 pii 规则会检测敏感实体，并对每个匹配 应用一个动作：
动作效果
mask把每个匹配替换为一个带类型的标记——jane@acme.com → [EMAIL]——并转发清理后的文本。模型永远见不到原始值。
block用 HTTP 400 guardrail_blocked 拒绝整个请求。当 PII 绝不允许到达提供商时使用。
flag不改变流量的任何内容；记录一次匹配。在你执行之前先衡量暴露面。
检测器集合是内置且确定性的——纯粹的模式匹配，没有网络调用， 在热路径上安全。内置实体： email、phone、credit_card、ssn、ip、iban、mac_address、jwt、 aws_access_key、api_key_openai、bitcoin_address，外加经校验和 门控的区域性标识符 jp_mynumber、kr_rrn 和 cn_resident_id。 在 mask 动作下，每个匹配都渲染为它带类型的标记——[EMAIL]、[SSN]、 [CREDIT_CARD] 等等——这样提示词的结构得以保留，而其中的值 已不复存在。
需要一个并未内置的检测器（一个内部员工 ID、一个账号）？添加一个 自定义实体——一条正则，带可选的 Luhn 校验和，每条规则最多 25 个 ——就放在内置实体旁边。参见 防护栏参考。

​
3. 具体示例——在请求上 mask PII

最快的起点是 PII Shield 预设：一条对 email、phone、ssn、 credit_card 和 ip 进行 mask 的 pii 规则。在控制台中配置它—— 无需修改代码，这一步也无需密钥。
1

创建防护栏

在控制台中，打开 Guardrails 并点击 New guardrail。从 pii 类别里选择 PII Shield 预设，或者手动编写一条对上述 实体执行 mask 动作的 pii 规则。保存。（写入需要 Developer 角色或更高。）
2

在沙箱里证明它有效

打开 Test 标签，粘贴 “reply to jane@acme.com”，选择 input 执行面，然后运行。沙箱返回 reply to [EMAIL]——在本地完成， 没有上游调用，也不消耗配额。
3

把它附加到一个密钥

在 API Keys 中，编辑一个密钥并从 Guardrail 下拉中选中该 防护栏，或者把该防护栏设为工作区默认值，这样每个未附加的密钥 都会继承它。绑定关系存在于网关的密钥上。
4

像往常一样调用网关

使用那个密钥，你的中继调用保持不变：
curl https://api.orcarouter.ai/v1/chat/completions \
  -H "Authorization: Bearer sk-orca-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-4o-mini",
    "messages": [
      {"role": "user", "content": "Draft a reply to jane@acme.com"}
    ]
  }'
网关在转发之前把邮箱改写为 [EMAIL]。上游模型永远收不到这个 地址。
PII Shield 是一条 both 执行面的规则，但当下已上线的是实时 请求阶段的 mask——网关在提示词离开发往模型之前对其进行 mask。 实时中继上的输出阶段（响应）mask 仍在路线图上。要验证一条 响应阶段规则的表现，请在 Test 标签里对它求值。关于流式， 参见 §5。

​
4. 大部分 mask、最糟的 block——按实体覆盖

单条规则可以通过 entity_actions 对不同实体应用不同动作。对 低风险标识符做 mask，但对你绝不希望被转发的实体做硬 block ——一条规则，而非三条相互重叠的规则： 
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "entities": ["email", "phone", "ip", "credit_card", "ssn"],
  "entity_actions": {
    "credit_card": "block",
    "ssn": "block"
  }
}
这里，邮箱、电话和 IP 被 mask 后放行；而一条携带卡号或 SSN 的 提示词会被改为用 HTTP 400 guardrail_blocked 拒绝。一个被拦截的 请求不消耗配额——一次输入阶段的 block 在计量之前就触发—— 并被标记为 skip-retry。每个 entity_actions 键都必须是规则上 声明过的实体（内置或自定义）；它的动作会针对该规则的动作集 进行校验。

​
5. 当下流式上有效的部分

动作与执行面跟流式的交互各不相同——在依赖它之前先了解这张 对照表：
完全实时。提示词在上游调用之前就被筛查，因此无论响应是否 流式，mask 和 block 都同样有效。这是 PII Shield 今天所执行的 执行面。
在流式和非流式响应上都被执行。在流式中，一个扫描器会中途切断 数据流，并在任何被拦截的内容到达客户端之前发出一条替代消息； 一次输出 block 会退还预先消耗的配额。
当前仅限非流式。在流式响应上，原始块会原样不经 mask 地 通过——带内（in-band）的流式改写是一项计划中的增强。要在 今天对响应做 mask，请使用非流式请求，或者依赖输入阶段的 mask。先在 Test 标签里证明你确切的阶段/流式组合。

​
6. 查看捕获到了什么

每一条触发的规则都会记录一次匹配（match）——它的类型、动作、 阶段，以及一个详情字符串——可在工作区 Matches 信息流上查看 （GET /api/guardrail/match，对任何成员开放）。从那里你可以分组、 过滤、导出为 CSV，并标记误报。
原始值默认不被记录。 一条防护栏的 Log raw content 开关 是关闭的——这是隐私保守的姿态——因此 Matches 信息流记录的是 一条 PII 规则触发了以及命中了哪个实体，但不记录命中的子串 （即那个邮箱地址本身）。仅在你为分类排查需要那个值时，才逐条 防护栏开启它；该设置不追溯既往。为了调试一次 PII 泄露而把 PII 捕获进你自己的审计追踪，反而会适得其反。

​
7. 更进一步

要获得完整的数据驻留、保留和被遗忘权控制——包括安装一个 合规包来为 GDPR、HIPAA 或 PCI DSS 物化这些防护栏——请从下面的 参考页面开始。

防护栏参考

每一种规则类型、阶段、动作、自定义实体、版本管理，以及评估 框架——本页背后的深度参考。

密钥泄露

凭据形态的姊妹篇——AWS、OpenAI、GitHub 令牌——由 Secrets Blocker 防护栏捕获。

不安全输出

筛查模型发回的内容，而不只是它接收的内容。

防护栏 vs 防火墙

何时筛查文本、何时治理动作——以及为什么你通常两者都需要。