Chuyển đến nội dung chính
Khi một agent gọi http_fetch, web_search, hoặc bất kỳ tool nào mở một kết nối đi ra ngoài, đích đến là phần bạn cần quản trị nhất. Một agent bối rối hay bị chiếm quyền mà có thể với tới 169.254.169.254 sẽ đọc thông tin xác thực cloud của bạn; một cái có thể POST tới một host kẻ tấn công sẽ rò rỉ dữ liệu của bạn. Kiểm soát egress của agent quản trị đích đến đó — bạn soạn một quy tắc allow/deny host/CIDR trên bề mặt egress của firewall, gắn nó vào một key, và gateway kiểm tra mọi đích đến đi ra ngoài mà một tool của agent báo cáo trước khi cuộc gọi đi ra. Đây là một trang tình huống dùng tập trung. Để biết toàn bộ ngữ pháp quy tắc và ngữ nghĩa verdict, xem Schema quy tắc và Verdict; để biết egress nằm đâu giữa các điểm thực thi khác, xem Stage.

​
1. Kiểm soát egress của agent trên bề mặt egress

Trong bốn bề mặt của firewall, egress là cái thấy đích đến mạng đi ra ngoài mà một tool báo cáo — một host, một IP literal, hoặc một CIDR. Một quy tắc ghim vào stage: egress khớp trên đích đến đó, không phải trên tên tool hay đối số của nó, điều này làm nó thành kiểm soát SSRF và rò rỉ dữ liệu: nó trả lời agent này có thể với tới đâu, độc lập với tool nào đã với tới.
Egress là thu hẹp đích đến, không phải block tool. Để ngăn một tool tồn tại hoàn toàn, deny nó theo tên trên bề mặt inbound (Block tool). Kiểm soát egress giả định tool có thể fetch hợp lệ — nó chỉ ràng buộc tới đâu.

​
2. Một ví dụ: deny các đích đến SSRF

Quy tắc egress điển hình deny endpoint cloud metadata và các dải RFC-1918 riêng — các đích đến mà một tool hình-dạng-fetch không bao giờ nên với tới. Trong console workspace của bạn, mở một chính sách và thêm một quy tắc với stage egress, verdict deny, và một danh sách egress: 
{
  "label": "deny SSRF destinations",
  "stage": "egress",
  "verdict": "deny",
  "egress_json": "{\"deny\":[\"169.254.169.254\",\"10.0.0.0/8\",\"172.16.0.0/12\",\"192.168.0.0/16\"],\"allow\":[\"api.openai.com\"]}"
}
egress_json là một chuỗi mã hóa JSON mang các danh sách host/CIDR — khi giải mã, nó là {"deny": [...], "allow": [...]}. Mỗi mục khớp như một CIDR, một IP literal, hoặc một hostname không phân biệt hoa-thường. Với một verdict deny, danh sách deny là tập trong-phạm-vi (các đích đến mà quy tắc block) và danh sách allow khoét các ngoại lệ ra khỏi nó — nên quy tắc trên block bốn dải nhưng để api.openai.com đi qua ngay cả khi nó từng phân giải vào một dải. Khi một đích đến là một hostname thay vì một IP literal và danh sách của bạn mang các mục IP/CIDR, tên được phân giải theo nỗ lực tốt nhất và các địa chỉ của nó được kiểm tra lại, nên metadata.internal vẫn khớp một deny 169.254.0.0/16 dù nó không được liệt kê theo tên.
Để có một tư thế allow-list thay vào — chỉ cho phép một tập đích đến có tên và block phần còn lại — viết quy tắc với verdict allow và đặt các đích đến của bạn vào danh sách allow. Cực tính lật: allow trở thành tập trong-phạm-vi và deny khoét ra các ngoại lệ. Ghép nó với một default_verdict deny của chính sách để bất cứ thứ gì quy tắc allow không bao phủ đều bị block.

​
3. Bạn soạn các quy tắc CIDR — không preset nào ship chúng

Không có danh sách CIDR preset. OrcaRouter không ship một quy tắc tích hợp sẵn deny 169.254.169.254, RFC-1918, hay bất kỳ dải nào khác. Quy tắc allow/deny CIDR là của bạn để soạn — nó là ví dụ ở §2, do bạn viết trên mạng của riêng bạn. Copy nó, rồi điều chỉnh các dải và các ngoại lệ allow-list theo môi trường của bạn.
Cái mà autonomy level tight và preset block_ssrf_egress của nó thực sự ship là một tập các deny trên tên tool hình-dạng-fetch — http_fetch, web_search, fetch_url, request, cộng các biến thể MCP <server>.<tool> của chúng. Đó là một tư thế thô bạo: nó từ chối các tool hình-dạng-egress dứt khoát thay vì thu hẹp nơi chúng có thể với tới. Dùng nó khi một agent không có việc gì làm các cuộc gọi mạng cả; dùng một quy tắc đích đến (§2) khi nó thực sự fetch nhưng chỉ từ một tập host đã được phê duyệt.
Cách tiếp cậnRàng buộc gìSoạn bởi
Preset SSRF tightTên tool hình-dạng-fetch (deny chúng)Tích hợp sẵn
Quy tắc CIDR/host egressĐích đến mà một fetch có thể với tớiBạn

