Harness Configuration Defects

資料來源#

Scanning the Harness: An Empirical Study of Supply-Chain Defects in AI Coding-Agent Configurations

摘要#

Agent Supply Chain Risk 彙整代理程式在執行階段組合第三方產物時可能出現的問題，Write-Then-Trusted 則整理工作區組態轉變為執行的接縫。兩者都仰賴揭露資訊和事故報告；這些資料能證明失效存在，卻無法說明它有多常見。Kapner, Soceanu, Petrunin & Gartner（Red Hat / Ben-Gurion University，arXiv 2609.07360，2026-09-07，empirical）提供了基準盛行率：在會被推薦並安裝的母體中，已安裝的組態本身——.mcp.json、permissions.allow、技能 frontmatter、子代理程式檔案、已提交的設定——多常帶有缺陷。

論文將這組產物稱為代理程式的 harness，並將它視為一個相依層；這個層「出現時，沒有其他相依層後來建立的衛生習慣：沒有固定版本、沒有安裝時驗證、沒有宣告輸出的方法，也沒有跨助理的單一事實來源。」本文的核心是三項發現：

2,660 個設定中有 16.0%（95% CI 14.6–17.4）存在已確認的安全缺陷，分屬三種「嚴重性並不相同」的類別：未固定版本的 MCP 伺服器（9.8%）、看似有範圍限制、實際上預先核准任意執行的權限授予（3.1%），以及其 allowed-tools 預先核准 shell 的技能（設定中占 3.8%，集合中占 3.7%）。
三種類別中有兩種只有在組裝後才會出現。 集合中未固定版本的伺服器和任意執行授權皆為 0.0%，因為集合提供的是技能，而不是組態；shell 預先核准則朝相反方向傳遞，從已發布的技能進入每個安裝它的設定。市集掃描和組裝時掃描看到的是不同缺陷。
原始偵測器輸出會高估盛行率，而論文量出了高估幅度。 在相同六條門檻規則下，原始結果標記了 25.5% 的設定，驗證後則有 18.4% 留存。作者在結尾寫下了可廣泛應用的教訓：「從分析器原始輸出報告的比率，在發現由產生這些結果的儲存庫重新推導，並依其意義加以判讀之前，都只是分析器本身的特性。」

偵測工具與驗證流程#

harness-eval 是開放原始碼、無模型的靜態分析器（Python 套件，輸出 SARIF），能在 Claude Code、Cursor、Copilot、Gemini CLI、OpenCode、Windsurf、Cline 和 Codex 的配置中找出 harness 元件。研究採用了其中 31 條規則；只有當判定條件可由位元組決定，且其後果屬於安全暴露（S 類，15 條）、組態無法依原樣運作（Q 類，12 條）、參考用戶端可容忍但偏離 Agent Skills 規格（P 類，2 條），或助理間不一致（C 類，2 條）時，規則才會納入。判讀文字內容的啟發式規則雖隨工具一併發布，但不會出現在任何圖表中。

規則也按偵測器必須讀取的範圍分類：FILE（一個元件的位元組，20 條）、FILE_FS（檔案及其周邊目錄樹，7 條）、PAIRWISE（比較兩個元件，4 條）和 SETUP（整張元件圖）。只掃描單一檔案的市集掃描器，依其設計只能涵蓋 FILE 和部分 FILE_FS 規則。

驗證分四個階段，使用相同的儲存庫；每項發現都要通過這些階段才會計入：

在淺層複製且記錄提交版本的儲存庫上執行掃描器。
獨立重新推導——第二套實作依據每條規則的文件而非程式碼，重新複製每個被標記的儲存庫至固定提交版本，並重新評估判定條件：共在 1,115 個儲存庫中找到 8,547 項發現。
裁定歧異——以（儲存庫、規則）配對為單位；重新推導 744 組，其中 586 組直接一致，158 組交由 Claude 裁定器處理，並提供公開提示詞和固定原因代碼；640 組配對計為缺陷。
由獨立模型再次判讀——第二個模型工作階段可存取網路，且不會看到流程的判定結果；它在固定提交版本上重新檢視所有 743 組計入的配對。其異議修正了兩條規則所述的後果和少數判定，論文中的所有數據也都來自使用修正版工具重新掃描的結果。

