Chuyển đến nội dung chính
Bạn đã soạn một guardrail và một chính sách firewall cho workspace của mình. Giờ bạn muốn một key cụ thể này — cái mà finance agent của bạn dùng — chạy một chính sách nội dung nghiêm hơn và một danh sách tool cho phép chặt hơn phần còn lại của workspace. Đó là điều mà hai trường đính kèm trên một key làm: gắn một guardrail và một chính sách firewall vào một key duy nhất, và mọi request mà key đó thực hiện đều được sàng lọc và thực thi bởi chính xác các chính sách đó — không đổi code agent, không triển khai lại. Trang này đề cập hai trường, cách chúng phân giải lúc request, và một quy tắc phân giải khiến nhiều người mắc bẫy: một phần đính kèm firewall bị tắt hành xử khác với một phần đính kèm guardrail bị tắt.

​
1. Chính sách bảo mật theo từng key: hai trường trên một key

Một guardrail sàng lọc văn bản chảy qua một mô hình (PII, secrets, jailbreak). Một chính sách firewall chi phối các cuộc gọi tool mà một agent phát ra (tool nào, MCP server nào, host nào). Cả hai đều là chính sách có tên, theo phạm vi workspace — soạn một lần, dùng chung trên workspace — và một key chọn dùng một cái cụ thể qua hai trường:
TrườngGắnĐặt trong console
guardrail_idGuardrail sàng lọc prompt và response của key này.Developer+
firewall_policy_idChính sách firewall đánh giá các cuộc gọi tool của key này.Developer+
Cả hai được đặt trong trình chỉnh sửa key tại /console/token. Đặt một trong hai là một hành động Developer+ — bản thân các chính sách cũng được soạn bởi Developer+ (xem Phạm vi & key).
Hai trường này độc lập. Một key có thể gắn một guardrail và không gắn một chính sách firewall, ngược lại, cả hai, hoặc không cái nào — mỗi mặt phẳng phân giải riêng. Để một trường không đặt (0) không giống với tắt việc thực thi; xem §3.

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

Giả sử guardrail mặc định của workspace gắn cờ PII nhưng cho nó đi qua, và chính sách firewall mặc định audit mọi cuộc gọi tool. Điều đó ổn cho hầu hết các agent — nhưng finance agent của bạn xử lý SSN của khách hàng và không bao giờ nên gọi một shell tool. Soạn một finance-guardrail nghiêm hơn (block PII hoàn toàn) và một finance-firewall (chỉ allow-list ba tool nó cần), rồi gắn cả hai vào key của agent đó: 
# Configure via the CONSOLE (UserAuth — your session), not a relay key.
# This is the key-update call the editor at /console/token makes.
PUT /api/token
{
  "id": 4127,
  "name": "finance-agent",
  "guardrail_id": 12,          // finance-guardrail (PII = block)
  "firewall_policy_id": 8      // finance-firewall (3-tool allow-list)
}
Từ request kế tiếp trở đi, traffic của key đó được sàng lọc bởi guardrail 12 và các cuộc gọi tool của nó được đánh giá bởi chính sách 8 — trong khi mọi key khác trong workspace vẫn chạy các mặc định của workspace. Code của chính agent không bao giờ thay đổi; nó vẫn gọi https://api.orcarouter.ai/v1/... với key sk-orca-… của nó y như trước.
Đây là khuôn mẫu least-agency: một key có phạm vi hẹp cho mỗi agent, mỗi cái gắn vào các chính sách mà công việc của nó thực sự cần. Khi agent đó bị xâm phạm, bán kính ảnh hưởng là bất cứ điều gì key của nó được phép làm — không gì hơn. Xem checklist least-agency.

​
3. Phân giải: quy tắc khiến nhiều người mắc bẫy

Với mỗi request, gateway phân giải guardrail đang hoạt động và chính sách firewall đang hoạt động một cách độc lập. Thứ tự trông giống nhau với cả hai — phần đính kèm trước, mặc định workspace sau — nhưng chúng rẽ nhánh ở một trường hợp.

