《Agent Runtime 後端服務設計》裡的 runtime 呼叫工具時「假設前面有一道 gateway 把關」——本篇就是拆開這道 gateway，看它內部長什麼樣。

系列裡有兩篇留下了一個明確的空位。《LLM 應用編排與 Agent 模式》建立了 Tool / Function Calling、決策與執行分離、幻覺 tool call 這些詞彙，並點出「執行點就是風險點」；Agent Runtime 篇則在工具執行章明說：runtime 只管把工具穩妥地執行、正確地回寫，「這個 tool call 能不能執行、呼叫端有沒有權限、要不要 sandbox」則屬於一個強制執行點（enforcement point）——它「應假設有一道 gateway 在前面把關，而不是自己重造安全邏輯」。本篇要回答的就是：這道 gateway 內部長什麼樣、它憑什麼擋下一個危險的工具呼叫。

先把定位釘死。Tool Gateway 是夾在 Agent Runtime 與真實工具／外部 API 之間的一層，它的職責只有一件事：對每一個 tool call 強制執行安全政策。用資安的話說，它是工具側的 Policy Enforcement Point（PEP）——所有工具呼叫都必須穿過它，沒有旁路。它守的是這樣一條信任邊界：

tool call 從「LLM 決定（不可信）」跨進「真實副作用（須治理）」的那條線，就是 gateway 站的位置。左邊越聰明，右邊越危險，這道邊界就越必要。

這也劃清了與鄰篇的分工。工具側的安全，和「模型側」「執行機制」「協定格式」是四件不同的事：

同樣叫「gateway」，LLM Gateway 管模型側路由與成本，Tool Gateway 管工具側政策與安全——兩者常被混為一談，但守備範圍完全不同。

gateway 到底在防什麼？先把危險的工具呼叫分成三類——它們正是後面決策鏈每一關存在的理由。

如果不先講清楚「威脅長什麼樣」，任何防護機制都像無的放矢。一個到達 gateway 的 tool call，可能在三個層面出問題。注意它們的共通點：三者都不是「模型壞掉」那麼簡單，而是「不能靠模型自律解決」。

三種威脅、三種來源：幻覺來自模型不可靠、惡意來自不可信內容注入、越權來自權限與身分沒對齊。gateway 的決策鏈，就是為了讓這三者各自撞上一道專門的關卡。

把 gateway 內部拆成一條決策鏈，讓第 2 節的三種威脅各自撞上專門的關卡——這也是本章 Demo 的主角。

gateway 內部不是一顆黑盒，而是一條有順序的政策決策鏈。一個 tool call 進來，會依序穿過五道關；任一關判定 deny，就立即短路攔截（deny-by-default），後面的關根本不會評估：

箭頭的方向就是短路的方向：任一關 deny，右邊的關全部不會被評估——只有最右邊的審計例外，它無論放行或攔截都會執行。

這五道關對應資安的一組通用語彙，面試常被問到，值得先對齊——一個 gateway 通常同時扮演 PEP 與 PDP：

記住 PEP／PDP 這對就夠用：gateway 攔（PEP）並判（PDP）。PAP、PIP 是餵給 PDP 的政策與資料。

還有一個排序細節值得點出：第 02 關的授權，評估的是主體的 capability／scope 對上這次呼叫「宣告」的動作與參數——它看「U 有沒有這一類權限、額度夠不夠」，並不依賴工具是否真實存在。所以越權情境（退 $5000 超過 U 的 $100 額度）在這一關就因額度不足被擋；而幻覺工具（宣告自己是讀取類操作）因 U 確實握有讀取 scope 而通過授權，要到第 03 關 allowlist 解析具體工具名時，才發現它不在註冊表而被擋——allowlist 才是把「宣告」對照真實註冊表的照妖鏡。實務上這兩關常合併評估，下方的決策器為了看清「哪個威脅在哪一關被擋」刻意把它們拆開；鐵律不變：額度不足就 deny、工具解析不到就 deny。下方的決策器就是這條鏈的可執行版本：你描述一次呼叫與一組政策，它把五道關的判定、依據數字、風險分數與爆炸半徑全部算給你看。

