OpenRouter 护栏与 Claude Code 权限模型：拦在请求链路上和拦在动作执行前

2026-08-18

「护栏」这个词被用得很泛。在 OpenRouter 的文档里它指挂在 API key 和成员身上的请求级检查，在 Claude Code 的文档里对应的是挂在工具调用上的规则。两者拦的位置不同：一个拦在请求转发给模型供应商之前，一个拦在动作在你机器上执行之前。搞混的代价很实在——你以为配了一层就都管了，结果两边都漏。

先问自己怕的是什么

决策路径只有一个岔口：你担心的是”什么内容离开你这里”，还是”什么动作在你这里发生”。

面向外部用户的应用，输入直接进模型，你怕注入、怕用户把身份证号粘进对话框、怕成员把钱花超——内容出站的问题。
一个 agent 在你的仓库和机器上跑命令，你怕它 git push 到错的地方、怕它删掉未提交的改动——本机动作的问题。

OpenRouter：拦在请求转发之前

OpenRouter 官方文档《Guardrails》页写明，guardrail 是组织用来控制成员和 API key 如何使用 OpenRouter 的一层配置。文档写明的启用路径是进入 Settings > Privacy，滚动到 Guardrails 一节，点击「New Guardrail」；组织账户须是组织管理员才能管理。

每一条 guardrail 可以任意组合七类设置项（该页列出的固定分类）：预算上限（Budget limit）、模型 allowlist、供应商 allowlist、Zero Data Retention（ZDR）、Security（针对提示注入与越狱的正则检测）、Sensitive Info（PII 检测与脱敏/拦截）、自定义内容过滤器。

挂载点有两级：成员级（member assignments，作为该成员所有 API key 与 chatroom 使用的基线）和 API key 级（在成员级之上叠加）。一个用户或一把 key 只能直接挂一条 guardrail，但组织成员创建的所有 API key 都会隐式跟随该成员的指派，即便这把 key 自己另外挂了一条。

多条 guardrail 同时命中时怎么合并，文档《Guardrail Hierarchy》一节逐条写明：

设置项	合并方式
供应商 allowlist	所有 guardrail 取交集
模型 allowlist	所有 guardrail 取交集
Zero Data Retention	按 model group 做 OR，任一条强制则该范围强制
Sensitive Info	取并集；同一实体类型出现不同动作时，block 优先于 redact
预算上限	每条 guardrail 各自独立检查

文档给的结论是「更严的规则总是胜出」，并注明 API key 自身的预算依然生效，取更低的那个。工作区另有一条默认 guardrail，文档写明它名为 Workspace <workspace-id> Default，适用于该工作区全部流量而无需显式指派，可先列出再按 id 更新：

curl https://openrouter.ai/api/v1/guardrails?workspace_id=YOUR_WORKSPACE_ID \
  -H "Authorization: Bearer YOUR_MANAGEMENT_KEY"

以上为官方文档中的原文示例，未经实测，以官方文档与 API 的实际响应为准。

OpenRouter 的三档动作，以及它自己承认拦不住的

官方文档《Prompt Injection Detection》页写明提示注入检测基于正则，模式来源包括 OWASP LLM Prompt Injection Prevention Cheat Sheet 等资料，命中后按配置执行三种动作之一：

Flag——请求原样放行，检测结果只进指标与分析事件，不做强制。文档建议先用它在自己的流量上测真阳性率。
Redact——命中的片段被替换成 [PROMPT_INJECTION]，脱敏后的请求继续发给模型。
Block——整个请求在到达模型之前被拒，返回 403。

多条 guardrail 同时命中时最严的动作胜出，优先级是 block > redact > flag。该页把检测模式分成九类（页面静态列出的分类数）：直接指令覆盖、开发者/管理员模式激活、系统覆盖、提示词提取、角色操纵、DAN 式越狱、安全绕过、标签注入与角色伪造、控制符注入。除正则外还有三种逃逸检测：打乱单词中间字母的 typoglycemia 变体、Base64 与十六进制解码后再查关键词、把字符间隔（如 i g n o r e）折叠后重扫。

它自己写明的边界，比能力清单更值得抄下来：

