Chuyển đến nội dung chính
Một chính sách firewall quyết định một điều về mọi cuộc gọi tool mà agent của bạn thực hiện: một verdict. Hoặc một quy tắc khớp và tạo ra một verdict, hoặc không quy tắc nào khớp và verdict mặc định của chính sách sẽ tiếp quản. Trang này đề cập cả hai — mỗi verdict firewall làm gì, cap_cost phân giải ra sao, và tại sao audit là mặc định bạn bắt đầu từ đó. Để biết verdict nằm ở đâu trong ngữ pháp quy tắc, xem Quy tắc Firewall; để chọn một verdict mặc định khi tạo một chính sách, xem Tạo & gắn.

​
1. Sáu verdict của quy tắc

Một quy tắc tạo ra đúng một trong sáu verdict. Soạn chúng trong trình chỉnh sửa quy tắc của console; engine duyệt các quy tắc theo thứ tự ưu tiên và match đầu tiên thắng.
Cuộc gọi tiếp tục mà không bị động đến. Nó vẫn xuất hiện trong events feed dưới dạng một allow, nên bạn vẫn giữ một audit trail mà không block gì cả. Dùng nó như một cấp phép tường minh trong một chính sách default-deny.
Kết quả traffic giống hệt allow, nhưng cuộc gọi được gắn cờ như một thứ bạn muốn theo dõi. Đây cũng là giá trị mà verdict mặc định rơi vào ngay từ đầu — quan sát mọi thứ, không block gì, cho đến khi bạn sẵn sàng thực thi.
Cuộc gọi không bao giờ đến được tool. Trên bề mặt inbound, relay trả về HTTP 400 với mã lỗi firewall_blocked, nêu tên tool và lý do; trên bề mặt mcp nó quay lại như một lỗi tool để mô hình có thể phản ứng. Xem một block trông như thế nào.
Che các chuỗi con khớp khỏi đối số của cuộc gọi tool (một secret hoặc PII mà agent đặt vào một trường command hay body) và chuyển tiếp cuộc gọi đã làm sạch. Nó chỉ che đối số — không bao giờ che nội dung mà một tool trả về. Trên bề mặt inbound chưa có đối số tại thời điểm gọi, nên sanitize leo thang thành một deny. Xem sanitize phản hồi.
Biến cuộc gọi thành một lượt xem xét ngoài luồng. Relay trả về HTTP 400 với mã firewall_approval_pending và một approval id; cuộc gọi không đến được tool. Một người duyệt phân giải nó trong console hoặc qua webhook callback, và agent gửi lại với một approval header dùng-một-lần. Xem phê duyệt.
Một cầu dao mạch chi phí — được soạn như một quy tắc nhưng phân giải về allow hoặc deny tại thời điểm đánh giá. Xem §3 và cap cost.
Shadow mode làm phẳng việc thực thi. Trong shadow mode, mọi verdict thực thi (deny, sanitize, pending_approval, và một cap_cost đã phân giải về deny) đều bị hạ cấp thành audit và lý do được thêm tiền tố [shadow] would …. Triển khai một chính sách thực thi theo cách này và quan sát events feed trước khi bạn bật nó lên live.

​
2. Verdict mặc định

Verdict mặc định (default_verdict trên chính sách) là điều chính sách làm khi không quy tắc nào khớp một cuộc gọi tool. Nó là sàn của tư thế của bạn, và khác với một verdict quy tắc, nó chỉ chấp nhận ba giá trị:
default_verdictKhi không quy tắc nào khớp…
audit (mặc định)Cho cuộc gọi qua, nhưng ghi lại. Nơi an toàn để bắt đầu.
allowCho qua và ghi log, không có bản ghi xem xét.
denyBlock bất cứ thứ gì mà một quy tắc không cho phép tường minh — một tư thế default-deny.
Một chính sách mới mặc định là audit: nó quan sát mọi cuộc gọi tool và không block gì cho đến khi bạn thêm các quy tắc thực thi. Ba verdict chỉ-dành-cho-quy-tắc — sanitize, pending_approval, và cap_cost — không thể làm một mặc định; một verdict mặc định là một fallback bao trùm, và những verdict đó chỉ có nghĩa khi được thu hẹp vào một match cụ thể.
deny làm một verdict mặc định chính là default-deny: bất kỳ cuộc gọi tool nào mà các quy tắc của bạn không tường minh allow đều bị block. Mạnh mẽ cho một agent bị khóa chặt, nhưng nó sẽ chặn các cuộc gọi bạn quên đưa vào allow-list. Hãy ghép nó với các quy tắc allow tường minh (tool allow-listing) và triển khai nó dưới shadow mode trước.

