範圍的組織方式：金鑰、政策和工作區

每個到達 OrcaRouter 的請求都攜帶一個 API 金鑰。那個金鑰不只是憑證—— 它是一個範圍聲明：呼叫者可以使用哪些模型、哪些 IP 可以提供它、 它可以花費多少，以及確切哪個防護欄和防火牆政策治理其流量。 本頁解釋三層層次結構以及政策在請求時如何解析。

​

1. 三個範圍

三個概念相互嵌套：

• 工作區——租戶邊界。工作區的每個成員共享相同的防護欄和防火牆政策目錄。 沒有東西跨越工作區邊界——在工作區 A 撰寫的政策對工作區 B 不可見。
• 政策——一個命名的、工作區範圍的規則集（防護欄或防火牆政策）。 編輯政策會在下次請求時對附加到它的每個金鑰生效，無需重新部署。
• 金鑰——身份加上附加。金鑰攜帶自己的限制並指向治理它的政策。

工作區是外部邊界；政策是其中的共享資源；金鑰是將限制和政策綁定在一起的每代理身份。

​

2. 金鑰攜帶什麼

每個 API 金鑰是一捆限制和附加。在金鑰編輯器（/console/token）中設定這些—— 建立或編輯金鑰需要 Developer 角色或更高。 金鑰在主控台顯示時被遮罩。明文在建立時顯示一次；閘道範圍的金鑰需要 Admin 才能再次擷取。

​

3. 政策解析順序

對於任何請求，OrcaRouter 獨立解析作用中的防護欄和防火牆政策：

1. 金鑰附加——如果金鑰有明確的 guardrail_id（或 firewall_policy_id） 且該政策存在且已啟用，則它適用。
2. 工作區預設值——如果金鑰沒有附加，則套用工作區已啟用的 is_default 防護欄（或政策）。
3. 不強制執行——如果兩者都未設定，請求在沒有內容篩查或工具呼叫強制執行的情況下通過。

每個工作區在任何時候最多只能有一個防護欄和一個防火牆政策作為預設值。 晉升新預設值會在同一交易中降級舊的——你永遠不會意外地有兩個預設值。

​

4. 最小代理權限金鑰——每個代理一個金鑰

最安全的設定是給每個代理自己的窄範圍金鑰，而不是在所有呼叫者之間共享一個工作區金鑰。 只呼叫一個模型並執行排程任務的代理的精心範圍化金鑰可能看起來像：

• model_limits: ["openai/gpt-4o-mini"]——代理不能切換到更昂貴或更有能力的模型。
• allow_ips: 排程器的外向 CIDR——沒有其他來源可以提供此金鑰。
• credit_limit_usd: 每週預算上限——失控的迴圈無法耗盡你的工作區餘額。
• expired_time: sprint 或部署生命週期的結束——金鑰自動過期，無需手動清理。
• guardrail_id: 特定於此代理資料敏感度的防護欄——比工作區預設值更嚴格。
• firewall_policy_id: 只允許此代理合法需要的工具的政策。

當此代理通過提示注入受到攻擊時，爆炸半徑是有界的：它只能呼叫一個模型、 只從一個 IP 範圍、只達到其支出上限，以及只有其防火牆政策允許的工具。 工作區的其餘部分不受影響。

​

5. 政策在哪裡撰寫

防護欄和防火牆政策都是工作區範圍的，在所有成員之間共享，但更改需要正確的角色：

• 讀取任何防護欄、政策或金鑰——任何工作區成員。
• 建立或更改防護欄、防火牆政策、MCP 伺服器、自主等級、審批動作和普通 API 金鑰——Developer+。
• 在金鑰上啟用 is_firewall_gateway；讀取閘道金鑰的明文——Admin+。

工作區是協作邊界：每個人都可以看到政策目錄；只有 Developer 及以上可以更改它； 只有 Admin 可以發出閘道憑證。

​

6. 下一步

範圍是控制堆疊的基礎。每個金鑰的範圍越窄，如果任何一個代理受到攻擊時的爆炸半徑就越小—— 而且稽核軌跡更清楚地顯示每個代理被授權做什麼。