跳转到主要内容
当一条防护栏规则触发时,OrcaRouter 会记录一条匹配,因此你可以 看到什么触发了以及多频繁。本页回答的隐私问题是:那条记录是否 包含实际的敏感文本——真实的 email、SSN、API 密钥——还是只是一条 规则匹配了这一事实? 默认情况下它只包含事实。托管网关上的防护栏隐私日志刻意保守: 除非你为那个防护栏明确开启 Log raw content,否则匹配的子串 被存储,而且翻转该开关永远不会回溯到你已经记录的数据。 这是 Matches 信息流隐私姿态的专注落地页。信息流本身——浏览、 分组、导出——参见Matches 信息流。 完整引擎参见防护栏参考

1. 防护栏隐私日志:默认关闭

每个防护栏都带有一个按策略的单一开关 Log raw content,它发布时 关闭。当它关闭时,匹配记录触发内容的元数据,但永不把违规文本 复制进信息流:

开关关闭时记录

规则类型、动作、阶段和一个简短的详情字符串——足以知道一条 pii 规则在请求上脱敏了一个 email,而不存储该地址。

仅开启时增加

匹配的子串——规则捕获的字面文本。只为你启用开关之后 记录的匹配捕获。
其理据正是大多数合规团队默认想要的:你了解到一个 SSN 出现在你的 流量中以及策略如何处理它,而不把受监管的数据从请求中复制出来 进入你自己的诊断存储。
默认关闭是隐私保守的姿态。 匹配的子串是防护栏可能记录的最 敏感的东西——按定义它就是规则存在所要捕获的数据。除非你按防护栏 选择开启,否则 OrcaRouter 不存储它。

2. 一条匹配记录持有什么

匹配是一条小型的、工作区级别的诊断记录。当 Log raw content 关闭时,它只携带元数据:
字段示例开关关闭时是否存在?
规则类型piiregexkeyword
动作blockmaskflag
阶段inputoutput
详情简短分类字符串(例如实体)
匹配的子串jane@acme.com仅开启时
匹配子串字段是该开关唯一门控的东西。其他一切无论如何都会被 记录,因此即使原始内容关闭,信息流对于流量、趋势和动作组合分析 仍然有用。
你可以纯粹基于元数据运行一整套观察或执行计划——看 PII 在哪里 进入、哪些规则触发最多、一个策略是否嘈杂。只在你需要在分诊期间 亲眼看确切匹配了什么的那个狭窄窗口开启子串。

3. 一个具体示例

拿一个带有在请求上脱敏 emailpii 规则、绑定到一个密钥的 防护栏。一个调用方发送:
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": "Reply to jane@acme.com please"}
    ]
  }'
规则在模型看到之前把地址脱敏为 [EMAIL],一条匹配落入信息流。 那条匹配包含什么完全取决于该开关:
匹配记录:规则类型 pii、动作 mask、阶段 input,以及一个 指明 email 实体的详情字符串。它存储 jane@acme.com。 你知道一个 email 在请求上被脱敏了;你无法从信息流中读回该 email。
同一条匹配额外携带匹配的子串——jane@acme.com——因此你可以在 一次分诊中精确确认规则捕获了什么。
两种情况下请求本身都相同。该开关只改变诊断信息流保留什么, 永不改变调用方或上游模型经历什么。

4. 开启它(以及不可追溯保证)

Log raw content 是一个按防护栏的设置。编辑一个防护栏是你 自己会话下的控制台操作,且需要工作区中的 Developer+——只有 最后的 /v1/* 调用使用 sk-orca-... 中继密钥。
1

打开防护栏

在控制台中打开 Guardrails,编辑你想为之捕获子串的策略。
2

启用 Log raw content

开启 Log raw content 开关并保存。保存会写入一条版本化的 历史记录,因此该变更可审计且可回退——参见 版本管理
3

捕获从此向前开始

从下一个请求起,这个防护栏上的匹配包含匹配的子串。你翻转 开关之前记录的匹配保持仅元数据。
该开关不可追溯——两个方向都是。 把它开启不会向你已经 记录的匹配回填子串;那些更旧的记录永远保持仅元数据。把它 关闭会停止捕获新子串,但不会抹去过去匹配上已经存储的子串。 如果你需要清除那些,参见 §6

5. 开启时捕获什么

Log raw content 开启时,引擎把字面匹配文本附加到每个违规上, 带有两个硬性上限,防止一个病态输入让单条匹配记录膨胀:
  • 每个违规至多 32 个匹配条目。
  • 每个条目上限为 256 个字符
因此一个在巨大文档上触发的防护栏存储的是匹配内容的一个有界、 有代表性的样本——而不是整个主体。详情字符串也被独立地长度钳制。 这些上限是为了存储卫生;把捕获集当作什么匹配了的证据,而不是 整个请求的逐字记录。
即使开关开启,防护栏也只记录一条规则实际匹配的文本。周围的 提示词和响应的其余部分永不被复制进 Matches 信息流。完整的 请求/响应负载与防护栏诊断是不同的关切。

6. 移除你已经捕获的子串

由于开关不可追溯,关闭它会让先前的子串保持原位。两个面可以清除 它们:
想移除如何
一条嘈杂的匹配把它标记为误报——POST /api/guardrail/match/:id/mark-fp(工作区 Admin),或信息流中的 Mark false positive 操作。
一个用户的所有防护栏匹配用户自助删除会触发一个 30 天宽限窗口,然后一次 PII 擦洗会级联穿过防护栏匹配、请求日志和防火墙事件。参见合规
关于调优一条频繁规则而不是擦洗数据, 调优误报流程会逐步 介绍标记和精炼匹配。

7. 谁能读什么

Matches 信息流是工作区级别的诊断数据。读取访问对每个活跃 成员开放;破坏性的误报操作门控更高:
操作路由角色
列出 / 分组 / 统计 / 导出匹配GET /api/guardrail/match*Member
单条匹配详情GET /api/guardrail/match/:idMember
标记 / 取消标记误报POST / DELETE /api/guardrail/match/:id/mark-fpAdmin
编辑一个防护栏(含 Log raw content)PUT /api/guardrail/Developer+
这些管理路由用你的控制台会话鉴权,而不是中继密钥。读取永不 暴露开关没有捕获的子串——读取时没有额外内容需要脱敏,因为没有 存储额外内容。

8. 一个务实的隐私默认值

对大多数工作区,正确的形态是:让 Log raw content 保持关闭, 在元数据上运行你的防护栏,并在你正在主动调试一条规则为什么那样 触发时,临时为单个策略开启该开关。然后把它翻回关闭——新匹配 立即停止携带子串。
这与一次仅观察的上线天然配对。从 Compliance Logger(仅 flag)开始,在元数据上观察 Matches 信息流,只在某条 特定匹配需要更近距离查看时才使用原始内容。

9. 接下来去哪里

Matches 信息流

浏览、分组、过滤并导出每条记录的匹配。

调优误报

标记和精炼匹配以安抚一条嘈杂规则。

版本管理

每次开关翻转都是一次版本化的、可回退的变更。

合规

保留、数据主体擦除,以及签名报告。
关于这如何融入更广的控制栈,参见 防护栏 vs 防火墙数据外泄。完整的引擎—— 阶段、高级规则和路由——请阅读防护栏参考