Chuyển đến nội dung chính
Một AI agent không chỉ sinh ra văn bản — nó hành động. Nó gọi shell.exec, truy vấn một cơ sở dữ liệu, fetch một URL, dispatch một tool qua một MCP server. Mỗi cái trong số đó là một hành động ngoài đời thực mà guardrails ở tầng prompt không thể thấy. Agent firewall là mặt phẳng ở tầng hành động kiểm soát chúng: một chính sách có tên, theo phạm vi workspace mà gateway đánh giá trên mọi cuộc gọi tool, trước khi nó đến được tool. Trang này là trung tâm cho phần Firewall — mô hình chính sách, các verdict, các bề mặt, và cách một chính sách gắn vào một key. Mỗi nhánh đi sâu hơn, và tham chiếu engine đầy đủ nằm ở Firewall và Quy tắc Firewall.

​
1. Agent firewall làm gì

Bạn soạn một chính sách một lần trong console workspace, gắn một API key vào nó (hoặc đặt một cái làm mặc định của workspace), và từ đó về sau mọi cuộc gọi tool mà key đó phát ra đều được kiểm tra đối với chính sách tại gateway. Không triển khai lại, không đổi code agent — agent của bạn vẫn phát ra các cuộc gọi tool y như trước, và việc chỉnh sửa chính sách có hiệu lực ở lần gọi kế tiếp cho mọi key gắn với nó. Một chính sách là một danh sách quy tắc có thứ tự. Mỗi quy tắc quyết định nó áp dụng cho những cuộc gọi tool nào và làm gì với chúng. Engine duyệt các quy tắc theo thứ tự ưu tiên, match đầu tiên thắng, và fallback về verdict mặc định của chính sách nếu không có gì khớp.
Phát hiện diễn ra ở gateway, ở lần dùng đầu tiên — không phải lúc cài đặt. Một tool, MCP server, hoặc skill mà một agent tự cài đặt được bắt ở lần đầu tiên cuộc gọi của nó vượt qua gateway. Đó là điểm nghẽn duy nhất thấy mọi provider, mọi agent, và mọi cuộc gọi tool bất kể khả năng đó đến đó bằng cách nào.

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

Giả sử bạn muốn block các lệnh shell phá hủy nhưng cho mọi thứ khác đi qua dưới audit. Trong console bạn tạo một chính sách với default_verdict = audit và một quy tắc: 
{
  "label": "block rm -rf",
  "tool_name_glob": "*.exec",
  "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf|drop table\"}]}",
  "verdict": "deny"
}
args_match_json là một chuỗi được mã hóa JSON (gateway validate nó đối với schema mệnh đề khi lưu): path là một JSONPath vào argument của cuộc gọi, op là một trong eq, contains, regex, in, cidr_match, gt, lt. Gắn một key vào chính sách (đặt firewall_policy_id trên key). Giờ khi một agent phát ra shell.exec với command: "rm -rf /", gateway trả về HTTP 400 với mã lỗi firewall_blocked và một lý do nêu tên tool — và cuộc gọi không bao giờ đến được shell. Mọi cuộc gọi tool khác đều được cho phép và ghi lại để xem xét.
Triển khai một chính sách mới dưới shadow mode trước: nó đánh giá và ghi log chính xác như nó sẽ làm trong production, nhưng mọi verdict thực thi bị hạ cấp thành audit và lý do được thêm tiền tố [shadow] would …. Theo dõi feed sự kiện, rồi tắt shadow để thực thi.

​
3. Chính sách, quy tắc, và phân giải

Một chính sách theo phạm vi workspace và có tên, với enabled, is_default, một default_verdict (allow / audit / deny, mặc định audit), và một cờ shadow_mode. Một quy tắc là một kiểm tra bên trong nó — xem Tạo một chính sách và Rule schema. Với bất kỳ cuộc gọi tool nào, gateway phân giải chính sách đang hoạt động theo thứ tự:
  1. Liên kết key — firewall_policy_id của key đang gọi, khi chính sách đó tồn tại và được bật.
  2. Mặc định workspace — ngược lại, chính sách is_default đã bật.
