跳转到主要内容
单独一次工具调用可以看起来完全无害。读取一条 CRM 记录：允许。调用一个 导出工具：允许。触及一个外部主机：允许。运行的形态——五十次读取，然后 一次导出，然后在一个周日凌晨 3 点向一个你从未见过的主机做 egress——才是 攻击。逐次调用的 判定 孤立地判断每一次 调用，永远看不到它。 本页涵盖那两个随时间而非一次一次地观察一次运行的防火墙机制：序列 规则（一个你编写的有序链）和行为异常检测（对你工作区学习到的正常 状态的偏离）。它们一起就是你检测智能体攻击链行为的方式——那是任何单条 allow/deny 规则都无法捕获的。
这里的一切都在控制台（Security → Firewall）中配置，其管理路由使用你的 会话 / 访问令牌——而非一个中继 sk-orca-… 密钥。你智能体的 /v1/* 调用不改变。

​
1. 为什么逐次调用规则错过链

防火墙的 工具 glob 和 参数子句 在设计上是无状态且 确定的——它们在热路径上快速地决定一次调用。那正是你想要的”拦截 shell.exec rm -rf”。它对一次每个单独调用都合法的慢烧外泄则恰恰错。 两个互补的工具填补了这个缺口：

序列规则

一条你编写的规则，匹配一个时间窗口内的有序链调用——“批量读取 → 导出 → egress”。你来命名这个模式。

异常检测

防火墙学习每个工作区正常的工具使用形态，并标记偏离——重试循环、 前所未见的工具路径，以及量/成本尖峰。无需编写规则。

​
2. 序列规则：命名攻击链

一条 sequence 规则像任何其他规则一样存在于一条 防火墙策略 内，但它携带的不是一个 单一的 tool_name_glob，而是一个有序的步骤列表。每个步骤是一个工具 glob，带有一个可选的 min_count 和一个可选的 egress: true；这些步骤 必须按顺序发生（与无关调用交错没问题），且整个链必须在 window_seconds 内完成。 
{
  "label": "bulk-read-then-exfil",
  "verdict": "audit",
  "sequence": {
    "window_seconds": 600,
    "steps": [
      { "match": "crm.*",   "min_count": 50 },
      { "match": "*.export" },
      { "match": "*", "egress": true }
    ]
  }
}
这在一个智能体读取 50+ 条 crm.* 记录、然后调用任何 *.export 工具、 然后做任何 egress 调用——全部在十分钟内——时触发。每一次调用单独都会通过； 这个模式才是信号。
一个序列在完成它的那次调用上被评估。 内联规则循环跳过链规则（一次 调用无法满足一个多步链）；当一次调用可能是一个链的最终步骤时，该匹配 运行，此时防火墙拉取该主体最近的事件并测试该链。你在该规则上设置的 verdict 就是随后对完成调用所发生的事：audit 记录它并放它通过， pending_approval 把它挂起以供 人工审查， 而 deny 拦截它。所以一个链可以实时停止它的最终调用——挑选判定来匹配。 当你只想检测和告警时使用 audit；当你需要一个硬停止时使用 pending_approval 或 deny（或与一条逐次调用 deny / egress 规则 搭配）。
完整的 sequence 字段语法——window_seconds: 0 表示无时间界限、 min_count 默认值、步骤排序语义——在 规则 schema 中。在控制台规则编辑器中 编写序列规则；保存是一个 Developer+ 操作。

​
3. 异常检测：对学习到的正常状态的偏离

序列规则问的是”这个特定模式有没有发生”，而异常检测问的是”这次运行有没有 任何东西对这个工作区来说是异常的”。它无需规则——防火墙从你自己的流量 构建一个基线，并对照它为实时活动评分。四种会浮现：
逐 (tool, key) 的调用量对照这个周内小时学习到的基线评分。当计数 越过一个绝对底线且相对基线偏高时，或当它的 z 分数越过统计阈值时， 一行会浮现。所以”周日凌晨 3 点的 100 次 db.query 调用”会显得突出， 即便一个周二下午 2 点同样规模的爆发不会。
同样的想法应用于花费：一个工具烧掉其针对这个周内小时学习到的基线成本 的数倍。即”钱包拒绝服务”的早期预警——把它与一条 cap_cost 规则搭配以执行一个硬上限。
一个 (conversation, tool, arguments) 组在一个紧密窗口内重复很多次 ——一个智能体卡在反复用相同参数调用同一个失败的工具，而非缓慢的正当 轮询。
一个这个工作区此前从未做过的 tool_a → tool_b 转移。一个智能体 第一次从 read_file 直接走到 http_fetch 时，即便两个工具单独都被 允许，那条边也会亮起。

​
周内小时基线

该基线是一个按周内小时（weekday × 24 + hour）分桶的 14 天滚动 平均，所以周二 14:00 专门对照过去的周二 14:00 历史比较——而非一个会冲淡 你真实日节律和周节律的平坦的全时段均值。一个尚无学习到的正常状态的全新 工作区，仍能通过一个绝对底线捕获一次明显的洪流，所以你从第一天起就受保护。
该信息流报告工具名、脱敏后的密钥 id、计数和一个 z 分数——绝不报告 原始密钥材料。每个异常携带一个建议的补救措施（rate_limit、review 或 block_tool），所以下一步是一次点击，而非一次猜测。

​
4. 一次具体演练

假设一个被攻陷的提示词把你的一个智能体逼进一个紧密的失败循环，然后探测 一个它从未触及的导出路径。这就是你看到的——事先没有编写任何规则：
1

智能体行为失常

被注入的指令推动该智能体用相同参数重试一个失败的 db.query，然后调用 report.export，随后是一次出站 fetch——一条这个工作区从未运行过的 路径。
2

打开异常信息流

在 Security → Firewall → Anomalies 中，这次运行浮现出一个 db.query 上的 retry_loop 和一个 report.export → http_fetch 边上的 novel_path。读取该信息流是一个 Member 操作——团队里任何人都能 分诊。
3

在事件 trace 中确认

点击进入 事件日志 和 运行分析 以查看确切的调用序列，关联 到该智能体运行和会话。异常信息流是 Member 可读的，但事件日志和运行 trace 携带工具调用来源，是 Developer+。
4

把发现转化为一条规则

现在你看到了那条链，把它编码进去：在危险导出上加一个 deny、在 fetch 上加一个 egress 白名单，或一条下次审计 整个模式的序列规则。异常检测找出未知；一条规则钉住已知。
如果在你调优时信息流嘈杂——比如一个确实每个周日都尖峰的正当批处理作业 ——在你调查时把异常信息流贪睡最多 7 天。贪睡是一个 Developer+ 操作；该窗口被服务端钳制，所以检测总会自行恢复。

​
5. 序列规则 vs. 异常检测

它们解决相邻的问题——挑选与你所知匹配的那一个：
序列规则异常检测
你编写确切的链无——它学习
捕获一个已知的多步模式未知 / 异常
动作把规则的判定应用到完成调用（audit / pending_approval / deny）浮现在信息流上
一个成熟的工作区两者都跑：异常检测是浮现你未预料到的链的雷达——只浮现， 绝不拦截；序列规则是你把你已有的链编码进去的方式，所以它们被标注、被追踪， 并（带一个 pending_approval 或 deny 判定）能够对完成调用设门。要对单独 一次调用做硬停止而不论任何链，使用一个逐次调用 判定。

​
6. RBAC 与信息流背后的路由

异常信息流和序列规则位于工作区防火墙管理路由之下——你的会话 / 访问 令牌，绝非一个中继密钥：
方法与路径角色用途
GET /api/workspace/firewall/anomaliesMember读取异常信息流（?window=）。
POST /api/workspace/firewall/anomalies/snoozeDeveloper+贪睡信息流（{until}，钳制到 7 天）。
POST /api/workspace/firewall/rulesDeveloper+在一条策略下创建一条序列（或任何）规则。
POST /api/workspace/firewall/testDeveloper+在依赖之前对照一个样本调用 dry-run 一条策略。
对信息流的读取对每个 Member 开放，这样整个团队都能分诊；编写规则和贪睡 信息流是 Developer+ 写入，与 防火墙 RBAC 模型 的其余部分一致。

​
接下来去哪里

规则 schema

完整的 sequence 字段——步骤、min_count、window_seconds 以及每个 其他规则字段。

事件日志

匹配到的序列和异常落入的地方——按运行、执行面和判定过滤。

封顶成本

把一个 burn_spike 信号变成一个硬的逐运行花费上限。

Egress 控制

在网络边界停止一条链的最终外泄步骤。
关于这些机制对抗的攻击者剧本，参见 链式攻击、 数据外泄 与 过度代理。关于深度防火墙参考， 参见 防火墙规则。