Limitations 一节写明基于正则的检测并不穷尽，复杂或新型的注入手法可能检测不到。
Flag 模式不执行任何强制，被 flag 的请求原样转发给模型。
误报可能发生（比如一段讨论安全测试的合法提示词）。可以从 Logs 页标记误报，但文档明确写着：标记误报不会追溯性地解封那次请求，动作是 block 的话原请求已经被拒了。
可以把已知安全的短语加进 allowlist 豁免，但《Allowlist》页写明它只作用于正则检测模式，对 typoglycemia 与 Base64/十六进制这两类逃逸检测不生效，因为它们工作在解码或归一化之后的文本上。allowlist 是大小写不敏感的精确子串匹配，不支持通配符与正则。

Sensitive Info 这一侧的边界同样明确：文档写明它只扫输入侧——message 内容、工具调用参数、prompt 字符串，不扫模型的响应。Person Name 与 Address 两个 preset 标注为 beta，文档写明检测准确度可能波动，并且检查超时时请求会继续放行而不是被拦——它是 fail-open 的。

自定义内容过滤器用 JavaScript 风味正则，文档写明不允许先行断言 (?=…)/(?!…)、后顾断言 (?<=…)/(?<!…)、反向引用，以及 (a+)+ 这类嵌套量词，创建或更新时会被以 invalid_regex_pattern 报错拒掉。

被拦时返回 403。文档还写明：预算与 allowlist 限制同样产生 403，但只有运行时内容检查会带上 openrouter_metadata 的阶段细节，且需通过 X-OpenRouter-Experimental-Metadata: enabled 这个头显式选择加入——注意头名里的 Experimental，这是文档自己标的实验性能力。

Claude Code：拦在工具动作执行之前

Claude Code 官方文档《Configure permissions》页写明三种规则：allow 让工具无需人工批准就能用，ask 每次尝试都要确认，deny 直接阻止。**评估顺序是 deny → ask → allow，第一个匹配决定结果，规则的具体程度不改变这个顺序。**后果是：Bash(aws *) 这样的宽 deny 会挡住所有匹配调用，包括同时命中更窄的 allow 规则 Bash(aws s3 ls) 的那次，所以 deny 规则里没法带例外白名单。规则语法是 Tool 或 Tool(specifier)：

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git commit *)"
    ],
    "deny": [
      "Bash(git push *)"
    ]
  }
}

以上为官方文档中的原文示例，未经实测，以官方文档与 --help 的实际输出为准。

规则之上还有一层 permission mode，文档《Choose a permission mode》页列出六档：default（CLI 里叫 Manual）、acceptEdits、plan、auto、dontAsk、bypassPermissions。模式定基线，规则在其上叠加。

这一侧最该记住的一句话在权限页的一个 Note 里：权限规则由 Claude Code 强制执行，不是由模型执行；提示词或 CLAUDE.md 里的内容影响 Claude 会尝试做什么，但改变不了 Claude Code 允许什么。要授予或收回访问权，得用 /permissions、规则、permission mode 或 PreToolUse hook。

它自己写明的失效边界同样直白：

