跳轉到主要內容
你已經為你的工作區撰寫了一份防護欄與一份防火牆政策。現在 你想讓這一把金鑰——你的財務代理所用的那把——執行 比工作區其餘部分更嚴格的內容政策與更緊的工具允許清單。那正是 金鑰上的兩個附掛欄位所做的事：把一份防護欄與一份防火牆政策綁定 到單一金鑰，於是那把金鑰發出的每個請求都會被恰好那些政策 審查與強制執行——無需修改代理程式碼、也無需重新部署。 本頁涵蓋這兩個欄位、它們在請求時如何解析，以及那一條 最常絆倒人的解析規則：一個已停用的防火牆附掛 表現得與一個已停用的防護欄附掛不同。

​
1. 每把金鑰各自的安全政策：金鑰上的兩個欄位

一份防護欄審查流經模型的文字（PII、密鑰、 越獄）。一份防火牆政策治理一個代理發出的工具呼叫 （哪些工具、哪些 MCP 伺服器、哪些主機）。兩者都是 工作區範圍限定的命名政策——撰寫一次、跨工作區共用—— 而一把金鑰透過兩個欄位選擇加入特定的一份：
欄位綁定在主控台中設定
guardrail_id審查這把金鑰之提示與回應的防護欄。Developer+
firewall_policy_id評估這把金鑰之工具呼叫的防火牆政策。Developer+
兩者都在 /console/token 的金鑰編輯器中設定。設定其中任一個都是 Developer+ 動作——政策本身也是由 Developer+ 撰寫 （參見範圍與金鑰）。
這兩個欄位是獨立的。一把金鑰可以附掛一份防護欄而不附掛 防火牆政策、反過來、兩者皆有、或兩者皆無——每個平面各自 解析。把一個欄位留空（0）並不等同於把強制執行關閉； 參見 §3。

​
2. 一個具體範例

假設你的工作區預設防護欄標記 PII 但放行它，而 預設防火牆政策稽核每一次工具呼叫。那對大多數代理而言 沒問題——但你的財務代理處理客戶 SSN，且絕不應該呼叫 shell 工具。撰寫一份更嚴格的 finance-guardrail（直接封鎖 PII） 與一份 finance-firewall（只允許清單它所需的三個工具），然後 把兩者都綁定到那個代理的金鑰： 
# 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)
}
從下一個請求起，那把金鑰的流量會被防護欄 12 審查， 而它的工具呼叫會被政策 8 評估——同時工作區中的其他每把金鑰 都繼續執行工作區預設值。代理自己的程式碼 從不改變；它繼續用它的 sk-orca-… 金鑰呼叫 https://api.orcarouter.ai/v1/...，與先前完全一樣。
這就是最小自主的模式：每個代理一把狹窄範圍限定的金鑰，各自 綁定到其工作實際需要的政策。當那個代理被 入侵時，波及範圍就是它的金鑰被授權做的事—— 僅此而已。參見 最小自主檢查清單。

​
3. 解析：最常絆倒人的規則

對每個請求，閘道獨立地解析作用中的防護欄與作用中的 防火牆政策。兩者的順序看起來相同—— 附掛優先、工作區預設值其次——但它們在一個情況上分歧。

​
防護欄解析

金鑰的 guardrail_id 指向一份存在且已 啟用的防護欄。那份防護欄會審查該請求。
停用已附掛的防護欄是一個關閉開關。該金鑰得到 無內容審查——它不會回退到工作區 預設值。這是刻意設計：附掛一份防護欄並停用它，正是 你為那把金鑰關閉審查的做法。
金鑰上沒有 guardrail_id。如果有設定，工作區已啟用的預設防護欄 便會套用。
沒有附掛、也沒有工作區預設值 → 該請求在沒有 內容審查的情況下通過。

​
防火牆解析

金鑰的 firewall_policy_id 指向一份存在且已 啟用的政策。那份政策會評估金鑰的工具呼叫。
這裡是差異所在。一個已停用的防火牆附掛會回退到 工作區預設防火牆政策——它不會把強制執行 關閉。停用一個防火牆附掛會把金鑰還原回工作區 預設值；它不會讓金鑰失去防護。
金鑰上沒有 firewall_policy_id → 工作區已啟用的預設 防火牆政策便會套用。
停用一個已附掛的政策並不對稱。 一個已停用的防護欄 附掛意味著那把金鑰沒有防護欄。一個已停用的防火牆 附掛意味著回退到工作區預設值。如果你想讓一把金鑰 真正不執行任何防火牆強制執行，你無法靠停用它的 附掛達到——請確保沒有設定工作區預設防火牆政策（或為 金鑰設定範圍，使它不發出任何受治理的工具呼叫）。
每個工作區在任何時間最多只能有一份防護欄與一份防火牆政策 作為預設值；晉升一個新的預設值會在同一交易中降級舊的那個， 所以你永遠不會意外地同時擁有兩個。

​
4. 封鎖的樣子

當一份綁定的政策拒絕一個請求時，呼叫者會看到一個結構化的錯誤—— 代理可以做出反應而不是崩潰：
平面錯誤代碼HTTP成本
防護欄guardrail_blocked400無——一個輸入封鎖在計量之前觸發；一個輸出封鎖會退款。標記為 skip-retry。
防火牆（inbound）firewall_blocked400一個 inbound 封鎖在模型呼叫之前觸發，所以沒有模型權杖。Skip-retry。
防火牆（保留）firewall_approval_pending400為人工審批而保留；代理輪詢並在獲批後重新提交。
兩種錯誤主體都是 OpenAI 形狀的，並指明政策與原因，所以你的 代理可以依代碼分支處理。完整的事件紀錄以及匹配如何被記錄， 參見深入參考。

​
5. 接下來去哪裡

範圍與金鑰

完整的三層模型——工作區、政策、金鑰——以及一把金鑰所攜帶的每個 欄位。

權杖物件

一把金鑰上的每個欄位：model_limits、allow_ips、credit_limit_usd、 expired_time，以及兩個政策附掛。

防護欄

撰寫你透過 guardrail_id 綁定的內容政策——規則、PII 實體、動作與預設集。

防火牆

撰寫你透過 firewall_policy_id 綁定的工具呼叫政策—— 裁決、介面與自主等級。
想一次設定你整個工作區的姿態，而不是一把一把地 綁定金鑰？一個自主等級會一次寫入兩個平面——防護欄 與防火牆。然後在少數需要超越工作區預設值的金鑰上 附掛更嚴格的政策。參見 防護欄 vs 防火牆。