跳转到主要内容
一个智能体不必泄露数据就能伤害你。它可以纯粹地花钱——一个 猛击昂贵模型的重试循环、一条被提示注入的指令扇出一千次工具 调用，或一把泄露的 API 密钥不断累积推理直到账单到来。这就是 拒绝钱包（denial of wallet）：攻击就是成本本身。与经典的 拒绝服务不同，网关保持在线，每一个请求单独看都合法——损害 在于聚合的花费。 OrcaRouter 给你三个独立的天花板，它们都坐在上游模型前面，因此 没有任何单一失控路径能让你的账单无上限地跑。

​
1. denial of wallet ai 威胁

一次拒绝钱包事件通常追溯到三种形态之一：
一个智能体在一个紧凑循环里重试同一个失败的工具或反复重新 规划，每一轮都为 token 重新付费。无需恶意——一个糟糕的停止 条件就够了。
一次提示注入把智能体 引导去刷屏某个工具或发出超大请求，使每轮花费倍增。
一把密钥落到了它不该出现的地方——一个被提交的 .env、一个 共享的 notebook——然后一个攻击者在你的账户上运行推理，直到 花费被察觉。
三种情形下的防御都是同一个：一个攻击者无法靠话术绕过的硬 天花板，在网关上执行，而非在你的智能体代码里。

​
2. 用 cap_cost 设置逐运行成本天花板

防火墙的 cap_cost 判定是针对失控循环的断路器。你把它编写为 一条带逐运行分（cents）上限的规则；引擎累加该智能体运行已积累 的花费，一旦该运行越过上限，就把判定解析为 deny——那次运行 中之后的每一次工具调用都被拦截。 cap_cost 是一个派发前天花板：它在调用到达工具之前求值， 因此它拦下下一次昂贵调用，而不是退还一次已经发生的调用。一个 对每个工具的典型一网打尽上限： 
{
  "priority": 50,
  "label": "cap runaway spend at $5 per run",
  "tool_name_glob": "*",
  "verdict": "cap_cost",
  "cap_cost_cents": 500
}
在上限之下，调用被允许；越过它，该运行被以一个 HTTP 400 firewall_blocked 拒绝——标记为 skip-retry，因此该循环无法 绕着这次拒绝猛击。天花板是逐智能体运行的，并在你整个工作区 策略上累加，因此一次失控的对话无法蚕食另一次的预算。
cap_cost 从你的请求日志里读取运行中花费。为该工作区保持 请求日志捕获开启，这样运行中花费的汇总才有行可累加——否则先前 花费的估算会保守地为 0，上限就看不到一次运行已经花了多少。
完整的匹配语言，以及 cap_cost 在其他判定中的位置，参见 防火墙规则参考。

​
3. 用 credit_limit_usd 为每个密钥设硬预算

cap_cost 限定单次运行。要限定一把密钥——它发出的每一次 运行——就在 API 密钥上设置 credit_limit_usd。它是对该密钥 终生花费的一个硬性 USD 天花板：网关把它转换为该密钥的剩余配额， 一旦该密钥花光其额度，进一步的中继调用就会因额度不足而被拒绝。 0 表示无限制。 把它与该密钥的其他范围配对，这样一把泄露的密钥在每个维度上 同时被限定：

credit_limit_usd

该密钥的硬性 USD 花费天花板（0 = 无限制）。

expired_time

自动过期时间戳（-1 = 永不）。一把短命密钥限定爆炸半径的 时间窗。

allow_ips

把密钥钉到已知的源 IP——一把泄露的密钥在网络外就没用了。

model_limits

把密钥限定到特定模型，这样它根本够不到最贵的那些。
给每个智能体它自己范围狭窄的密钥，并配一个它正当情况下绝不 应该超出的 credit_limit_usd。这个限额是预算，而不是对攻击者 行为的猜测——即便一把被完全攻陷的密钥也会停在天花板处。
从控制台密钥编辑器（或 token API）在你的会话下配置所有这些 ——这些是密钥设置，不是中继调用。只有 /v1/* 推理请求才使用 sk-orca-... 密钥本身。编辑限额会在该密钥的下一次请求时生效； 无需重新部署。

​
4. 捕获你没预料到的尖峰：成本异常

一个静态上限拦下你预料到的花费。防火墙的异常检测捕获你没 预料到的。它对照一个周内小时基线（一个 14 天滚动平均）学习 每个工作区正常的工具使用形态，并在一个 Member 可读的信息流上 浮现偏离：
异常它标记什么
burn_spike一个工具的成本远高于其学习到的基线成本——拒绝钱包信号。
rate_spike调用量远高于基线——扇出和洪流。
retry_loop同一个工具加同样的参数在一个紧凑窗口里重复——经典的失控循环。
于是”这个工具这一小时烧了它平常 40 倍的成本”会显得突出，即便 每一次单独的调用都被策略允许。在你调查期间，你可以把一个异常 **贪睡（snooze）**最多 7 天。
异常检测是你的早期预警；cap_cost 和 credit_limit_usd 才是 硬性的停止。观察该信息流以发现你真实的花费在哪里，然后围绕 它编写一个上限。

​
5. 把它组装起来

把这三者叠加，让一次失控永远到不了账单：
控制范围何时触发
cap_cost 规则一次智能体运行该运行积累的花费越过分上限
credit_limit_usd一把密钥，终生该密钥的总花费触及其 USD 天花板
burn_spike / retry_loop工作区，学习而来花费或重复模式偏离基线
一个实用基线：一个作用于 * 的逐运行 cap_cost、每把智能体 密钥上的一个 credit_limit_usd，以及一个检查异常信息流的习惯。 先以 影子模式 上线 一条新的 cap_cost 策略——它会记录 [shadow] would deny 而不 拦截——这样你就能在它生效之前，对照真实流量来确定上限的大小。
cap_cost 和异常信息流限定的是穿越网关的工具调用与运行。 一个智能体完全在它自己进程内执行的工具永远到不了引擎。把 模型中介的和 MCP 工具调用路由经过网关——并给每把密钥一个 credit_limit_usd——这样无论智能体如何循环，天花板都成立。

​
6. 相关威胁

拒绝钱包很少单独到来——那个烧掉你预算的循环往往是被上游的 某个东西驱动的：
  • 提示注入——被注入的 指令是扇出和工具刷屏的常见触发。
  • 过度自主权——一个 有太多回旋余地的智能体有更多花钱的方式。
  • 危险工具调用—— 同一个防火墙规则平面限定一个工具可以做什么，而不只是它花 多少钱。
  • 威胁模型——失控成本在 完整的智能体攻击面中处于何处。

防火墙概览

判定、异常检测、自治级别和可观测性。

限定范围的密钥与策略

密钥限额、防护栏和防火墙策略如何逐密钥组合。