跳轉到主要內容
大多數團隊太晚才去拿代理安全,而且一次一個平面——這裡在提示上一個 regex、那裡一個工具拒絕清單。結果是一個有漏洞的姿態:從不看見一個 shell.exec 的文字審查,或從不注意到一個信用卡號在一個提示中離開的 工具防火牆。 通往一個完整代理安全基準最快的方式是同時設定兩個平面。 OrcaRouter 的自主控制項——Secure Agents 基準——正是做這件事:一個 單一的工作區層級開關,在一個交易中一起寫入一個 防火牆政策與一個 防護欄,並支援一鍵還原。你不必為了 受到保護而撰寫一條規則;你挑選一個等級,稍後再調校。
這兩個平面是互補的,而非冗餘的。防護欄審查提示／回應文字 （PII、密鑰、越獄與注入意圖）;防火牆治理一個代理採取的動作 （哪些工具、MCP 呼叫與主機）。任一個單獨都留下另一個關閉的缺口—— 參見防護欄 vs. 防火牆。

​
1. 為何一個基準勝過兩個半套措施

一次真實的代理執行在單一請求中跨越兩個平面。模型讀取一個提示 （文字）、決定呼叫 db.query（動作）,而工具的結果回饋進下一個回合 （又是文字）。只保護一個平面會讓另一個不受守護：

僅防火牆

你拒絕破壞性 shell,但一個提示仍把一個客戶的 SSN 直接帶給模型—— 而一個工具引數仍洩漏一個 API 金鑰。

僅防護欄

你在提示中遮罩 PII,但代理仍呼叫 rm -rf、觸及一個 cloud-metadata 端點,或在一個失控的工具上迴圈。
自主控制項移除了這個選擇。一個等級在兩個平面上設定一個連貫的姿態, 所以不會有一個窗口讓一個被設定而另一個沒有。

​
2. 代理安全基準：三個等級

每個等級涵蓋同樣的兩個平面。挑一個;它是你的底線,而你稍後用規則 增加精確度。
等級防火牆防護欄觀察模式
tightDefault-deny;破壞性 shell + 擷取形狀的工具被拒絕PII Shield + Secrets Blocker 強制執行關閉
balancedDefault-audit;破壞性 shell 被拒絕PII Shield 僅稽核（標記 PII）關閉
permissive沒有強制執行的政策無開啟——將每次呼叫記錄為一個缺口
幾個值得釘下來的具體細節,因為它們形塑了每個等級實際捕捉什麼：
tight 把防火牆政策的預設裁決壓為 deny,然後為攜帶破壞性 指令的 shell/exec 工具名稱——shell.*、bash、cmd、 powershell、exec——以及為攜帶 SSRF 的擷取形狀的工具名稱—— http_fetch、web_search、fetch_url、request（以及它們的 <server>.* MCP 命名空間變體）——疊加 deny 規則。它拒絕這些工具 名稱;它不附帶一條 CIDR 或 cloud-metadata egress 規則。如果你 想依目的地拒絕 169.254.169.254 或 RFC-1918 範圍,撰寫你自己的 egress 規則——參見Egress 控制。
PII Shield 與 Secrets Blocker 防護欄都作用中且強制執行。 PII Shield 在請求抵達模型之前遮罩它上面的 PII;Secrets Blocker 捕捉請求中的憑證。工具引數中的密鑰由這個防護欄在請求上捕捉—— 防火牆預設不剝除它們。
balanced 稽核一切（預設裁決 audit）,所以你看見你代理的真實 行為,同時仍拒絕那單一最具破壞性的類別——破壞性 shell。PII Shield 以僅稽核模式執行（標記 PII,不封鎖）。你得到一條完整軌跡而幾乎 沒有意外封鎖的風險,然後從可見性而非猜測來收緊。
permissive 什麼都不強制執行——它存在的目的是以零意外封鎖風險 觀察一個全新的代理。觀察模式保持開啟,所以每一次工具呼叫仍會 被記錄為一個涵蓋缺口（在 Discovered Tools 中可見）。用它來學習一個 代理的形狀,然後移到 balanced 或 tight。

