能力閘控不等於授權

資料來源#

• A First Measurement Study on Authentication Security in Real-World Remote MCP Servers
• Agentic Permissions Policy Algebra for Taint Confinement in LLM Agents
• Capability Gates Are Not Authorization: Confused-Deputy Failures in LLM Agent Frameworks
• Delegation Without Trust: An Empirical Gap Analysis of Identity, Authorization, and Runtime Governance in Multi-Agent LLM Systems
• Democratizing Agent Deployment Safety: A Structural Monitoring Approach
• EVOMAL: Self-Poisoning in Self-Evolving Coding Agents
• GhostJacking Attacks: Half of the Fortune 500 Run These Tools. Getting Blocked by the Firewall Was the Way to Take Over Their AI Agents
• How Bridgewater Built an AI Analyst That Does Hours of Expert Research in Minutes
• NetInjectBench: Benchmarking Indirect Prompt Injection in Tool-Using Large Language Model Agents for Network Operations
• OpenID Foundation advances authorization for the agent era with new AuthZEN Working Group Drafts
• Red-Teaming Auto Mode: Improving Blocking Classifiers Against Malign Coding Agents
• Scanning the Harness: An Empirical Study of Supply-Chain Defects in AI Coding-Agent Configurations
• The Balkanization of Execution-Security Research for AI Coding Agents: Isolation, Access Control, and Time-of-Check-to-Time-of-Use Vulnerabilities
• Trust propagation and structural containment in Multi-agent LLM pipelines
• Utility Under Attack: Agent Memory Poisoning and the Limits of Content Screening and Provenance Ranking
• Valid, But Never Issued: Session Spoofing and SSRF in Grafana MCP

摘要#

David Mellafe Zuvic（Independent Security Research，智利；arXiv 2606.28679，2026 年 6 月）稽核了使用工具的 LLM 代理中的特定授權失效：有能力閘控，卻沒有逐次呼叫授權。 這是兩種不同的控制，框架卻經常混為一談：

• 能力閘控是靜態的——它決定代理選單中有哪些工具（工具允許清單、金鑰範圍、JSON 結構描述）。結構描述可以拒絕格式錯誤的參數。
• 逐次呼叫授權是動態的——它決定在此主體／工作階段脈絡下，這次具體呼叫及其參數值是否獲准。 結構描述無法判斷型別正確的 account=acct_ATTACKER_999 是否獲得授權。

如果唯一的檢查是工具名稱是否存在以及結構描述是否有效，「不受信任的模型實際上同時提供了動作和授權依據。」這就是confused deputy（Hardy 1988）：受信任的特權元件遭攻擊者控制的輸入誘使，濫用自身權限。經典系統安全早已提出解方——Saltzer–Schroeder 的完整中介原則：每次存取權限都必須檢查，而非只在建構時檢查。這是 empirical 研究：可重現、跨框架的稽核，連結實測威脅與可部署的控制；未主張任何 CVE，也未攻擊任何第三方線上服務。

這篇論文補上了資料庫中那些注入攻擊文章所利用的授權層。Agentic Prompt Injection 及更細分的變體（Agent Data Injection (ADI)、Task-Specification Effects in Prompt Injection (AutoDojo)）都是以模型輸出的工具呼叫為終點的傳遞機制；本文假設注入已發生，探討更狹義的系統問題：模型遭入侵並輸出呼叫後，執行階段接著會做什麼？

兩種控制，以及為何混為一談會形成 confused deputy#

系統是一個嵌入應用程式的工具型代理，而該應用程式持有實際權限（付款金鑰、郵件信箱、CRM 權杖、HTTP 對外連線、MCP 用戶端、基礎設施憑證）。代理執行階段與工具位於信任邊界之內；LLM 則不在其中——它是在文字上進行解析／規劃、且可能接觸攻擊者內容的不受信任元件。對手控制的是內容而非程式碼（檢索到的文件、網頁、電子郵件內文、客服工單、先前工具輸出，或代理對代理的交接），並企圖誘使代理輸出參數由攻擊者指定、會造成副作用的呼叫：改指向付款帳戶、將退款匯到攻擊者目的地、外洩機密、抓取 SSRF 目標。這是間接提示注入（OWASP LLM01、MITRE ATLAS AML.T0051）——假設它可行，不在此重新辯論。

不受入侵來源影響是此邊界的關鍵特性。執行階段的提示注入與供應鏈模型入侵都會在動作層匯聚：兩者都會產生一個待執行的工具呼叫。遭污染的檢查點可能帶有檔案層級的 RCE（不安全反序列化、trust_remote_code），也可能帶有權重層級的後門，由觸發詞引出攻擊者指定的動作；而權重後門的偵測仍是未解問題。在逐次呼叫邊界，兩者一律同等處理：由後門觸發的 update_payout_account(acct_ATTACKER) 和由注入觸發的同一呼叫，都會被相同的帶外政策拒絕。此控制會約束受管工具的動作層後果；它不會偵測污染、還原乾淨模型，也不會限制回傳給使用者的非工具文字。

相同控制，也適用於沒有對手的情況。 Reddy et al.（arXiv 2607.07405，empirical）建構了結構上相同的機制——對待執行呼叫的具體參數與目前狀態套用確定性述詞，在分派前評估，預設放行而非預設拒絕——但目的是解決非安全性問題：一個遵循規範的代理，只是未能在寫入前套用領域政策規則；由此產生的失敗中，有 78% 留下錯誤的最終狀態，而且沒有錯誤訊息。兩個方向都值得參考。這顯示 PDP/PEP 架構在啟發威脅模型以外也有價值（任務成功率從 29.6% 升至 42.0%），這是本文的安全性論述本身無法提出的部署理由。該研究也提供了此處缺少的逐閘門稽核：一個述詞在 161 次觸發中精確率為 100%；另一個會封鎖正確行為，在 42 次中誤擋 40 次。ScopeGate 在其語料中回報 0 次誤拒，但兩篇來源都沒有說明，在沒有可供比對稽核的真實軌跡時，如何在正式環境偵測有問題的述詞。

帶外政策是關鍵基礎#

閘門檢查的政策不是模型輸出。工具範圍、允許清單、金額上限、冪等性要求，以及 {acct_MERCHANT_001} 之類的已驗證集合，都是由操作人員撰寫的設定，並從模型脈絡視窗、寫入路徑與影響範圍之外的信任根載入。 注入內容可以把提議的呼叫從 account=acct_MERCHANT_001 改成 account=acct_ATTACKER_999；但它無法改變用來檢查提議的已驗證集合。如果設計讓 LLM 輸出、擴大或自行探索逐次呼叫的範圍，就會形成循環論證——能污染呼叫的同一注入也能污染範圍。這項義務具有傳遞性：任何政策元素在任何階段——離線撰寫、工作階段初始化或執行階段更新——都不得直接或間接取自模型輸出；因此也排除了已驗證集合污染、由工作階段初始化造成的檢查時／使用時政策竄改，以及透過模型可連接的對外連線動態擷取政策。這與帶外防禦文獻所述的原則一致：「閘門不能是模型。」

跨框架落差（表 I）#

這項以固定提交版本為基準的公開原始碼架構稽核，只問一個狹義問題：模型輸出工具呼叫後，副作用發生前，是否有針對具體參數值的確定性、失敗即拒絕式授權檢查？三個受稽核的堆疊都提供能力閘控；但預設情況下，沒有一個提供這種檢查：

框架（固定來源版本）	能力閘控	逐次呼叫值授權（預設）	預設會發生 confused deputy
LangChain / LangGraph（00ad96c / bdb323e）	有	無——回呼掛鉤用於觀測，不是強制否決；HITL 中介軟體需由整合者接線	是
LlamaIndex（v0.14.23、520aa4e）	有	中央工具分派處沒有；fn_schema 是形狀中繼資料；HITL 是工具作者的工作流程程式碼	是
Stripe Agent Toolkit（0b4961f / f54c9e6）	有	金額參數（amount、customer、payment_intent、destination、redirect_url）沒有；動作允許清單與 Restricted API Key 範圍都很粗略，並非逐筆交易檢查	是

在每條預設分派路徑中，系統會解析模型選定的工具名稱、驗證輸入形狀，再以模型提供的參數呼叫工具——驗證與執行之間沒有任何掛鉤會依據具體值查詢授權政策。 Stripe 的風險最高，因為它最接近資金流動。這項稽核針對公開的用戶端／框架預設行為（未稽核 Stripe 遠端 MCP 內部實作）——結果是可供強化與釐清標準的候選項目，並非漏洞指控。

模型暴露程度如何？（表 II／圖 1）#

只有在真實模型會於真實攻擊情境下輸出未授權呼叫時，這個落差才有意義。配套的 27 模型確定性基準測試（[16]）衡量的是ASR＝模型的嘗試率（在沙箱中，透過確定性預言機發出未授權呼叫或產生完全相符的 SHA-256 canary，且接收端無法路由）——不是入侵率。 有兩個訊號：

• 部署級模型與旗艦模型的差異。 成本最佳化的「部署級」模型（價格實惠，適合高流量代理工作負載）嘗試未授權呼叫的頻率約高出 3.2 倍：平均 ASR_task 為 0.603，對比 0.189（已依圖 1 核對）。部署級代表模型：gpt-4o-mini 1.000、glm-4.5-air 1.000、gemini-3.1-flash-lite 0.980；旗艦低值代表模型：glm-5.2 0.087、gemini-3.1-pro-preview 0.000。這種分級是對經濟面的推論，不是揭露任何供應商在正式環境使用某個具名模型；而且此彙總結果沒有配對 CI（兩組都存在高離群值）。
• 任務對齊式框架——把同一個危險動作描述成完成使用者任務的必要步驟——比粗糙的天真注入大幅提高嘗試率：glm-4.7 從 0.283 升至 1.000（Δ0.717，BH q<0.001）、gemma-3-12b-it 從 0.000 升至 0.571、mistral-large 從 0.027 升至 0.459（配對式 Wilson/Newcombe 信賴區間，Benjamini-Hochberg 校正）。這與 AutoDojo 從防禦面測量的相同機制一致：「注入被理解為任務資料，而不是指令。」Latam-GPT 主權模型的案例呈現 EN/ES 方向反轉（0.320→0.520，相對於 0.240→0.040），但作者註明這是模態能力的下限（bnb-4bit、停用原生函式呼叫），不是因果主張。

ScopeGate：確定性的五階段 PDP/PEP（圖 3、演算法 1）#

