Chuyển đến nội dung chính
Các quy tắc firewall tĩnh bắt các cuộc gọi bạn biết để nêu tên. Chúng không thể bắt cuộc gọi được phép riêng lẻ nhưng sai khi tổng hợp — 200 cuộc gọi db.query vào 3 giờ sáng Chủ Nhật, một agent đập một tool đang fail trong một vòng lặp chật, một bước nhảy tool-tới-tool mà workspace này chưa bao giờ làm. Mỗi cuộc gọi qua mọi quy tắc; mẫu mới là vấn đề. Phát hiện bất thường firewall là lớp hành vi. Gateway học hình dạng dùng tool bình thường của workspace bạn và chấm điểm hoạt động live trên đó, làm hiện các lệch trên một feed mà bất kỳ Member nào có thể đọc. Đó là cách bạn để ý một agent bị xâm phạm hoặc một vòng lặp chạy hoang mà không cần đã viết-trước một quy tắc cho một hình dạng bạn chưa từng thấy. Trang này là điểm đáp tập trung cho feed phát hiện bất thường firewall đó; tổng quan Firewall là tham chiếu sâu.
Feed bất thường là phát hiện, không phải thực thi. Nó cho bạn biết cái gì trông lệch — nó không block. Khi một mẫu là thật, bạn biến nó thành một quy tắc hoặc một verdict giới-hạn-tốc-độ để lần xuất hiện kế tiếp bị dừng inline. Đọc feed mở cho mọi Member; biến một phát hiện thành chính sách là Developer+.

​
1. Phát hiện bất thường firewall gắn cờ gì

Bốn loại tín hiệu, mỗi cái gắn với một chế độ thất bại khác nhau:
Khối lượng cuộc gọi theo-tool chấm điểm trên một baseline giờ-trong-tuần đã học. Một tool kích hoạt rate_spike khi số đếm của nó vượt một sàn tuyệt đối và chạy cao so với baseline cho giờ đó, hoặc khi z-score của nó vượt ngưỡng. Khóa theo giờ-trong-tuần (không phải giờ-trong-ngày) nghĩa là Thứ Ba-14:00 được so với các Thứ Ba-14:00 trong quá khứ, nên traffic đỉnh-ngày-thường hợp lệ không đọc như một đột biến trong khi cùng khối lượng vào 3 giờ sáng Chủ Nhật thì có.
Cùng so sánh giờ-trong-tuần, áp dụng cho chi phí tích lũy thay vì số đếm cuộc gọi. Một tool mà chi tiêu chạy vượt xa mức chi-phí đã học của nó hiện ra như một burn_spike — tín hiệu cảnh-báo-sớm cho một agent đắt tiền trước khi nó phá hủy.
Một nhóm (conversation, tool, arguments) lặp lại nhiều lần trong một cửa sổ ngắn — một agent kẹt phát lại cùng cuộc gọi tool đang fail thay vì hồi phục. Polling chậm, hợp lệ không vấp nó; tín hiệu là một vòng lặp chật.
Một chuyển tiếp liên tiếp tool_a → tool_b mà workspace này không có baseline đã học. Lần đầu một agent đi, chẳng hạn, crm.read → http.fetch, cạnh đó là mới lạ — đúng kiểu bước mà một chuỗi rò-rỉ-dữ-liệu thực hiện.
Phát hiện bất thường bổ trợ quy tắc chuỗi. Một quy tắc chuỗi khớp một chuỗi bạn đã định trước; novel_path gắn cờ một chuyển tiếp bạn không định — nó là cách bạn khám phá các chuỗi đáng viết một quy tắc chuỗi.

​
2. Baseline 14 ngày

Bộ phát hiện không phải một ngưỡng cố định — nó là một mức bình thường đã học. Với mỗi bucket (tool, hour-of-week) gateway giữ một số-đếm-cuộc-gọi và chi phí kỳ vọng trượt, backfill từ một lookback 14 ngày (khoảng hai lần xuất hiện của mỗi bucket giờ-trong-tuần — đủ để làm mượt một ngày lẻ mà không mất hình dạng hàng tuần). novel_path dùng baseline chuyển tiếp song song: số đếm xuất hiện đã học cho mỗi cạnh tool_a → tool_b trong giờ-trong-tuần đó. Một workspace hoàn toàn mới chưa có baseline. Không sao: không có mức bình thường đã học, các bộ phát hiện khối lượng rơi về một sàn tuyệt đối, nên một cơn lũ hiển nhiên vẫn bị bắt vào ngày đầu trong khi các mức bình thường theo-giờ điền vào.
Tín hiệuHọc từ cái gì
rate_spike / burn_spikeSố đếm và chi phí theo-(tool, hour-of-week), trượt 14 ngày.
novel_pathSố đếm chuyển tiếp theo-(tool_a → tool_b, hour-of-week).
retry_loopKhông baseline — một ngưỡng lặp theo-cửa-sổ trên (conversation, tool, args).
Feed báo cáo chỉ tên tool, token id đã che, và số đếm. Một API-key id thô không bao giờ xuất hiện — mỗi item mang một digest một-chiều của token đang gọi, nên bạn có thể phân biệt hai bất thường mà feed không bao giờ rò rỉ key đằng sau chúng.

