Chuyển đến nội dung chính
Khi chính sách firewall của bạn phán xét một cuộc gọi tool, nó viết một dòng. Events feed là log đang chạy đó: một bản ghi cho mỗi đánh giá, mang verdict, bề mặt nó kích hoạt, tool, lý do, và lần-chạy/session nó thuộc về. Đó là cách bạn trả lời câu hỏi duy nhất quan trọng sau khi bạn ship một chính sách — firewall có thực sự làm cái tôi nghĩ nó làm không, trên các cuộc gọi tôi nghĩ nó làm nó không? Đây là bề mặt log AI firewall của bạn. Mọi allow, mọi deny, mọi phê duyệt được giữ, mọi “would-have” của shadow-mode đáp xuống đây, có thể lọc và tương quan trở lại lần chạy agent đã tạo ra nó.
Events feed là Developer+ để đọc. Mỗi dòng dành riêng một trường args_summary có-giới-hạn cho một snapshot đối số cuộc-gọi-tool, nên bề mặt này nằm trên các cái Member-đọc-được (cài đặt, chính sách, discovered tools, feed bất thường). Cấu hình toàn bộ cái này từ console — đây là các route xác-thực-bằng-session, không phải các cuộc gọi relay.

​
1. Cái gì đáp xuống events feed

Mỗi đánh giá mà engine chạy được ghi lại — không chỉ các block. Một allow và một audit để lại một dòng đúng như một deny làm, nên feed là một dấu vết đầy đủ, không phải một log ngoại lệ. Verdict trên một dòng là cái mà agent thực sự thấy:
VerdictNghĩa
allow / auditCho qua; audit gắn cờ nó như một thứ bạn muốn theo dõi.
denyBị block — firewall_blocked (HTTP 400) ở inbound, lỗi tool trên mcp.
sanitizeChuyển tiếp với các chuỗi con đã khớp được che khỏi đối số của cuộc gọi.
pending_approvalĐược giữ chờ một con người; dòng đánh dấu cuộc gọi được quản trị.
observeKhông chính sách nào khớp — một khoảng trống độ phủ observe-mode.
Bạn sẽ không bao giờ thấy một cap_cost theo nghĩa đen trong feed. Một quy tắc cap-cost phân giải về một allow hoặc deny cụ thể tại thời điểm đánh giá, và đó là cái được ghi log — verdict mà lần chạy thực sự trải qua.
Trong shadow mode các verdict thực thi bị hạ cấp thành audit và lý do được thêm tiền tố [shadow] would …, nên feed cho bạn thấy chính xác cái mà một chính sách sẽ block trước khi bạn bật nó live.

​
2. Mỗi event ghi lại gì

Một event đơn là một snapshot phi-chuẩn-hóa — đủ để tái dựng quyết định mà không cần join lại với bất cứ thứ gì:
verdict, surface (inbound / response / mcp / egress), tool_name, và một reason con người (“destructive shell command”, “egress to 169.254.169.254 denied”). Khi quy tắc đã khớp có một nhãn, policy_name và rule_label nêu tên đúng quy tắc đã kích hoạt — nên dòng trỏ thẳng về dòng bạn đã viết.
request_id join event với request log; conversation_id nhóm một session nhiều-lượt; agent_run_id (với step_id / parent_step_id) buộc nó với một lần chạy agent đầy đủ và cuộc gọi LLM đã yêu cầu tool. Đây là những cái làm feed thành một trace, không phải một danh sách phẳng — xem §4.
token_name, model_name, và ip người gọi — key, mô hình, và nguồn gốc đằng sau cuộc gọi. skill_name nêu tên skill sở hữu khi cuộc gọi quy được cho một cái, và quarantine gắn cờ một lần giữ skill-quarantine.
args_summary là trường snapshot đối số cuộc-gọi-tool có-giới-hạn (lý do bề mặt này là Developer+). Trên một event egress, egress_host ghi lại đích đến đi ra ngoài đã được phán xét.
args_summary có giới hạn — các byte đối số thô không bao giờ được viết nguyên văn vào feed, và hash nhóm retry-loop hậu thuẫn phát hiện bất thường là chỉ-server: nó không bao giờ ship trong API.

