Chuyển đến nội dung chính
Một reasoning agent kẹt trong một vòng lặp retry, fan-out một nghìn sub-task, hoặc đơn giản chạy hoang giữa kế hoạch có thể tiêu tiền thật trước khi ai đó để ý. Verdict firewall cap_cost là cầu dao mạch cho việc đó: bạn soạn một trần cents theo từng lần chạy một lần, và gateway deny cuộc gọi tool kế tiếp ngay khi chi tiêu tích lũy của một lần chạy vượt nó — trước khi cuộc gọi đó đến được mô hình hoặc tool. Đây là kiểm soát chi phí AI agent được thực thi tại gateway, không phải gắn vào vòng lặp agent của bạn. Như mọi verdict firewall, một quy tắc cap_cost sống trong một chính sách workspace, gắn vào một key, và có hiệu lực trên cuộc gọi kế tiếp mà không cần redeploy.

1. Cầu dao mạch chi tiêu theo từng lần chạy

cap_cost là một verdict quy tắc bạn soạn với một trường thêm — cap_cost_cents, trần chi tiêu của lần chạy tính bằng cents USD. Khi quy tắc khớp một cuộc gọi tool, engine so sánh chi tiêu tích lũy của lần chạy agent với cap đó:
  • Dưới cap → cuộc gọi được phép; việc đánh giá tiếp tục.
  • Trên cap → cuộc gọi bị deny, với một lý do nêu tổng của lần chạy so với cap. Đó là kết cục cuối cùng, cầu dao mạch — lần chạy không thể phát ra một cuộc gọi được quản trị nữa cho đến một lần chạy mới.
Cap được khóa vào lần chạy agent, không phải một request đơn. Một lần chạy dài đã đốt phần lớn ngân sách của nó bị deny ở cuộc gọi kế tiếp ngay cả khi chính cuộc gọi đó rẻ — cầu dao trip trên tổng đang chạy, không phải chi phí biên.
Phạm vi lần chạy, với một fallback theo từng request. Khi request mang một agent-run id, trần áp dụng cho chi tiêu tích lũy của lần chạy. Một cuộc gọi không có liên kết lần chạy (vd: một dispatch MCP trần không có session được chuyển tiếp) rơi về một so sánh theo từng request thay vào. Dù cách nào, cầu dao trip trước khi cuộc gọi vượt-ngân-sách được dispatch.

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

Giới hạn bất kỳ lần chạy nào trên một key ở $5.00 chi tiêu tích lũy. Một quy tắc wildcard đơn làm việc đó — cap_cost_cents500 (cents):
{
  "label": "run cost ceiling $5",
  "tool_name_glob": "*",
  "verdict": "cap_cost",
  "cap_cost_cents": 500
}
Soạn nó trong trình chỉnh sửa quy tắc của console trên một chính sách bạn đã tạo (xem Tạo & gắn một chính sách). Viết một quy tắc là một hành động Developer+. Gắn chính sách vào một key qua firewall_policy_id, hoặc đặt làm mặc định của workspace, và mọi lần chạy mà key đó điều khiển giờ đều bị giới hạn. Bạn có thể thu hẹp cap chặt hơn “mọi tool”. Thu hẹp glob tên-tool để chỉ một họ cuộc gọi đắt tiền được tính vào cầu dao — vd: cap_cost trên *.search để giới hạn fan-out web-search trong khi để các tool nội bộ rẻ không bị đo.
Xếp chồng một tầng cảnh báo rẻ hơn bằng các ưu tiên. Một quy tắc audit cap-thấp ở một ưu tiên cao hơn (số thấp hơn) cho bạn quan sát một lần chạy tiến gần ngân sách của nó trong events feed trước khi quy tắc cap_cost thực thi trip. Match đầu tiên thắng, nên sắp watcher trước.

3. Nó kích hoạt ở đâu — và ở đâu nó không thể