​
3. Một lần đọc cụ thể

Giả sử một agent key bắt đầu loop. Kéo feed trong console dưới Security → Firewall → Anomalies, hoặc đọc nó trực tiếp — bất kỳ Member nào cũng có thể: 
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
  }
}
Một item retry_loop không mang baseline hay z_score (các trường đó ở lại 0 — chúng thuộc về các bộ phát hiện khối-lượng/chi-phí), và nó mang một id mờ ổn định nên hai loop riêng biệt trên cùng tool không va chạm trên một dòng. Một rate_spike thì ngược lại: nó báo cáo một baseline đã học và một z_score, và để id trống.
$ORCA_SESSION_TOKEN là session / access token console của bạn — cùng auth như mọi route quản lý /api/workspace/firewall/*. Nó không phải một relay key sk-orca-… (những cái đó chỉ cho các cuộc gọi mô hình /v1/*) và không phải một firewall-gateway key. Một relay key trên route này bị từ chối.
Mỗi item nêu tên tool, token đã che, bao nhiêu cuộc gọi đã kích hoạt, z-score (chỉ tín hiệu khối-lượng/chi-phí), và một suggested_action (rate_limit, block_tool, hoặc review). Từ đây bạn hành động: thả một quy tắc deny trên tool, kiểm tra đối số của nó, hoặc mở events log để thấy chính xác agent đã làm gì.

​
4. Snooze feed

Một load test đã biết hoặc một backfill đã lên kế hoạch sẽ làm feed sáng lên. Thay vì đuổi theo nhiễu, hãy snooze nó — tối đa 7 ngày: 
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}'
Trong khi một snooze đang hoạt động feed trả về không item và báo cáo snoozed_until; nó tự xóa ngay khi deadline qua. Cap là một trần cứng — một until gõ-nhầm hay thù địch xa hơn bị clamp nên phát hiện bất thường không thể bị làm câm vô thời hạn. POST một until quá-khứ hoặc bây-giờ xóa một snooze hiện có.
Đọc feed là một hành động Member; snooze nó là Developer+ — làm câm một tín hiệu an toàn toàn-workspace là một thao tác ghi, không phải một đọc.

​
5. RBAC trong nháy mắt

Bề mặt analytics chia theo ranh giới đọc/hành-động thông thường:
Hành độngVai trò
Đọc feed bất thườngMember
Đọc cài đặt, chính sách, discovered toolsMember
Snooze feedDeveloper+
Events, runs, aggregate, traceDeveloper+
Soạn một quy tắc từ một phát hiệnDeveloper+
Các chế độ xem tổng hợp nhẹ hơn — cài đặt, chính sách, và bản đồ độ phủ discovered-tools — cũng là đọc Member; chi tiết events và runs cấp-dòng là Developer+, vì nó mang dữ liệu đối số theo-từng-cuộc-gọi.

​
6. Từ tín hiệu tới chính sách

Feed là khởi đầu của một vòng lặp, không phải kết thúc:
1

Phát hiện mẫu

Một novel_path hoặc rate_spike cho thấy một hình dạng bạn không mong đợi. Đọc nó trên events log để xác nhận nó là thật, không phải một-lần.
2

Viết quy tắc

Biến phát hiện thành thực thi — một block, một mệnh đề argument, một quy tắc chuỗi cho chuỗi, hoặc một cap chi phí cho lần đốt.
3

Triển khai nó an toàn

Đáp quy tắc dưới shadow mode trước để bạn đo bán kính tác động của nó trước khi nó block một cuộc gọi nào, rồi thực thi.

​
Đi đâu tiếp theo

Tổng quan Firewall

Tham chiếu phát-hiện-bất-thường đầy đủ và phần còn lại của mặt phẳng chính sách.

Events log

Đào từ một bất thường vào các cuộc gọi chính xác đằng sau nó.

Block một tool

Biến một phát hiện thành một quy tắc thực thi.

Chế độ thực thi

Cách phát hiện, audit, shadow, và thực thi khớp với nhau.
Để biết các mối đe dọa mà các tín hiệu này phơi bày, xem rò rỉ dữ liệu và quyền tự quyết quá mức.