跳轉到主要內容
阻止一個代理做某件危險事最快的方法，是指名該工具並拒絕它。一個 在工具名稱 glob 上的 deny 裁決是代理防火牆的 拒絕清單原語：一條規則、一個 glob、裁決 deny、綁定到一個金鑰—— 從此閘道在每一次呼叫上拒絕那個工具，而無需更動你的代理程式碼。 本頁涵蓋拒絕清單使用情境，以及它逼你做的那一個決定：你封鎖在 哪個介面上——你公告的工具（inbound）還是模型發出的工具 呼叫（response）。關於完整的匹配詞彙與裁決語意，參見 規則綱要與 裁決。

​
1. 封鎖 AI 代理發出的一次工具呼叫

一條拒絕清單規則是一個防火牆政策能表達的最簡單的東西：依名稱匹配 一個工具，傳回 deny。當一個工具對某個給定金鑰應該絕不觸發時就 使用它——shell.exec、*.delete、一個你不信任的社群插件——無論 引數為何。 在你的工作區主控台中，開啟一個政策（或 建立一個）並加入一條規則： 
{
  "label": "block destructive shell",
  "tool_name_glob": "*.exec",
  "verdict": "deny"
}
tool_name_glob 是一個小而區分大小寫的 glob——shell.* 捕捉 整個家族、*.delete 跨伺服器捕捉一個動詞、* 捕捉一切。不需要 引數子句：一個光禿禿的 glob + deny 會無條件封鎖該工具。只有當你 想在一般情況下允許該工具但拒絕某一種呼叫形狀時，才加入一個 引數子句。
引擎會按優先順序走訪一個政策的規則，而第一個匹配者勝出。把 窄的 allow 例外放在較低的 priority 數字（它們先執行），把你寬泛的 deny 放在它們下面——例如，允許來自一個受信任 builtin.* 技能的 shell.exec，在其他每處拒絕它。參見 規則優先順序。

​
2. Inbound vs response：挑選介面

一個 deny 可以落在請求生命週期中的兩個不同點，而其差別很重要。用 stage 欄位固定該規則，或將它留空以涵蓋兩者。

inbound

你的代理在請求上向模型公告的工具（工具定義）。這裡的一個 deny 會在模型甚至無法選擇它之前剝除該工具——模型從不把它看作 一個選項。

response

模型在其回覆中發出的 tool_calls。這裡的一個 deny 會在模型 已決定要做的呼叫抵達工具之前捕捉它。
當你想讓一個工具隱形時，偏好 inbound——模型無法呼叫它從未被 提供的東西，所以你避免了它選了一個工具卻被拒絕的浪費回合。當該 工具在某些請求中正當出現、而你想捕捉實際發出的呼叫時，或當你只 控制代理迴圈而非被公告的工具集時，使用 response（或將 stage 留空）。
一條沒有 stage 的規則會套用於所有介面——同一個 deny 涵蓋 一個工具，無論它是被公告、被發出，或 透過 MCP 派發。那是那個雙重 保險的預設值；只有當一個 deny 應該限定於一個介面時才固定一個介面。 參見介面。

​
3. 綁定政策並觀察它觸發

一個政策在某個金鑰解析到它之前什麼都不做。在主控台中透過在 金鑰上設定 firewall_policy_id 來綁定，或將該政策設為工作區預設值。解析是： 金鑰綁定的政策（當它存在且已啟用時），否則是工作區預設值。（一個 已停用的綁定政策會回退到預設值——參見 管理政策。） 一旦綁定，inbound 介面上一個被拒絕的呼叫會傳回 HTTP 400， 帶有錯誤代碼 firewall_blocked 與一個指名工具的原因——例如 tool "shell.exec" blocked by firewall。該錯誤被標記為 skip-retry （重跑同一個呼叫只會再次被封鎖），且不耗費任何模型權杖，因為一個 inbound 封鎖在上游呼叫之前觸發。一個 透過 MCP 閘道派發的 deny 會以一個 工具錯誤呈現，這樣模型會看見該拒絕並能做出反應。
inbound 介面上的一個 deny 會把該工具從模型被提供的東西中移除。 如果你的代理框架要求它公告的某個工具可被呼叫，在 inbound 封鎖它 可能會搞亂迴圈——在那種情況下改為在 response 上封鎖，這樣 工具仍被公告但實際呼叫被拒絕。在你推出之前測試其差別（參見 §5）。

​
4. Deny 是若干裁決之一

Deny 是拒絕清單上最直接了當的工具。當一個硬封鎖太過時，同一個 glob 可以攜帶一個較柔和的裁決：
裁決何時改用它而非 deny
audit你想看見該工具觸發，但尚不封鎖它。
sanitize工具沒問題但它的引數可能攜帶密鑰／PII——遮罩 args，絕不遮罩工具結果。
pending_approval一個人類應該頻道外批准每一次呼叫。
cap_cost允許，直到某代理執行的花費跨越一個分（cents）上限。
所有這些都記錄在裁決上。一個 拒絕清單就是裁決為 deny 的那個子集。對於一個允許清單姿態（拒絕 一切、許可一個指名集合），將政策的 default_verdict 切換為 deny 並加入窄的 allow 規則——參見 工具允許清單。

​
5. 安全地推出

主控台 Test 分頁會對照一個樣本工具呼叫乾跑一個政策，並傳回 裁決、匹配到的規則與原因——不派發、不持久化任何東西。在綁定一個 金鑰之前，確認你的 glob 匹配你意指的工具（且只有那個工具）。 參見測試規則。
在政策上開啟影子模式， 每個強制執行的裁決——包括你的 deny——都會被降級為 audit，原因 加上前綴 [shadow] would …。你能精確衡量該 deny 會對照真實 流量封鎖什麼，然後關閉影子以強制執行。
不確定要 glob 的精確工具名稱？Discovered Tools 檢視列出工作區 看過的每一個工具，標記為 covered 或 gap。直接從實際出現的名稱 撰寫你的 deny。參見分析。
每一次評估都會寫入一個帶有裁決、介面、工具與匹配規則的防火牆 事件。在你強制執行後，按裁決 deny 篩選 事件記錄，以看見規則在你 預期的呼叫上觸發。

​
6. 誰能做什麼

所有拒絕清單設定都在主控台中於你的工作階段下執行 （/api/workspace/firewall/*）：
動作角色
讀取政策、預設集、discovered tools、SimulateMember
乾跑一個政策（Test）Developer+
建立／編輯／刪除規則與政策Developer+
讀取事件記錄與執行彙整Developer+
撰寫或變更一條 deny 規則是一項 Developer+ 寫入，主控台 Test 乾跑也是。讀取一個政策與唯讀的 Simulate（「假設」）檢視則對每個 成員開放。

​
相關

Glob 語法

shell.*、*.exec 與 *.shell.* 究竟如何匹配。

工具允許清單

反向姿態：default-deny、許可一個指名集合。

驗證引數

只拒絕一種呼叫形狀，而非整個工具。

危險的工具呼叫

一個拒絕清單處理的威脅。

裁決

deny 與它較柔和的同類在線路上做什麼。

防火牆參考

完整的規則 + 匹配參考。