Chuyển đến nội dung chính
Một MCP server bạn kết nối ship các tool vươn ra mạng — một fetch, một web_search, một webhook poster. Tên tool có thể nằm trên allow-list của bạn, các argument có thể trông sạch, và cuộc gọi vẫn kết thúc bằng việc POST dữ liệu của bạn tới một host do kẻ tấn công kiểm soát hoặc kéo credential khỏi endpoint metadata 169.254.169.254. Đích đến là phần của cuộc gọi mà các quy tắc tên-tool của bạn không bao giờ thấy. mcp egress control đóng khoảng trống đó. Một quy tắc egress thu hẹp một verdict firewall về nơi một tool vươn tới — một host, một IP, hoặc một dải CIDR — nên cùng một http_fetch được phép tới api.openai.com bị từ chối tới mọi thứ khác. Nó chạy trên bề mặt egress của firewall, ở trên đánh giá theo từng cuộc gọi mà mọi tools/call đã đi qua.
Đây là một nhiệm vụ console. Các quy tắc firewall sống trên các route /api/workspace/firewall/*, vốn xác thực bằng session / access token của bạn — không phải một relay key sk-orca-…. Việc soạn một quy tắc yêu cầu vai trò Developer+.

​
1. Một quy tắc egress kiểm soát cái gì

Một quy tắc thông thường khớp trên tên tool và các argument của nó. Một quy tắc egress thêm một chiều thứ ba: đích đến mà cuộc gọi giải tới đó. Bạn đặt stage của quy tắc thành egress và đính một danh sách egress_json gồm các mục allow / deny. Engine trích host đích từ cuộc gọi và chỉ kích hoạt quy tắc khi host đó nằm trong phạm vi. Các mục được khớp ba cách:

Hostname

Khớp chính xác không phân biệt hoa thường, ví dụ api.openai.com. Một dấu chấm cuối được cắt ở cả hai phía.

IP literal

Khớp chính xác đối với IP dial đã phân giải, ví dụ 169.254.169.254.

Dải CIDR

IP đích — literal hoặc được DNS phân giải — phải rơi vào trong khối, ví dụ 10.0.0.0/8.
Khi một đích đến là một hostname nhưng danh sách của bạn mang các mục IP/CIDR, tên được phân giải và các IP của nó được kiểm tra lại — nên metadata.internal khớp một deny 169.254.0.0/16 dù nó không được liệt kê theo tên. Đây là phòng vệ theo chiều sâu nỗ lực tốt nhất chống lại một tên phân giải vào một dải bị từ chối; bảo vệ SSRF có thẩm quyền vẫn chạy ở lớp dial của gateway.

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

Từ chối mọi tool hình dạng fetch tiếp cận endpoint cloud-metadata và các dải RFC-1918. Đây là cắt chân exfil SSRF chính tắc: một verdict deny trên stage egress, được thu hẹp bởi một denylist egress_json. 
curl https://api.orcarouter.ai/api/workspace/firewall/rules \
  -H "Authorization: Bearer <your-session-or-access-token>" \
  -H "Content-Type: application/json" \
  -d '{
    "policy_id": 12,
    "priority": 10,
    "label": "Deny SSRF / metadata egress",
    "stage": "egress",
    "tool_name_glob": "*",
    "verdict": "deny",
    "egress_json": "{\"deny\":[\"169.254.169.254\",\"10.0.0.0/8\",\"172.16.0.0/12\",\"192.168.0.0/16\"]}"
  }'
Một tools/call có đích đến phân giải vào bất kỳ dải nào trong số đó quay lại mô hình như một lỗi tool; một cuộc gọi tới một host công khai mà denylist không bao trùm thì đi qua.
Các danh sách allow/deny đảo nghĩa với verdict. Trên một quy tắc deny (hoặc enforcing khác), danh sách deny là tập trong-phạm-vi và allow khắc ra các miễn trừ — “từ chối những cái này, trừ những cái kia”. Trên một quy tắc allow, các vai trò đảo ngược: danh sách allow là tập trong-phạm-vi và deny khắc ra các miễn trừ — “chỉ cho phép những cái này”. Một egress_json không rỗng phải khai báo ít nhất một mục allow hoặc deny, nếu không việc ghi bị từ chối.

​
3. Allow-list chỉ một đích đến

Điều ngược lại của ví dụ trên: ghim một fetch tool vào một host đã được phê chuẩn duy nhất và để default_verdict của chính sách (hoặc một catch-all sau đó) xử lý phần còn lại. Vì đây là một verdict allow, danh sách allow là tập trong-phạm-vi. 
// egress_json on an allow-verdict, stage=egress rule
{ "allow": ["api.openai.com", "api.anthropic.com"] }
Quy tắc giờ kích hoạt (cho phép) chỉ khi đích đến là một trong hai host đó. Bất cứ thứ gì khác rơi xuống quy tắc kế tiếp — ghép cái này với một chính sách default-deny để một đích đến không được liệt kê bị từ chối thay vì được vẫy cho qua.
Test nó trước khi bạn tin nó. Tab Test của console và endpoint POST /api/workspace/firewall/test (Developer+) phát lại một sample call đối với chính sách nháp của bạn để bạn có thể xác nhận verdict trên một đích đến đã biết mà không gửi lưu lượng live.

​
4. Cách nó kết hợp với phần còn lại của firewall

Một quy tắc egress là một quy tắc trong số nhiều quy tắc trong một chính sách firewall workspace. Engine duyệt các quy tắc theo thứ tự ưu tiên (thấp nhất trước) và khớp đầu tiên thắng, nên đặt một egress deny chặt phía trên bất kỳ allow rộng nào.
Verdict trên một quy tắc egressHiệu ứng
denyBlock cuộc gọi tới các đích đến trong-phạm-vi — được ghi trên bề mặt egress và trả về tool như một lỗi.
auditGhi log cuộc gọi đã khớp như một sự kiện firewall; vẫn dispatch.
allowCho phép các đích đến trong-phạm-vi; ghép với một nền default-deny.
pending_approval và cap_cost không được thực thi trên bề mặt egress — egress là một kiểm tra đích đến, không phải một lần giữ hay một spend cap. Dùng các verdict đó trên các bề mặt mcp hoặc inbound thay vào đó. Xem tham chiếu verdict.
Hai biện pháp kiểm soát liên quan đáng nối song song với một quy tắc egress:
Độc lập với bất kỳ quy tắc nào bạn soạn, MCP gateway xác thực mọi server endpoint và IP dial đã phân giải của nó đối với một chính sách SSRF — các dải intranet và địa chỉ cloud-metadata bị từ chối, và IP được kiểm tra lại trên mọi hop để đánh bại DNS rebinding. Quy tắc egress của bạn xếp một chính sách đích đến đặc thù workspace ở trên baseline đó.
Một egress deny đơn dừng một tool tiếp cận một host. Một quy tắc sequence dừng chuỗi — ví dụ “đọc một file, rồi egress trong cửa sổ” — bằng cách gắn cờ chân egress chỉ khi nó theo sau một lần đọc nhạy cảm. Đó là cái phá bộ ba chí mạng; thu hẹp phạm vi egress là biện pháp kiểm soát theo từng cuộc gọi.

​
5. Shadow nó trước, rồi enforce

Cuộn một egress deny thẳng tới thực thi trên một workspace bận rộn có nguy cơ làm hỏng một tích hợp hợp lệ bạn quên. Hai lưới an toàn:
  • Shadow mode. Một chính sách trong shadow mode hạ cấp mọi verdict enforcing xuống audit — egress deny của bạn ghi log [shadow] would deny … thay vì block, nên bạn thấy bán kính nổ trước khi nó cắn.
  • Observe mode. Cài đặt workspace firewall_observe_mode ghi log các cuộc gọi chưa được bao trùm như Discovered Tools, hiện ra các đích đến thật mà các agent của bạn đã tiếp cận để bạn có thể viết một allow-list chính xác từ dữ liệu thay vì phỏng đoán.
Việc khớp đích đến egress dựa trên host mà cuộc gọi phân giải tới vào thời điểm đánh giá. Một server thù địch vẫn có thể rebind DNS giữa lần kiểm tra chính sách và lần dial thực tế (TOCTOU) — đó chính là lý do bảo vệ IP lớp socket của gateway là biện pháp kiểm soát có thẩm quyền và quy tắc này là phòng vệ theo chiều sâu, không phải tuyến duy nhất.

​
6. Vai trò và route

Tất cả các route console đều theo phạm vi workspace và xác thực bằng session / access token của bạn. Các lần đọc mở cho bất kỳ Member nào; việc soạn hoặc chỉnh sửa một quy tắc yêu cầu Developer+.
Method & pathVai tròMục đích
GET /api/workspace/firewall/policies/:idMemberĐọc một chính sách và các quy tắc của nó.
POST /api/workspace/firewall/rulesDeveloper+Thêm một quy tắc (đặt stage: egress).
PUT /api/workspace/firewall/rulesDeveloper+Cập nhật một quy tắc (id trong body).
DELETE /api/workspace/firewall/rules/:idDeveloper+Gỡ một quy tắc.
POST /api/workspace/firewall/testDeveloper+Phát lại một sample call đối với một chính sách nháp.

​
Liên quan

Tham chiếu quy tắc Firewall

Toàn bộ rule DSL — tool globs, khớp args, các danh sách egress, sequences.

Kết nối một MCP server

Đăng ký một server để các lời gọi tool của nó chạy phía sau firewall.

Allow-list các tool MCP

Default-deny các tool bạn không chấp thuận tường minh.

Exfiltration dữ liệu

Mối đe dọa mà egress control được xây dựng để dừng.