跳转到主要内容
输入阶段防护栏在请求到达模型之前筛查调用方的请求。 它是执行内容策略最廉价的地方：网关在请求进入时检查 提示词，如果某条规则拦截，请求会在计量之前被拒绝—— 你不为这次调用付任何费用。这里是你阻止泄露的密钥、PII 字段 或注入尝试触达上游模型的地方。 完整的引擎——每种规则类型、字段和路由——请见 防护栏参考。本页专注于输入 阶段：什么在模型之前运行，以及为什么这里的拦截不消耗配额。

​
1. 面向 LLM 应用的输入防护栏，在模型之前

每条防护栏规则都带有一个阶段——input、output 或 both。 一条 input 规则在请求文本到达的那一刻、在前往上游模型的 路上对其运行： 
caller → [ input guardrail ] → metering → model → [ output guardrail ] → caller
那个排序就是关键。输入规则在网关预先扣除任何配额之前看到 提示词，因此这个阶段的拦截是免费的——请求永远不会到达 模型，也永远不会计费。对比输出阶段， 它在模型响应返回之后筛查响应（输出拦截会改为退回预先 扣除的配额）。
输入规则筛查调用方的请求。如果你还使用 注册表提示词，被注入的系统消息会在 路由的更晚阶段添加——因此输入规则看到的是你的应用发送的消息， 而不是被注入的提示词。无论哪种方式，输出规则都筛查响应。

​
2. 你可以在输入阶段运行什么

任何规则类型都可以在 input 运行。在模型之前把关请求的 最常见原因：

脱敏提示词中的 PII

带 mask 动作的 pii 规则会把实体改写为带类型的标签 （jane@acme.com → [EMAIL]），让上游模型永远看不到 原始值。参见 PII Shield。

在密钥泄露前拦截它们

携带 API 密钥或云凭证的请求会在门口被拒绝——计量之前， 无上游调用。参见 拦截密钥。

阻止注入尝试

提示注入基础预设把 keyword/regex 检测器与一条针对注入意图的 llm_judge 规则配对。参见 提示注入。

限制提示词大小

一条 max_chars 规则会在超大提示词计费任何 token 之前拒绝 它。参见成本防护栏。
七种规则类型——keyword、regex、pii、max_chars、 external、llm_judge、grounding——和五种动作 block、 mask、flag、annotate 与 spotlight 都适用于此。（spotlight 用分隔符包裹匹配到的不可信文本，让模型将其视为数据而非 指令——一种输入阶段的提示注入防御；annotate 在不改变流量的 情况下附加一条注释。）一个值得了解的例外： grounding衡量的是 答案相对于检索到的来源，因此它本质上是一种输出阶段检查。 其他一切都天然适合输入阶段。
输入阶段脱敏今天已上线——无论是否流式。网关在每条路径上 都会在模型看到之前改写请求。输出 mask 只脱敏非流式响应； 带内的流式输出改写在规划路线图上，因此脱敏规则目前还不会 脱敏流式回复。相比之下，输出 block 两种方式都会执行—— 流式和非流式（参见 流式覆盖）。

​
3. 一个具体示例

在控制台中编写规则（在你自己的会话下——防护栏配置需要 Developer+），而不是用中继密钥。给一个名为 secrets-shield 的防护栏添加单条 input 规则： 
{
  "type": "regex",
  "stage": "input",
  "action": "block",
  "pattern": "sk-[A-Za-z0-9]{20,}"
}
将防护栏绑定到一个密钥（设置 guardrail_id，或将它标记为 工作区默认值——参见绑定到密钥）， 然后用那个 sk-orca-... 中继密钥调用网关： 
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": "Debug this: OPENAI_API_KEY=sk-abcdefghij1234567890"}
    ]
  }'
请求在输入阶段匹配，并在网关向上游转发任何内容之前以 HTTP 400 guardrail_blocked 被拒绝： 
{
  "error": {
    "type": "guardrail_blocked",
    "message": "request blocked by guardrail \"secrets-shield\": regex(...)"
  }
}
完整的响应形态见 guardrail_blocked 错误。

​
4. 为何输入拦截不消耗配额

这是在请求进入途中捕获问题的结构性优势。输入阶段拦截位于 预扣除之前，因此：
属性输入阶段拦截
HTTP 状态400 guardrail_blocked
消耗配额无——在计量之前触发
上游调用从未发出
重试标记为 skip-retry——重新运行只会再次拦截
由于请求从未到达任何通道，输入拦截被标记为 skip-retry：针对另一个通道重新运行同一个提示词只会 再次拦截并浪费精力。输出阶段不同——那里的拦截会退回网关 已经预扣除的配额。同样的 400，不同的记账方式。

​
5. 解析与回退

只有当某个防护栏在请求上实际解析出来时，输入阶段规则才会 运行。解析是明确的：
  1. 密钥明确的 guardrail_id，如果它存在且已启用。
  2. 否则是工作区默认防护栏。
  3. 否则无——请求与没有策略的工作区字节相同。
明确绑定永不静默回退。禁用一个绑定的防护栏就是 关闭开关——它不会下沉到工作区默认值。（防火墙策略在这里 行为不同；参见 防护栏 vs. 防火墙。）

​
6. 上线前先证明它

不要凭信任就把一条拦截型输入规则绑定到真实流量。两种先 验证的方式：
打开防护栏编辑器中的 Test 标签页，粘贴一个样本，选择 input 阶段，然后运行。沙箱在本地评估当前策略——没有 上游调用，没有配额——并返回判定结果加上（对于 mask 规则） 渲染后的文本。参见 测试与 eval。
先把动作设为 flag。flag 不改变流量的任何方面——它只 记录一条匹配——因此你可以在把它翻为 block 之前衡量某条 规则在真实输入上会触发的频率。参见 调优误报。
每条触发的规则都会记录一条匹配——类型、动作、阶段和一个 详情字符串。只有在开启 Log raw content 时（默认关闭） 才记录匹配的子串。参见 Matches 信息流和 日志与隐私。

​
7. 接下来去哪里

输入阶段阻止坏输入到达模型。要把关模型的响应，将它与 输出阶段配对；要治理智能体的工具调用，使用防火墙。 阅读防护栏参考以了解完整引擎，或阅读 安全快速开始，把输入防护栏和 防火墙连接起来构成一个智能体基线。