Một chính sách firewall đã gắn nhưng bị tắt sẽ fallback về mặc định của workspace — điều này khác với guardrails, nơi một liên kết bị tắt phân giải về không có. Công tắc tắt trên firewall của một key là “dùng mặc định”, không phải “không thực thi”. Xem Quản lý chính sách.
Khi không có chính sách nào phân giải, hành vi phụ thuộc vào cài đặt firewall_observe_mode của workspace: với observe mode bật, cuộc gọi được cho phép nhưng được ghi log như một khoảng trống độ phủ (nó xuất hiện trong Discovered Tools); với nó tắt, cuộc gọi được cho phép một cách im lặng.

​
4. Verdict

Một quy tắc — hoặc mặc định — tạo ra một trong các giá trị:
VerdictNó làm gì
allowCho đi qua, được ghi log.
auditCho phép + ghi lại để xem xét. Mặc định thông thường.
denyBlock. HTTP 400 firewall_blocked trên inbound; lỗi tool trên MCP.
sanitizeRedact các chuỗi con đã khớp khỏi argument của tool và chuyển tiếp.
pending_approvalGiữ lại cho một con người; HTTP 400 firewall_approval_pending.
cap_costDeny một khi mức chi tiêu của lần chạy vượt qua một mức trần theo từng quy tắc.
Một verdict sanitize chỉ redact argument của cuộc gọi — không bao giờ nội dung mà một tool trả về. Trên bề mặt inbound, nơi chưa có argument tại thời điểm gọi, sanitize leo thang thành một block. Xem Verdict và Sanitize phản hồi.

​
5. Bốn bề mặt thực thi

Mỗi cuộc gọi tool được đánh giá đối với đúng một bề mặt — ghim một quy tắc vào một bề mặt bằng trường stage, hoặc để trống để áp dụng cho tất cả.

inbound

Các tool mà một agent quảng bá tới mô hình trên request. Block một tool nguy hiểm trước khi mô hình kịp chọn nó.

response

Các tool_calls mà mô hình phát ra trong câu trả lời của nó.

mcp

Một tools/call được dispatch qua MCP gateway. Xem MCP server.

egress

Một host / IP / CIDR đi ra ngoài mà một tool vươn tới — bề mặt SSRF và rò rỉ dữ liệu.

​
6. So khớp

Các quy tắc diễn đạt những cuộc gọi tool nào chúng bắt bằng một bộ từ vựng nhỏ, xác định, an toàn trên hot path:
Một glob phân biệt chữ hoa-thường trên tên tool (shell.*, *.delete), tùy chọn AND với một glob trên skill sở hữu. Xem Cú pháp glob và Allow-list tool.
Các predicate JSONPath trên argument của cuộc gọi với các toán tử eq, contains, regex, in, cidr_match, gt, lt — sự khác biệt giữa “block shell.exec” và “block nó chỉ khi lệnh là rm -rf”. Các mệnh đề fail closed (quy tắc, không phải request). Xem Validate argument.
Danh sách allow và deny host / IP / CIDR trên bề mặt egress. Bạn có thể tự soạn quy tắc deny của mình cho cloud-metadata hoặc các dải RFC-1918. Xem Kiểm soát egress.
Một quy tắc sequence khớp một chuỗi cuộc gọi có thứ tự qua một cửa sổ (thực thi phản ứng); một quy tắc cap_cost deny một khi mức chi tiêu tích lũy của một lần chạy agent vượt qua một mức trần tính bằng cents. Xem Quy tắc chuỗi và Giới hạn chi phí.