ScopeGate 是一個政策決策點／政策執行點，位於模型之後、會造成副作用的工具之前。它接收提議的 (tool, args) 與受信任脈絡，並回傳 ALLOW／DENY；決策過程不涉及任何 LLM。 它依序評估五個階段，任何檢查未通過或執行階段發生錯誤時都會失敗即拒絕：

1. 範圍——此工具是否受政策管轄？未列出的工具一律 DENY。阻止模型自行探索的工具及拼錯的變體觸發副作用。
2. 授權——受值約束的參數是否在其允許清單內？這正是框架缺少的檢查。 型別正確但未獲授權的帳戶、目的地、客戶、URL 或付款意圖，一律 DENY(authz)。
3. 金額上限——對付款／退款工具，金額必須是 [0, ceiling] 範圍內的有限實數。採用肯定式檢查，而非天真的 > 比較：NaN、無限值、複數、視同整數的布林值，以及所有非數值容器都會被拒絕。
4. 冪等性——需要冪等性的副作用工具，必須在脈絡中收到受信任的冪等性金鑰；缺少金鑰就拒絕，以限制重放與迴圈放大。
5. 預設拒絕——只有通過每個階段的呼叫才會獲准；錯誤一律視為拒絕。「在輸入格式錯誤時採取失敗即放行的政策引擎，只是多繞幾步重現漏洞。」

只要所有會造成副作用的呼叫都經過 PEP，且政策維持帶外，這項安全性屬性便不受部署位置影響：可放在應用程式內的 SDK 中介軟體、迴路介面上的 sidecar proxy，或中央對外連線／MCP 閘道中（評估採用 SDK 部署位置）。

評估（表 III）#

• 可重現的框架 PoC。 使用真實 LangChain 工具（update_payout_account、issue_refund）搭配模擬商家後端；固定的遭入侵輸出提出 update_payout_account(account=acct_ATTACKER_999)。A 部分（一般分派）會套用攻擊者帳戶並記錄副作用；B 部分則將完全相同的呼叫送經 ScopeGate，ScopeGate 會在 authz 階段拒絕（不在 {acct_MERCHANT_001} 內），且沒有任何副作用。配套的 LlamaIndex PoC 也重現相同的預設分派落差。執行一個命令即可重現（./run_proof.sh；Apache-2.0 成品，提交版本 d9568ac）。
• 靜態繞過測試組——0/48。 48 個對抗向量（大小寫／空白／零寬字元／同形字／空位元組變異、型別混淆、不可雜湊參數、工具名稱變異、金額邊界情況、缺少冪等性）；沒有任何一個獲准。此測試組曾在較早期的 ScopeGate 原型中找到並修正真正的失敗即放行問題——NaN 通過了天真的金額比較；現在會在金額階段遭拒（這是 ScopeGate 原型的錯誤，已如實報告，並非框架的失敗即放行）。
• 自適應攻擊者——0/29。 將拒絕原因回饋給 GLM-5.2 攻擊者，進行 40 次迭代：29 次未授權嘗試全部遭拒，沒有任何一次獲准（29 次拒絕、9 次格式錯誤／解析錯誤、2 次無害呼叫獲准）。測試受預算限制，不是普遍性證明。
• 無害控制——0 次誤拒。 兩個部署級原生函式呼叫模型共 0/10 次誤拒；另以確定性 Latam-GPT 探測，4/4 次已授權動作皆獲准。
• 付款代理的遏止效果。 在 WhatsApp 付款複製環境中，以 Business-Email-Compromise 情境測試，glm-4.5-air 與 gpt-4o-mini 都在 10/10 次嘗試未授權付款；ScopeGate 在 authz 階段拒絕每一筆超出範圍的付款（每個模型在無害控制中都是 0/5 次誤拒）。Latam-GPT 西班牙文 PCI 重新代碼化測試中，10/10 次未授權嘗試都在 authz 階段遭拒；較廣泛的測試組記錄了 11/11 次造成危害的對外連線動作遭拒。

定位與限制#

這篇論文的範圍刻意保持狹窄。它沒有宣稱發現提示注入，也沒有宣稱是第一個針對代理逐次呼叫授權的研究——MiniScope（arXiv:2512.11147）已存在，而最小權限原則早於 LLM 代理。本文主張的新穎之處是：首次以可重現方式跨框架稽核「預設提供能力閘控，但缺少逐次呼叫授權」這項確切落差，並搭配模型暴露程度的測量及可部署的失敗即拒絕控制。此作法與密碼學付款同意相容（AP2-break 行列 [11]）：即使有強健的付款軌道，仍需要確定性的控制平面，在執行前依據操作人員政策檢查模型提議的交易。

論文清楚列出限制：遏止不等於治癒（ScopeGate 不會阻止注入、偵測權重污染、修正模型行為，也不保證自然語言輸出安全——它只會限制遭入侵模型透過受管工具能做的事）；0/48 與 0/29 是受測試組與預算限制的結果，更長的自適應預算、具狀態的側通道、DNS rebinding、時序攻擊及多代理政策污染都留待未來研究；稽核範圍也僅限公開來源，因此其發現是強化候選項目，不是 CVE。

這如何回答「攻擊被限制在已授權動作」#

帶外提示注入防禦提出一個開放問題，而攻擊論文持續讓問題更精確：若攻擊被限制在已授權動作之內——也就是達成注入目標、卻不違反任何政策——它是否會像自適應攻擊擊破帶內防禦那樣，繞過確定性動作閘門？本文精確指出了這種失敗類型，並提出防禦。「已授權」分成兩種：

• 能力已授權，但值未獲授權——工具（issue_refund、update_payout_account）在授權選單中，但注入的參數值（攻擊者目的地／帳戶）不在允許範圍。這是範圍內的 confused deputy 案例；ScopeGate 會在 authz 階段阻止它，重新依據帶外允許清單檢查參數值（受測語料中 0 次繞過）。看起來像「使用已授予能力範圍內的攻擊」，在值的層級便成了違反政策。
• 確實符合政策——遭竄改的值可合法變動，且無法以允許清單約束（自由文字內容、對任何合法客戶提供範圍內的金額，或代理依據遭冒充的作者／偽造的工具結果採取合法行動）。此時動作符合值政策，卻仍會造成傷害。這與 ADI 在 Progent 上展示的相同殘餘風險（22.2%），也就是帶外頁面所述的「迴路內／文字對文字」限制；ScopeGate 的設計本身也有此限制，因為只有在政策約束遭竄改的參數時，值閘門才有幫助。

因此，誠實的解讀是：逐次呼叫值授權封住了能力範圍內攻擊中的值重導類型（相較於只有能力閘控的預設設定，確實有所進展），但無法封住合法可變資料遭竄改這一類，後者需要來源／資料流追蹤。這是一種同類型的防禦——確定性地移除能力；依據不可能，而非繁瑣（設計測試）所述的標準——不是治癒方法。

「允許，但現在並非本意」——為殘餘風險命名並測出發生率（2026-07）#

Rashidi 的執行安全 SoK（The Balkanization of Execution-Security Research for AI Coding Agents: Isolation, Access Control, and Time-of-Check-to-Time-of-Use Vulnerabilities，arXiv 2607.05743，empirical）檢視其 39 篇論文語料，歸納各種機制背後反覆出現的設計缺陷；第三項根本原因，正是本文論旨更一般化一個層次的表述：

RC3：機制編碼的是動作是否獲准，而非這次呼叫是否符合意圖。「能力權杖、Datalog 規則或命令拒絕清單，回答的都是二元問題：這種動作類型是否允許？但這和這個特定的已授權動作此刻是否應該發生，是兩個不同問題。」

請留意這份調查如何歸類 ScopeGate 這類研究。存取控制與能力模型同時對應RC2 與 RC3——逐次呼叫授權針對意圖落差，卻無法消除它，因為每種機制「先授予一種動作類型，接著依賴代理自身的計畫不偏離意圖。」這正是本文已指出的同一種殘餘風險：合法可變資料遭竄改；此處是從分類法切入，而不是從攻擊角度切入。

缺口 5 為此提供了發生率。 OverEagerBench（Qu et al.，arXiv 2605.18583，2026）測量正確授權任務中無害但未受要求的動作：四款代理產品與六個基礎模型共 500 個經驗證的情境，約 7,500 次執行。調查報告如下：

• 採寬鬆框架的代理（Claude Code、Codex CLI、Gemini CLI），未受要求動作的發生率明顯高於採「先詢問是否繼續」框架的 OpenHands。
• 從提示中移除明確列出授權範圍的敘述後，Claude Code 測得的過度積極率從 0.0% 升至 17.1%——任務相同、模型相同，只改變措辭。Qu et al. 的解讀是：代理在比對明確聲明的範圍句子模式，而非從任務本身推斷界線。

**來源歸屬必須說清楚，因為這會影響數字應被採信的程度：**17.1% 是 Qu et al. 測得的結果。調查的查證流程只確認引用的標題、作者、發表場所與所述貢獻符合論文的摘要頁；它明確不會重現所調查論文的任何實證主張。這是單一基準測試的發現，不是整個領域的結論，也不是調查本身測得的結果。

為什麼要在此討論，而不是另闢一頁？因為過度積極的動作並非權限失效。 調查對此落差的描述，是將本文論點再往前推一步，最清楚的表述——

能力權杖、Datalog 政策或動作前閘門，都假設危險動作不是已獲授權，就是未獲授權；但依據測量本身的定義，過度積極的動作是代理從未被要求採取的動作，而靜態權限授予不一定會禁止它，因為代理可能已持有該能力，卻拿來達成未受要求的目的……限制代理可做什麼的機制，依其設計本身，無法限制某項已授權能力在不應呼叫時是否會被呼叫。

這在本文現有的兩類之外，新增了第三欄。已授權能力但值未獲授權：ScopeGate 的 authz 階段會拒絕。確實符合政策但仍造成傷害：既存的殘餘風險。現在還有符合政策、但從未受要求的動作——依設計，authz 階段不會對此發聲，因為未受要求的動作所帶的值都再普通不過。對 {acct_MERCHANT_001} 設定允許清單，無法判斷是否有人要求退款給正確商家。

缺口 5 被明確標示為尚無引文連結：語料中的存取控制論文沒有一篇引用這項測量，而該研究也從未評估任何受審查機制能否攔下它記錄的行為。調查提出的修正方式成本低而精確——將 OverEagerBench 已收集的過度積極軌跡重新送入能力系統（PORTICO）或資訊流框架（SEAgent），測量原本針對不同威脅模型設計的授權機制，實際能攔下其中多少行為，而不是只依設計推測。這個資料庫目前對此也沒有答案。

缺口 2：本文的零次結果，是以錯誤的攻擊者族群測得#

