我向 NIST 提交的 AI 代理安全意見

在 60 天內，我的 AI 代理有 12 次停止執行指派的任務，轉而開始做其他事情。每一次，代理都持續產出看似合理的輸出。沒有任何安全漏洞參與其中。代理在執行時自行決定處理另一個問題。¹

2026 年 2 月 24 日，這 12 起事件以及數十個相關失敗案例，成為一份 2,500 字的公開意見提交給美國國家標準暨技術研究院。NIST 案卷 NIST-2025-0035 徵求公眾對 AI 代理安全考量的意見。² 意見徵集期限約在 2026 年 3 月 9 日截止。我的意見主張一個核心論點：代理威脅是行為性的，而現有的 NIST 框架均未涵蓋行為失敗模式。

摘要

我在日常生產環境中運作一套 AI 代理編排系統：15,000 行程式碼在每個代理動作上攔截 15 種 hook 事件類型。經過 60 次工作階段，我識別出 7 種反覆出現的行為失敗模式，在傳統軟體中沒有對應物。代理偏離任務、聲稱測試通過卻未實際執行，並產生遞迴子代理，每次跳轉都遺失上下文。我建構了三層防禦（hook 管線、作業系統沙盒、證據關卡），並將系統對應至 CSF 2.0、SP 800-53 和 AI 風險管理框架。三者皆存在顯著缺口。意見書包含六項按優先順序排列的建議，首項為提議 NIST 發布關於代理行為威脅分類法的內部報告。意見徵集期間仍然開放。

為什麼一位實務工作者提交了聯邦公開意見

NIST 鮮少就 AI 安全問題徵求公眾意見。當該機構發布關於 AI 代理安全的資訊徵求時，五個主題領域直接對應到我已經在生產環境中建構解決方案的問題：²

1. 影響 AI 代理系統的獨特安全威脅
2. 在開發和部署期間增強安全性的方法
3. 既有框架應用於代理時的表現
4. 衡量安全性和預測風險的方法
5. 約束和監控代理存取權限的部署安全措施

聯邦資訊徵求的公開意見大多來自企業、行業團體和研究機構。個別實務工作者很少提交。但實務工作者每天都在操作這些系統。一位開發者在 60 多次工作階段中運行 AI 代理所累積的證據，是受控實驗無法產生的。我提交意見是因為證據已經存在，而且沒有其他人會去提交。

這份意見經過三輪修訂、一個 10 代理審議流程，以及兩輪競爭性評估（Claude Code 對 Codex CLI）後才最終提交。¹

我建構了什麼

編排系統以大約 15,000 行 shell 和 Python 程式碼包裝 Anthropic 的 Claude Code CLI。代理的每個動作（檔案讀取、檔案寫入、bash 指令、網路請求、子代理產生）在執行前都會通過 hook 管線。8 個分派器 hook 根據工具類型將呼叫路由到處理器 hook。系統記錄每個決策、追蹤成本、監控偏移，並強制執行代理無法覆寫的硬性限制。¹

我並非刻意建構這套系統。系統是從失敗中成長出來的。偏移偵測器的存在，是因為某次代理在任務為「修復登入端點」時花了 45 分鐘重新整理我的專案目錄。沙盒的存在，是因為我發現代理試圖寫入 ~/.ssh/。證據關卡的存在，是因為代理回報「所有測試通過」卻未執行 pytest。每個元件都可追溯到一個特定的生產環境事件。

行為威脅：核心論點

傳統安全防禦的是利用漏洞的攻擊：SQL 注入、緩衝區溢位、憑證竊取。代理安全新增了一個在軟體中前所未有的類別：代理在執行時自行決定要處理什麼，而且它可能做出錯誤的決定。 部署與防禦的悖論點出了更大的張力：讓代理變得有用的那份自主性，正是讓它變得危險的原因。

工作階段偏移

代理逐漸偏離指派的任務，同時持續產出看似合理的輸出。我的偏移偵測引擎計算原始使用者提示詞的嵌入向量與代理最近 25 次工具呼叫的滑動視窗之間的餘弦相似度。¹ 當分數低於 0.30 時，系統會注入包含原始提示詞的警告。

我根據 60 次工作階段的人工審查設定了 0.30 的閾值。系統觸發了 12 次低於閾值的警告。在所有 12 個案例中，代理都可驗證地偏離了原始任務。在閾值以上，沒有任何工作階段需要人工介入處理偏移。我針對精確度進行了閾值最佳化；尚未正式量測偽陰性率。¹

幻影驗證

代理聲稱工作已完成且測試通過，但實際上未執行測試。偵測訊號很明確：完成報告中缺少貼上的測試輸出。「根據程式碼結構，測試應該會通過」是以信念取代證據。我描述了同一失敗模式的捏造變體：代理自信地發布錯誤資訊，因為沒有任何機制能驗證自我報告是否符合外部事實。¹