​
Phân giải guardrail

guardrail_id của key trỏ tới một guardrail tồn tại và được bật. Guardrail đó sàng lọc request.
Vô hiệu hóa guardrail đã gắn là một công tắc tắt. Key không nhận được sàng lọc nội dung nào — nó không fallback về mặc định của workspace. Điều này là chủ đích: gắn một guardrail và vô hiệu hóa nó là cách bạn tắt sàng lọc cho key đó.
Không có guardrail_id trên key. Guardrail mặc định được bật của workspace áp dụng, nếu có một cái được đặt.
Không có phần đính kèm và không có mặc định workspace → request đi qua mà không có sàng lọc nội dung.

​
Phân giải firewall

firewall_policy_id của key trỏ tới một chính sách tồn tại và được bật. Chính sách đó đánh giá các cuộc gọi tool của key.
Đây là điểm khác biệt. Một phần đính kèm firewall bị tắt fallback về chính sách firewall mặc định của workspace — nó không tắt việc thực thi. Vô hiệu hóa một phần đính kèm firewall đưa key trở về mặc định của workspace; nó không để key không được bảo vệ.
Không có firewall_policy_id trên key → chính sách firewall mặc định được bật của workspace áp dụng.
Vô hiệu hóa một chính sách đã gắn không đối xứng. Một phần đính kèm guardrail bị tắt nghĩa là không có guardrail cho key đó. Một phần đính kèm firewall bị tắt nghĩa là fallback về mặc định của workspace. Nếu bạn muốn một key thực sự không chạy thực thi firewall nào, bạn không thể đạt được điều đó bằng cách vô hiệu hóa phần đính kèm của nó — hãy chắc chắn không có chính sách firewall mặc định nào được đặt cho workspace (hoặc định phạm vi key sao cho nó không phát ra cuộc gọi tool nào bị chi phối).
Tối đa một guardrail và một chính sách firewall cho mỗi workspace có thể là mặc định tại bất kỳ thời điểm nào; thăng cấp một mặc định mới sẽ hạ cấp cái cũ trong cùng một transaction, nên bạn không bao giờ vô tình có hai.

​
4. Một block trông như thế nào

Khi một chính sách đã gắn từ chối một request, caller thấy một lỗi có cấu trúc — agent có thể phản ứng thay vì crash:
Mặt phẳngMã lỗiHTTPChi phí
Guardrailguardrail_blocked400Không — một block input kích hoạt trước khi đo lường; một block output hoàn lại. Được đánh dấu skip-retry.
Firewall (inbound)firewall_blocked400Một block inbound kích hoạt trước cuộc gọi mô hình, nên không có token mô hình. Skip-retry.
Firewall (held)firewall_approval_pending400Bị giữ lại chờ con người phê duyệt; agent poll và gửi lại một khi được phê duyệt.
Cả hai thân lỗi đều theo định dạng OpenAI và nêu tên chính sách và lý do, nên agent của bạn có thể rẽ nhánh theo mã. Xem các tham chiếu chuyên sâu để biết bản ghi sự kiện đầy đủ và cách các match được ghi log.

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

Phạm vi & key

Toàn bộ mô hình ba cấp — workspace, chính sách, key — và mọi trường mà một key mang theo.

Đối tượng token

Mọi trường trên một key: model_limits, allow_ips, credit_limit_usd, expired_time, và hai phần đính kèm chính sách.

Guardrails

Soạn chính sách nội dung bạn gắn qua guardrail_id — quy tắc, thực thể PII, hành động, và preset.

Firewall

Soạn chính sách cuộc gọi tool bạn gắn qua firewall_policy_id — verdict, bề mặt, và cấp độ tự chủ.
Muốn đặt toàn bộ tư thế workspace của bạn trong một động tác thay vì gắn từng key một? Một cấp độ tự chủ ghi cả hai mặt phẳng — guardrails và firewall — cùng lúc. Rồi gắn các chính sách nghiêm hơn lên vài key cần đi xa hơn mặc định của workspace. Xem Guardrails vs Firewall.