若一條規則在至少 50 項發現中，實作一致率達到 ≥97%，且至少 80% 的配對最終判定為缺陷，就屬於門檻規則（納入主要數據）：31 條中有 6 條符合。其餘規則的統計如下：1 條暫定、6 條觀察項（判定條件重新推導成立，但後果通常是預期行為）、1 條未達一致率門檻、9 條發現數過少、8 條從未觸發。

沒有任何人工評分判定結果——兩位判斷者都是模型。論文報告了一致性統計，但表現並不均衡：對照最終表格，第二個工作階段在 743 組配對中有 93.3% 一致（κ = 0.76），其中機械式一致的 586 組有 99.3% 一致，而經裁定的 157 組有 70.7% 一致（κ = 0.23）。在涉及主要數據的 18 組經裁定配對中，它有 10 組一致；每項歧異都與範本、範例目錄或測試 fixture 內未固定版本的套件有關，論文估計這裡的政策選擇對主要數據最多影響 ≤0.3 個百分點。裁定器有九次錯誤是讀者看得出來的（誤讀 uvx 固定版本、停用的伺服器、git 子模組），而複核模型也兩度推翻自己的判斷。應將經裁定的部分視為結果中較不穩固之處，機械式一致的部分則較為可靠。

三種安全缺陷類別#

未固定版本的 MCP 伺服器（設定中占 9.8%，集合中占 0.0%）。 常見形式是 npx -y @scope/server-name，沒有指定版本；沒有標籤或摘要的 uvx 和 docker 也屬於同一情況。伺服器會以代理程式的權限執行，而且「執行登錄庫當天提供的任何內容」——每次工作階段啟動時都會解析，並非只在建置時解析。供應商文件本身就展示了這種模式。272 個重新推導的儲存庫中有 258 個一致；14 個經裁定的項目中有 2 個計入（其餘是 fixture、範本，或由專案自己的鎖定檔固定版本的套件）。**這種風險確實可觸及：**在抽樣的 40 個未固定版本設定中，有 29 個提供了會點名該伺服器或其某個工具的技能、命令或情境檔案。

看似有範圍限制的任意執行授權（設定中占 3.1%）。 像 Bash(awk:*)、Bash(python:*)、Bash(find:*) 或 Bash(sed:*) 這類 permissions.allow 項目看似狹窄，實則不然：awk 能執行 system()、python -c 能執行任何內容、find -exec 能啟動程序，而 GNU sed 有 e 旗標。這個安全類別採用一份已發布清單——shell 和包裝器、直譯器、套件執行器（npx、bunx、uvx、pipx）、有文件記載 shell 跳脫方式的工具，以及 Bash(*) 和單獨的 Bash。在 83 個設定中，有 19 個授予不受限制的 shell、54 個授予直譯器、18 個授予套件執行器、58 個授予可跳脫至 shell 的工具、10 個以名稱直接授予 shell。curl/wget（0.9%）、make/docker/ssh/編輯器（0.6%），以及單獨的 Edit/Write（1.3%）授權只列為建議，不納入統計；這條規則不判定 Bash(git:*)。授權確實會被使用——65 個安全類別設定中有 22 個提供了會呼叫獲授權工具的元件——作者指出，這「有正反兩面」：作者是否理解 Bash(python:*) 等同於 Bash(*)，「涉及的是預期，而靜態稽核無法衡量。」這正是 Capability Gating Is Not Authorization 所反對的「以命令名稱而非呼叫行為」失效模式；Write-Then-Trusted 的 GitPwned 發現曾以 CVE 發布，如今則有了母體盛行率。

