敏感信息护栏

自动检测并处理 API 请求中的敏感信息

敏感信息护栏可以在请求到达模型服务提供商之前，自动检测并处理敏感信息——例如电子邮件地址、电话号码、信用卡号和姓名。检测到敏感数据时，你可以选择 遮蔽（Redact）（替换为占位符）或 阻止（Block）（直接拒绝请求）。

该功能属于护栏的一部分，可以与预算上限、模型限制及其他护栏设置一起配置。

工作原理

当敏感信息护栏处于启用状态时，每次 API 请求在转发到模型服务提供商之前都会被扫描：

1. 检测 — 对照你配置的模式和预设检查请求内容。
2. 操作 — 若发现匹配，则应用已配置的操作：
   • 遮蔽：匹配文本替换为带标签的占位符（例如 [EMAIL]、[PHONE]、[REDACTED]），修改后的请求再转发到模型服务提供商。
   • 阻止：整个请求以 HTTP 403 Forbidden 错误被拒绝。
3. 转发 — 若未检测到敏感信息（或所有匹配都已被遮蔽），请求按正常流程进入模型服务提供商。

检测方法

OpenRouter 使用两种互补的检测方法：

基于正则的检测

大多数内置预设以及全部自定义模式使用正则表达式匹配。这种方式速度快、结果确定，给请求增加的延迟可以忽略不计。

基于正则的预设包括：

• 电子邮件地址
• 电话号码
• 社会安全号码（SSN）
• 信用卡号
• IP 地址

基于 NLP 的检测

有些类型的敏感信息——例如人名和实际地址——无法用简单模式可靠检测。对于这些类型，OpenRouter 使用由 NLP 驱动的实体识别（通过 Presidio），结合上下文分析文本。

基于 NLP 的预设包括：

• 人名 （测试版）
• 实际地址 / 地点 （测试版）

内置预设

以下预设开箱即用。每一项都可以单独启用，并配置为 遮蔽 或 阻止 操作。

NLP 预设限制

基于 NLP 的检测依赖上下文，且是概率性的。请注意以下事项：

人名：

• 缺少周围上下文时可能无法捕获姓名
• 不常见或非西方姓名可能被漏检
• 单字姓名（例如 “Cher”）更难检测

地址：

• 没有城市/州的不完整地址可能被漏检
• 有歧义的地点名称（例如 “Paris” 作为人名还是城市）取决于上下文
• 非标准或缩写格式可能无法被检测

自定义模式

除内置预设外，你还可以定义自己的自定义正则模式，以检测特定于业务领域的敏感信息。每条自定义模式需要：

• 模式 — 有效的正则表达式
• 操作 — redact 或 block

自定义模式在 遮蔽 操作下匹配时，匹配文本会替换为 [REDACTED]。设为 阻止 时，整个请求会被拒绝。

自定义模式示例

模式安全性

模式会按以下方面校验：

1. 语法 — 必须是有效的 JavaScript 正则表达式。
2. 安全性 — 不得存在灾难性回溯漏洞（ReDoS）。带有嵌套量词的模式（如 (a+)+ 或 (a|a)*）会被拒绝。

无效或不安全的模式会在创建时被拒绝，并返回描述性错误消息。

配置敏感信息护栏

通过控制台

1. 前往工作区的 隐私与护栏（Privacy & Guardrails） 页面，或打开 设置 > 隐私。
2. 创建新护栏或编辑现有护栏。
3. 展开 敏感信息（Sensitive Info） 部分。
4. 启用所需的内置预设，和/或添加自定义模式。
5. 为每个预设或模式选择操作：遮蔽 或 阻止。
6. 保存护栏。

你可以使用 全部启用（Enable all） / 全部禁用（Disable all） 按钮快速切换所有内置预设。

通过 API

敏感信息过滤器作为护栏对象的一部分，通过 content_filter_builtins 和 content_filters 字段配置。

