Chuyển đến nội dung chính
Khi một mô hình trả lời, nó không chỉ trả về văn bản — nó phát ra tool_calls: các lời gọi cụ thể với đối số thật do mô hình chọn. Bề mặt response của agent firewall kiểm tra đúng những cái đó, ngay khi chúng rời mô hình và trước khi chúng đến được vòng lặp agent của bạn. Đây là bề mặt nơi bạn lọc cái mà mô hình thực sự quyết định làm, với các đối số nó thực sự chọn. Trang này đề cập tình huống dùng để lọc trên bề mặt response — khi nào dùng nó thay vì inbound, một biến tấu verdict duy nhất nó thêm vào, và nó cư xử ra sao trên một stream. Để biết toàn bộ từ vựng quy tắc và ngữ nghĩa verdict, xem Schema quy tắc và Verdict.

​
1. Lọc cuộc gọi tool response của llm, với đối số trong phạm vi

Stage inbound thấy các tool bạn quảng bá — chỉ tên, chưa có đối số tại thời điểm gọi. Stage response thấy các tool_calls mà mô hình phát ra, vốn mang các đối số mô hình đã chọn. Đó là toàn bộ lý do để lọc ở đây: nó là bề mặt duy nhất thấy cuộc gọi + đối số thực tế cho một tool do-client-thực-thi (không-MCP), nên các mệnh đề argument, chuỗi, và quy tắc trạng-thái-lần-chạy đều đáp xuống response. Sự phân biệt trong một dòng:
StageThấyDùng nó để
inboundCác định nghĩa tool được quảng báLàm một tool vô hình với mô hình
responsetool_calls được phát ra + đối sốLọc cuộc gọi mà mô hình thực sự làm
Vậy inbound trả lời những tool nào tồn tại; response trả lời mô hình đã làm gì với một cái. Dùng response (hoặc để stage trống để bao cả hai) khi một tool xuất hiện hợp lệ trong một số request nhưng một cuộc gọi cụ thể của nó nguy hiểm — hoặc khi bạn chỉ kiểm soát vòng lặp agent, không phải tập tool được quảng bá.
Một quy tắc không có stage chạy trên mọi bề mặt, kể cả response. Ghim vào response chỉ khi một quy tắc nên chỉ kiểm tra các cuộc gọi được phát ra — ví dụ một mệnh đề argument vốn không có gì để khớp trên bề mặt inbound dù sao đi nữa. Xem Stage.

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

Allow shell.exec nói chung, nhưng bóc nó khỏi câu trả lời của mô hình ngay khi đối số command của nó trông có vẻ phá hủy. Trong console workspace của bạn, mở một chính sách (hoặc tạo một cái) và thêm một quy tắc ghim vào bề mặt response: 
{
  "label": "block destructive shell calls",
  "stage": "response",
  "tool_name_glob": "shell.exec",
  "verdict": "deny",
  "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf|mkfs|dd if=\"}]}"
}
Bộ khớp đối số sống trong args_match_json — một chuỗi JSON giữ {"clauses":[…]}, mỗi mệnh đề là một bộ ba path / op / value (op là một trong eq, contains, regex, gt, lt). Form của console xây nó cho bạn; hình dạng thô được hiển thị ở đây để tên trường rõ ràng. Tool vẫn được quảng bá — mô hình vẫn có thể đề xuất shell.exec — nhưng khi cuộc gọi được phát ra mang một command phá hủy, firewall loại bỏ tool_call đó khỏi câu trả lời trước khi agent của bạn kịp thấy. Một shell.exec lành tính (chẳng hạn, ls -la) lướt qua không bị động đến. Đây là mẫu “allow tool, quản trị cuộc gọi” mà bề mặt response tồn tại vì nó; mệnh đề argument là cái làm nó khả thi.
Các quy tắc đánh giá theo thứ tự ưu tiên, match đầu tiên thắng. Đặt một ngoại lệ allow hẹp ở một số priority thấp hơn một deny rộng để ngoại lệ chạy trước. Xem Ưu tiên quy tắc.

​
3. Một verdict làm gì trên bề mặt response

