Chuyển đến nội dung chính
Một quy tắc firewall kích hoạt tại một điểm cụ thể trong vòng đời của một cuộc gọi tool. Điểm đó là stage của nó — một trong bốn bề mặt thực thi, mỗi cái thấy một lát cắt khác nhau của cuộc gọi. Ghim một quy tắc vào sai stage và nó thấy sai dữ liệu: một allowlist egress trên bề mặt inbound không có đích đến để kiểm tra; một mệnh đề argument trên inbound chưa có argument tại thời điểm gọi. Trang này là hướng dẫn tập trung về bốn stage agent firewall: mỗi bề mặt quan sát cái gì, khi nào một quy tắc nên nhắm vào nó, và cách cụ thể mà cùng một ý định được diễn đạt ở các stage khác nhau. Để biết từ vựng quy tắc đầy đủ, xem Quy tắc Firewall; để biết mô hình chính sách xung quanh nó, Firewall.

​
1. Bốn stage trong nháy mắt

Mỗi lần đánh giá được đóng dấu đúng một stage. Một quy tắc không có stage ("") áp dụng cho tất cả chúng; một quy tắc ghim vào một stage chỉ kích hoạt ở đó.
StageBề mặt thấy cái gì
inboundCác tool mà agent quảng bá trên request
responseCác tool_calls mà mô hình phát ra trong câu trả lời
mcpMột tools/call được dispatch qua MCP gateway
egressMột host / IP / CIDR đi ra ngoài mà một tool vươn tới
Tên stage là các giá trị enum ổn định — bạn đặt chúng nguyên văn trong trường stage của trình chỉnh sửa quy tắc, hoặc làm thuộc tính stage khi soạn qua API.
Stage kiểm soát dữ liệu nào trong phạm vi, không phải verdict nghiêm đến đâu. Một deny là một deny trên bất kỳ stage nào; cái thay đổi là liệu quy tắc có argument, tên tool, hay đích đến mà nó cần để khớp hay không.

​
2. inbound — các tool mà một agent quảng bá

Bề mặt sớm nhất. Trước khi mô hình chạy, agent của bạn gửi một danh sách định nghĩa tool mà nó sẵn lòng cho mô hình gọi. Stage inbound thấy bộ tool được quảng bá đó và có thể block một tool nguy hiểm trước khi mô hình kịp chọn nó. Không có argument tại thời điểm gọi ở stage này — mô hình chưa quyết định gọi bất cứ thứ gì thế nào — nên các quy tắc inbound khớp trên tên tool (và tùy chọn skill sở hữu của nó), không phải trên args_match_json.
Một verdict sanitize trên inbound không có gì để redact (chưa có argument tồn tại), nên nó leo thang thành một block. Soạn các quy tắc inbound dưới dạng allow / deny tường minh, và để dành sanitize cho các stage thực thi.
Một cuộc gọi bị deny ở đây trả về HTTP 400 với mã firewall_blocked, được đặt tên theo tool và lý do, và được đánh dấu skip-retry.

​
3. response — các cuộc gọi tool mà mô hình phát ra

Một khi mô hình trả lời, nó có thể phát ra một hoặc nhiều tool_calls — các lời gọi cụ thể với argument thực. Stage response thấy những cái đó, nên đây là nơi các quy tắc ở cấp argument thuộc về: không phải “block shell.exec” mà “block shell.exec chỉ khi lệnh là rm -rf”. 
{
  "stage": "response",
  "tool_name_glob": "shell.exec",
  "verdict": "deny",
  "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf|mkfs|dd if=\"}]}"
}
Bởi vì các argument mà mô hình chọn có mặt, sanitize hoạt động ở đây — nó redact các chuỗi con đã khớp khỏi argument của cuộc gọi và chuyển tiếp cuộc gọi đã làm sạch. (Sanitize redact argument của cuộc gọi tool; nó không bao giờ động tới nội dung mà một tool trả về.)

​
4. mcp — các cuộc gọi được dispatch qua gateway