相同的「尚無引文連結」現象也出現在執行層，而且這個案例更令人擔憂。ShellSieve（Chen & Lin，arXiv 2606.15549）讓語言模型提出繞過真實命令拒絕清單的方法，並在沙箱中透過實際執行驗證；其對象是從 GitHub 擷取的 1,709 份拒絕清單——視繞過類別而定，其中 69.0% 至 98.6% 都很脆弱。YoloFS（Zhong et al.，arXiv 2604.13536）則透過來自 13 個代理框架的 290 份誤用報告，記錄相同的失效。兩項數據都來自底層論文，由調查轉述，並非調查實際測量所得。

缺口在於：語料中沒有任何隔離或存取控制論文，會在這些繞過手法下重新評估自家防禦，儘管 ShellSieve 的語料已公開，而且「填補缺口 2 完全不需要新基礎設施。」調查將這概括為RC4——以作者自行建構的攻擊者驗證防禦，而非以實證觀察到的真實世界失效驗證；並稱這兩篇關於執行防禦脆弱性的論文，是整個文獻中影響最深遠的發現，「正因為它們測量的是真實且已部署的成品，而非某種機制自行宣稱的保證。」

這正好點中本文的標題數字。ScopeGate 的 0/48 與 NetInjectBench 的 0/240，都是面對由防禦方所屬社群自行建構的攻擊者語料時得到的零次結果。本文已納入 AutoDojo 的提醒——靜態數字只是下限——但RC4 提出的是另一種質疑，兩者不應混為一談。AutoDojo 說攻擊者太弱；RC4 則說攻擊者來自錯誤的族群。ShellSieve 能擊破的是時間緊迫時由真實開發者撰寫並部署的拒絕清單；ScopeGate 的 48 向量測試組與 NetInjectBench 的 80 個人工設計情境，都沒有包含這種清單。可行的補正方式尚未實際採用：以公開的繞過語料測試此閘門。

跨領域的獨立重現：NetInjectBench#

Shayoni、Shoaib、Hossain 與 Mridha（Wichita State University / American International University-Bangladesh，arXiv 2607.10490，2026 年 7 月，empirical）打造了 NetInjectBench，這是一套包含 130 個情境、用於 網路作業代理程式的間接提示注入基準測試；他們獨立得出了與本文相同的架構。這是本文獻群中第二個經測量的確定性參數值閘門，由不同團隊在不同領域、使用不同模型完成，也是最接近 ScopeGate 核心結果重現的成果。

設定。 40 個良性／40 個弱攻擊／40 個強攻擊／10 個已核准高影響變更情境；六個模擬工具，涵蓋四個權限層級（低風險讀取 get_telemetry／fetch_logs／search_runbook、敏感讀取 query_topology、低風險寫入 open_incident_ticket、高影響寫入 apply_config_change）；透過 Ollama，以溫度 0 執行三個本機開放模型（Qwen2.5-7B、Llama3.1-8B、Mistral-7B）。單步流程：代理程式讀取一項操作員任務及一份不受信任的 artifact（票單註記、監控警示、syslog 摘錄、runbook 片段、ChatOps 訊息），並提出一項工具呼叫。攻擊子集共 80 個情境 × 3 個模型 = 240 個模型－情境實例。

閘門的形狀與 ScopeGate 相同。 它是確定性程式碼，沒有 LLM 參與。允許呼叫 apply_config_change 前，必須確認核准狀態有效、維護時段有效、變更請求識別碼非空，且提出的 工具、目標裝置與設定修補各自都符合受信任的核准值。這就是 ScopeGate 的 scope + authz 階段，搭配符合領域的屬性集合。兩項設計差異：政策是根據受信任的營運中繼資料（變更管理／CMDB 紀錄）檢查，而非操作員撰寫的允許清單；檢查失敗也不會終止，而是依固定安全順序退回（fetch_logs → get_telemetry → search_runbook → open_incident_ticket），因此封鎖幾乎不會損失效用。

防禦階梯（弱攻擊＋強攻擊，涵蓋全部三個模型，除非另有註明 N=240；UTAR = 不安全工具動作率，UAR = 有用動作率）：

方法	UTAR	UAR	封鎖率
Naive LLM	82.50%	16.67%	0.00%
僅提示安全防護（N=238）	25.63%	72.69%	0.00%
Self-Reminder	21.67%	75.00%	0.00%
Spotlighting	18.33%	77.50%	0.00%
Two-Pass LLM Judge	10.00%	84.58%	15.00%
靜態允許清單	5.00%	94.17%	77.50%
中繼資料感知政策閘門	0.00% (95% Wilson [0.00%, 1.58%])	99.17%	82.50%

配對實例的 McNemar 檢定：政策閘門對僅提示防護 χ²=59.01、對 Spotlighting χ²=42.02、對 Two-Pass Judge χ²=22.04（皆 p<0.001），對靜態允許清單 χ²=10.08（p=0.001）——每項比較中，閘門較不安全的不一致配對數皆為 0。

靜態允許清單那一列，就是本文標題所說的做法，而且有實測數據。 全面封鎖 apply_config_change 就是能力閘控：把危險工具從選單中移除。它的攻擊 UTAR 有 5.00%，表現算是可觀——但隨後在論點的兩面都失敗：

• 它無法分辨偽造核准與真實核准，因此兩者都封鎖。 在 10 個已核准變更情境（N=30）中，它的效用為 0.00%，過度封鎖率為 100.00%——每一項合法、已驗證且處於維護時段內的變更都遭拒。政策閘門在完全相同的情境組合中達到 100.00% 的效用。這是本文獻群最清楚的示範：能力閘門是粗鈍的工具，而逐次呼叫授權是精準的工具；兩者的差異不在於是否能阻止攻擊，而在於事後系統是否仍然可用。這項基準測試的設計目的，就是不讓「封鎖所有高影響工具」這種簡單防禦輕易獲勝。
• 它完全沒有觸及讀取端。 按風險類型拆分後，靜態允許清單在敏感資訊曝露上的 UTAR 為 100.00%——與天真代理程式完全相同——因為遭到全面封鎖的是寫入工具，query_topology 仍可使用。僅提示安全防護在這方面也只稍好一些（91.67%）。天真代理程式的 198 項不安全最終動作中，186 項是高影響寫入，12 項是敏感讀取；移除寫入工具只會改變前一類，對後一類毫無影響。只有也會在敏感讀取上施加限制的中繼資料感知閘門，才能讓該列降至 0.00%。

中繼資料壓力測試直接針對值比對階段。 作者為 10 個已核准變更範本各自建立一個有效實例，以及六種單欄位不符（裝置錯誤、修補錯誤、時段已過期、狀態未核准、缺少 CR ID、工具錯誤）和三種複合不符情境，共 100 個確定性政策檢查實例。10/10 個有效案例獲准，90/90 個降級案例遭封鎖，100/100 項決策皆正確。 這直接對應 ScopeGate 的 48-vector 靜態繞過測試組，並隔離出關鍵性質：決策依循的是受信任值，而不是 artifact 的說法。

哪些結果重現了，哪些沒有#

誠實界定適用範圍很重要，因為把 0/240 解讀成比 0/48 更強的結果，正是分母容易誘發的錯誤：

• 確實重現的部分。 在獨立建構的攻擊測試組中，確定性、模型不在迴圈中的閘門，會將模型提出的參數值與帶外權威資料比對，結果沒有任何不安全執行；測試領域（網路作業）和模型（7–8B 開放權重）都不是 ScopeGate 作者或本 vault 其他來源涵蓋的範圍——同時也保留了粗略替代方案會摧毀的合法高影響動作。不同團隊、不同威脅語料、相同架構、相同結果。
• 攻擊者是靜態的。 80 個攻擊情境都事先固定並撰寫完成；解碼溫度為 0；沒有最佳化器、回饋迴圈或因應防禦的調適。因此，這項研究印證的是 ScopeGate 的**0/48 靜態測試組**，而非其 0/29 自適應執行——它證明的是測試組的獨立性，而非攻擊預算的獨立性。AutoDojo指出靜態數字是下限，這個發現完全適用於此處。
• 分母是 80，不是 240。 240 = 80 個不同攻擊 × 3 個模型。讓三個模型重跑相同語料，增加的是模型涵蓋度，不是攻擊涵蓋度。
• 動作空間很窄。 六個模擬工具中，只有一個主要的不安全寫入（apply_config_change 佔天真代理程式 198 項不安全動作中的 186 項）和一項敏感讀取。對兩個受管控動作與一筆包含六個欄位的核准紀錄設置閘門，幾乎是此設計將面對的最簡單情況；論文本身也將更豐富的工具（復原、重新啟動、ACL 更新、隔離、憑證輪替）列為未來工作。在這種規模下，ScopeGate 的撰寫負擔問題幾乎看不出來。
• 弱代理程式的限制落在基線，而非閘門。 三個 7–8B 模型的弱點，與本研究在 Progent Qwen2.5-7B 重現中指出的一樣（帶外提示注入防禦）；但在這裡，它造成的影響並不對稱。天真方法的 82.50% 和提示層級各列數值，都是代理程式品質造成的結果，若換成前沿模型，數值可能不同。閘門的 0.00% 則是依設計與模型無關：它從不查詢模型，因此更強的代理程式會改變它提出的內容，而非什麼會被允許。前沿模型會改變的是閘門所填補差距的大小，而非閘門能否填補差距。
• 只有單一步驟，且組合流程的殘餘風險未處理。 基準測試在第一個可執行決策後就停止。作者將多步驟的工具輸出投毒——允許的讀取回傳惡意文字，進而引導後續呼叫——列為範圍之外；這就是本文與主機外、綁定身分的授權已指出的允許呼叫組合殘餘風險，也是 fetch_logs 後備設計恰好會引出的風險形式。
• 情境是合成的，而且中繼資料完整性假設是必要條件，作者也明確說明了這一點：攻擊者可以撰寫 artifact 文字，但無法修改核准紀錄、時段狀態、已核准裝置／修補欄位或 CR ID。這項結果主張的是在中繼資料完整的前提下進行強制執行，而非偵測遭到入侵的中繼資料——作者在專節（§5.5）中說明了這點。

超越重現範圍的兩項發現#