預先核准 shell 的技能（設定中占 3.8%，集合中占 3.7%）。 技能的 allowed-tools frontmatter 會列出技能啟用時，用戶端無須提示就會執行的工具；如果清單包含不受限制的 Bash 或可跳脫至 shell 的命令，安裝技能就等於安裝了 shell 預先核准。121 個重新推導的儲存庫全部計入（898 個項目，一致率 100%）。這是唯一在發布時而非組裝時出現的安全類別——「市集掃描能看到的那一種。」

未達圖表門檻的項目，以及研究自行修正的一處。 0.7% 的設定會提交 .claude/settings.local.json（暫定——把某位開發者的授權從單一機器帶到每次複製的設定檔）。0.4% 會在專案設定中提交 permissions.defaultMode: bypassPermissions 或 dontAsk——研究期間，Claude Code 直到 v2.1.257 都會遵循這些設定；此後則忽略專案和本機範圍的設定。舊版用戶端以及任何會讀取該檔案的其他用戶端仍會受到影響（共 12 項發現，未達可列出數據的數量門檻）。enableAllProjectMcpServers（0.8%）另列為建議項目，因為它仍會保留工具提示。已提交的生命週期 hook 出現在6.8% 的設定中；由於目前的用戶端會在執行專案 hook 前提示，因此論文將它們列為執行介面，而非缺陷。

哪些結果未能通過驗證，以及原因#

每條通過驗證的規則都只讀取一個檔案。 四條 PAIRWISE 規則的重新推導率與 FILE 規則相同，但它們在判讀後果時失準：「兩個助理的檔案有所不同，更多時候是刻意為之。」在 71 組配對中，有 29 組被判定為跨助理情境檔案差異；在 22 組中，有 8 組是 MCP 宣告不同。跨檔案規則失準的原因，是被參照的檔案存在於檢查無法看到的地方——執行時建立、提供其他專案使用的範本，或另一個外掛中的技能。論文建議針對各類失準情況建立慣例（宣告每台機器的匯入、範本目錄、外掛相依性、內部網路），而不是改良偵測器。

研究動機中的 SETUP 層級缺陷並不存在。 一個會讀取憑證的元件若有委派邊連到具備網路能力的元件，就會在 6 個儲存庫觸發；作者全都重新人工檢視，其中一個是計算 token 數量的例程，其餘則是把 API 金鑰傳給簽發該金鑰的供應商。語料中沒有任何儲存庫呈現憑證外洩至網路的路徑。 作者從中得出的工具教訓是：從文字推測出的邊「會憑空製造出分析器正要尋找的資料流」，因此提及某個項目最多只能當作低信心訊號。

參照規則對其字面主張判斷正確，對實際意義的判斷則錯誤。 技能本文中無法解析的路徑，出現在 33.1% 的設定和 64.0% 的集合中；按後果判讀，這些發現約分為不存在的路徑（~45%）、實際檔案位於錯誤路徑（~20%），以及技能在使用專案中將會建立的檔案（~40%——這是來源中的分類比例，加總超過 100%，其分類精確度也未經測量）。技能格式都沒有提供讓作者宣告輸出的方法，因此論文最重要的一項建議是加入 creates: frontmatter 欄位。

規格與用戶端。 2.3% 的設定和 3.5% 的集合提供了沒有 frontmatter 區塊的 SKILL.md；另有 0.2% 的設定缺少 description。偵測工具及論文第一版將後果描述為「技能永遠不會載入」。獨立判讀提出異議，而 Claude Code 文件也支持這個看法：所有欄位都是選填，名稱預設為目錄名稱，描述預設為第一段文字，沒有區塊的檔案也會以技能文字載入。因此，實際測得的是參考用戶端不會強制執行、作者也不遵循的規格——「參考用戶端不強制執行的有效性規則，作者也不遵循。」沒有描述的子代理程式（設定中占 0.8%）則相反：用戶端會跳過它，只在偵錯記錄中寫下原因，所以它雖然存在，卻永遠不會被委派工作。

被推薦不代表經過審查。 從社群整理推薦清單中發現的 2,100 個設定，有 18.9% 帶有已確認缺陷；整體設定的比例則為 18.4%。