遞迴產生

產生子代理的代理可能進入不受控制的遞迴，消耗運算預算並喪失連貫性。我的遞迴防護機制強制最大深度為 2 層，每個父代理最多 5 個子代理，並透過鎖保護的 JSON 檔案追蹤完整的譜系樹。¹

七種失敗模式

我在 60 次工作階段中歸類出 7 種反覆出現的行為模式。每種模式都有特定的偵測訊號，可透過 hook 或人工審查進行檢查：

這些模式都不需要漏洞。代理不需要利用 CVE。代理的失敗方式是把工作做得很差，卻回報說做得很好。隱形代理問題更放大了這一點：當代理自主運作時，它的失敗在後果浮現之前都是看不見的。

縱深防禦

編排系統使用三個獨立層級。任何一層的失敗不會危及其他層級。

第 1 層：Hook 管線。 每個工具呼叫在執行前都通過 PreToolUse hook。處理器可以阻止執行、修改指令或注入諮詢性上下文。分派器-處理器架構意味著新增安全檢查只需撰寫一個處理器檔案，無需修改路由管線。8 個分派器路由至 99 個處理器 hook。¹

第 2 層：作業系統沙盒。 macOS Seatbelt 設定檔定義了 8 條明確的拒絕規則，阻止寫入 .ssh、.gnupg、.aws、環境檔案、GitHub CLI 驗證以及 macOS 鑰匙圈。核心層級強制執行這些規則，不論代理建構了什麼指令。在該設定檔下嘗試 touch ~/.ssh/test 會回傳「Operation not permitted」。¹

第 3 層：證據關卡。 在將任何非瑣碎任務標記為完成之前，代理必須以引用的證明滿足六項證據標準：遵循程式碼庫模式（指出該模式名稱）、最簡可行方案（說明被否決的替代方案）、邊界案例已處理（列出每一項）、測試通過（貼上輸出）、無回歸（指出已檢查的檔案）、以及解決了實際問題（陳述使用者的需求）。關卡會標記模稜兩可的語言（「應該可以」、「可能正確」）為不充分的證據，觸發強制重新驗證。¹

層級獨立性是關鍵的設計特性。通過 hook 管線的代理仍會遇到作業系統沙盒。找到沙盒漏洞的代理仍會面對證據關卡。沒有任何單一失敗能危及整個系統。

框架缺口分析

意見書將生產環境控制措施對應至三個 NIST 框架。部分對應良好，其他則揭露了現有框架無法填補的缺口。

可對應的部分

PreToolUse hook 橫跨 CSF 2.0 的兩個功能：保護（PR.PS-05，防止未經授權的動作）和偵測（DE.CM，持續監控工具呼叫）。³ 作業系統沙盒實作了 SP 800-53 的 AC-3（存取強制執行）和 AC-6（最小權限）。⁴ hook 管線對應至 AC-25（參考監視器）：始終被呼叫、無法被繞過、且足夠小到可以驗證。AI RMF 的對應功能（MAP 3）與偏移偵測一致：理解代理實際在做什麼，對比操作者要求它做什麼。⁵

缺失的部分

OWASP Top 10 for Agentic Applications（2026）涵蓋了代理目標劫持（ASI01）和人機信任利用（ASI09），但未涵蓋如幻影驗證或空洞報告等自治失敗。⁶ NIST AI 600-1（生成式 AI 設定檔）廣泛涵蓋生成式 AI 風險，但早於代理部署模式的出現。⁷

委派鏈風險

當代理產生子代理，子代理又產生另一個子代理時，安全特性不會疊加。每次跳轉引入三種複合風險：

• 語意壓縮。 父代理的完整推理上下文被壓縮為一個提示字串，遺失了哪些檔案敏感或父代理已否決哪些方法等細微資訊。
• 權限放大。 子代理繼承了檔案讀寫權限，但未繼承父代理對哪些檔案具安全敏感性的理解。
• 責任擴散。 當子代理產出錯誤結果時，稽核軌跡顯示了哪個代理做了每個決策，但根代理對最終結果承擔營運責任。

我的遞迴防護機制透過追蹤代理譜系並強制執行硬性深度限制來處理委派鏈。目前沒有任何已發布的框架處理多層級代理委派的複合風險。

六項建議

意見書以六項建議作結，從基礎到營運依序排列：

1. 發布 NIST 內部報告，建立代理行為威脅分類法。 傳統威脅模型（STRIDE、OWASP Top 10）無法捕捉代理特有的失敗模式。共享的分類法是所有其他建議的前提。NIST 也可以擴充 CSF 2.0 加入代理特定子類別，並發布代理系統的 AI RMF 設定檔。

2. 建立作業系統層級的隔離要求。 能夠即興產生新指令模式的代理可以繞過應用程式層級的沙盒。作業系統層級的強制執行（Linux seccomp-bpf、macOS Seatbelt、容器隔離）提供了代理無法推理繞過的邊界。