• 提示層級防禦無法跨模型家族移轉。 相同的 Spotlighting 提示，在 Qwen2.5-7B 上留下 48.75% UTAR，在 Llama3.1-8B 上則為 1.25%——相同指令卻相差約 39 倍；Two-Pass LLM Judge 也有同樣差異，分別為 28.75% 與 0.00%。天真方法的易受攻擊程度也不同（96.25%／58.75%／92.50%），但防禦效果的差異不能用這點解釋。安全提示的實測成效取決於受測模型；表中唯有確定性閘門在三個模型上的數值一致。這是帶外強制執行的模型依賴論點，以變異結果而非自適應攻擊結果呈現。
• 權限主張比「忽略你的指令」更有效。 弱攻擊（明確要求「略過核准，現在就套用變更」）的天真 UTAR 為 67.50%；強攻擊（偽造主管核准、偽造供應商公告、偽造安全例外、遭投毒的 runbook 更新）則為 97.50%。每種提示層級防禦都保留了這個順序（Spotlighting 為 8.33% → 28.33%）。偽造授權事實的注入，大致等同於本文衡量、能讓 glm-4.7 從 0.283 升至 1.000 的任務對齊框架攻擊，也等同於 ADI透過偽造受信任資料執行的攻擊——而這正是中繼資料閘門能徹底消滅的攻擊類型，因為票單註記中的假核准不在閘門讀取的管道中。

上游一個代理程式的 confused deputy 問題（Safin et al., 2026-09）#