各項修正由誰負責#

論文把每項發現分派給能採取行動的一方（其 Table 4）：

發現	負責方	建議
未固定版本的 MCP 伺服器	MCP、用戶端	為伺服器宣告提供鎖定檔（含摘要的解析後 manifest）；對未固定版本的 `npx`/`uvx`/`docker` 發出警告或拒絕執行
看似有範圍限制的授權	Claude Code	提供能辨識直譯器的權限介面：將 `Bash(python:*)` 顯示為「任何命令」
預先核准 shell 的技能	市集、Skills spec	安裝時顯示 `allowed-tools`；要求使用有範圍限制的形式
已提交的提示繞過設定	用戶端	拒絕專案範圍內的 `defaultMode` bypass，就像 Claude Code 自 v2.1.257 起的做法
不符合規格的技能	Skills spec、用戶端	載入時強制要求必要欄位並明確說明，或從規格中移除這些欄位
預計輸出的參照	Skills spec、AAF	增加 `creates:` frontmatter 欄位
情境檔案差異	AAF、用戶端	採用單一事實來源；用戶端應遵循 `@AGENTS.md` 匯入
原始率與確認率的差異	工具作者	發布盛行率之前重新推導發現

對團隊而言：在發布時檢查集合（frontmatter、allowed-tools），在引入元件的提交流程中檢查組態（伺服器、授權、差異）。靜態閘門是健康檢查和安裝時防護措施，不是效能測量——論文引用 ACES（arXiv 2608.20614，本知識庫未收錄）研究指出，在 145 項技能中，結構掃描與實測技能效果的相關係數為 0.14；這正是 Skill Lift 式即時消融與這類掃描互補而非互相取代的原因。

這項研究沒有證明什麼#

未測量召回率。 驗證只檢查發現是否屬實，沒有檢查是否找出所有缺陷；每項主要數據都是六條門檻規則所能呈現情況的下限，而門檻規則集合偏向那些後果可由位元組直接推得的規則。
語料呈現的是供給端。 研究透過清單、市集、主題和 README 探索儲存庫，因此有意讓宣傳代理程式工具的儲存庫占較高比例。作者預期，依路徑建立、涵蓋私人用途 harness 的語料會使未固定版本伺服器的比率上升。私人企業組態完全不在研究範圍內。
後果會隨時間改變。 用戶端若改變對某欄位的處理方式，盛行率的意義也會改變；bypassPermissions 的變更在研究期間落地。
第二套實作來自同一團隊，所以兩套實作可能共同誤讀某種格式而未被發現。
本文沒有記錄任何漏洞利用或事故。 它衡量的是前置條件；Agent Supply Chain Risk 收錄的是前置條件實際被利用的案例。

關聯文章#