Bề mặt response kiểm tra mỗi tool_call được phát ra và viết lại câu trả lời tại chỗ. Các cuộc gọi được giữ lại được chuyển tiếp byte-cho-byte; chỉ một cuộc gọi đã khớp thay đổi:
tool_call đã khớp bị loại bỏ khỏi phản hồi của mô hình trước khi nó đến được agent của bạn. Khác với một deny inbound — vốn trả về HTTP 400 với mã firewall_blocked — một deny bề-mặt-response không làm fail request; phần còn lại của câu trả lời (các cuộc gọi tool khác, văn bản bất kỳ) chảy qua với cuộc gọi vi phạm đơn giản vắng mặt.
Các chuỗi con đã khớp trong đối số của cuộc gọi được thay bằng các đối số đã che của engine và cuộc gọi đã làm sạch được chuyển tiếp — hữu ích khi tool ổn nhưng mô hình đặt một giá trị secret hay PII vào một đối số. Sanitize chỉ che đối số cuộc gọi tool; nó không bao giờ động đến nội dung mà một tool trả về. Nếu engine không có gì để thay, cuộc gọi bị bóc (fail-closed). Xem Sanitize phản hồi.
Giữ con-người-trong-vòng-lặp mở trên bề mặt inbound, không phải response. Một quy tắc pending_approval mà lần đầu khớp trên một cuộc gọi được phát ra do đó bị bóc (fail-closed) — giữ nó sẽ chuyển tiếp một cuộc gọi chưa-xem-xét mà không có quyết định của con người. Soạn các lần giữ HITL để kích hoạt inbound; xem Phê duyệt.
allow và audit đều chuyển tiếp cuộc gọi; audit là default_verdict thông thường — ghi lại mọi thứ, không block gì, cho đến khi bạn sẵn sàng thực thi.
cap_cost và pending_approval là khái niệm inbound trên bề mặt này. cap_cost trơ trên response (mô hình đã chạy), và pending_approval phân giải thành một bóc thay vì một lần giữ. Đặt các cap chi phí và các lần giữ HITL trên bề mặt inbound — xem Cap cost và Phê duyệt.

​
4. Streaming: giữ lại, rồi lọc

Trên một câu trả lời không-stream toàn bộ phản hồi được parse và lọc cùng lúc. Trên một stream, các tool_calls của mô hình đến dưới dạng các delta theo-index trên nhiều frame SSE — và một khi một delta được chuyển tiếp, agent của bạn đã có nó và nó không thể bị thu hồi. Nên gateway giữ các frame tool-call: chúng không bao giờ được chuyển tiếp giữa-stream. Ở cuối stream firewall lắp ráp mỗi cuộc gọi (tên + đối số đầy đủ), đánh giá nó, và chỉ phát ra các cuộc gọi sống sót.
Các frame content vẫn stream bình thường — các token văn bản đến client của bạn khi chúng đến. Chỉ các frame tool_call bị giữ lại để đánh giá, nên một cuộc gọi bị deny hoặc sanitize bị lọc ra trước khi cuộc gọi tool đã lắp ráp được giao. Ngữ nghĩa verdict và quy tắc giống hệt bề mặt không-stream. Để biết chi tiết cấp-frame, xem Nội bộ streaming và Streaming provider.

​
5. Triển khai nó an toàn

Tab Test của console chạy một chính sách trên một cuộc gọi tool mẫu và trả về verdict, quy tắc đã khớp, và lý do — không gì được dispatch, không gì được lưu. Xác nhận glob và mệnh đề argument của bạn khớp đúng cuộc gọi bạn định trước khi gắn một key. Xem Test quy tắc.
Bật shadow mode và mọi verdict thực thi — kể cả một deny bề-mặt-response — bị hạ cấp thành audit, lý do thêm tiền tố [shadow] would …. Bạn đo chính xác cái mà quy tắc sẽ bóc trên traffic thật trước khi nó thay đổi một câu trả lời nào.
Mỗi đánh giá ghi một event firewall với verdict, bề mặt, tool, và quy tắc đã khớp. Lọc events log theo bề mặt response để thấy quy tắc của bạn kích hoạt trên các cuộc gọi được phát ra bạn mong đợi. Xem Analytics.

​
6. Gắn chính sách và ai có thể cấu hình 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: 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 — và một chính sách được gắn nhưng bị tắt rơi về mặc định của workspace. Xem Quản lý chính sách. Toàn bộ cấu hình 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, SimulateMember
Chạy thử (Test), đọc events log và tổng hợp lần chạyDeveloper+
Tạo / chỉnh sửa / xóa quy tắc và chính sáchDeveloper+

​
Liên quan

Kiểm tra đối số

Các mệnh đề argument làm cho lọc bề-mặt-response chính xác.

Sanitize phản hồi

Che secret khỏi đối số của một cuộc gọi thay vì bóc nó.

Stage Firewall

Cách response so với inbound, mcp, và egress.

Block tool

Đối tác inbound: deny một tool trước khi mô hình được chào nó.

Cuộc gọi tool nguy hiểm

Mối đe dọa mà lọc response giải quyết.

Tham chiếu Firewall

Toàn bộ tham chiếu quy tắc + so khớp.