OrcaRouter 如何審查每個請求

閘道坐落在你的代理和它呼叫的每個模型之間。這使它成為 無論供應商如何都能看見每次呼叫的單一點——每個提示詞、每個回應、 每次工具呼叫，以及你的代理透過它路由的每個外向請求—— 無論哪個 SDK 發出了呼叫。這個咽喉要道是審查和強制執行所屬之處。 （它看不見的東西——一個完全在你的行程內執行且從不穿越閘道的工具 ——在§4中涵蓋。） 本頁精確解釋閘道能看見和不能看見什麼、偵測如何運作， 以及如何填補缺口。

​

1. 為何閘道是正確的審查點

大多數安全控制存在於應用程式中：程式庫包裝器、代理框架鉤子、 每個供應商的 SDK。這些控制有一個致命的結構性缺陷——一旦你增加第二個供應商、 切換框架，或讓代理自行安裝新技能，它們就會失效。 閘道沒有這些縫隙。你的代理發出的每次呼叫，無論模型、供應商或 工具能力如何到達，在任何東西到達上游之前都會穿越一個單一點。 這是你能做出保證的唯一層次：如果它發生了，閘道看見了它。 OrcaRouter 使用這個位置進行兩個不同的強制執行通道：

• 防護欄審查文字——你的代理發送的提示詞和模型返回的回應。 防護欄封鎖返回 HTTP 400 guardrail_blocked 且不消耗配額。
• 防火牆判斷動作——代理呼叫的工具、它觸及的 MCP 伺服器， 以及它報告的網路目的地。防火牆拒絕在 inbound 表面返回 HTTP 400 firewall_blocked，或在 MCP 表面返回工具錯誤， 這樣模型就能看到拒絕並對其做出推理。

兩個層次都在你的工作區設定一次並附加到 API 金鑰。無需重新部署。 無需 SDK 更改。你的代理像以前一樣繼續呼叫 https://api.orcarouter.ai/v1。

​

2. 四個強制執行表面

防火牆對照恰好一個表面評估每次工具呼叫—— 這是閘道在呼叫生命週期中看見它的那個點。 防護欄在上述表面之上增加兩個文字階段：input（請求提示詞和訊息） 和 output（模型的回應文字）。一個請求可以通過所有這些。

​

3. 首次使用偵測

這意味著新工具在出現在請求上的那一刻就落入Discovered tools 視圖， 即使沒有規則命名它。開啟觀察模式將每個沒有匹配規則的工具呼叫 記錄為覆蓋缺口——該視圖從真實流量驅動政策撰寫。

​

4. 閘道看不見什麼

審查保證涵蓋穿越閘道的呼叫。它不延伸到你的代理 完全在其自己行程內執行的工具——一個讀取本地文件、 呼叫程式庫函數或在不向閘道發送訊息的情況下執行子行程的工具。 這是一個誠實的邊界，而不是設計缺陷。設計目標是使閘道 成為重要呼叫的稽核路徑——那些有真實世界後果的呼叫： 如果你今天有在行程內執行且有真實世界後果的工具， 覆蓋的路徑是在防火牆 MCP 閘道後面 將它們註冊為 MCP 伺服器，或在派發之前從你的代理迴圈呼叫評估鉤子。

​

5. 審查資料的角色控管

在你的工作區內，審查表面的存取是角色範圍的：

​

6. 下一步去哪裡

閘道是穿越它的每次呼叫的單一審查點——設定你的政策一次， 每個供應商、每個代理和每次工具呼叫都被涵蓋。