​
7. Phê duyệt bởi con người, tự chủ, và bất thường

  • Human-in-the-loop. Một verdict pending_approval giữ cuộc gọi lại và trả về approval id của nó. Một reviewer giải quyết nó trong console (Developer+) hoặc qua một webhook callback ký HMAC; agent poll và gửi lại với một header X-OrcaRouter-Firewall-Approval dùng một lần. Xem Phê duyệt và Webhook phê duyệt.
  • Cấp độ tự chủ. Một công tắc đặt toàn bộ tư thế của bạn: tight (default-deny + deny destructive shell + deny các tool dạng fetch (http_fetch/web_search/fetch_url/request, vector SSRF) + thực thi PII Shield + Secrets Blocker), balanced (audit mặc định, deny destructive shell, PII Shield chỉ audit), hoặc permissive (chỉ observe). Mỗi cái ghi ra các hàng chính sách và guardrail thực, có thể chỉnh sửa, với hoàn tác một cú nhấp từ snapshot audit.
  • Phát hiện bất thường. Vượt ra ngoài các quy tắc tĩnh, firewall chấm điểm việc dùng tool đối với một baseline giờ-trong-tuần đã học (14 ngày) và gắn cờ các spike tốc độ/chi phí, retry_loop, và novel_path trên một feed mà Member có thể đọc, bạn có thể snooze lên đến 7 ngày.

​
8. Firewall nằm ở đâu

Firewall là đối tác ở tầng hành động của hai mặt phẳng kề bên:
Mặt phẳngKiểm soátKhi nào dùng
GuardrailsVăn bản prompt & responsePII, secrets, jailbreak, ý định injection
Agent firewallHành động toolTool nào, cuộc gọi MCP, host, và chi phí
ComplianceBằng chứng & frameworkSẵn sàng SOC 2 / HIPAA / EU AI Act
Cả mặt phẳng nội dung lẫn hành động đều có thể áp dụng cho một request đơn lẻ, và một cấp độ tự chủ cấu hình chúng cùng nhau. Xem Guardrails vs. Firewall và control stack.

​
9. Gắn và kết nối

Một chính sách liên kết với một key qua firewall_policy_id (cấu hình trong console; liên kết nằm trên key trong gateway). Hai cách để một cuộc gọi tool đến được engine, cả hai đều yêu cầu một key có phạm vi firewall-gateway (is_firewall_gateway = true) — một key relay thông thường nhận 403 trên các route này:
  • MCP gateway — trỏ MCP client của bạn vào endpoint hợp nhất ANY /api/v1/firewall/mcp; mỗi tools/call được đánh giá inline. Xem MCP server.
  • Evaluate hook — gọi POST /api/v1/firewall/evaluate (hoặc /evaluate_plan cho một kế hoạch nhiều bước) từ vòng lặp agent của riêng bạn trước khi dispatch, và hành động dựa trên verdict.
Mọi cấu hình console chạy dưới session của bạn qua /api/workspace/firewall/*. Đọc chính sách, cài đặt, discovered tools, bộ mô phỏng tự chủ chỉ-đọc, và feed bất thường mở cho mọi thành viên workspace; sandbox Test dry-run, log Events / Runs, và mọi thao tác ghi yêu cầu Developer+. Xem Gateway key và Test quy tắc.

​
10. Các mối đe dọa mặt phẳng này giải quyết

Cuộc gọi tool nguy hiểm

Deny destructive shell, DB drop, và các động từ rủi ro theo glob + args.

Rò rỉ dữ liệu

Danh sách egress và quy tắc chuỗi read-then-export.

MCP tool poisoning

Đánh giá theo từng cuộc gọi trên bề mặt mcp trước khi dispatch.

Excessive agency

Phê duyệt, mức trần chi phí, và tư thế default-deny.

​
Các bước tiếp theo

Tạo một chính sách

Soạn chính sách và quy tắc đầu tiên của bạn.

Verdict

Mỗi verdict làm gì trên đường truyền.

Log sự kiện

Đọc firewall đã quyết định gì và tại sao.