第一件該試的事：其餘不動，只把呼叫主體從 on-behalf-of U 換成 agent 服務身分。第 02 關仍然 PASS（有效額度變成 agent 的環境額度 100,000），風險分數卻升級成需人審——因為爆炸半徑從「1,200 元 / 12 筆」跳成「1,200,000 元 / 48,000 筆」。這就是 confused deputy 被算出來的樣子：危險的不是分數，是半徑。

決策鏈的前兩關。認證回答「你是誰」，授權回答「你能不能這樣用這個工具」——後者才是越權防護的核心。

認證（authn）在 Agent 世界比想像中麻煩，因為一次工具呼叫牽涉不只一個身分。把它們分開，是理解 confused deputy 的前提：

授權要對齊的是 end-user，不是 agent；工具對下游的憑證則從頭到尾不該被模型看到。三者一旦混為一談，越權與洩漏就同時發生。

授權（authz）是整條鏈的核心，也是越權防護真正發生的地方。兩種主流模型，實務常混用：

一段參數級最小權限的政策，概念上長這樣：

# 政策即程式碼（policy-as-code，概念示意；預設拒絕）
allow if {
    input.tool == "issue_refund"
    input.principal.role == "support_agent"
    input.args.order.owner == input.principal.on_behalf_of   # 只能退「這位使用者自己的」單
    input.args.amount <= input.principal.limits.refund_max   # 且不超過其退款上限
}
# 其餘一切 → deny（含 amount 超限、非本人訂單、未知工具）

同一支 issue_refund，退 $80 自己的單 → allow；退 $5000 → deny；退別人的單 → deny。授權看的是「主體 × 工具 × 參數 × 資源」的組合，不是工具名。政策獨立於 runtime，改權限不必重新部署 runtime（呼應 Agent Runtime 篇的 externalize）。

決策鏈第三關。承接 Agent 編排篇——LLM 輸出的 tool call 是「不可信輸入」，這一關就是那句話的具體實作。

就算通過了認證與授權，tool call 的內容本身還沒被檢查過。這一關把「模型輸出」當成和「使用者上傳的表單」一樣的不可信資料，逐層過濾：

由淺到深：名字對不對 → 格式對不對 → 值有沒有毒 → 存取的實例是不是你的。allowlist 是幻覺工具的攔截點、schema 是「湊參數」的攔截點。兩點補充：① 參數層對 SSRF 這類「目的地」攻擊只能做 best-effort 黑名單（可被 DNS rebinding、redirect、編碼 IP 繞過），真正可靠的攔截靠第 6 節的 egress allowlist；② 「資源歸屬」檢查放哪一關取決於屬性可得性——PIP 能直接供給歸屬時可在授權（02）完成，必須先抓物件才知歸屬時就下沉到這一層（03），兩者是同一個最小權限原則、只是落實時機不同。

決策鏈第四、五關。前面幾關管「該不該放行」，這兩關管「放行後怎麼把傷害關住、以及留下不可否認的紀錄」。

政策再嚴也可能有漏網之魚，或工具本身就是高風險（執行程式碼、打外部網路）。Sandbox 是防禦縱深（defense in depth）的最後一層：假設呼叫已經穿過前三關，仍把它的執行圈在一個受限環境裡，讓「就算出事，傷害也有邊界」。

sandbox 圈住的是「爆炸半徑（blast radius）」。它不能取代前面的授權與校驗，而是疊在它們之上——縱深防禦的意義就是每一層都假設前一層可能失守。

審計（audit）是決策鏈的最後一關，也是唯一「無論放行或攔截都會執行」的一關。它把每一次判定與每一個已執行的副作用，寫成一筆不可竄改的紀錄：

最值錢的判斷不是「會不會做一道 gateway」，而是「知道這個 Agent 的風險，該把 gateway 做到哪一階」。

gateway 的每一關都在買安全、賣延遲與營運複雜度。不是每個 Agent 都需要全套五關。判準只有一個：這些工具能造成多大、多不可逆的傷害？答案決定你該停在哪一階：

與 Agent 編排篇「能用 Workflow 就別上 Agent」、Agent Runtime 篇「能同步就別上重型 runtime」同一種紀律：安全也要按風險投資，別為低風險工具過度設計，也別為高風險工具偷工。