跳转到主要内容
静态 防火墙规则 捕获你知道去点名的调用。它们 无法捕获那种单独被允许但在总体上错误的调用——周日凌晨 3 点的 200 次 db.query 调用、一个在紧密循环中猛击一个失败工具的智能体、一个这个工作区 此前从未做过的工具到工具的跳转。每一次调用都通过每一条规则；这个模式才是 问题。 防火墙异常检测是行为层。网关学习你工作区正常的工具使用形态并对照它为 实时活动评分，把偏离浮现在任何 Member 都能读取的信息流上。它是你如何在 没有事先为一个你从未见过的形态写一条规则的情况下注意到一个被攻陷的智能体或 一个失控循环的方式。本页是那个 firewall anomaly detection 信息流的聚焦 落点；防火墙概览 是深度参考。
异常信息流是检测，而非执行。它告诉你什么看起来不对劲——它不拦截。当一个 模式是真实的时，你把它变成一条 规则 或 一个 速率限制的判定，这样下一次出现就被 内联停止。读取信息流对每个 Member 开放；把一个发现变成策略是 Developer+。

​
1. 防火墙异常检测标记什么

四种信号种类，每一种绑定到一个不同的失败模式：
逐工具的调用量对照一个学习到的周内小时基线评分。当一个工具的计数 越过一个绝对底线且相对那个小时的基线偏高时，或当它的 z 分数越过 阈值时，它触发 rate_spike。以周内小时（而非一天中的小时）为键意味着 周二 14:00 与过去的周二 14:00 比较，所以正当的工作日峰值流量不读作一个 尖峰，而周日凌晨 3 点的同样量则会。
同样的周内小时比较，应用于累积的成本而非调用计数。一个其花费远超 其学习到的成本正常值的工具浮现为一个 burn_spike——一个智能体在它具 破坏性之前先昂贵的早期预警信号。
一个 (conversation, tool, arguments) 组在一个短窗口内重复很多次——一个 卡在重新发出同一个失败工具调用而非恢复的智能体。缓慢的、正当的轮询不会 触发它；信号是一个紧密循环。
一个这个工作区没有学习基线的 tool_a → tool_b 连续转移。一个智能体 第一次走，比如说，crm.read → http.fetch，那条边就是新颖的——恰恰是 一条 数据外泄 链会采取的那种 步骤。
异常检测补充 序列规则。一条序列规则 匹配一个你事先定义的链；novel_path 标记一个你没有定义的转移——它是 你如何发现值得为之编写一条序列规则的链。

​
2. 14 天基线

该检测器不是一个固定阈值——它是一个学习到的正常值。对于每个 (tool, hour-of-week) 桶，网关保留一个滚动的期望调用计数和成本，从一个 14 天回溯回填（每个周内小时桶约两次出现——足以平滑单独一个怪异的日子 而不丢失周形态）。novel_path 使用并行的转移基线：那个周内小时里每个 tool_a → tool_b 边学习到的出现计数。 一个全新的工作区还没有基线。那没问题：在没有学习到的正常值时，量检测器 回退到一个绝对底线，所以在逐小时正常值填入的同时，一次明显的洪流在第一天 仍被捕获。
信号它从什么中学习
rate_spike / burn_spike逐 (tool, hour-of-week) 的计数和成本，14 天滚动。
novel_path逐 (tool_a → tool_b, hour-of-week) 的转移计数。
retry_loop无基线——(conversation, tool, args) 上的一个窗口化重复阈值。
该信息流只报告工具名、脱敏后的令牌 id 和计数。一个原始 API 密钥 id 绝不 出现——每个条目携带调用令牌的一个单向摘要，所以你能分辨两个异常而信息流绝不 泄露它们背后的密钥。

​
3. 一次具体的读取

假设一个智能体密钥开始循环。在控制台 Security → Firewall → Anomalies 下拉取信息流，或直接读取它——任何 Member 都能： 
curl https://api.orcarouter.ai/api/workspace/firewall/anomalies \
  -H "Authorization: Bearer $ORCA_SESSION_TOKEN"

{
  "data": {
    "items": [
      {
        "id": "3f1c9a7b0e2d4a86",
        "kind": "retry_loop",
        "tool_name": "db.query",
        "token_id_redacted": "sk-***-9f2a",
        "count": 412,
        "baseline": 0,
        "z_score": 0,
        "suggested_action": "rate_limit",
        "first_seen": 1749470400,
        "last_seen": 1749470520
      }
    ],
    "snoozed_until": 0
  }
}
一个 retry_loop 条目不携带 baseline 或 z_score（那些字段保持 0 ——它们属于量/成本检测器），而它携带一个稳定的不透明 id，这样同一个工具上 两个不同的循环不会在一行上相撞。一个 rate_spike 是相反的：它报告一个学习 到的 baseline 和一个 z_score，并把 id 留空。
$ORCA_SESSION_TOKEN 是你的控制台会话 / 访问令牌——与每个 /api/workspace/firewall/* 管理路由相同的认证。它不是一个中继 sk-orca-… 密钥（那些只用于 /v1/* 模型调用），也不是一个 firewall-gateway 密钥。一个中继密钥在这条路由上会被拒绝。
每个条目点名工具、脱敏后的令牌、触发了多少次调用、z 分数（仅量/成本信号）， 以及一个 suggested_action（rate_limit、block_tool 或 review）。从 这里你行动：在该工具上落一条 deny 规则、 验证它的参数，或打开 事件日志 以准确看到该智能体做了什么。

​
4. 贪睡信息流

一次已知的负载测试或一次计划的回填会点亮信息流。与其追逐噪声，不如贪睡它 ——最多 7 天： 
curl -X POST https://api.orcarouter.ai/api/workspace/firewall/anomalies/snooze \
  -H "Authorization: Bearer $ORCA_SESSION_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"until": 1749643200}'
在一次贪睡活跃期间，信息流不返回任何条目并报告 snoozed_until；它在截止 时刻一过就自行清除。该上限是一个硬天花板——一个手误或恶意的、更远的 until 被钳制，这样异常检测无法被无限期静音。POST 一个过去或现在的 until 会清除 一个现有的贪睡。
读取信息流是一个 Member 操作；贪睡它是 Developer+——把一个工作区 范围的安全信号静音是一次写入，而非一次读取。

​
5. RBAC 一览

分析执行面沿着通常的读/动作分界线分割：
操作角色
读取异常信息流Member
读取设置、策略、discovered toolsMember
贪睡信息流Developer+
Events、runs、aggregate、traceDeveloper+
从一个发现编写一条规则Developer+
更轻的汇总视图——设置、策略以及 discovered-tools 覆盖图——也是 Member 读取； 行级的 events 和 runs 细节是 Developer+， 因为它携带逐次调用的参数数据。

​
6. 从信号到策略

该信息流是一个循环的开始，而非结束：
1

发现模式

一个 novel_path 或 rate_spike 显示一个你没预料到的形态。对照 事件日志 读它，以确认它是真实的， 而非一次性的。
2

编写规则

把发现变成执行——一个 拦截、一个 参数子句、一条针对该链的 序列规则，或一个针对该烧耗的 成本上限。
3

安全地上线它

先在 影子模式 下落该规则，这样你在 它拦截任何一次调用之前衡量它的杀伤半径，然后执行。

​
接下来去哪里

防火墙概览

完整的异常检测参考以及策略平面的其余部分。

事件日志

从一个异常钻取到它背后的确切调用。

拦截一个工具

把一个发现变成一条执行性规则。

执行模式

检测、审计、影子和执行如何契合在一起。
关于这些信号暴露的威胁，参见 数据外泄 与 过度代理。