Chuyển đến nội dung chính
Một agent tự chủ chạy dài là thứ khó bảo mật nhất. Nó tự lặp trong nhiều giờ, tự chọn tool, tự fetch URL, và tiêu tiền của bạn suốt thời gian đó. Các chế độ thất bại không phải là một prompt xấu đơn lẻ — chúng là một vòng lặp retry đốt $400 qua đêm, một cuộc gọi tool bạn chưa từng xem xét, một key bạn đã phát hành cho một thí nghiệm một tuần mà vẫn hoạt động sáu tháng sau. Công thức này kết nối bốn kiểm soát quanh chính xác hình dạng agent đó. Bạn cấu hình tất cả trong console (hoặc REST API) — agent vẫn gọi https://api.orcarouter.ai/v1/... y như trước.
Mới ở đây? Áp dụng baseline balanced trước và quan sát những gì agent của bạn làm trong một ngày. Trang này là bước kế tiếp: biến quan sát thành thực thi cho một agent bạn không thể trông nom.

​
1. Công thức autonomous agent an toàn

Một autonomous agent an toàn cần bốn thứ mà một chatbot không cần:

Một mức trần chi phí cứng

Một quy tắc cap_cost deny lần chạy một khi mức chi tiêu tích lũy của nó vượt qua mức trần của bạn — cầu dao ngắt mạch cho một vòng lặp không chịu dừng.

Phát hiện spike

Phát hiện bất thường học hình dạng giờ-trong-tuần bình thường của agent và gắn cờ các spike tốc độ và chi phí lọt qua các quy tắc tĩnh.

Phê duyệt trên các cuộc gọi nguy hiểm

Một verdict pending_approval giữ các cuộc gọi tool phá hủy hoặc không thể đảo ngược lại cho một con người, thay vì tin tưởng agent cẩn thận.

Một key hết hạn

Thu hẹp phạm vi key của agent thành một thời điểm hết hạn và một mức trần tín dụng để một thí nghiệm bị quên không thể chạy — hoặc tiêu — mãi mãi.
Mỗi cái ánh xạ tới một trường Firewall policy hoặc key. Không cái nào chạm code agent của bạn.

​
2. Giới hạn chi phí của mọi lần chạy

Điều đầu tiên mà một vòng lặp mất kiểm soát thổi bay là ngân sách của bạn. Một quy tắc cap_cost là một mức trần chi phí kiểm-tra-trước nghiêm ngặt: khi nó khớp, gateway ước lượng chi phí của request và deny trước dispatch một khi mức chi tiêu tích lũy của lần chạy sẽ vượt quá mức trần — nên một cuộc gọi vượt ngân sách không bao giờ đến được provider. Mức trần là theo phạm vi lần chạy. Gateway cộng dồn mức chi tiêu trước đó trên toàn bộ lần chạy agent, nên một lần chạy dài đã đốt phần lớn ngân sách của nó bị deny ngay cả khi cuộc gọi đơn lẻ kế tiếp rẻ. Đó là điều khiến nó là một cầu dao ngắt mạch chứ không phải một giới hạn theo từng request. Thêm một quy tắc wildcard vào chính sách firewall của bạn: 
{
  "priority": 50,
  "tool_name_glob": "*",
  "verdict": "cap_cost",
  "cap_cost_cents": 1000
}
Cái này giới hạn lần chạy ở $10 (cap_cost_cents tính bằng USD cents). Verdict phân giải thành allow khi còn trong ngân sách và deny một khi ước lượng sẽ vượt qua nó. Hầu hết các template firewall built-in (Coding, Support, RAG, Data, DevOps, Browser) đều cung cấp một cost cap theo từng lần chạy chính xác như thế này — áp dụng một cái và chỉnh mức trần.
Tích lũy theo phạm vi lần chạy cần bật chụp request-log cho workspace. Với nó tắt, phần cộng dồn chi tiêu trước đó đọc về zero và mức trần suy giảm chỉ còn theo từng request — vẫn an toàn, nhưng nó sẽ không bắt được một dòng nhỏ giọt 500 cuộc gọi chậm. Xem denial-of-wallet.

​
3. Phát hiện spike đối với một baseline đã học

Một mức trần dừng thảm họa; phát hiện bất thường bắt cái kỳ lạ trước khi nó trở thành một thảm họa. Firewall học hình dạng dùng tool bình thường của mỗi workspace — một trung bình trượt 14 ngày được chia theo giờ-trong-tuần, nên traffic Thứ-Ba-14:00 được so với lịch sử Thứ-Ba-14:00, không phải một trung bình ngày phẳng — và làm nổi các sai lệch trên một feed mà viewer có thể đọc:
Khối lượng cuộc gọi theo từng tool được chấm điểm đối với baseline đã học. “143 cuộc gọi db.query trong một giờ đối với một baseline 8” nổi bật ngay cả khi mỗi cuộc gọi đơn lẻ đều được cho phép.
Cùng baseline, áp dụng cho mức chi tiêu thay vì số đếm — một lần chạy đột nhiên đốt nhiều hơn nhiều so với mức giờ này thường làm.
Dấu hiệu của một agent tự chủ mắc kẹt retry cùng một cuộc gọi hỏng. Xem excessive-agency.
Một bước tool-sang-tool mà workspace này chưa bao giờ thực hiện — hình dạng của một agent đi tới đâu đó mới.
Feed báo cáo tên tool, các token id đã được redact, và số đếm — không bao giờ argument thô. Đọc nó mở cho mọi Member; một Developer+ có thể snooze feed lên đến 7 ngày trong khi điều tra. Ghép feed với một quy tắc cap_cost để một spike cũng vượt ngân sách bị dừng, không chỉ được chú ý.