​
3. Một ví dụ cụ thể

Agent của bạn phát ra một cuộc gọi shell.exec với rm -rf /data, một quy tắc deny bắt nó, và bạn muốn thấy quyết định đó. Lọc feed theo verdict và tool: 
# 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
}
Console render cùng các dòng như một bảng có thể lọc — bạn hiếm khi gọi route bằng tay. Cấu hình filter, đào sâu vào một lần chạy, và export từ chế độ xem events; curl ở trên chỉ để cho thấy hình dạng.
$ORCA_CONSOLE_TOKEN là session / access token của bạn, không phải một relay key sk-orca-…. Các route /api/workspace/firewall/* xác-thực-bằng- console và giới hạn vai trò; chỉ traffic /v1/* dùng một relay key.

​
4. Tương quan theo lần chạy và session

Lý do mỗi event mang agent_run_id và conversation_id là để bạn có thể ngừng nhìn các cuộc gọi cô lập và bắt đầu hỏi agent này đã làm gì trên cả lần chạy của nó:
FilterCâu hỏi nó trả lời
run_id=<run>Mọi verdict trong một lần chạy agent — toàn bộ dấu vết hành động.
session_id=<conv>Mọi verdict trên một conversation nhiều-lượt.
verdict=deny,pending_approvalChế độ xem “cái gì bị dừng hoặc giữ” trong một truy vấn.
surface=egressChỉ các quyết định đích-đến-đi-ra-ngoài — lăng kính rò rỉ.
Danh sách events cũng chấp nhận since / until (giây unix) và limit / skip để phân trang. Để có chế độ xem tổng-hợp — một dòng cho mỗi lần chạy hoặc session với một phân tích theo-từng-verdict, các tool và mô hình riêng biệt, và first/last-seen — console đọc GET /api/workspace/firewall/events/aggregate?group_by=run (hoặc group_by=session), và cây agent-trace đọc /trace/by-run. Cả hai là Developer+, giống feed thô.
Từ ngăn kéo request-log bạn có thể xoay hướng ngược lại: GET /api/workspace/firewall/events/by-request/:request_id trả về mọi event firewall được bắt dưới một request duy nhất — tiện khi một request vấp nhiều quy tắc trên các bề mặt.

​
5. Lưu giữ và xóa

Các event firewall mang chân trời lưu giữ riêng của chúng — một mặc định 30 ngày, server-clamp về một tối đa cứng 365 ngày. Mỗi event được viết với một hết hạn và được lão hóa ra tự động bởi một TTL index; không gì trong feed sống quá cài đặt lưu giữ của bạn. Một yêu cầu quyền-được-xóa cũng xếp tầng ở đây: xóa một người dùng bắt đầu một giai đoạn ân hạn 30 ngày, sau đó PII của họ bị chà sạch và các event firewall của họ bị thanh lọc cùng với request log và các match guardrail của cùng phạm vi.

​
Đi đâu tiếp theo

Verdict

Mỗi verdict trong feed thực sự đã làm gì với cuộc gọi.

Shadow mode

Đọc feed ở chế độ “would-have” trước khi bạn thực thi.

Stage & bề mặt

Bốn bề mặt mà trường surface nêu tên.

Tham chiếu Firewall

Toàn bộ tham chiếu chính sách, quy tắc, và API.
Để biết các mối đe dọa mà các log này giúp bạn bắt tại trận, xem rò rỉ dữ liệu và cuộc gọi tool nguy hiểm. Để biết cách firewall ghép với sàng lọc văn bản prompt/phản hồi, xem firewall + guardrails.