​
3. 一個具體範例：套用 balanced、觀察兩個動態

套用一個等級是一個單一的主控台動作（Firewall → Posture）或一個 API 呼叫。該路由在你的工作階段下執行並需要 Developer+。 
# Configure in the console, or POST under your session token (Developer+):
POST /api/workspace/firewall/autonomy
Content-Type: application/json

{ "level": "balanced" }
回應攜帶一個 audit_id——保留它;它是你傳給還原的東西。一旦 套用,基準在下一次工具呼叫時即時。無需重新部署、無需代理程式碼 變更。現在你同時觀察兩個平面：
  • Firewall → Events——每一個工具呼叫裁決（audit、被拒絕的 破壞性 shell 呼叫）。參見事件記錄。
  • Guardrails → Matches——每一個內容政策命中（PII Shield 標記）。
由於 balanced 寫入一個真實、可編輯的防火牆政策與一個真實的 防護欄（各以該等級命名）,你之後可以開啟任一個並調校它——基準是 一個起點,而非一個鎖定的預設集。
在你承諾之前預覽。GET /api/workspace/firewall/simulate?level=tight （Member,唯讀）精確顯示 tight 對照你目前狀態會改變什麼——什麼 都不套用。在 balanced 上跑一兩天後執行它,以確認 tight 不會拒絕 屬於你正常流量一部分的呼叫。

​
4. 還原是一個呼叫

每一次自主變更都可從它的稽核快照逆轉,還原確切的先前狀態—— 政策、規則、防護欄與設定——而非一個通用的重設。 
# Developer+; :audit_id is the value returned when you applied the level.
POST /api/workspace/firewall/autonomy/undo/:audit_id
對一個其快照超過稽核記錄大小限制的非常大的工作區,套用仍會成功,但 那次變更的一鍵還原不可用——你改為重新套用你想要的等級。這很 罕見,但在你收緊一個繁忙的生產工作區之前值得知道。

​
5. 建議的路徑

從寬廣開始、觀察,然後從一個可見性的位置收緊：
1

套用 balanced

完整的稽核軌跡;只有破壞性 shell 被拒絕;PII 被標記。正常執行你的 代理一兩天。
2

模擬 tight

GET /api/workspace/firewall/simulate?level=tight,並把它的拒絕對照 Events 動態實際顯示的東西比較。如果擷取形狀的或破壞性 shell 的 呼叫屬於你正常流程的一部分,先修正代理。
3

套用 tight

一旦模擬沒有意外,切換到 tight。如果生產壞掉,還原只是一個呼叫 之遙。
4

用規則調校

基準是你的底線。用防火牆規則與 命名的防護欄切出例外或加入它未涵蓋 的控制項。把一個特定的政策或防護欄綁定到一個個別金鑰以取得更 精細的範圍。

​
6. 組合基準的角色

自主控制項橫跨兩個平面,但每個動作都是角色把關的。
動作最低角色
模擬一個等級 / 檢視防護欄 Matches / 檢視 Discovered ToolsMember
檢視防火牆 Events & RunsDeveloper+
套用一個自主等級Developer+
還原一次自主變更Developer+
所有設定都在主控台中於你的工作階段下執行（/api/workspace/firewall/* 與 /api/guardrail/*）。只有 /v1/* 中繼呼叫使用一個 sk-orca-… 金鑰;閘道金鑰路由是一個獨立的範圍。參見 範圍：金鑰、政策、工作區。

​
7. 基準之後：在哪裡調校每個平面

基準讓你在最初 30 分鐘內受到保護。從那裡開始,每個平面都有它自己 的精確工作參考：

防火牆總覽

裁決、介面、引數判定式、審批——動作平面。

防護欄

keyword、regex、PII、llm_judge 與 grounding 規則——內容平面。

影子模式

在強制執行之前以僅稽核推出一個收緊的防火牆政策。

Secure Agents 基準

自主控制項及其還原語意的概念頁。
基準是同時關閉兩個平面的底線;規則是你如何抬高天花板。參見 保護 AI 代理與 控制堆疊了解各層如何組合, 並參見過度代理權了解這個 基準最直接回應的威脅。