​
4. Giữ các cuộc gọi nguy hiểm lại cho một con người

Bạn không thể xem xét mọi cuộc gọi mà một agent tự chủ thực hiện — nhưng bạn có thể khiến nó dừng lại và hỏi trước khi nắm tay nhỏ những cái quan trọng. Một verdict pending_approval giữ một cuộc gọi tool lại ngoài luồng:
  1. Agent phát ra, ví dụ, một cuộc gọi payments.transfer. Quy tắc khớp và engine trả về HTTP 400 firewall_approval_pending với một approval id — cuộc gọi không bao giờ đến được tool.
  2. Một reviewer giải quyết nó từ console (Developer+), hoặc hệ thống của riêng bạn giải quyết nó qua một webhook callback ký HMAC tới POST /api/v1/firewall/approvals/:id/callback.
  3. Agent poll GET /api/v1/firewall/approvals/:id; một khi được phê duyệt nó gửi lại cuộc gọi gốc với một header dùng một lần X-OrcaRouter-Firewall-Approval, và gateway cho nó đi qua đúng lần đó.
Một quy tắc giữ lại các thao tác ghi tới một bề mặt phá hủy: 
{
  "priority": 20,
  "tool_name_glob": "payments.*",
  "verdict": "pending_approval"
}
Triển khai cái này trong shadow mode trước — pending_approval hạ cấp thành audit, nên bạn thấy những cuộc gọi nào sẽ bị giữ lại mà không thực sự block agent của bạn. Tắt shadow khi feed trông đúng.

​
5. Cho agent một key hết hạn

Kiểm soát sống lâu hơn mọi chính sách là chính key đó. Một agent tự chủ nên nhận một key có phạm vi giới hạn, không phải key mặc định của bạn. Đặt các trường này khi bạn phát hành nó (console → keys, hoặc token API):
TrườngĐặt thànhTại sao
expired_timemột Unix timestampThí nghiệm kết thúc; key chết theo nó. -1 nghĩa là không bao giờ — đừng dùng ở đây.
credit_limit_usdmột mức trần đô-laMột mức trần chi tiêu trên key độc lập với mức trần lần chạy. 0 nghĩa là không giới hạn.
firewall_policy_idchính sách của bạn ở trênLiên kết các quy tắc cap_cost + phê duyệt với key này.
allow_ipscác IP egress của agentMột key bị rò rỉ là vô dụng từ bất cứ nơi nào khác.
Đặt một tag environment nữa, để key — và mọi thứ nó làm trong Events và Matches — có thể quy gán cho agent này. Một key hết hạn, giới-hạn-tín-dụng, ghim-IP là tuyến phòng thủ cuối: ngay cả khi mọi chính sách bằng cách nào đó bị vượt qua, bán kính sát thương bị giới hạn bởi thời gian và đô-la.
Cấu hình key là một hành động console / token-API và được gated theo vai trò. Đọc plaintext của một firewall-gateway key yêu cầu Admin+.

​
6. Ghép lại với nhau

Một agent tự chủ được gia cố kết thúc với một chính sách firewall và một key có phạm vi giới hạn:
LớpKiểm soátBắt được
Ngân sáchQuy tắc cap_cost, theo phạm vi lần chạyVòng lặp mất kiểm soát, denial-of-wallet
Hành viFeed bất thường (rate / burn / retry / novel)Cái kỳ lạ-nhưng-được-phép
Tin cậypending_approval trên các tool phá hủyCác hành động không thể đảo ngược
Phạm viKey hết hạn, giới-hạn-tín-dụng, ghim-IPCác key bị quên hoặc rò rỉ
Soạn các quy tắc ngân sách và phê duyệt cùng nhau, đặt một mức trần theo từng lần chạy với firewall rules, và đọc phần còn lại của tham chiếu Firewall cho bề mặt, verdict, và khả năng quan sát. Cho các mối đe dọa liên quan mà công thức này phòng thủ chống lại, xem excessive-agency, dangerous-tool-calls, và denial-of-wallet.

​
7. Bước tiếp theo

Gia cố một MCP agent

Quản lý một agent vươn tới các tool qua MCP server.

Dừng exfiltration

Quy tắc egress cho một agent fetch URL của riêng nó.

Chế độ thực thi

Observe → shadow → enforce, triển khai an toàn.

Firewall rules

Ngôn ngữ so khớp đằng sau mọi quy tắc ở trên.