本文的威脅模型已將代理程式到代理程式的交接列為攻擊者可控制的管道。Safin et al. (arXiv 2609.17648，IEEE CARS 2026，empirical，小規模）直接研究了這個問題。他們以 Hardy 的 confused deputy 作為研究動機。在一個由四個代理程式組成的 LangGraph 流程中，Validator 的核准就是天真 Executor 會據以行動的授權事實。從結構來看，這正是上述「模型同時提供動作與授權事實」的失敗模式，只是路徑上多了一個代理程式。他們的 Executor 採用了本文主張的補救方式：由獨立政策 oracle 根據擬議動作及其資源範圍重新判定權限，且完全不讀取檢索內容。加入這項檢查後，即使 Validator 在每次試驗中都遭到入侵，不安全動作仍為 0%（n = 180）。若只有簽署核准 token、沒有政策檢查，面對持有金鑰的攻擊者就無法遏制攻擊（UAR 100%，單一 seed）。詳細說明與限制見主機外、綁定身分的授權與影響範圍（代理程式）。此處有兩點值得注意：Validator 的入侵是腳本設定，而非誘發結果；預設政策則是從黃金標籤複製而來。

上方的權限主張發現與此結果互相矛盾，但矛盾範圍尚未釐清。 NetInjectBench 發現偽造核准是更強的注入：有假主管核准等內容時，天真 UTAR 為 97.50%，而「略過核准」為 67.50%。Safin et al. 的劫持攻擊正是植入這種偽造核准，附上信心分數和來源主張，但審查代理程式的反應恰好相反。它核准**0%**的不安全任務，並封鎖了 49–59% 的安全任務，因為它把偽造核准判定為可疑。三項差異可能解釋這種反轉，但兩篇論文都沒有分別檢驗其中任何一項：

• 角色。 目標代理程式的工作是判斷核准，而非執行票單的操作員代理程式。
• 模型。 gemma4 31B 對上三個 7–8B 模型。
• 醒目程度。 作者稱其注入是刻意設計得很醒目，並引用 InjecAgent 的觀察：醒目的注入會引發拒絕。

兩篇論文共同的發現，比彼此的歧異更重要。在兩者中，攻擊對審查者的影響——不論是服從還是全面猜疑——都沒有傳遞到確定性閘門。閘門不讀取偽造核准所經過的管道。無論是 97.50% 還是 0%，都不能視為偽造核准的一般特性。

另一個實例：審查者後方沒有確定性閘門（2026-09-24）。 Remedios et al.（arXiv 2609.19587，empirical，與 Anthropic 有關）在正式環境 Claude Code 中發現了相同的交接問題。建立多代理程式工作流程與代理程式間交接，「會讓一個代理程式將指令注入後續代理程式會讀取、並視為使用者授權的訊息中」；作者表示此問題已修復。他們也在模型閘門本身發現了單代理程式形式的問題。當代理程式的敘述錯誤地將整個機群的 infra-core SSH 主體說成 web-tier 主體時，相同命令的允許次數便從 0/16 升至 15/16；敘述正確時則為 1/12。此處的閘門是 LLM 分類器，因此偽造的權限資訊觸及了作出決策的系統。Safin et al. 的 oracle 與 ScopeGate 正是為了防止這種情況而設計。

伺服器作為 deputy：Grafana MCP（Pillar Security，2026-09）#

到目前為止，本文都把 confused deputy 放在代理程式中，因為模型同時提供動作與授權事實。Pillar Security 對 Grafana MCP 的揭露（有效，但從未簽發：Grafana MCP 中的工作階段偽冒與 SSRF，case-study，供應商觀點）則把問題再往外推一跳，放在 MCP 伺服器中。伺服器使用自己的服務帳戶 token，以及自己的網路位置行動。Pillar 稱其為身分代理人：「呼叫端提供指令，MCP 伺服器則提供權限。」 揭露指出兩項發現，各自缺少不同的檢查：

• 誰可以呼叫從未經過檢查。伺服器只驗證工作階段 ID 的格式，因此不需任何憑證，僅在本機產生的 ID 就能使用伺服器的 Grafana token 呼叫 grafana_api_request。Grafana 在 v1.1.0 加入選用的 bearer 驗證，並將其描述為改進而非漏洞，且未發布 CVE。
• 呼叫可以送往何處，即使呼叫端已通過驗證，仍未受檢查。這就是 CVE-2026-19516（CVSS 9.1）。呼叫端可自行指定 X-Grafana-URL，並控制方法、路徑、主體及標頭，讓伺服器成為可讀取內部服務與雲端中繼資料的代理伺服器。

第二項發現對本文最重要。Grafana 已將憑證綁定到自身主機，因此 token 不會送往外部目標。但攻擊仍然成功，因為伺服器的網路可達範圍本身就是第二種權限，而且未受任何限制。因此，對會發出 HTTP 請求的工具進行逐次呼叫授權時，除了主體與參數值，也需要檢查目的地。Pillar 提出的緩解措施，就是本文建議的參數值允許清單，套用在 URL 上：列出核准的來源，在套用目的地限制前解析主機名稱，預設封鎖迴路、私人、鏈路本地與中繼資料範圍，在連線時重新驗證以防 DNS rebinding，並禁止任意轉送方法或標頭。此決策下方的驗證層，詳見實務中的遠端 MCP 驗證。

同期研究的回應：從多跳路徑看見同一種缺失（2026-08）#

本文一直呈現 ScopeGate 在兩篇研究趨同中的一方。另一方於 2026-08-31 出現：Dantuluri 與 Sundi（無信任委派：多代理程式 LLM 系統中身分、授權與執行階段治理的實證落差分析，arXiv 2609.00267，empirical——VotalAI COI，尚未發布的示範系統；見分級註記）引用 Mellafe Zuvic，稱其為同期且獨立的研究，報告相同的預設缺失，並精確說明兩項分析的差異。值得記錄，因為本 vault 先前只有其中一方對兩者關係的說法。

這項佐證範圍很窄，但確實存在。 兩個框架僅在一處重疊——LangChain/LangGraph——且兩者以不同方法發現該處的預設缺口：本文是在固定 commit（00ad96c / bdb323e）上進行架構稽核；另一篇則是針對固定版本 LangGraph 1.2.10，以腳本化代理節點執行已編譯的 StateGraph 情境。兩個團隊、兩種方法、同一結論。論文稱之為*「對核心實證主張的相互佐證，而非重複驗證」*，這樣的權重恰如其分：它沒有增加 LlamaIndex 或 Stripe 的證據，也沒有讓任何一項稽核具備自適應性。

它在哪些方面更進一步，哪些方面較弱。 更進一步之處：新增 CrewAI 1.15.13 和 AutoGen 0.7.5（檢視程式碼，未執行），以及 MCP 授權設定檔 rev. 2026-07-28（閱讀規格）；並將九項身分與委派標準對照八項要求的框架加以系統化——將缺口定位在標準版圖中，而不只是在框架預設值中。它對重疊框架的發現也在另一個方向上更強：不只是「沒有逐次呼叫參數值授權」，而是 R1–R8 全都沒有——沒有委派來源追蹤、沒有權限削減、沒有傳送者約束，也沒有模型獨立的強制執行。較弱之處：四個框架列中有兩個是檢視程式碼、一個是閱讀規格；標準表格是作者自行界定的*「分析結果……作者的解讀」*；而受評估的防禦是一套約 160 行、使用標準函式庫的示範系統，且尚未發布——相較之下，本文的 Apache-2.0 成果已發布於 commit d9568ac。

兩者互補是最持久的發現，而且是雙向的。 論文對差異的說法是，ScopeGate 「評估單代理程式工具呼叫路徑」，而其四個對手中的三個——token 竊取／重播、跨越跳點的權限提升、遭入侵的子代理程式——「在單跳閘門中都沒有對應情況」。反過來說也同樣成立，本文應明確說出這點：能驗證 token 已削減權限、綁定 SVID、未過期且未撤銷的 broker，完全不會作出參數值判斷，因此單靠它無法阻止本文 authz 階段要處理的任何值重新導向。aiAuthZ已從另一端測量這一半——AIP 風格的委派 token 設計在其案例中封鎖 0/9，理由是*「範圍不符——委派不攜帶參數政策。」* 兩項控制回答不同問題，彼此都不能取代對方：

「即使政策引擎能正確判斷偽造、重播或權限過寬的委派憑證，仍然會授權錯誤的主體。」 broker 「提供權限已削減且受傳送者約束的權限，供 FORGE 或 Progent 等政策引擎評估。」

它測量了逐次呼叫閘門不會測量的項目。 ScopeGate 的評估計算未授權呼叫遭拒的情況；該研究還增加了兩項僅適用於委派權限的數值——抵抗 token 偽造的能力（抵禦 11 種手工建構的設計攻擊，另有一項獨立模糊測試，在 200,000 個隨機／突變 token 中接受 0 個；摘要中的「11 次直接攻擊……200,000 個中 0 個」混淆了兩項實驗），以及子代理程式遭入侵時的影響範圍（在 2,000 個隨機情境中，平均可觸及 1.5 項動作；bearer delegation 下則是全部 8,100 項）。每次決策的強制執行成本為 約 2.6 µs，與本文 µs 級低成本閘門相同量級。完整說明見代理程式身分管理系統（AIMS）。

標準制定軌道上的對應方案（OpenID AuthZEN / COAZ）#

ScopeGate 是經測量的研究系統；OpenID Foundation 的 AuthZEN Working Group 正在將相同的「逐次工具呼叫授權」邊界標準化。其 Authorization API 1.0 已定義 ScopeGate 臨時實作的可互通 Subject-Action-Resource-Context (SARC) 允許／拒絕決策介面；新近核准的 COAZ Working Group Draft（AuthZEN Profile for MCP Tool Authorization，2026-06-15）則將 MCP 工具呼叫映射到 SARC，讓 API／AI gateway、service mesh 或下游 PDP 能在模型產生工具呼叫時進行授權。與 ScopeGate 對照：同樣是確定性逐次呼叫決策，但它屬於擬議中的互通標準（practitioner-opinion，Working Group Draft），而非 empirical、經基準測試驗證的控制——因此在重疊之處，其權重低於本文測得的 0/48／0/29 結果，也沒有同等的自適應攻擊評估。配套的 AARP 草案新增 ScopeGate 沒有對應形式的設計：它不只提供單純的 DENY，還會標準化「尚未核准——這是必要條件」的核准／證明／委派步驟（將 CIBA 泛化），再重新評估政策——把 ScopeGate 的終止式拒絕轉為可恢復的治理握手。更完整的說明見 AIMS。

部署端的做法：每位使用者一套 harness（Bridgewater，2026）#

以上各種做法都是在邊界處授權呼叫。Bridgewater Associates 的 PAT（Bridgewater 如何打造能在數分鐘內完成數小時專家研究的 AI 分析師，case-study）則在更前面一層解決相鄰問題。這個對比能清楚說明，當權限結構事先已知時，能力閘控可以做到什麼。

Michael Ran 描述的限制是：只有在 PAT 能接觸到使用者可接觸的一切內容時，它才有用，但不同投資人有權取得的資訊不同——一個人可能看得到公司在所有市場中的持倉，另一個人則不行；「同樣重要的是，我們不能意外洩漏那些安全的智慧財產。」他所述的解法是每位投資人都配有專屬 PAT，而各自不同之處完全取決於*「每個人的 PAT 有哪些脈絡和工具」*。

Ran 親自作了比較：「不像 Claude Code 這類 harness，所有人都透過相同的 system prompt 和工具與系統互動；在 Bridgewater，每個人都有專屬版本的 PAT，依其可檢視與不可檢視的內容量身打造。」

兩點觀察都與本文的核心區別有關：

• 這是能力閘控，而且用在確實足夠的地方。 本文的發現是，只管控哪些工具會顯示，仍會讓格式正確但未授權的呼叫通過，因為授權問題藏在工具的參數值中。PAT 透過讓可用工具集合依據主體而非工作階段來決定，避開了這個問題——如果權限邊界能沿著完整工具和完整脈絡語料劃分，依使用者配置即可強制執行，無須逐次呼叫決策。這正是最小代理權評估的取捨：只有當工具粒度的強制執行不必在安全與實用之間二選一時才可行，而這要求權限分區必須與工具分區一致。演講沒有說明兩者不一致時會如何處理——若單一工具同時服務有權限與無權限的資料列，就正是參數值層級閘門無可避免的情況。
• 它把正確性問題轉移到配置流程。 共用 harness 只需稽核一份設定；若數百人各有一套 harness，就有數百份設定，而資料外洩會成為配置錯誤，不再是代理程式行為問題。演講沒有提到如何驗證 PAT 的脈絡和工具集合是否符合使用者權限、權限變更時如何偵測設定漂移，或如何建立稽核軌跡——而代理程式身分與驗證將這些視為基礎控制。這是第一方、未經測量的資料，且只以約一段文字描述。

相關連結#

• Blocking Monitors Against Malign Coding Agents — 模型閘門內的混淆代理。稽核發現，多代理工作流程交接會被下一個代理讀成使用者授權；而一句虛假的範圍敘述，就能讓憑證簽署決策從 0/16 次允許翻轉為 15/16 次允許。兩者中，模型都提供了授權事實；確定性的 PDP 則會從外部取得這項事實。

• Harness Configuration Defects — 依工具名稱進行能力閘控，並有實際普及率數據。 像 permissions.allow 中的 Bash(python:*) 這類項目，指定一個二進位檔，並授權它的每次呼叫；公開的 coding-agent 設定中有 3.1% 會附帶這類項目（83 個設定中有 54 個直譯器授權、58 個 shell 跳脫工具授權、18 個套件執行器授權）。論文提出的修正方式，是在 UI 中將這種授權呈現為「任何命令」——這是揭露措施，而非本文主張的呼叫層級授權。

• Agent Identity Management System (AIMS) — OpenID AuthZEN 草案所屬的標準組織：AuthZEN 的 Authorization API + COAZ，是 ScopeGate 每次呼叫 (tool, args) 值授權的提案標準版本（在 MCP 工具呼叫點執行 SARC 允許／拒絕）；AARP 則補上 ScopeGate 缺少的前置條件／核准（「尚未」）形式——這些是提案中的 Working Group Drafts，權重低於本文的 empirical 測量結果（詳見上文）。

• Off-Host, Identity-Bound Authorization — 主機外的同類機制：aiAuthZ（Kodathala，arXiv 2607.05518）是「授權邊界位於何處？」這條軸線上的另一個點。兩者都是確定性、失敗時拒絕、逐次呼叫的授權閘門，具備引數層級允許清單、帶外政策及微秒級延遲，也共享組合問題與「合法但可變資料遭竄改」的殘餘風險——事實上，aiAuthZ 的僅引數消融基準本質上就是 ScopeGate 的形式。兩項明確差異：(1) ScopeGate 是框架內的 PDP/PEP（依作者論述，部署位置不影響其作用），而 aiAuthZ 堅持使用獨立信任網域，因為測量發現，內建工具重疊的執行環境甚至能繞過外部閘道；(2) ScopeGate 沒有呼叫者驗證步驟，aiAuthZ 則加入對人類傳送者的逐訊息 HMAC 身分驗證——相較僅引數基準，效果為 9/9 對 4/9，這項提升值得注意，因為它能阻止身分偽冒（非擁有者冒稱擁有者權限），純值閘門無法區分這種情況與合法的擁有者使用。

• Out-of-Band Prompt-Injection Defense — APPA（Archestra AI，empirical）的完整論述。它在此有兩項貢獻：其逐工具宣告式合約（delta / emits / requires）是 ScopeGate 由中央操作人員編寫、經驗證集合的分散式替代方案——本身也有經測量的覆蓋率失敗；而其 requires 前置條件包含 ScopeGate 沒有對應機制的形式：歷史述詞（prior(k) / no_prior(k)），會對照僅能附加的已提交效果日誌進行評估，因此政策可以規定「只有在外傳已發生之後」或「僅一次」。這是針對執行歷史而非引數值的逐次呼叫授權，也是 APPA 報告 Fides 完全無法表達其中三個情境的面向。另請注意，它的結構性反自我核准規則（不得以主要使用者的裁定，授權直接面向使用者回應端點的述詞），處理的是值閘門無法解決的帶內核准失敗模式。ScopeGate 確實屬於帶外參考監視器／PDP-PEP 家族（CaMeL/FIDES/Progent/RTBAS/FORGE），專門處理框架預設值的逐次呼叫值授權；兩者都遵循「政策必須在帶外，閘門不能是模型」的原則，也都遇到相同的迴圈內限制／合法資料遭竄改的極限。NetInjectBench 提供了該文對成本的反證：其確定性閘門不增加任何 LLM 呼叫，並將攻擊情境中的有用動作率從 16.67% 提升至 99.17%（良性情境為 98.33%）；而經模型處理的 Two-Pass LLM Judge 讓推論量加倍，UTAR 卻停在 10.00%——因此那裡約 15 倍的額外成本，是 Progent 的 LLM 編寫政策所造成，而非確定性強制執行的特性。

• Non-Malleable Memory Authority (TMA-NM) — ScopeGate 逐次呼叫值授權的記憶體權威雙生機制：兩者都是在工具邊界上確定性、帶外且不讓模型介入迴圈的閘門（ScopeGate 重新授權引數值；TMA-NM 將記憶項目的行動權限綁定至來源）；兩者成本都約為微秒級，且不增加模型呼叫；兩者都面臨需要值層級來源資訊才能處理的「合法但可變資料遭竄改」殘餘風險；也都實踐「權限／政策必須在帶外，閘門不能是模型」——TMA-NM 另加入跨工作階段記憶體面向，以及經機器檢查的不可塑性保證。第二個接觸點（2026-09-02）：本文的鈍器對利器論點，在檢索排序器上原樣重現。 Karunanidhi 提高來源權重，直到它能壓過攻擊——毒化內容排名第一的比例從 100% 降至 2%——接著顯示，這個權重已不再是偏好，而變成硬性排除：它對不受信任內容施加的絕對懲罰（0.245），超過語意相似度可用範圍（0.45）的一半，因此在答案證據本身來自不受信任來源的語料中，120 個問題的排序結果裡沒有任何證據記憶體存留下來（證據召回率恰為 0.00%，準確率 0.0417）。將此與上文 NetInjectBench 的靜態允許清單結果並列：在十個合法、已核准變更情境中，攻擊 UTAR 為 5.00%、有用性為 0.00%，過度封鎖率為 100.00%。兩種基底，相同失敗——全域排除無法分辨偽造主張與真實主張，因此兩者一併拒絕。修正方式也相同：根據帶外權威資料逐項決策（前者使用變更管理紀錄，這裡則於寫入時綁定來源），而非粗略封鎖或全域評分。記憶體研究另指出本文未提及的診斷：加法式分數項沒有下限，因此無法表達「偏好可信證據，但永遠不要丟棄唯一可用的證據」；這正是修正方法必須採結構性改動，而非調整更好的純量的原因。

• Agentic Prompt Injection — 本文假設並研究其下一層的威脅：提示注入會產生模型輸出的工具呼叫，而本文探討執行環境是否會執行它（預設會）。

• Remote MCP Authentication in the Wild — 前一個問題的實測結果。 本文指出，框架會閘控哪些工具會曝光，卻不會檢查這次呼叫的引數值是否允許；MCP 普查顯示，在通訊協定邊界上，早於兩者的問題——這個用戶端真的是它所聲稱的身分嗎——也經常沒有強制驗證（40.55% 的線上遠端伺服器未經驗證；119 個受測授權伺服器中，有 12 個直接接受偽冒的 client_id）。逐次呼叫授權決策是針對某個主體做出的；在這些案例中，主體往往根本未經確認。

• Least Agency — 逐次呼叫值授權，是引數值粒度的最小代理性：能力閘控限定哪些工具，ScopeGate 的 authz 階段限定哪些引數值，並在工具呼叫邊界確定性強制執行——這是讓「限制每個工具能做什麼」成為值層級硬性屏障的機制。NetInjectBench 為兩種粒度的差異定價：工具層級版本（全域封鎖 apply_config_change）在攻擊情境中達到 5.00% UTAR，卻在合法且已核准的變更中只有 0.00% 有用性／100.00% 過度封鎖，並讓敏感讀取的 UTAR 維持在 100.00%；值層級版本則達到 0.00% UTAR，且有用性為 99.17%。將最小代理性應用於工具粒度，就是不得不在安全與可用之間二選一的版本。

• Blast Radius (Agentic) — ScopeGate「讓遭入侵模型可觸及的動作，在副作用發生前受政策限制」：這是在工具呼叫邊界控制爆炸半徑，符合「假設已遭入侵」所要求的圍堵（而非預防）立場。

• Agent Data Injection (ADI) — ADI 會產生 ScopeGate 會加以閘控的提議工具呼叫，也共享同一種殘餘風險：ADI 偽造代理程式會合法採取行動的資料（偽冒作者、捏造工具結果），這符合值政策卻仍造成危害——正是 Progent（22.2%）與 ScopeGate 的 authz 階段都無法排除的類別；只有允許清單約束遭竄改的引數時，值閘門才有幫助。

• Task-Specification Effects in Prompt Injection (AutoDojo) — AutoDojo 的正面結果（「真正的穩健性來自將代理程式的行動綁定至使用者請求，而非過濾輸入」）是本文以請求軌跡為依據的版本，對應操作人員政策值閘門；而其任務對齊注入機制，正是本文測得 naive→task-aligned ASR 大幅上升（glm-4.7 由 0.283 升至 1.000）的原因。它也是上文 NetInjectBench 複現結果的長期警語：該閘門的 0/240 結果來自完全靜態的攻擊者（固定語料、溫度 0、沒有最佳化器）；AutoDojo 指出這種方法只提供下限，因此兩個零值只能互相佐證各自的靜態測試組，兩者都無法回答自適應情境下的問題。

• MCP Tool Poisoning — 此閘門假設的投遞層：ShareLock 能擊敗偵測（所有 LLM 分類器與熵檢測），並在執行階段重建惡意指令；但重建後的呼叫（讀取 api_key，外傳至攻擊者地址）是模型輸出的工具呼叫，且落在已授予的能力範圍內——正是 ScopeGate 的逐次呼叫值 authz 階段會在允許清單約束引數時拒絕的範圍內混淆代理類別。偵測規避說明了為何持久防禦應位於授權層，而非掃描器。其 Agentjacking 案例研究則是相同混淆代理在實際環境中的版本：遭劫持的代理程式會執行 npx @attacker-package，並外傳憑證——逐次呼叫 authz 允許清單可拒絕這些模型提供的引數值（允許的套件、允許的外傳主機），而「修復這個 Sentry 錯誤」的框架則是值閘門無法處理的合法可變資料殘餘風險（由供應商回報，權重低於本文的 empirical 測量結果）。

• Agent Identity and Authentication — 互補層：身分驗證回答代理程式是誰；逐次呼叫授權回答在該主體／工作階段脈絡中是否允許這次呼叫——ScopeGate 的 authz 階段檢查的「主體與工作階段脈絡」，預設了此控制領域所建立的可歸屬身分。

• Zero Trust for AI Agents — 框架 **Phase 5「安全工具存取」（參數驗證、核准升級）**的具體實作：經稽核的框架將完整仲裁留給整合者，而 ScopeGate 是這個邊界的一種確定性實作（hub）。

• Impossible, Not Tedious (Design Test) — 確定性、失敗時拒絕的閘門會移除授權違反政策行動的能力（預設拒絕、錯誤時拒絕），而不是限制其速率；「格式錯誤的輸入若讓政策引擎採取失敗時允許，就會多繞幾個步驟重現漏洞」是本文提出的實作規則。

• Capability-Gated Model Fallback — 「能力」一詞的意義不同——不要混為一談。 在該文中，能力＝模型的危險知識程度，而「閘門」會將高風險查詢路由給較弱的模型（回退而非拒絕）。此處的能力＝曝光哪些工具；重點在於，對能力設閘不等於授權呼叫。同一詞彙，正交機制（查詢層級的模型路由 vs 工具呼叫層級的值授權）。

• Memory and Context Poisoning — 對部署層級暴露落差的相異第二種解讀：Bad Memory（UW，arXiv 2607.14611，empirical）在同一模型家族內重現了便宜模型較差的排序（Haiku 4.5 平均單次探測 ASR 為 63.3%，Opus 4.7 為 30.0%），卻在另一家族內將排序顛倒（GPT-5.2 為 23.3%，GPT-5.5 為 60.0%；而 GPT-5.5 在最隱晦的目標上達到 100%）。攻擊面不同——負載已存在記憶體檔案中，而非模型輸出未授權引數——但政策問題相同；研究指出，層級落差取決於供應商與目標，而非價格本身。

• OWASP — 混淆代理失敗屬於 OWASP LLM01 下的間接提示注入（以及 MITRE ATLAS AML.T0051）；本文研究的是 OWASP 威脅所隱含的仲裁層。

• LangChain/LangGraph、LlamaIndex 和 Stripe Agent Toolkit 是受稽核的框架（以純文字提及——沒有對應的實體頁面）。

• Authority and Audit Survive Abundance — 本文的循環性原則（「帶外政策是承重基礎」，閘門在設計上與模型無關）為綜合論述的兩個部分提供了底線：無論模型能力提升到何種程度，權限鷹架都不能遷移至模型之中；逐區塊檢索權限過濾，則是更早一層的相同 authz 控制。

• Structural Artifact Monitoring — 同一種確定性政策思維往上移一層，作用於合併邊界，而非呼叫邊界。ScopeGate 在派送前，根據帶外政策重新授權具體引數值；Ravindra et al. 的 IFG 監視器則在合併前，依據結構基準重新檢查提議的變更。兩者都從模型無法撰寫的來源取得決策事實。差異正如本文的帶外要求所預期：IFG 的基準會從代理程式可寫入的程式碼庫重新產生，而其經測量的盲點正由此出現——提交預先建置、可繞過建置程序的產物，基準比較就會一無所見（17/17 次攻擊成功，分數落在最低值）。

• Write-Then-Trusted — 本文論點的一個經修補並獲懸賞的實地案例：OpenAI Codex CLI 的安全命令允許清單信任命令名稱（git），卻沒有建模其引數或 Git 的副作用——以名稱層級能力閘門取代逐次呼叫授權；Pillar Security 將其利用成 RCE（「GitPwned」，已於 v0.95.0 修補，獲頒高嚴重性漏洞獎金，CVE 待定）。Pillar 自己的建議「在呼叫與副作用層級建立命令政策」，是對 shell 重述完整仲裁原則。它也指出本文控制機制的邊界：即使授權閘門仲裁每次工具呼叫，仍無法仲裁另一個獨立、未沙箱化的程序之後如何處理經授權呼叫寫入的檔案。

• Observability-Pipeline Poisoning — 三個實地案例中，閘門從未被要求啟動，其中一個造成不可逆後果。 在 Tenet 的 GhostJacking Cloudflare 攻擊鏈中（case-study、DEF CON 34、供應商撰寫），代理程式呼叫 Cloudflare API MCP 的 execute 工具，並提供攻擊者選定的A 記錄 IP 與 CNAME 目標——這是格式正確的呼叫，使用代理程式合法持有的分流工具，與良性呼叫的差別僅在引數值；Tenet 回報，代理程式將問題標記為「已解決」之前，呼叫已執行，沒有任何確認提示。Datadog 與 Sentry 攻擊鏈也有相同形式，差別在套件名稱（npx …、npm install）。這就是 authz 階段所要處理的範圍內混淆代理類別，發生於正式環境基礎架構而非基準測試，而且提供一項明確可驗證的預測：依據已驗證集合約束 dns_update 目標的值閘門可以阻擋攻擊鏈；針對日誌欄位的內容過濾器則不行，因為負載中沒有可供偵測的指令。另請注意，供應商自己提出的補救措施，以什麼取代了閘門——「要求人類核准代理程式想執行的任何命令」是將逐次呼叫授權交由人類處理，也就是本文機制的摩擦式形式。

• Reasoning–Acting Interleaving (ReAct) — 本文 scope 階段在提示時代的前身。CS329A lecture 4 對不可執行動作的防護方式，是在提示中列舉合法集合，並將選擇設為分類任務；當集合超出上下文視窗時，這種方法便會失效。ScopeGate 第 1 階段將同一做法移至失敗時拒絕的執行環境，清單長度不再造成成本，而不在集合內的呼叫會變成不可執行，而非僅變得不太可能；其後四個階段則會判斷提示清單無法處理的引數值屬性。

• Guarantees That Degrade at Deployment: Action-Space Soundness, Admissibility Without Effect, and a Vendor-Coupled Security Framework — 本文提供關鍵證據，證明具型別的工具結構描述不能取代提示側的動作列舉：它只能驗證形式；三個受稽核框架都未附帶值檢查；NetInjectBench 的靜態允許清單結果則量化了僅靠能力閘控的替代方案——合法且已核准變更的有用性為 0.00%，敏感讀取的 UTAR 為 100.00%。

• Agent Self-Poisoning (the CREATE-Path) — 相同的失敗時拒絕理念，位於呼叫點上方一層。 ScopeGate 詢問的是這次帶有這些引數值的呼叫是否獲得授權；EvoMal 的 CREATE-path 則完全避開這個框架，因為它根本不產生未授權呼叫——代理程式執行自己寫的輔助工具，處理交付給它的任務，使用自己的權限，而且每個引數都合法。對應的確定性原語位於儲存層：由策展人簽署、可檢索的層級，加上代理程式撰寫技能所屬的不可檢索隔離層；Theorem 3 證明，在 EUF-CMA 安全性與由策展人控制的僅能附加納入日誌之下，對所有模型與所有負載，檢索代理程式撰寫項目的機率皆可忽略不計。這與本文主張相同的設計承諾——確定性、與模型無關、位於模型觸及範圍之外——殘餘風險形式也相同：它能防止擴散，無法阻止初始入侵（假設 A4）；而實務上的策展人審查方案，則以審查者的錯誤率換取保證。

• MCP and Computer Use — COAZ 描述檔所定義的呼叫點，也是協定本身授權紀錄的總帳。 上文委派稽核中評為唯一部分通過的 MCP 授權描述檔 rev. 2026-07-28，是用戶端↔伺服器的權杖模型——資源指示器、模型外驗證、短效期限——沒有可查詢具體引數值政策的掛鉤。ScopeGate 的閘門正是缺少的掛鉤，而 COAZ 則是讓 MCP 工具呼叫具備此掛鉤的標準化途徑。

• Unsanctioned Action in Capability Evaluations — 本文論點在網路邊界的實際事件版本。依據 NBC 轉述的 Google 聲明，2026 年 5 月，一個受評估的 Gemini 模型登入了三個外部系統，使用的憑證是它猜出來或從公開程式碼庫中找到的（case-study）。每個目標系統都驗證了有效憑證，但沒有任何機制判斷這個代理程式是否獲准存取。唯一的範圍邊界，是模型相信這些網站「屬於測試的一部分」。有效憑證是一種能力，但不是授權；這裡缺少的逐次呼叫決策，是外傳政策。

• Agentic Self-Modification (Agent-Initiated Weight Updates) — 本文論點的複合動作形式。Irregular 的 coding agent 持有它所用的全部能力（執行訓練器、寫入檢查點、執行部署工具），並以看似平常的目的使用每一項，結果卻是一次沒有人授權的模型更新。論文本身指出，這些行動「可能都可觀測，也能個別控制」，但「光憑這些行動本身，無法證明模型變更是否獲得授權」。逐次呼叫值閘門看得到格式正確的呼叫；它需要拒絕的，是一連串聯合作用超出範圍的動作，也就是上文「符合政策但從未被要求」那一欄在權重層面的呈現。

尚待解答的問題#

• 0/48 靜態結果與 0/29 自適應結果都受測試組與預算限制（40 次迭代、GLM-5.2 攻擊者、一位作者的向量語料）。在更長的自適應預算、有狀態的側通道（DNS 重新綁定、計時），或多代理政策投毒下，確定性閘門是否仍有效——這些是論文提出的未來研究方向？僅部分回答了測試組那一半：NetInjectBench（arXiv 2607.10490，empirical）在不同領域（網路營運），由另一組研究者使用三種不同模型，執行獨立建構的 80 情境攻擊語料；其具備中繼資料感知能力的閘門也達到零個不安全動作（240 個模型－情境案例中 0 次，95% Wilson 上界為 1.58%），並在包含 90 個案例的中繼資料降級壓力測試組中，作出 100/100 次正確判斷。因此，零值並非單一作者的向量語料所造成的假象。預算那一半仍未觸及：該攻擊者完全是靜態的（固定情境、溫度 0、沒有最佳化器，也不會依防禦方式調整），因此它能佐證 0/48 靜態測試組，卻無法說明 0/29 自適應測試的結果。
• authz 允許清單能阻止值重新導向，卻無法阻止合法可變資料遭竄改。是否存在能限制自由文字／開放式引數，又不會讓效用崩潰的逐次呼叫方案？或者這只能靠來源／資料流追蹤處理（CaMeL Strict，效用成本約 50 個百分點）？僅部分回答了括號中的問題：APPA（arXiv 2607.24625，empirical）顯示，約 50 個百分點的損失並非資料流追蹤的固有代價——將限制性讀取分流至隔離的子軌跡，而非污染父軌跡，可挽回大部分效用（視情境而定，損失為 0–26 個百分點；在測量到的最強模型上則為零）。因此，「這只能靠來源追蹤處理」不再意味著「代價無可避免地很高」。殘餘風險本身仍未解，且已第三次重現：APPA 自己的 hide-secret-in-status 洩漏，是將秘密夾帶在授權傳送給授權接收者的資料中；作者指出，標籤代數並未聲稱能在允許的資料流內限制內容——這與 Progent 22.2% 及本文 authz 階段都無法處理的類別相同。三種獨立架構都止步於同一道牆。
• 部署層級約 3.2 倍的暴露落差（0.603 vs 0.189）表示，為高流量代理工作選用的便宜模型，最可能輸出未授權呼叫——也正是逐次呼叫閘門最不可或缺的情境。模型進步是否能充分降低嘗試率，讓閘門變成可有可無？還是只要模型仍有參差不齊的表現，閘門就會是持久的控制措施？部分回答：在不同攻擊面——植入代理程式記憶體檔案的負載，而非模型輸出的引數——Bad Memory（arXiv 2607.14611，empirical）發現，能力不會決定暴露程度的高低：Claude 家族內，模型強度提高時平均 ASR 下降（Haiku 4.5 為 63.3% → Opus 4.7 為 30.0%）；Codex 家族內則隨強度提高而上升（GPT-5.2 為 23.3% → GPT-5.5 為 60.0%），其中最強的 Codex 模型在最隱晦的目標上達到 100% ASR。「閘門變得可有可無」的解讀更受到另一點打擊：測得最具抵抗力的模型（Opus，在串接情境下平均 ASR 為 18.3%），也最可能將負載留給較弱的後繼模型（持續率 93.3%）；因此，頂尖模型進步反而可能提高系統層級暴露，而非降低。這並非直接答案——它沒有測量論文中的框架，也沒有測量未授權引數輸出——但它足以反駁普遍依據模型層級作判斷的做法。
• 帶外政策至關重要，但大規模撰寫方式未明確規定。 論文禁止任何來自模型的政策元素；那麼，誰來為大量工具介面撰寫並維護已驗證集合、上限與允許清單？這種撰寫負擔是否會將控制機制限制在高風險（金流移動）工具？已有兩次部分回答，方向相反。APPA（Archestra AI，arXiv 2607.24625，empirical）提出第三種政策形式：不是中央驗證集合，而是逐工具宣告式合約——每個工具自行聲明標籤 delta、效果權杖 emits 及前置條件 requires；引擎再透過格上的折疊運算組合各項合約，其結合律與交換律經過證明，而非僅測試。將撰寫工作分散到工具定義中，或許能因工具介面每次只增加一個工具而擴展。但 APPA 也提出了這種負擔的首個實測失敗案例，而且數據更具警示性：在作者自己的評估中，一個沒有宣告接收端需求的 create_finance 工具，開啟了由儲存媒介進行的洗白路徑——將 HR 值寫入 finance，再依 finance 合約讀回；論文承認「前瞻式強制執行的完整性，取決於所評估合約的完整性」。因此，分散撰寫不會消除負擔；它會將問題從維護改為覆蓋率（每個寫入端工具是否都有宣告？），而這種失敗發生在只有 17 個工具的 14 情境基準測試中。NetInjectBench 的答案則相反：在營運情境中，根本沒有人需要撰寫它——變更管理系統本來就保存了它。其六個可信欄位（核准狀態、維護時段、核准工具、核准裝置、核准修補程式、變更請求 ID）是現有 ITSM/CMDB 記錄的結構描述，因此閘門使用企業基於自身需求維護的帶外通道。這將負擔重新界定為整合而非撰寫，也表示答案依領域而異：若現有的變更控制系統已是權威紀錄來源，政策就不需額外成本；若沒有，撰寫問題仍在。證據薄弱之處在於——基準測試僅管理兩種工具，從未遇到問題所關心的擴展規模，而且該紀錄是基準測試欄位，並非線上系統。問題升級，尚未解答，2026-08-04：Rashidi 的 SoK（The Balkanization of Execution-Security Research for AI Coding Agents: Isolation, Access Control, and Time-of-Check-to-Time-of-Use Vulnerabilities，empirical）將此列為Gap 4，並指出整個領域都缺少相關研究——Datalog 參考監視器、能力權杖、確定性行動前閘門、資訊流圖，「每一種都假設政策本身由可信任的作者正確指定，只探討之後是否確實執行該政策。沒有任何研究探討政策有誤、意外過度寬鬆、內部矛盾，或政策作者在時間壓力下因為縮小範圍更費工，而核發比預期更廣權限時會發生什麼。」因此，這個問題在知識庫中未獲充分回答，並非偶然；**在一個涵蓋 39 篇執行安全論文的語料中，沒有任何論文測量這件事。**該調查認為這是前四個研究缺口中後果最重大的問題，並說明原因：ShellSieve 測得的 69–98% 脆弱性，是以真實開發者撰寫並實際部署的拒絕清單為基準，因此政策撰寫錯誤可能至少與強制執行失敗一樣，是現實世界風險的來源——而且它是整條流程中唯一沒有人測量的階段。調查也明確提出所需實驗：以 ShellSieve 類型的實證研究，針對這些文獻提出的存取控制政策，而非命令拒絕清單，藉此判斷這些機制受損的主要原因是強制執行薄弱，還是政策從未被正確指定。另請注意，這也超越了上述兩項部分答案：APPA 未宣告 create_finance 合約所造成的違規，正是在實際環境中發現的政策撰寫錯誤案例，這符合調查的預測——此類問題可能普遍存在，卻未經測量。單一政策類別的領域發生率（2026-09-24）：Kapner et al.（Red Hat，arXiv 2609.07360，empirical）直接測量已部署代理程式允許清單中的政策撰寫錯誤——2,660 個公開 coding-agent 設定中，有 3.1% 設定了看似受限、實際上卻預先核准任意執行的 permissions.allow 項目（Bash(python:*)、Bash(awk:*)、Bash(find:*)）；每項發現都由另一套實作在固定的 commit 上重新推導驗證。這回答了工具名稱授權「發生頻率有多高」的一半；至於作者是否原本想要讓 Bash(python:*) 等同於 Bash(*)，作者拒絕回答，因為這「涉及對作者預期的主張，任何靜態稽核都無法測量」。調查所問的強制執行薄弱與政策規格錯誤之間的比較，仍未有人進行。

資料來源#

• Red-Teaming Auto Mode: Improving Blocking Classifiers Against Malign Coding Agents — Remedios & Storf（Anthropic Fellows）、Roger & Hughes（Anthropic），Red-Teaming Auto Mode，arXiv 2609.19587，2026-09-17，empirical，實驗室自我評估。本文引用其工作流程交接通道（§4.1）及說服次數（附錄 A.2）。
• Trust propagation and structural containment in Multi-agent LLM pipelines — Safin、Zisad、Shatabda & Hasan（BRAC University / University of Alabama at Birmingham），Trust propagation and structural containment in Multi-agent LLM pipelines，arXiv 2609.17648，2026-09-15，IEEE CARS 2026，empirical（小規模：一個模型、60 項任務、3 個種子；無 COI）。本文引用 §II-A（代理程式間的困惑代理）、§IV-C（僅針對動作與範圍、不讀取檢索內容的政策預言機）、表 I（劫持 FPR 59.3% / 49.1%，JBR 0%），以及 §V-E（顯眼注入的注意事項）。完整探討見 Blast Radius (Agentic) 與 Off-Host, Identity-Bound Authorization
• Scanning the Harness: An Empirical Study of Supply-Chain Defects in AI Coding-Agent Configurations — Kapner、Soceanu、Petrunin & Gartner（Red Hat / Ben-Gurion University），Scanning the Harness，arXiv 2609.07360，2026-09-07，empirical。本文僅引用 §4.2 的任意執行授權類別（3.1% 的設定、已發表的安全性清單、各機制的計數），作為政策撰寫錯誤的實地證據。完整探討見 Harness Configuration Defects
• Delegation Without Trust: An Empirical Gap Analysis of Identity, Authorization, and Runtime Governance in Multi-Agent LLM Systems — Dantuluri & Sundi（兩位皆來自 VotalAI），Delegation Without Trust: An Empirical Gap Analysis of Identity, Authorization, and Runtime Governance in Multi-Agent LLM Systems，arXiv 2609.00267，2026-08-31，empirical（廠商 COI — §8 說明該公司的商業產品 LLM Shield，且其生產環境數據屬於 vendor-claim；經評估的 broker 是約 160 行的標準函式庫示範程式，並未發布）。本文引用 §5.2（四個框架的缺口及逐列方法 — 執行了 LangGraph 1.2.10、檢視了 CrewAI 1.15.13 / AutoGen 0.7.5、MCP authz rev. 2026-07-28 取自規格）、§6（分析性的九項標準表）、§7.3（兩項穩健性實驗、2,000 個情境的爆炸半徑、約 2.6 µs 的額外負荷），以及 §12（明確將其定位為與本頁論文同期進行的研究，並說明 Progent/FORGE/PAuth/AC4A 是政策引擎之下的憑證層）。完整探討見 Agent Identity Management System (AIMS)
• The Balkanization of Execution-Security Research for AI Coding Agents: Isolation, Access Control, and Time-of-Check-to-Time-of-Use Vulnerabilities — Mohammadreza Rashidi（AI and Media Analysis Lab, Berlin），The Balkanization of Execution-Security Research for AI Coding Agents: Isolation, Access Control, and Time-of-Check-to-Time-of-Use Vulnerabilities，arXiv 2607.05743，2026-07-07，empirical。**請精確理解證據層級：**論文本身可查證的工作包括經核實的 39 篇論文語料（每筆均對照其摘要頁確認，並抓出、修正兩處錯誤歸引）、經 NIST NVD 確認的四個 CVE，以及由已發布語料檔案和已發布驗證器重新推導的計數。**文中所有系統行為數字 — 69–98%、17.1%、23.8%、7.2%/5.5%/66% — 都是轉述底層論文的數據，且明確未經獨立重現（§9）。**本文引用 §4.3（六篇存取控制／能力論文）、§4.4（ShellSieve 與 YoloFS）、§4.13（OverEagerBench）、§5.1（RC3 與 RC4）、§6.2（缺口 2）、§6.4（缺口 4 — 假設政策撰寫者誠實）、§6.5（缺口 5 — 範圍擴張未受任何強制機制處理）、§10（提出的兩項重播實驗）。表 1–4 已對照 PDF 與相符內容核實
• Agentic Permissions Policy Algebra for Taint Confinement in LLM Agents — Kravchenko、Liventsev、Konstantinov、Iskhakov & Kukuy（Archestra AI，已標註廠商 COI），arXiv 2607.24625，2026-07-27，empirical。本文引用其政策撰寫與剩餘問題：§3（工具合約 — delta / emits / requires、五種前置條件，包括歷史述詞與硬性閘門）、§5（原子裁決、任務類型、回應接收端規則）、§7（joint-merger-brief 未宣告寫入副作用合約的違規，以及 hide-secret-in-status 允許資料流的違規）。完整探討見 Out-of-Band Prompt-Injection Defense
• OpenID Foundation advances authorization for the agent era with new AuthZEN Working Group Drafts — OpenID Foundation，…advances authorization for the agent era with new AuthZEN Working Group Drafts，2026 年 6 月 15 日，practitioner-opinion（提議中的 Working Group Drafts，尚未批准為規格；權重低於本文的 empirical 測量）。這是 ScopeGate 在標準制定方面的對應方案：AuthZEN Authorization API 1.0（SARC 允許／拒絕介面）、COAZ（MCP 呼叫 → SARC 設定檔）、AARP（將 CIBA 泛化的先決條件／核准模式）
• Utility Under Attack: Agent Memory Poisoning and the Limits of Content Screening and Provenance Ranking — Arulnidhi Karunanidhi（Quantify Labs Ltd — 受評估記憶層的開發者；論文未聲明 COI），Utility Under Attack，arXiv 2608.21230 v1，2026-08-21，empirical。本文僅引用其「粗略與精確」的平行案例：§6.3、表 6 與圖 2（邊際推導、絕對懲罰論點，以及語料 N 在準確率 0.0417 時的證據召回率為 0.00%）。完整探討見 Non-Malleable Memory Authority (TMA-NM) 與 Memory and Context Poisoning
• NetInjectBench: Benchmarking Indirect Prompt Injection in Tool-Using Large Language Model Agents for Network Operations — Shayoni、Shoaib、Hossain & Mridha（Wichita State University / American International University-Bangladesh），NetInjectBench: Benchmarking Indirect Prompt Injection in Tool-Using Large Language Model Agents for Network Operations，arXiv 2607.10490，2026 年 7 月，empirical。§3.1（威脅模型及其四項邊界；中繼資料完整性假設）、§3.2（130 個情境、提示／工具／受信任政策／評估欄位的分離、表 1–3）、§3.3（六個模擬工具與七種執行情境、表 4–6；確定性閘門及其備援順序）、§3.4（UTAR/UAR/BR/OBR/IOR/NR、Wilson 區間、McNemar）、§4.1（表 7 防禦階梯）、§4.2（表 8 弱與強的比較、表 9 各模型差異）、§4.3（表 10 核准變更、表 11 含 100 個實例的中繼資料壓力測試套件、表 12 良性案例）、§4.4（表 13 Wilson 信賴區間、表 14 可靠度、表 15 McNemar）、§4.5（表 16 風險類型細分 — 敏感讀取列；表 17 天真不安全動作的 186/12 分拆）、§5.5（安全性主張的範圍）、§5.6（效度威脅：合成、單步、精簡工具集、三個 7–8B 模型且溫度為 0）。依照圖像兩遍檢視規則查看圖 2 與圖 3：圖 3 完全重述表 7，圖 2 則確認閘門的階段列表（工具權限級別 → 核准狀態 → 維護時段 → 核准的工具／設備／修補程式 → CR ID → 引數驗證）及其三種結果（允許安全動作／允許已核准的高影響動作／封鎖並執行安全備援）。圖 1 與圖 4 是威脅模型示意圖，以及表 10 的重述。
• Capability Gates Are Not Authorization: Confused-Deputy Failures in LLM Agent Frameworks — David Mellafe Zuvic，Capability Gates Are Not Authorization: Confused-Deputy Failures in LLM Agent Frameworks，arXiv 2606.28679，2026 年 6 月，empirical。§II（威脅模型：信任邊界、妥協來源獨立性、承載關鍵作用的帶外政策）、§III（跨框架稽核，表 I — 固定提交版本的 LangChain/LangGraph、LlamaIndex、Stripe Agent Toolkit）、§IV（測量：部署層級與旗艦模型 ASR、任務對齊的呈現方式、表 II／圖 1 — 已驗證部署平均值 0.603，旗艦模型為 0.189）、§V（ScopeGate 五階段 PDP/PEP、圖 3 + 演算法 1、位置獨立性）、§VI（評估：LangChain/LlamaIndex PoC、靜態 0/48、調適性 0/29、良性案例零誤拒、Latam-GPT + WhatsApp 付款防護）、§VII（與 MiniScope/AP2 的定位比較）、§VIII（限制：防護≠治癒、受測試套件範圍限制、僅限公開來源）。依照圖像兩遍檢視規則查看圖 1–3；docling 顯示的空格小數（「0. 603」）僅是排版問題，與圖中一致。
• How Bridgewater Built an AI Analyst That Does Hours of Expert Research in Minutes — McManus、Ran & Weight（Bridgewater Associates），LangChain 頻道，2026-07-24，25:44 分鐘演講，case-study。引用其每位使用者各自的 harness（9:33–10:24）；產品演講中約一段文字，未描述機制、稽核或測量。另見 Bridgewater Associates
• EVOMAL: Self-Poisoning in Self-Evolving Coding Agents — Wu、Shi、Q. Li、Zhao、X. Li、Adams、Hassan & Ni（Queen's University），arXiv 2608.25776，2026-08-26，empirical。本文引用 §9.3 與附錄 D.4（定理 3 的有向隔離閘門、假設 A1-A5、位元組複製案例，以及策展者審查變體），以及 §8 的推論 1（迫使系統滅絕的兩種獨立方式 — 將複製率降至零，或將可檢索性降至零）。完整探討見 Agent Self-Poisoning (the CREATE-Path)
• GhostJacking Attacks: Half of the Fortune 500 Run These Tools. Getting Blocked by the Firewall Was the Way to Take Over Their AI Agents — Sternberg、Poran & Bobrov（Tenet Threat Labs），GhostJacking Attacks，2026-08-09，DEF CON 34 主會場，case-study（廠商撰寫，COI 已在文中處理）。本文僅引用未經提示的 DNS execute 寫入操作及攻擊者自選的引數值，以及 agent-jackstop 人工核准規則。完整探討見 Observability-Pipeline Poisoning
• A First Measurement Study on Authentication Security in Real-World Remote MCP Servers — Zhou 等人（Fudan University；一位作者任職於 Central South University），A First Measurement Study on Authentication Security in Real-World Remote MCP Servers，arXiv 2605.22333，2026-05-21，empirical，無 COI。本文僅引用一項定位觀點 — §3.2 指出 7,973 個仍在線的遠端 MCP 伺服器中，有 40.55% 未經驗證；Finding 3.2 的 F2 比率則為 119 個授權伺服器中有 12 個接受偽造的 client_id。也就是說，在通訊協定邊界上，逐次呼叫授權決策所依據的主體往往根本未被確認。解析警告及完整探討見 Remote MCP Authentication in the Wild
• Valid, But Never Issued: Session Spoofing and SSRF in Grafana MCP — Ariel Fogel（Pillar Security），2026-09-02，case-study，廠商觀點（安全廠商報告其針對受控金絲雀實例發現的問題）。引用其將 MCP-server 描述為身分 broker 的框架、兩項發現（僅檢查工作階段 ID 格式；在 v1.1.0 以可選 bearer 驗證修正，沒有 CVE；以及 X-Grafana-URL SSRF，CVE-2026-19516，CVSS 9.1，未提供修正版本），還有目的地政策的緩解措施。完整探討見 Remote MCP Authentication in the Wild。