Khi một agent vươn tới một tool qua MCP gateway của OrcaRouter, mỗi tools/call được đánh giá trên stage mcp trước khi nó được dispatch tới server đã đăng ký. Đây là bề mặt kiểm soát traffic Model Context Protocol — cùng từ vựng glob / argument / verdict như response, áp dụng cho dispatch MCP. Một block ở đây hiện ra dưới dạng một lỗi tool (firewall deny: <reason>) thay vì một thất bại truyền tải, nên mô hình thấy sự từ chối và có thể phản ứng — chọn một tool khác, hỏi người dùng, hoặc dừng.
Stage mcp ghép đôi với việc kiểm soát theo từng server: mỗi MCP server đã đăng ký có health probe và credential mã hóa riêng, và các skill nạp qua nó mang theo một risk band và một chế độ thực thi. Xem Firewall MCP và Firewall skills.

​
5. egress — đích đến đi ra ngoài mà một tool vươn tới

Bề mặt cuối cùng. Khi một tool báo cáo một đích đến mạng đi ra ngoài, stage egress khớp trên nó — bề mặt SSRF và rò rỉ dữ liệu. Các quy tắc egress không khớp trên một mẫu tên tool đơn thuần; chúng khớp trên một danh sách host / IP / CIDR: 
{
  "stage": "egress",
  "verdict": "deny",
  "egress_json": "{\"deny\":[\"169.254.169.254\",\"10.0.0.0/8\"],\"allow\":[\"api.openai.com\"]}"
}
Các entry khớp như một CIDR, một IP literal, hoặc một hostname không phân biệt chữ hoa-thường. Bạn tự soạn các quy tắc deny host và CIDR — endpoint cloud-metadata (169.254.169.254) và các dải RFC-1918 là những thứ kinh điển cần deny. Xem Quy tắc Firewall §6 để biết cực tính allow/deny.
Không preset nào ship quy tắc CIDR. Tư thế SSRF của cấp độ tự chủ tight deny các tên tool dạng fetch (vd: http_fetch, web_search, fetch_url); một egress deny dựa trên đích đến là thứ bạn soạn cho các host và dải mà agent của bạn không bao giờ được vươn tới.

​
6. Chọn đúng stage

Cùng một mục tiêu bảo mật thường có một stage tốt nhất. Khớp ý định với bề mặt thực sự mang dữ liệu bạn cần:
Nếu mô hình không bao giờ nên thấy một tool, deny nó trên inbound. Block đến trước cuộc gọi mô hình, nên nó không tốn token mô hình.
Các mệnh đề argument cần các argument mà mô hình chọn, vốn chỉ tồn tại trên response và mcp. Deny trên một argument nguy hiểm, hoặc sanitize để loại bỏ một secret hoặc giá trị PII mà agent đặt trong một argument.
Các cuộc gọi định tuyến qua MCP gateway được đánh giá trên mcp trước khi dispatch — điểm nghẽn cho các tool của mọi server đã đăng ký.
Các quy tắc dựa trên đích đến — block IP cloud-metadata, deny một CIDR, allowlist các host đã phê duyệt của bạn — chỉ có ý nghĩa trên egress.
Một quy tắc không có stage chạy trên cả bốn. Dùng nó cho một quy tắc kiểu default_verdict bao trùm, hoặc một tool bạn deny ở mọi nơi nó xuất hiện.

​
7. Stage và shadow mode

Cờ shadow_mode của một chính sách độc lập với stage. Bật nó và mọi verdict thực thi — trên bất kỳ stage nào — bị hạ cấp thành audit và lý do được thêm tiền tố [shadow] would …, nên bạn có thể xác nhận một quy tắc kích hoạt trên đúng bề mặt trước khi nó thay đổi traffic thực. Xem Shadow mode và Chế độ thực thi.

​
8. Stage nằm ở đâu trong bức tranh lớn

Bốn stage là nơi thực thi; phần còn lại của mô hình là cái gì và ai.

Verdict

Mỗi stage có thể làm gì một khi nó khớp — allow, audit, deny, sanitize, giữ lại chờ phê duyệt, giới hạn chi phí.

Allow-list tool

Dùng inbound để ràng buộc bộ tool mà một agent quảng bá.

Validate argument

Soạn các mệnh đề argument response / mcp gating một tool theo cách nó được gọi.

Kiểm soát egress

Block các đích đến đi ra ngoài trên bề mặt egress — ranh giới rò rỉ.
Để biết các bề mặt này nằm thế nào trên đường thanh tra, xem OrcaRouter thanh tra thế nào và các ghi chú độ trễ đường thực thi. Để biết các mối đe dọa mỗi stage giải quyết, xem Cuộc gọi tool nguy hiểm, Rò rỉ dữ liệu, và MCP tool poisoning.