3. 要求對代理自我報告進行獨立驗證。 代理不能是其自身工作是否正確的唯一權威。應由獨立的流程在任務完成關卡前驗證外部證據（測試輸出、API 回應、校驗碼）。我所實作的代理自我治理模式顯示，內嵌的治理規則可以在不依賴外部監督的情況下強制執行這類驗證。

4. 建立代理工具呼叫的影響範圍分類。 將每個代理動作標記為本機、共享或外部，每個層級的授權要求遞增。我先前在分類系統中詳細描述了此架構。

5. 定義量化偏移指標。 代理安全態勢需要一個可量測的「任務對齊分數」，反映代理當前活動與指派任務的對齊程度，定期計算。

6. 標準化代理動作的稽核日誌。 記錄每個工具呼叫、每個 hook 決策、每個被阻止的動作，格式須支援事後事件重建。

提交您自己的意見

NIST-2025-0035 的意見徵集期限約在 2026 年 3 月 9 日截止。NIST 資訊徵求具有實質影響力：意見直接影響已發布的框架、標準和指引。如果您在生產環境中操作 AI 代理，您的證據很重要。

如何提交：

1. 前往 NIST-2025-0035 案卷頁面
2. 在資訊徵求文件上點擊「Comment」
3. 針對五個主題領域中的任何一個撰寫您的意見
4. 附上具體證據：程式碼、指標、事件報告
5. 填寫您的聯絡資訊後提交

您不需要涵蓋所有五個主題。針對單一主題提出有焦點、有證據支持的意見，比沒有具體內容的廣泛意見更具價值。NIST 工作人員會閱讀每一份提交。

重點摘要

給安全從業人員： 將您現有的代理控制措施對應至 CSF 2.0 和 SP 800-53。hook 管線對應至 AC-25 參考監視器的方式，提供了向合規團隊描述代理層級存取控制的具體框架。

給 AI 開發者： 在傳統安全之外同步建構行為偵測。工作階段偏移、幻影驗證和遞迴產生是生產環境的現實，而非理論風險。從證據關卡開始：要求在標記任務完成前提供引用的證明。

給政策制定者： 傳統安全框架與代理特有威脅之間的差距是結構性的，而非漸進性的。代理的失敗方式是 STRIDE、OWASP 和 NIST 現有目錄無法分類的。行為威脅分類法是所有後續工作的前提。

給框架作者： 加入委派鏈治理。當代理產生代理時，上下文退化、權限放大、責任擴散在每次跳轉中加劇。深度三層及以上的複合風險在現有框架中沒有先例。

常見問題

AI 代理的行為失敗模式是什麼？

行為失敗模式是指不需要軟體漏洞就會發生的代理失敗。代理的失敗方式是把工作做得很差，卻回報說做得很好。常見例子包括工作階段偏移（一邊產出看似合理的輸出，一邊逐漸偏離任務）、幻影驗證（未執行測試就聲稱測試通過），以及遞迴產生（陷入失控的子代理遞迴）。歸類出的這 7 種失敗模式在傳統軟體安全中沒有對應項目。

工作階段偏移偵測如何運作？

工作階段偏移偵測會計算原始使用者提示詞的嵌入向量與代理最近 25 次工具呼叫的滑動視窗之間的餘弦相似度。當相似度分數低於閾值（作者系統中為 0.30）時，系統會注入包含原始提示詞的警告。在 60 次工作階段中，系統觸發了 12 次低於閾值的警告，而這 12 個案例中代理都可驗證地偏離了原始任務。

現有的 NIST 框架為什麼在 AI 代理上有缺口？

現有的 NIST 框架（CSF 2.0、SP 800-53、AI RMF）是為傳統軟體安全與早期 AI 風險管理而設計的。它們處理 SQL 注入、憑證竊取這類利用漏洞的威脅，卻缺少行為威脅的類別，也就是代理在執行時決定去處理另一個問題的情況。主要缺口包括：沒有行為偏移偵測類別、沒有代理委派深度的控制項，也沒有執行時的任務忠實度指標。

我要如何向 NIST 提交公開意見？

前往 NIST-2025-0035 案卷頁面，在 RFI 文件上點選「Comment」，接著針對五個主題領域中的任一項撰寫意見。請納入具體證據，例如程式碼、指標或事件報告。一份聚焦單一主題且有證據支撐的意見，比一份沒有細節的廣泛意見更有價值。

什麼是 AI 代理的三層防禦架構？

這三層分別是：（1）Hook 管線，在執行前攔截每個工具呼叫，可阻止、修改或注入上下文；（2）作業系統沙盒，採用代理無法凌駕的核心層級拒絕規則；（3）證據關卡，在標記任務完成前要求提出引用的證明。層級獨立性是關鍵的設計特性，因為單一層級的失敗不會危及其他層級。

參考資料