内置预设 使用 content_filter_builtins 字段：

{
  "name": "个人身份信息保护",
  "content_filter_builtins": [
    { "slug": "email", "action": "redact" },
    { "slug": "phone", "action": "redact" },
    { "slug": "ssn", "action": "block" },
    { "slug": "credit-card", "action": "block" },
    { "slug": "ip-address", "action": "redact" },
    { "slug": "person-name", "action": "redact" },
    { "slug": "address", "action": "redact" }
  ]
}

可用 slug：email、phone、ssn、credit-card、ip-address、person-name、address。

自定义模式 使用 content_filters 字段：

{
  "name": "自定义过滤器",
  "content_filters": [
    { "pattern": "AKIA[0-9A-Z]{16}", "action": "block", "label": "AWS 密钥" },
    { "pattern": "PROJ-\\d{4,6}", "action": "redact" }
  ]
}

每条自定义过滤器都支持可选的 label 字段，用于阻止时提供描述性错误消息。

完整端点文档见 护栏 API 参考。

敏感信息与其他护栏的交互

敏感信息过滤器遵循与其他护栏设置相同的护栏层级。当多条护栏作用于某次请求时：

• 内容过滤器取并集 — 若成员护栏有电子邮件过滤器，API 密钥护栏有电话过滤器，则两者都生效。
• 阻止优先于遮蔽 — 若同一实体类型在多条护栏中出现且操作不同，以更严格的操作（阻止）为准。
• 自定义过滤器与内置过滤器合并 — 所有适用护栏（默认、成员和 API 密钥层级）中的过滤器会合在一起。

错误响应

当请求被内容过滤器阻止时，API 返回：

{
  "error": {
    "code": 403,
    "message": "Request blocked by content filter: [LABEL]"
  }
}

错误消息中的 [LABEL] 取决于触发阻止的原因：

• 对于内置预设：预设标签（例如 Email address、Social Security number）
• 对于带有 label 字段的自定义模式：自定义标签
• 对于没有标签的自定义模式：[BLOCKED]
• 对于 NLP 检测到的实体：实体类型（例如 Blocked PII detected: PERSON）

报告误报

如果检测错误地标记了合法内容，你可以在日志（Logs）页面将其标为误报。带有护栏事件的生成记录行上会显示盾牌图标；悬停即可打开护栏弹出框。

当只检测到一种实体类型时，直接在弹出框中点击 标为误报（Mark as false positive）：

当检测到多种实体类型时，弹出框会改为链接到生成详情视图，你可以在其中选择要报告的具体实体类型：

在详情视图中，于 标为误报 下勾选被错误标记的实体类型，然后点击 提交（Submit）：

该事件会被可视化标记，你的反馈会记录下来，用于改进后续检测。

最佳实践

• 从遮蔽开始 — 刚开始时将 遮蔽 作为默认操作。这样请求可以继续进行，同时保护敏感数据，让你有时间评估检测准确率，再切换到 阻止。

• 对常见个人身份信息（PII）使用内置预设 — 内置预设针对常见格式做了调优，是最容易上手的方式。对特定于业务领域的数据再添加自定义模式。

• 注意 NLP 延迟 — 人名 和 地址 预设使用基于 NLP 的检测，延迟与输入大小成正比。如果延迟很关键，可考虑只使用基于正则的预设。

• 部署前先测试 — 使用护栏编辑器中的测试预览，在保存并分配护栏前验证过滤器是否按预期工作。如果检测误触发，你可以在日志页面报告误报。

• 与其他护栏设置结合 — 敏感信息过滤器可与预算上限、模型允许列表、模型服务提供商限制和零数据保留（ZDR）强制执行一起使用。将它们组合起来可实现全面治理。

• 为自定义阻止模式添加标签 — 给使用 阻止 操作的自定义模式添加 label，可以为 API 调用方提供更清晰的错误消息，更容易理解请求被拒绝的原因。