cap_cost chỉ có nghĩa trước khi một cuộc gọi được dispatch — đó là điểm duy nhất mà việc dừng cuộc gọi vẫn ngăn được chi tiêu. Nên nó live trên hai bề mặt tiền-dispatch và bị từ chối trên các bề mặt hậu-dispatch:
Bề mặtcap_cost?
inbound (tool được quảng bá)Thực thi.
mcp (dispatch tools/call)Thực thi.
response (cuộc gọi do mô hình phát ra)Từ chối khi lưu — chẳng còn gì để dừng.
egress (đích đến đi ra ngoài)Từ chối khi lưu — chẳng còn gì để dừng.
Một quy tắc cap_cost ghim vào response hoặc egress bị từ chối tại thời-điểm-lưu, nên một quy tắc không bao giờ có thể hiển thị là live mà lại không bao giờ deny được. Để stage trống để bao cả hai bề mặt tiền-dispatch, hoặc ghim nó vào inbound / mcp.
cap_cost_centsbắt buộc và không âm cho một quy tắc cap_cost. Console và API từ chối một quy tắc cap_cost không có cap, nên một trần cấu hình sai không thể âm thầm cho mọi cuộc gọi đi qua.

4. Cầu dao trông như thế nào khi nó trip

Một cuộc gọi vượt-ngân-sách là một deny firewall bình thường:
  • Trên inbound, relay trả về HTTP 400 với mã lỗi firewall_blocked. Block kích hoạt trước cuộc gọi mô hình thượng nguồn, nên nó tốn không token mô hình, và được đánh dấu skip-retry — chạy lại cùng cuộc gọi thì cũng chỉ trip cầu dao lại.
  • Trên mcp, nó quay lại như một lỗi tool nên mô hình thấy sự từ chối và có thể dừng hoặc hỏi người dùng, thay vì crash.
Lý do deny nêu các con số, vd: cap_cost: estimated run cost $5.40 exceeds cap $5.00, nên một operator đọc events feed thấy chính xác tại sao cầu dao trip.
Events không bao giờ mang một cap_cost theo nghĩa đen. Bạn soạn verdict là cap_cost, nhưng engine phân giải nó thành một allow hoặc deny cụ thể trước khi event được ghi lại. Feed hiển thị allow/deny mà agent thực sự thấy — trần chi-phí-lần-chạy là lý do, không phải nhãn verdict. Cái này phản chiếu cách verdict phân giải.

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

Vì một cầu dao trip dừng-cứng một lần chạy, hãy kiểm tra nó trước khi thực thi. Bật shadow mode trên chính sách: quy tắc cap_cost vẫn đánh giá và một deny giả định bị hạ cấp thành audit, thêm tiền tố [shadow] would …. Quan sát events feed để xác nhận cap trip ở nơi bạn mong đợi — và chỉ nơi bạn mong đợi — rồi tắt shadow mode để bắt đầu thực thi. Bạn cũng có thể chạy thử một chính sách trên một cuộc gọi mẫu trong tab Test (một sandbox Developer+) để thấy verdict đã phân giải và quy tắc đã khớp trước khi bất cứ thứ gì phụ thuộc vào nó.

6. Nó khớp vào phần còn lại của firewall ra sao

cap_cost là một verdict trong sáu. Nó ghép tự nhiên với các kiểm soát khác trên cùng chính sách:

Verdict

Toàn bộ tập — allow, audit, deny, sanitize, pending_approval, và cách cap_cost phân giải.

Block tool nguy hiểm

Deny shell phá hủy, delete, và các cuộc gọi rủi ro cao khác dứt khoát.

Tham chiếu quy tắc

Toàn bộ ngôn ngữ so khớp — glob, mệnh đề argument, chuỗi.

Phát hiện bất thường

Đột biến chi phí được gắn cờ trên một baseline giờ-trong-tuần đã học.
Một trần chi-phí-lần-chạy là một chặn cứng tĩnh, xác định; firewall cũng học hình dạng chi phí bình thường của mỗi workspace và gắn cờ các đột biến trên một baseline giờ-trong-tuần 14 ngày trên một feed bất thường Member-đọc-được. Dùng cap_cost cho điểm dừng cứng, bất thường cho tín hiệu sớm.
Giới hạn quota trên chính key (credit_limit_usd) giới hạn chi tiêu tổng trên mọi lần chạy; cap_cost giới hạn một lần chạy đơn. Chúng kết hợp — một vòng lặp chạy hoang trip cầu dao theo-lần-chạy từ rất lâu trước khi nó có thể cạn credit trọn đời của key. Xem phạm vi: key, chính sách, workspace.

Đi đâu tiếp theo

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

Tạo một chính sách, chọn một verdict mặc định, liên kết nó với một key.

Shadow mode

Đo một cap trước khi nó thay đổi traffic.
Để biết các mối đe dọa agent-chạy-hoang mà một trần chi tiêu chặn, xem quyền tự quyết quá mứccuộc gọi tool nguy hiểm.