Chuyển đến nội dung chính
Tư thế an toàn nhất cho một agent tự trị là default-deny: block mọi tool theo mặc định, rồi chỉ allow một cách tường minh số ít mà agent của bạn dùng. Bất cứ thứ gì mới mà một agent nhặt được — một community skill, một MCP server cấu hình sai, một tool mà một jailbreak dụ mô hình dùng — đều bị deny vì bạn chưa bao giờ đưa nó vào, chứ không phải vì bạn nhớ block nó. Trang này là mẫu allow-list tool cho agent trên api.orcarouter.ai: một verdict mặc định deny cộng một hoặc nhiều quy tắc allow khóa trên một tool_name_glob. Để biết toàn bộ ngôn ngữ so khớp đằng sau những quy tắc đó, xem Quy tắc Firewall.
Allow-list được soạn trong console dưới Security → Firewall, hoặc qua các route quản lý /api/workspace/firewall/* (session / access token của bạn — không phải một relay key sk-orca-…). Chỉ các cuộc gọi /v1/* của agent bạn dùng relay key. Tạo hoặc chỉnh sửa một chính sách là một hành động Developer+.

​
1. Tại sao default-deny cho agent

Một block-list (“deny shell.exec, deny db.delete, …”) chỉ đầy đủ đến mức mối đe dọa cuối cùng bạn nghĩ ra. Một allow-list đảo ngược gánh nặng chứng minh: gateway deny mọi thứ mà chính sách không tường minh cho phép, nên một tool chưa biết bị đóng theo cấu trúc.

Verdict mặc định = deny

Sàn của chính sách. Không quy tắc nào khớp thì mọi cuộc gọi tool đều bị block.

Quy tắc allow đưa tool quay lại

Mỗi quy tắc allow nêu tên các tool bạn thực sự dùng — theo tên chính xác hoặc theo glob.
Engine duyệt các quy tắc của một chính sách theo thứ tự ưu tiên và match đầu tiên thắng; nếu không gì khớp thì rơi về default_verdict của chính sách. Vậy một allow-list chỉ là: các quy tắc allow ưu tiên cao cho các tool thực của bạn, với một sàn deny bắt mọi thứ còn lại.

​
2. Một ví dụ: allow-list các tool của một agent nghiên cứu

Giả sử agent của bạn chỉ cần tìm kiếm web và đọc từ một knowledge base — các tool tên web.search và kb.read. Mọi thứ khác (shell, ghi file, mutation cơ sở dữ liệu, bất kỳ tool nào mà một prompt-injection có thể triệu hồi) phải bị deny. Xây chính sách thành mặc định deny + hai quy tắc allow:
1

Tạo chính sách với mặc định deny

Security → Firewall → Policies → New policy. Đặt tên, để Enabled bật, và đặt verdict mặc định thành deny. Đây là sàn đóng — xem Tạo một chính sách.
2

Thêm một quy tắc allow cho mỗi họ tool

Trong trình chỉnh sửa quy tắc, thêm hai quy tắc, cả hai verdict = allow:
prioritytool_name_globverdict
10web.searchallow
20kb.*allow
web.search là một match chính xác; kb.* là một prefix glob cho phép kb.read, kb.search, và bất kỳ tool kb.* nào trong tương lai mà không cần chỉnh sửa lại chính sách.
3

Gắn nó vào key của agent bạn

Đặt firewall_policy_id của key thành chính sách này (hoặc đặt làm mặc định của workspace). Request body của agent bạn không đổi.
Giờ web.search và kb.read đi qua; một cuộc gọi tới shell.exec không khớp quy tắc allow nào, chạm sàn deny, và quay lại dưới dạng HTTP 400 với mã firewall_blocked trên bề mặt inbound — xem một block trông như thế nào.
Soạn các quy tắc allow dưới dạng tên chính xác hoặc tiền tố hẹp (kb.*), không phải hậu tố rộng. Một *.read lỏng lẻo sẽ cho phép kb.read và secrets.read — ngược lại với mục đích của một allow-list. Giữ glob chặt nhất mà cách đặt tên tool cho phép.

​
3. Glob trong một màn hình

tool_name_glob là một ngữ pháp nhỏ, phân biệt hoa-thường — không regex, thời gian tuyến tính. Các hình dạng quan trọng cho một allow-list:
MẫuCho phép
web.searchĐúng tool đó.
kb.*Tiền tố — kb.read, kb.search (không phải kb trần).
*.searchHậu tố — web.search, kb.search, và search trần.
*.tools.*Trung tố — byo.tools.fetch và tương tự.
Để biết toàn bộ ngữ pháp (quy tắc trung tố, trường hợp biên, glob tên skill), xem Cú pháp glob và tham chiếu Quy tắc Firewall.
Một glob *.suffix cũng khớp động từ trần, không namespace — *.search cho phép một tool tên đúng nghĩa đen là search, không chỉ web.search. Các provider và MCP server không-namespace phơi bày tool dưới các động từ trần, nên một hậu tố được allow-list rộng hơn vẻ ngoài của nó. Ưu tiên tên chính xác hoặc tiền tố khi bạn muốn một allow-list chặt.

​
4. Triển khai nó mà không làm hỏng agent

Default-deny là tư thế dễ block nhất một tool bạn quên là mình cần. Hãy phân giai đoạn nó:
Bật shadow mode. Chính sách đánh giá và ghi log đúng như nó sẽ làm khi live, nhưng hạ cấp mọi deny thành audit với lý do được thêm tiền tố [shadow] would …. Chạy traffic thật, rồi đọc events feed.
Discovered tools liệt kê mọi tool mà workspace đã thấy, gắn cờ covered hoặc gap. Các event “would-deny” của shadow mode cộng với các gap cho bạn biết chính xác bạn còn cần các quy tắc allow nào.
Test sandbox chạy thử 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 dispatch gì, không lưu gì. Xác nhận web.search allow và shell.exec deny, rồi tắt shadow.
Một cuộc gọi inbound bị deny tốn không token mô hình nào — nó bị block trước khi mô hình thượng nguồn chạy — và được đánh dấu skip-retry, nên một tool bị block sẽ không đốt một ngân sách retry để bị block lại. Xem Verdict.

​
5. Đi đâu tiếp theo

Block các tool cụ thể

Mặt ngược lại — giữ một sàn default-allow và deny các tool có tên.

Kiểm tra đối số

Allow một tool, nhưng chỉ với đối số an toàn (db.query nhưng không DROP TABLE).

Ưu tiên quy tắc

Cách first-match-wins sắp các quy tắc allow của bạn trên sàn deny.

Verdict

allow, audit, deny, sanitize, pending_approval, cap_cost.
Để biết mối đe dọa mà mẫu này giải quyết, xem quyền tự quyết quá mức và cuộc gọi tool nguy hiểm. Để biết tại sao default-deny là baseline của agent, xem tại sao zero trust.