跳转到主要内容
一个长时运行的自治智能体是最难保护的东西。它自行循环数小时、自己挑选 工具、自己抓取 URL，并在整个过程中花你的钱。其失败模式不是单条糟糕的 提示——而是一个一夜烧掉 $400 的重试循环、一个你从未审查过的工具调用、 一个你为一周实验铸造、六个月后仍能用的密钥。 本配方围绕恰好那种形态的智能体接好四项控制。你在控制台（或 REST API） 中配置全部内容——智能体像以前那样继续调用 https://api.orcarouter.ai/v1/...。
刚到这里？先应用 balanced 基线 并 观察你的智能体做什么 一天。本页是 下一步：把观察变成对一个你无法盯守的智能体的执行。

​
1. 安全自治智能体配方

一个安全的自治智能体需要四样聊天机器人不需要的东西：

一个硬性成本上限

一条 cap_cost 规则会在运行的累积花费越过你的上限后拒绝该运行 ——一个不会停止的循环的断路器。

尖峰检测

异常检测学习智能体正常的周内小时形态，并标记溜过静态规则的速率和 成本尖峰。

对危险调用的审批

一个 pending_approval 判定把破坏性或不可逆的工具调用挂起交给人工， 而不是信任智能体会小心。

一个会过期的密钥

把智能体的密钥限定到一个到期时间和一个额度上限，这样一个被遗忘的 实验就不能永远运行——或永远花钱。
每一项映射到一个 防火墙 策略或 密钥 字段。没有一项 触及你的智能体代码。

​
2. 封顶每一次运行的成本

一个失控循环最先炸掉的是你的预算。一条 cap_cost 规则是一个严格的 预检查成本上限：当它匹配时，网关估算请求的成本，并在该运行的累积花费 将超过上限时在派发前拒绝——所以一个超预算的调用永远不会到达 提供商。 该上限是运行限定的。网关把整个智能体运行内的先前花费求和，因此一个 已经烧掉其大部分预算的长时运行，即便下一个单独的调用很便宜也会被拒绝。 那正是它成为一个断路器而非一个每请求限制的原因。 向你的防火墙策略加入一条通配符规则： 
{
  "priority": 50,
  "tool_name_glob": "*",
  "verdict": "cap_cost",
  "cap_cost_cents": 1000
}
这把运行封顶在 $10（cap_cost_cents 以 USD 美分为单位）。判定在 未超预算时解析为 allow，在估算将越过时解析为 deny。大多数内置的 防火墙模板（Coding、Support、RAG、Data、DevOps、Browser）都附带一个 恰如此例的每运行成本上限——应用一个并编辑上限。
运行限定的累积需要为工作区启用请求日志捕获。在它关闭时，先前花费的 汇总读数为零，上限退化为仅每请求——仍然安全，但它不会捕捉一个缓慢的 500 次调用滴流。参见 denial-of-wallet。

​
3. 对照一个学习到的基线检测尖峰

一个上限阻止灾难；异常检测在异常成为灾难之前就捕捉它。防火墙 学习每个工作区正常的工具使用形态——一个按周内小时分桶的 14 天滚动 平均，因此周二 14:00 的流量对照周二 14:00 的历史比较，而不是一个平直的 每日均值——并在一个查看者可读的信息流上呈现偏离：
按工具的调用量对照学习到的基线评分。“一小时内 143 次 db.query 调用，对照一个 8 的基线”即便每个单独调用都被允许也会呈现出来。
同一个基线，应用于花费而非计数——一个突然烧掉远多于这个小时通常 花费的运行。
一个自治智能体卡在重试同一个坏掉调用的特征。参见 excessive-agency。
本工作区从未做过的一次工具到工具的跳转——一个智能体走向新地方的 形态。
该信息流报告工具名、脱敏后的令牌 id 和计数——绝不报告原始参数。读取它 对任何 Member 开放；一个 Developer+ 可在调查期间将信息流 **贪睡（snooze）**最多 7 天。把信息流和一条 cap_cost 规则配对，这样 一个同时也超预算的尖峰会被阻止，而不只是被注意到。

​
4. 把危险调用挂起交给人工

你无法审查一个自治智能体发出的每一次调用——但你可以让它在那少数几个 重要的调用之前停下来询问。一个 pending_approval 判定把一次工具调用 带外挂起：
  1. 智能体发出，比如说，一次 payments.transfer 调用。规则匹配，引擎 返回 HTTP 400 firewall_approval_pending，带一个审批 id——该调用 永远不会到达工具。
  2. 一名审查者从控制台（Developer+）解决它，或你自己的系统经由一个 HMAC 签名的 webhook 回调到 POST /api/v1/firewall/approvals/:id/callback 解决它。
  3. 智能体轮询 GET /api/v1/firewall/approvals/:id；一旦获批，它携带一个 一次性的 X-OrcaRouter-Firewall-Approval 头重新提交原始调用，网关便 放行那一次。
一条把写入挂起到一个破坏性执行面的规则： 
{
  "priority": 20,
  "tool_name_glob": "payments.*",
  "verdict": "pending_approval"
}
先在 shadow mode 中上线它—— pending_approval 降级为 audit，因此你能看到哪些调用会被挂起，而 实际上不拦截你的智能体。当信息流看起来对了，关闭 shadow。

​
5. 给智能体一个会过期的密钥

比每一条策略都活得更久的控制是密钥本身。一个自治智能体应该拿到一个 限定范围的密钥，而不是你的默认密钥。在你铸造它时设置这些字段 （控制台 → keys，或 token API）：
字段设为为什么
expired_time一个 Unix 时间戳实验结束；密钥随之消亡。-1 表示永不——这里别用它。
credit_limit_usd一个美元上限密钥上独立于运行上限的花费上限。0 表示无限。
firewall_policy_id你上面的策略把 cap_cost + 审批规则绑定到这个密钥。
allow_ips智能体的出站 IP一个泄露的密钥从其他任何地方都没用。
也设置一个 environment 标签，这样密钥——以及它在 Events 和 Matches 中 所做的一切——都可归因于这个智能体。一个会过期、有额度上限、IP 钉死的 密钥是最后一道防线：即便每一条策略都不知怎么被绕过，爆炸半径也被时间和 金钱限定。
密钥配置是一个控制台 / token-API 动作，并受角色门控。读取一个 firewall-gateway 密钥的明文需要 Admin+。

​
6. 把它组合起来

一个加固过的自治智能体最终得到一条防火墙策略和一个限定范围的密钥：
层控制捕捉
预算cap_cost 规则，运行限定失控循环、denial-of-wallet
行为Anomaly feed（rate / burn / retry / novel）异常但被允许的
信任破坏性工具上的 pending_approval不可逆的动作
范围会过期、有额度上限、IP 钉死的密钥被遗忘或泄露的密钥
把预算和审批规则一起编写，用 防火墙规则 设置一个每运行上限，并阅读 防火墙参考 的其余部分了解执行面、判定和 可观测性。关于本配方所防御的相关威胁，参见 excessive-agency、 dangerous-tool-calls 和 denial-of-wallet。

​
7. 下一步

加固一个 MCP 智能体

治理一个经由 MCP 服务器访问工具的智能体。

阻止外泄

为一个抓取自己 URL 的智能体设置 egress 规则。

执行模式

Observe → shadow → enforce，安全的上线。

防火墙规则

上面每条规则背后的匹配语言。