跳转到主要内容
一个自主智能体最安全的姿态是默认拒绝：默认拦截每一个工具，然后明确 只允许你的智能体本应使用的那一小撮。智能体捡起的任何新东西——一个社区 技能、一个配置错误的 MCP 服务器、一个越狱说动模型去用的工具——都因为你 从未把它选入而被拒绝，而不是因为你记得去拦截它。 本页是 api.orcarouter.ai 上的智能体工具白名单模式：一个 deny 默认判定，加上一条或多条以 tool_name_glob 为键的 allow 规则。 关于那些规则背后的完整匹配语言，参见 防火墙规则。
白名单在控制台的 Security → Firewall 下编写，或通过 /api/workspace/firewall/* 管理路由（你的会话 / 访问令牌——而非一个 中继 sk-orca-… 密钥）编写。只有你智能体的 /v1/* 调用才使用中继密钥。 创建或编辑一条策略是一个 Developer+ 操作。

​
1. 为什么对智能体用默认拒绝

一个黑名单（“拒绝 shell.exec、拒绝 db.delete、……”）的完整程度永远 只取决于你想到的最后一个威胁。一个白名单反转了举证责任：网关拒绝该策略 没有明确允许的一切，所以一个未知工具因构造而被关闭。

默认判定 = deny

策略的底线。在没有规则匹配时，每一次工具调用都被拦截。

allow 规则把工具选回来

每一条 allow 规则点名你实际使用的工具——按精确名称或按 glob。
引擎按优先级顺序遍历一条策略的规则，首个匹配生效；如果没有匹配，它 落到策略的 default_verdict。所以一个白名单不过就是：为你的真实工具设置 高优先级的 allow 规则，外加一个捕获其他一切的 deny 底线。

​
2. 一个示例：为一个研究智能体的工具做白名单

假设你的智能体只需要搜索网络和从一个知识库读取——名为 web.search 和 kb.read 的工具。其他一切（shell、文件写入、数据库变更、任何提示注入 可能召唤出的工具）都必须被拒绝。 把该策略构建为默认 deny + 两条 allow 规则：
1

用一个 deny 默认创建策略

Security → Firewall → Policies → New policy。给它命名，保持 Enabled 开启，并把默认判定设为 deny。这是那个关闭的底线—— 参见 创建策略。
2

为每个工具家族添加一条 allow 规则

在规则编辑器中添加两条规则，两条都 verdict = allow：
prioritytool_name_globverdict
10web.searchallow
20kb.*allow
web.search 是一个精确匹配；kb.* 是一个前缀 glob，它允许 kb.read、kb.search 以及任何未来的 kb.* 工具，而无需重新编辑该 策略。
3

把它绑定到你智能体的密钥

把密钥的 firewall_policy_id 设为这条策略（或将它设为工作区默认）。 你智能体的请求体不变。
现在 web.search 和 kb.read 通过；一次对 shell.exec 的调用匹配不到任何 allow 规则，撞上 deny 底线，并在 inbound 执行面上作为带有码 firewall_blocked 的 HTTP 400 返回——参见 拦截的表现形式。
把 allow 规则编写为精确名称或窄前缀（kb.*），而非宽后缀。一个松散的 *.read 会允许 kb.read 和 secrets.read——与白名单的目的恰恰相反。 在工具命名允许的范围内，把 glob 保持得尽可能紧。

​
3. 一屏看懂 glob

tool_name_glob 是一个小而大小写敏感的语法——没有正则，线性时间。对一个 白名单重要的形态：
模式允许
web.search恰好那个工具。
kb.*前缀——kb.read、kb.search（不含裸 kb）。
*.search后缀——web.search、kb.search 以及裸 search。
*.tools.*中缀——byo.tools.fetch 及类似。
关于完整语法（中缀规则、边界情况、技能名 glob），参见 Glob 语法 与 防火墙规则参考。
一个 *.suffix glob 也匹配裸的、无命名空间的动词——*.search 允许一个 字面名为 search 的工具，而不只是 web.search。提供商和不做命名空间的 MCP 服务器以裸动词暴露工具，所以一个加入白名单的后缀比它看起来要宽。当你 想要一个紧的白名单时，优先用精确名称或前缀。

​
4. 不破坏你的智能体地上线它

默认拒绝是最有可能拦下你忘了自己需要的某个工具的姿态。分阶段进行：
打开 影子模式。该策略完全像实时 那样评估和记录，但把每个拒绝降级为 audit，原因前缀为 [shadow] would …。跑真实流量，然后读事件信息流。
Discovered tools 列出工作区见过的 每一个工具，标记为 covered 或 gap。影子模式的”would-deny”事件 加上那些缺口，会准确告诉你还需要哪些 allow 规则。
Test 沙箱 对一个样本工具调用 dry-run 该策略，并返回判定、匹配到的规则和原因——不派发任何内容，不持久化 任何内容。确认 web.search 允许、shell.exec 拒绝，然后关闭影子。
一次被拒绝的 inbound 调用不消耗任何模型 token——它在上游模型运行之前 就被拦截——并被标记为 skip-retry，所以一个被拦截的工具不会因反复拦截 而烧掉一个重试预算。参见 判定。

​
5. 接下来去哪里

拦截特定工具

反面做法——保留一个默认允许的底线，拒绝点名的工具。

验证参数

允许一个工具，但只在参数安全时（db.query 而非 DROP TABLE）。

规则优先级

首个匹配生效如何把你的 allow 规则排在 deny 底线之上。

判定

allow、audit、deny、sanitize、pending_approval、cap_cost。
关于这个模式应对的威胁，参见 过度代理 与 危险工具调用。关于为什么默认 拒绝是智能体基线，参见 为什么零信任。