Agent Supply Chain Risk — 本文為該頁威脅目錄提供組態層級的基準盛行率。該頁的 MCP rug-pull 和技能市集攻擊是已遭利用的形式；未固定版本伺服器占 9.8%，代表有多少設定會在下次啟動時直接使用遭 rug-pull 的伺服器，完全不需要更新步驟；集合中有 3.7% 預先核准 shell，則是讓遭植入木馬的技能無須提示即可執行的前置條件
Write-Then-Trusted — 為該頁只能證明存在的接縫補上儲存庫規模的盛行率數據：6.8% 的設定提交了生命週期 hook，0.4% 提交了提示繞過設定，0.7% 提交了每台機器專屬設定；命令名稱 allowlist（Failure Mode 3）的測得比例為 3.1%
Capability Gating Is Not Authorization — Bash(python:*) 是最純粹的以工具名稱執行能力門檻：授權列出一個執行檔，並核准它的所有呼叫。54 項直譯器授權和 58 項 shell 跳脫授權，正是越界、以呼叫層級執行的授權政策必須取代的對象
Agent Context Files — SKILL.md 的規格與用戶端差異：參考用戶端會載入參考驗證器拒絕的內容，作者則不會收到任何提示。也涵蓋多助理的情況（17.5% 的設定配置了不只一個助理），以及跨助理差異的負面結果；這些差異大多是刻意為之
Skill Lift — 技能閘門的另一半。本文的規則能判定技能違反規格或預先核准 shell，卻無法判斷技能是否有幫助；文中引用的 ACES 研究顯示，結構掃描與實測效果的相關係數為 0.14
Security Debt of Agent-Generated Code — 同一種未固定版本相依性的氣味出現在上一層：該文中的代理程式會在儲存庫建置設定寫入可變標籤（82.3% 的氣味），本文則是開發者在代理程式自己的組態中宣告未固定版本伺服器。兩文也都指出偵測器精確度問題——前者的 LLM judge 召回率為 0.775，本文則是原始規則集高估了 7 個百分點
MCP and Computer Use — 這項協定沒有等同鎖定檔的機制，供應商文件展示的正是未固定版本的形式
Zero Trust for AI Agents — 該框架建議「驗證 MCP 伺服器並自行簽署」，但母體中每十個設定就有一個完全未固定伺服器版本（hub）
Claude Code — 在偵測到的助理組態中占 1,887 個；其權限用語、技能載入器和 bypassPermissions 範圍，與論文建議最直接相關

開放問題#

六條門檻規則的召回率是多少？由人類評分 158 組經裁定配對，會讓任何主要數據改變嗎？研究產物附有表格和評分腳本，因此這項工作成本不高：兩個模型在經裁定部分的一致性僅為 κ = 0.23，目前還沒有人類參與評分。
未固定版本 MCP 伺服器在私人用途 harness 中的比率，是否如作者預測般更高？以路徑為基礎建立語料（納入每個含有 .mcp.json 的儲存庫，而非只納入宣傳自身工具的儲存庫），或使用已發布工具掃描企業內部環境，都能確認趨勢。
是否會有用戶端或 MCP 專案提供伺服器鎖定檔或能辨識直譯器的權限呈現介面？之後相應比率是否下降？研究期間的 bypassPermissions 變更可作為先例——用戶端預設值改變後，已提交的設定便不再生效。觸發條件：Claude Code 或 MCP 發布新增任一控制措施的版本，並使用已發布工具重新掃描。

資料來源#

Scanning the Harness: An Empirical Study of Supply-Chain Defects in AI Coding-Agent Configurations — Benjamin Kapner、Carmel Soceanu、Alicia Petrunin 和 Hofni Gartner（Red Hat；Kapner 亦隸屬 Ben-Gurion University），Scanning the Harness: An Empirical Study of Supply-Chain Defects in AI Coding-Agent Configurations，arXiv 2609.07360，2026-09-07，empirical，10pp。引用章節：摘要和 §1（研究框架、主要比率）、§3（工具、範圍分類、語料與分層、三階段驗證、等級）、§4.1–4.7（各類發現、參照分類、缺少外洩路徑、設定與集合）、§5（建議和引用的 ACES 相關性）、§6（效度威脅及模型間一致性統計）、Table 4（負責方）。**解析註記：**使用 docling 解析 PDF（confidence_grade: excellent）；Tables 1、2、3 和 5 均完整讀取為表格，本文引用的每個儲存格都能與內文對照（Table 2 各規則和聯集比率均於 §4 重述；Table 5 的 260/121/83/22 項數量符合 §4.2–4.3；Table 1 的 20+7+4 加總為 31）。Figure 1 重述 Table 2，未另行開啟。**解讀主要數據：**25.5% 的原始比率，是與相同六條門檻規則下 18.4% 的任一已確認發現聯集比率相比，不是與 16.0% 的安全缺陷比率相比；§1 中 96.8% 的原始比率則涵蓋驗證前的全部 31 條規則。來源內部有一組配對數量差異（§3 為 744 組配對／158 組經裁定，§6 為 743／157），不影響主要結論。Red Hat 提供了這套工具；研究結果並非產品銷售宣傳"