​
3. cap_cost phân giải về allow hoặc deny

cap_cost là verdict duy nhất không phải là thứ hiện ra trong events của bạn. Bạn soạn một quy tắc với một trần cap_cost_cents, nhưng tại thời điểm đánh giá engine phân giải nó thành một allow hoặc deny cụ thể trước khi event được ghi lại — nên events feed không bao giờ mang một verdict cap_cost theo nghĩa đen, chỉ có allow/deny mà agent thực sự thấy. Trần là mỗi lần chạy agent: engine so sánh chi tiêu tích lũy của lần chạy với cap của bạn.
  • Dưới cap → phân giải về allow. (Bên trong điều này được xử lý như không khớp, nên việc đánh giá tiếp tục đến quy tắc kế tiếp thay vì để cap_cost thắng match-đầu-tiên như một cấp phép.)
  • Trên cap → phân giải về deny, với một lý do nêu tổng của lần chạy so với cap. Đây là kết cục cuối cùng, cầu dao mạch.
// A rule that caps a run at $5.00 of accumulated spend.
{
  "label": "run cost ceiling",
  "tool_name_glob": "*",
  "verdict": "cap_cost",
  "cap_cost_cents": 500
}
cap_cost chỉ kích hoạt trên các bề mặt tiền-dispatch (inbound, mcp) — những điểm mà việc block một cuộc gọi vẫn ngăn được chi tiêu. Trên các bề mặt hậu-dispatch response và egress nó trơ (chẳng còn gì để dừng), nên engine bỏ qua nó ở đó.

​
4. Cách một verdict được chọn

Với bất kỳ cuộc gọi tool nào, việc phân giải đều như nhau bất kể verdict nào thắng:
Gateway chọn chính sách được gắn vào key đang gọi (firewall_policy_id), hoặc mặc định của workspace — xem phân giải.
Các quy tắc chạy theo thứ tự priority ASC. Quy tắc đầu tiên mà bề mặt, tool glob, các mệnh đề argument tùy chọn, và phạm vi egress tùy chọn tất cả đều khớp sẽ tạo ra verdict.
Nếu không quy tắc nào khớp, default_verdict của chính sách áp dụng — audit trừ khi bạn đã đổi nó.
Nếu cuộc gọi thuộc về một skill được quản trị, một skill chế độ block ép một deny và một skill chế độ quarantine leo thang bất cứ thứ gì chưa tới mức deny thành pending_approval.

​
5. Hành vi chi phí và retry của một deny

Một verdict firewall trên bề mặt inbound kích hoạt trước cuộc gọi mô hình thượng nguồn, nên một deny ở đó không tốn token mô hình nào. Lỗi được đánh dấu skip-retry — chạy lại cùng một cuộc gọi đã bị block thì cũng chỉ bị block lại, nên gateway báo cho client đừng retry nó. Điều này khác với một block guardrail, vốn sàng lọc văn bản prompt/phản hồi (PII, secret) thay vì hành động tool, và trả về lỗi guardrail_blocked riêng của nó. Một request có thể đi qua cả hai mặt phẳng.
Mỗi verdict để lại một dấu vết. Mọi đánh giá — allow, audit, deny, cap_cost đã phân giải, phê duyệt được giữ — đều được ghi lại như một event firewall, có thể lọc theo verdict, bề mặt, tool, và lần chạy. Events feed là cách bạn xác nhận một chính sách đang tạo ra các verdict bạn mong đợi. Xem events log và analytics.

​
Đi đâu tiếp theo

Tạo & gắn một chính sách

Chọn một verdict mặc định và liên kết một chính sách với một key.

Cap cost

Soạn một trần chi tiêu và cách nó phân giải mỗi lần chạy.

Shadow mode

Hạ cấp mọi verdict thực thi thành audit trong khi bạn đo tác động.

Tham chiếu quy tắc

Toàn bộ ngôn ngữ so khớp đằng sau một verdict.
Để biết các mối đe dọa mà những verdict này nhằm ngăn chặn, xem cuộc gọi tool nguy hiểm và quyền tự quyết quá mức.