跳转到主要内容
当你的 防火墙策略 判断一次工具调用时，它写一行。 事件信息流就是那份运行日志：每次评估一条记录，携带判定、它触发的执行面、 工具、原因，以及它所属的运行/会话。它是你在上线一条策略之后回答唯一重要 问题的方式——防火墙是否真的做了我认为它做的事，在我认为它做了的那些调用 上？ 这是你的 AI 防火墙日志执行面。每一个 allow、每一个 deny、每一个 被挂起的审批、每一个影子模式的”本来会”都落在这里，可过滤并关联回产生它的 那次智能体运行。
事件信息流读取需 Developer+。每一行保留一个有上限的 args_summary 字段用于一个工具调用参数快照，所以这个执行面位于 Member 可读的那些之上 （设置、策略、discovered tools、 异常信息流）。从控制台配置所有这些——这些是会话 认证的路由，而非中继调用。

​
1. 什么落入事件信息流

引擎运行的每一次评估都被记录——不只是拦截。一个 allow 和一个 audit 就像一个 deny 一样留下一行，所以该信息流是一份完整的追踪，而非一份 异常日志。 一行上的判定是智能体实际看到的那个：
判定意味着
allow / audit放行；audit 把它 flag 为你想要观察的东西。
deny被拦截——inbound 上 firewall_blocked（HTTP 400），mcp 上工具错误。
sanitize转发，匹配的子串已从该调用的参数中脱敏。
pending_approval为一名人工挂起；该行标记该调用被设门。
observe没有策略匹配——一个 观察模式 覆盖缺口。
你绝不会在信息流中看到一个字面的 cap_cost。一条 cap-cost 规则 在评估时解析为一个具体的 allow 或 deny，而被记录的就是那个——该运行实际经历的判定。
在 影子模式 下，执行性判定被降级为 audit，原因前缀为 [shadow] would …，所以该信息流向你准确显示一条策略在 你把它切换到实时之前本来会拦截什么。

​
2. 每个事件记录什么

单个事件是一个去规范化的快照——足以重建该决策而无需 join 回任何东西：
verdict、surface（inbound / response / mcp / egress）、 tool_name，以及一个人类 reason（“destructive shell command”、 “egress to 169.254.169.254 denied”）。当匹配规则有一个标签时， policy_name 和 rule_label 点名触发的确切规则——所以该行直接指回你 写的那一行。
request_id 把该事件 join 到请求日志；conversation_id 把一个多回合 会话分组；agent_run_id（带 step_id / parent_step_id）把它绑定到一次 完整的智能体运行以及请求该工具的 LLM 调用。这些就是让该信息流成为一个 trace 而非一个平坦列表的东西——参见 §4。
token_name、model_name，以及调用者 ip——该调用背后的密钥、模型和 来源。skill_name 在该调用可归属于一个 技能 时点名所属技能，而 quarantine flag 一个技能隔离挂起。
args_summary 是有上限的工具调用参数快照字段（这个执行面是 Developer+ 的原因）。在一个 egress 事件上，egress_host 记录被判断的出站目的地。
args_summary 是有上限的——原始参数字节绝不逐字写入信息流，而支撑异常 检测的 retry-loop 分组哈希是仅服务端的：它绝不在 API 中传输。

​
3. 一个具体示例

你的智能体发出了一个带 rm -rf /data 的 shell.exec 调用，一条 deny 规则捕获了它，而你想看到那一个决策。按判定和工具过滤信息流： 
# Developer+ console session — GET /api/workspace/firewall/events
curl https://api.orcarouter.ai/api/workspace/firewall/events?verdict=deny&tool=shell.exec \
  -H "Authorization: Bearer $ORCA_CONSOLE_TOKEN"

{
  "events": [
    {
      "verdict": "deny",
      "surface": "response",
      "tool_name": "shell.exec",
      "reason": "destructive shell command",
      "policy_name": "agent-baseline",
      "rule_label": "block destructive shell",
      "model_name": "gpt-4o",
      "token_name": "prod-agent",
      "agent_run_id": "run_abc",
      "request_id": "req_…"
    }
  ],
  "total": 1
}
控制台把同样的行渲染为一个可过滤的表——你很少手动打到这条路由。从事件视图 配置过滤器、钻取一次运行并导出；上面的 curl 只是为了展示其形态。
$ORCA_CONSOLE_TOKEN 是你的会话 / 访问令牌，而非一个 sk-orca-… 中继 密钥。/api/workspace/firewall/* 路由是控制台认证且角色门控的；只有 /v1/* 流量使用一个中继密钥。

​
4. 按运行和会话关联

每个事件都携带 agent_run_id 和 conversation_id 的原因，就是为了让你 停止孤立地看待调用，开始追问这个智能体在它的整次运行中做了什么：
过滤器它回答的问题
run_id=<run>一次智能体运行中的每一个判定——完整的动作追踪。
session_id=<conv>一个多回合对话中的每一个判定。
verdict=deny,pending_approval一次查询中的”什么被停止或挂起”视图。
surface=egress只有出站目的地决策——外泄透镜。
事件列表还接受 since / until（unix 秒）以及用于分页的 limit / skip。 关于汇总视图——每次运行或会话一行，带逐判定细分、不同的工具和模型， 以及首次/末次出现——控制台读取 GET /api/workspace/firewall/events/aggregate?group_by=run（或 group_by=session），而智能体 trace 树读取 /trace/by-run。两者都是 Developer+，与原始信息流相同。
从请求日志抽屉，你可以朝另一个方向转向： GET /api/workspace/firewall/events/by-request/:request_id 返回单个请求下 捕获的每一个防火墙事件——当一个请求跨执行面触发了若干条规则时很方便。

​
5. 保留与擦除

防火墙事件携带它们自己的保留期限——一个 30 天默认，服务端钳制到一个 365 天硬上限。每个事件以一个到期写入，并由一个 TTL 索引自动老化淘汰； 信息流中没有任何东西活过你的保留设置。 一个 被遗忘权 请求也在此处 级联：删除一个用户启动一个 30 天宽限期，之后他们的 PII 被擦除，而他们的 防火墙事件连同同范围的请求日志和防护栏匹配一起被清除。

​
接下来去哪里

判定

信息流中的每个判定实际对该调用做了什么。

影子模式

在你执行之前以”本来会”模式读取信息流。

执行面与执行面

surface 字段点名的四个执行面。

防火墙参考

完整的策略、规则和 API 参考。
关于这些日志帮助你当场捕获的威胁，参见 数据外泄 与 危险工具调用。关于防火墙如何与 提示词/响应文本筛查搭配，参见 防火墙 + 防护栏。