Read 与 Edit 的 deny 规则作用于内建文件工具，以及 Claude Code 认得出来的 Bash 文件命令（如 cat、head、tail、sed），但不作用于任意子进程——一个自己打开文件的 Python 或 Node 脚本不受这些规则约束。文档给的出路是启用 sandbox 做 OS 级强制。
靠 Bash 规则约束命令参数是脆弱的。文档举的例子是 Bash(curl http://github.com/ *)：URL 前带选项、换成 https、跟随重定向、用变量拼 URL、多打一个空格，都能绕开它。
bypassPermissions 模式带有明确警告：该模式对提示注入或非预期动作不提供保护。
auto mode 的 classifier 只看得到用户消息、工具调用和 CLAUDE.md 内容，工具结果被剥掉，所以文件或网页里的敌意内容无法直接操纵它；另有一层服务端探针扫描进来的工具结果。这是文档写明的分层，不是我们的推测。

两边能对上的四个维度

只在双方都有依据的维度上比。

一、拦截时机。 OpenRouter 拦在请求转发给模型供应商之前，检查对象是请求内容本身；Claude Code 拦在工具调用执行之前，检查对象是这次调用的工具与参数。前者管不到你机器上发生了什么，后者管不到请求内容里有什么。

二、判定方式。 OpenRouter 的两类检测（正则确定性，NLP 用于人名地址、标注 beta、超时放行）与 Claude Code 的规则匹配加 auto mode 分类器，都把「确定性规则」和「模型/统计判断」分开写，并且都给统计判断标了不确定性。

三、动作分档。 OpenRouter 是 flag / redact / block 三档；Claude Code 是 allow / ask / deny 三种规则加六种 permission mode。两边都是「更严的赢」，但 OpenRouter 多一个 redact 档——改写请求后继续放行，这一点我们在 Claude Code 的权限文档里没有找到对应机制。

四、组织侧覆盖。 OpenRouter 的多条 guardrail 对 allowlist 取交集，账户级隐私与供应商设置作为默认 guardrail 始终生效；Claude Code 的 managed settings 优先级最高，文档写明包括命令行参数在内没有任何层级能覆盖 managed 的权限规则。两边结论一致：管理员那一层可以把口子焊死。

这些维度不比：OpenRouter 是 HTTP API 层的服务，我们在它的文档里没有找到关于本机文件系统、命令执行、子进程隔离的对应说明；反过来，我们在 Claude Code 的权限文档里也没有找到按预算、按供应商 allowlist 拦截请求的对应说明。两侧各缺一半，没法比。

Windows 侧的差别

OpenRouter 这一层是 HTTP API。文档写明检测模式是在请求转发给模型供应商之前就地评估的，全篇没有区分调用方的操作系统——我们在它的文档里没有找到任何与 Windows 或 Linux/macOS 相关的说明，所以这一侧不存在平台差异的依据可写。

Claude Code 这一层不一样，它在你本机跑。文档写明 Windows 上路径会先归一化成 POSIX 形式再匹配，C:\Users\alice 变成 /c/Users/alice，所以要匹配某个盘上任意位置的 .env 得写 //c/**/.env，跨所有盘写 //**/.env。还有一条只在 Windows 出现：命令参数里含 UNC 网络路径（形如 \\server\share\file）时会提示确认，文档给的理由是访问网络路径可能把你的 Windows 凭据发给它命名的那台主机；这条检查同样适用于 PowerShell 工具的命令。PowerShell 规则的形状与 Bash 规则一致，常见别名会先规范化再匹配，匹配大小写不敏感。Linux/macOS 侧另有一条：文档写明以 root 或 sudo 运行时，Claude Code 拒绝以 --dangerously-skip-permissions 启动。

这个差异什么时候会咬到你

最常见的一种：你自己写了一个 agent，模型接入走 OpenRouter，agent 在本机执行工具。两层拦截互相看不见对方——OpenRouter 的 guardrail 只看得到发出去的请求内容，不知道模型返回的指令随后在你机器上执行了什么；权限规则只看得到工具调用，不管请求里带了什么。

另一种：以为开了提示注入检测就不用管本机权限。OpenRouter 文档自己写着正则检测不穷尽、flag 模式不强制、NLP 检查超时会放行；Claude Code 文档也写着 bypassPermissions 对提示注入不提供保护、deny 规则管不住任意子进程。两份文档都没有把自己写成兜底。

真要落地，先把「内容出站」和「本机动作」分开列，各自对应到哪一层拦截、哪一层文档里明说了不保证，再决定要不要补第三样东西（比如 OS 级隔离）。别指望其中任何一层替另一层挡刀。

本文依据 OpenRouter 官方文档（openrouter.ai/docs）于 2026-08-18 的公开内容整理。该平台闭源，本文只复述官方文档写明的机制，不推断其内部实现； 我们没有对文中涉及的功能做过实测，因此不涉及界面外观与运行表现的任何描述。该平台的供应商、模型与路由策略随时变动，文中不列具体供应商名单与模型清单；价格、额度与限流的具体数值请以官方定价页与用量说明为准。

本文涉及的另一方内容依据其官方文档整理（Claude Code：code.claude.com/docs）。双方均为闭源商业产品，本文只对照各方公开写明的机制，不推断实现，也不对产品做优劣排名。

两款产品迭代频繁，文中涉及的字段、配置项与规则语义随版本变动，请以官方文档最新内容为准。安全与合规相关做法请结合自身环境评估，本文不构成安全方案建议。