​
4. Một egress bị block trông như thế nào

Khi một đích đến khớp một quy tắc egress thực thi, cuộc gọi bị deny trước khi nó rời gateway và đánh giá được ghi lại như một event firewall với bề mặt egress và verdict deny. Trong shadow mode lệnh deny bị hạ cấp thành audit với lý do được thêm tiền tố [shadow] would …, nên bạn có thể đo chính xác đích đến nào một quy tắc sẽ block trên traffic thật trước khi bạn thực thi nó.
Một danh sách egress dị dạng hoặc không có mục được xử lý một cách thận trọng: một quy tắc deny thực thi vẫn quản trị (một lỗi gõ không thể âm thầm ngăn nó block), nhưng một quy tắc allow với một danh sách hỏng sẽ không kích hoạt — nếu không một allow-list gõ sai sẽ trở thành allow-all và che mất một default deny. Các quy tắc mới được kiểm tra khi lưu (danh sách phải khai báo ít nhất một mục allow hoặc deny), nên điều này chỉ bảo vệ các dòng legacy.

​
5. Soạn từ traffic thật, rồi triển khai

Events log ghi lại host đích đến trên mỗi event bề mặt egress (egress_host/egress_url), nên hãy lọc nó về bề mặt egress và soạn danh sách deny của bạn từ các đích đến thực sự đã xuất hiện thay vì đoán. Tab Discovered Tools là một tổng hợp theo-tên-tool (tên tool và các bề mặt chúng kích hoạt) — nó cho bạn biết tool hình-dạng-fetch nào đã chạy, không phải các host chúng với tới. Xem Analytics.
Tab Test của console chạy thử một chính sách trên một tool_name + bề mặt mẫu (+ args tùy chọn) và trả về verdict, quy tắc đã khớp, và lý do — không gì được dispatch. Nó xác nhận quy tắc nào một cuộc gọi phân giải về; để xác nhận phép tính CIDR/host của bạn trên đích đến thật, dùng shadow mode bên dưới (payload Test không mang một đích đến, nên việc khớp danh sách egress được thực thi trên traffic egress live). Xem Test quy tắc.
Bật shadow mode và lệnh deny egress được ghi log như nó sẽ kích hoạt mà không block. Quan sát events log lọc về bề mặt egress, xác nhận nó bắt các đích đến bạn mong đợi, rồi tắt shadow.
Thu hẹp đích đến tại gateway là phòng-thủ-theo-chiều-sâu, không phải tuyến cuối cùng. IP mà một hostname phân giải về tại thời điểm đánh giá có thể khác cái mà một tool thực sự quay số (DNS rebinding). Hãy giữ một kiểm soát IP-deny ở tầng egress/dialer của riêng bạn nữa; quy tắc gateway là cái bắt tiền-chuyến-bay rẻ tiền cho các trường hợp hiển nhiên.

​
6. Gắn chính sách và ai có thể chỉnh sửa nó

Một chính sách không làm gì cho đến khi một key phân giải về nó. Gắn trong console bằng cách đặt firewall_policy_id trên key, hoặc đặt chính sách làm mặc định của workspace. Phân giải là: chính sách được gắn của key (khi nó tồn tại và được bật), nếu không thì mặc định của workspace. Toàn bộ cấu hình quy tắc egress chạy trong console dưới session của bạn (/api/workspace/firewall/*):
Hành độngVai trò
Đọc chính sách, preset, discovered tools, Simulate autonomyMember
Tạo / chỉnh sửa / xóa quy tắc egress và chính sáchDeveloper+
Endpoint Test chạy thử (POST /test)Developer+
Đọc events log và tổng hợp lần chạyDeveloper+

​
Liên quan

Rò rỉ dữ liệu

Mối đe dọa mà kiểm soát egress giải quyết.

Stage

Bốn bề mặt, và nơi egress nằm.

Verdict

Deny, audit, và allow làm gì trên đường truyền.

Block tool

Deny một tool fetch theo tên thay vì theo đích đến.

Cuộc gọi tool nguy hiểm

Lớp rủi ro rộng hơn.

Tham chiếu Firewall

Toàn bộ tham chiếu quy tắc + so khớp, bao gồm danh sách egress.