AI 代理的治理難題：當自主安裝成為常態，我們需要的不只是更好的模型，而是更穩固的系統

AI 代理（AI Agent）自主編寫程式、安裝套件與執行指令的能力，正推動一場生產力革命，但也同時為潛在的災難敞開大門。真正的風險，已不再只是模型是否會被巧妙的提示（prompt）所欺騙，而是當一個缺乏人類直覺與警覺性的代理，獲得了在系統中自主行動的權力時，我們該如何有效治理。我的觀察是，解方並非追求一個永遠不會犯錯的「超級智慧」，而是必須回歸軟體工程中那些經過驗證、穩定可靠的「枯れた技術」（Kareta Gijutsu），將白名單、審核閘門、策略即程式碼與沙箱隔離，建構成為 AI 系統預設的基礎設施。

AI 代理如何加速供應鏈攻擊？想像 2026 年的場景

想像一個發生在 2026 年的場景：一個開發者代理被賦予任務，要為一個數據分析專案添加新功能。在分析過程中，代理判斷需要一個新的 Python 套件來處理特定格式的資料。它在 PyPI（Python Package Index）上搜尋，找到了一個名為 `pandas-pro` 的套件，下載數和說明看起來都相當合理。然而，這其實是一個惡意攻擊者上傳的「typosquatting」套件，偽裝成知名套件 `pandas` 的增強版。

一個有經驗的人類開發者可能會對這個陌生的名稱產生警覺，花幾分鐘檢查其來源與社群評價。但 AI 代理的目標函數是「完成任務」，它缺乏這種源於經驗的「直覺式懷疑」。於是，它執行了 `pip install pandas-pro`，惡意程式碼隨之進入系統，悄悄竊取內部的數據與憑證。這類軟體供應鏈攻擊並非危言聳聽，根據 Sonatype 的《軟體供應鏈狀況報告》，過去三年中，這類攻擊平均每年增長 742%。當執行安裝指令的主體從人類變成數以千計、日夜不休的 AI 代理時，這個攻擊面將會呈指數級擴大。

為什麼單靠模型改良無法解決根本問題？

一個常見的直覺反應是：我們能否訓練出更「聰明」、更「謹慎」的 AI 模型，讓它能自行辨識這些陷阱？雖然模型安全性的研究至關重要，例如防範間接提示注入（Indirect Prompt Injection）等攻擊，但將所有希望寄託於模型本身，是一種危險的簡化。

原因有三：

• 攻擊手法的不對稱性：攻擊者總是在不斷創造新的詐騙與偽裝技巧，防守方永遠處於被動。要讓模型能辨識所有潛在威脅，幾乎是不可能的任務。
• 目標函數的內在衝突：代理的核心驅動力是效率與任務完成度。過度的謹慎可能會被視為一種「效能不彰」，導致其在最佳化過程中被減弱。
• 權力與能力的脫鉤：問題的根源不在於代理「做錯了決定」，而在於它「擁有做出這個決定的權力」。我們給予了一個強大但天真的行動者過高的權限，卻沒有建立相應的監督與制衡機制。

我們的目標不應是打造一個永遠不會犯錯的 AI，而是建立一個即使 AI 犯錯，其後果也能被控制在最小範圍的系統。

我們該如何治理 AI 代理？導入「枯れた技術」的四大支柱

與其追求完美的模型，我們更應該借鏡數十年來在 DevOps 與系統安全領域發展成熟的治理框架。這些看似傳統、甚至有些「過時」的技術，正是在高度自動化環境中維持穩定的基石。針對自主 AI 代理，我認為以下四大支柱缺一不可：

1. 白名單機制（Whitelisting）：預設規則是「全部禁止，除非明確允許」。只有經過團隊審核、確認安全的套件、API 端點或可執行指令，才能被代理使用。任何不在白名單上的請求都應直接被拒絕。
2. 策略即程式碼（Policy-as-Code）：將治理規則程式碼化，透過像 Open Policy Agent (OPA) 這樣的工具，自動化地強制執行安全策略。例如，我們可以定義一條規則：「禁止任何 AI 代理在生產環境中安裝未經簽署的套件」。
3. 審核閘門（Approval Gates）：對於高風險操作，系統應自動暫停代理的執行流程，並通知人類進行審核。這就是「人在環」（Human-in-the-loop）的現代實踐。例如，使用 LangGraph 這類框架的 `interrupt`（中斷）功能，可以在代理決定安裝一個新套件時，暫停工作流程，等待開發者在 Slack 或其他協作工具中點擊「批准」。
4. 沙箱化執行環境（Sandboxed Execution）：所有由代理執行的程式碼，都必須在一個與主系統嚴格隔離的沙箱環境中運行。這能大幅限制潛在惡意程式碼的破壞半徑。AWS 的 Firecracker 就是一個很好的例子，它能在極短時間內（通常少於 125 毫秒）啟動一個輕量級的 microVM，提供強大的隔離性。

將這四個支柱結合起來，我們就能建構一個更具韌性的 AI 協作系統。這套縱深防禦體系，遠比單純寄望 AI 自身更為可靠。

想像一下，當代理試圖安裝不在白名單上的 `pandas-pro` 時，Policy-as-Code 會立即攔截這個行為，LangGraph 則觸發一個審核請求給人類。即便人類審核員不慎批准了，該套件也只會被安裝在一個短暫、沒有網路權限的 Firecracker 沙箱中，無法對核心系統造成實質傷害。

隨著 AI 代理從實驗室走向生產環境，我們面臨的挑戰正在從「模型能力」轉向「系統治理」。與其不斷追逐更強大的模型，不如現在就開始打好基礎，將這些成熟、穩健的治理原則融入我們的 AI 基礎設施。唯有如此，我們才能在享受自主代理帶來的高效率時，確保整個系統的穩定與安全。

延伸閱讀

• AIエージェントを統制する4つの柱——LangGraph interrupt と Firecracker で作る2026年版 (原始靈感來源)
• A Survey on Large Language Model (LLM) Security and Privacy (關於 LLM 安全性的綜合性學術論文)
• Software supply chain security for dummies (Google Cloud 對軟體供應鏈安全的入門介紹)

我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。