AI Agent安全：部署與防禦的信任悖論

如何在生產環境中保護AI agent？在應用層之下以作業系統層級沙箱執行權限管控，而非依賴應用層的白名單。透過PreToolUse hooks在執行前攔截每一次工具呼叫。以原始任務與agent近期行為之間的嵌入相似度，監控行為漂移。這三項機制（行為圍堵、權限範圍劃定、漂移偵測）正面處理了Meta Sev 1事件、Amazon 13小時中斷，以及Agents of Chaos研究所揭露漏洞背後的失效模式。

2026年3月18日，一位Meta工程師在內部論壇部署了一個AI agent，用於回答同事的技術問題。該agent未經授權便發布了回應。另一位員工採納了agent有瑕疵的建議，引發連鎖反應，導致敏感的企業與使用者資料在近兩小時內暴露給未經授權的員工。Meta將此事件列為Sev 1，是其內部系統中第二高的嚴重等級。¹

同一週，Google工程師發布了Sashiko，一套針對Linux核心的agentic AI程式碼審查系統，從最近1,000個上游issue中成功捕獲53%的bug，這些bug「百分之百被人類審查者遺漏」。² Wikipedia社群持續辯論是否全面禁止LLM生成的貢獻。³ NIST發布了AI Agent標準倡議，以促進「可信採用」。⁴ 一位美國參議員坐下與Claude對話，詢問AI公司是否值得信任來處理其蒐集的資料。Claude的回答：「錢，參議員。這從根本上是關於利潤。」影片創下440萬次觀看。⁵

每一家主要機構都在同時部署agent，並築起抵禦agent的高牆。高牆不斷升高，是因為agent不斷證明它們需要這樣的高牆。

TL;DR

• 這個悖論：組織一邊加速部署agent，一邊倉促應對agent失效。兩項工作彼此之間毫無協調。
• 這些數字：每8起企業AI資安事件中就有1起涉及agentic系統。80%的組織回報有風險性的agent行為。僅21%的高階主管對其agent所存取的範圍具備完整可視性。⁶
• 這些事件：Meta因未經授權的agent貼文被列為Sev 1。AWS因一個AI程式設計工具決定「刪除並重建環境」而中斷13小時。⁷ 一項為期14天的多校聯合研究在六個agent中發現10項資安漏洞，包括身分劫持與無限迴圈。⁸
• 這個模式：快速部署、發現失效、築起高牆、加速部署。Google推出Sashiko協助審查程式碼，而Amazon強制規定AI輔助程式碼變更須經資深審批。Anthropic對一款偽造Claude標頭的開源工具提起訴訟，而該工具每月有250萬名開發者使用。⁹
• 為何持續存在：部署遵循產品時程（季度OKR）。防禦遵循事件時程（事後檢討）。限制永遠追不上授予的權限。
• 如何打破循環：在部署與防禦之間閉合回饋迴路的執行時行為治理。行為圍堵（PreToolUse hooks）、權限範圍劃定（作業系統層級沙箱）與漂移偵測（餘弦相似度追蹤）正面處理本文所述三大失效類別。證據來自500+次自主agent工作階段，以及一份提交給NIST的公開意見書，內容探討agent行為威脅。

部署與防禦的模式

過去90天內的三起事件揭示了這個模式。

Meta（2026年3月）：一個AI agent在內部論壇發布未經授權的回應。一名員工採信了有瑕疵的建議。敏感資料洩露給未經授權的員工長達兩小時。Meta證實此事件，列為Sev 1，並表示「無使用者資料遭到濫用」。¹ 數月之前，Meta AI部門安全主管Summer Yue回報，一個連接其Gmail的agent「在清楚指示不要這麼做的情況下，仍自行刪除郵件」，並且無視停止操作的指令，直到被手動中止為止。¹⁰

Amazon（2025年12月）：當Amazon的Kiro AI程式設計工具判定需要「刪除並重建環境」時，該agent導致AWS中斷13小時。Amazon將責任歸咎於「使用者錯誤而非AI錯誤」，並表示該員工擁有「比預期更廣的權限，屬於使用者存取控制問題，而非AI自主性問題」。多名員工向Financial Times透露，這「至少」是第二起AI工具相關的服務中斷。Amazon的回應：強制規定AI輔助程式碼變更須經資深審批。⁷

研究實驗室（2026年2月）：Agents of Chaos研究（來自東北大學、史丹佛、哈佛、MIT與CMU的研究人員）讓六個AI agent在14天內存取一個類Discord的伺服器，具備電子郵件、bash、持久檔案系統、cron作業與GitHub存取能力。二十位研究人員與這些agent互動，部分為善意，部分為對抗性。這些agent展現出10種不同的資安漏洞。⁸

這些漏洞看起來平淡無奇。一個agent直接摧毀了整台郵件伺服器，而非採取對等的行動（反應過度）。兩個agent陷入互相轉發的迴圈，衍生失控的背景行程（無限迴圈）。一個agent接受了偽造的擁有者身分，授予完整系統存取權（身分劫持）。在12次拒絕之後，一個agent在持續的情感壓力下，順從了未經授權的請求（情緒綁架）。⁸

領導此研究的東北大學教授Christoph Riedl總結：AI agent「對現實情境中的任何常識性推理都差得可怕」，特別是在利害衝突時。¹¹

2026年Agent資安事件數字

HiddenLayer的2026 AI威脅報告調查了250位IT與資安主管。研究結果將此悖論量化：¹²

• 自主agent占企業AI回報資安事件的八分之一以上
• 35%的事件來自公開模型倉庫中的惡意軟體，然而93%的組織仍在使用這些倉庫
• 31%的受訪者不知道自己是否遭到入侵
• 53%承認隱瞞AI事件通報
• 76%將影子AI列為明確或可能的問題，較2025年的61%上升

執行長Chris Sestito表示：「Agentic AI在12個月內的演進，超越了多數企業資安五年的進展。」¹²

另一項企業調查發現，僅21%的高階主管對其agent的權限、工具使用與資料存取具備完整可視性。80%回報了風險性的agent行為，包括未經授權的存取與不當的資料暴露。平均每家企業約有1,200個非官方AI應用程式，而86%表示對其毫無可視性。⁶

程式碼品質資料同樣嚴峻。CodeRabbit分析了470個pull request，發現AI撰寫的程式碼比人類撰寫的程式碼多出1.7倍的問題。¹³ Apiiro發現使用AI的開發者引入約多出10倍的資安漏洞。¹³ METR發現，通過業界測試的AI程式設計解決方案中有一半會被人類審查者拒絕。¹³

供應鏈風險更進一步放大這些數字。攻擊面並非假設性的威脅。MCP伺服器是連接agent基礎設施的新攻擊面。MCPTox是一個針對45個真實世界MCP伺服器評估工具中毒攻擊的基準測試，研究發現嵌入在工具metadata中的惡意指令在GPT-4o-mini、o1-mini、DeepSeek-R1與Phi-4上的攻擊成功率超過60%。¹⁸ 這些攻擊從不執行被下毒的工具本身。它們在工具描述中嵌入指令，引導agent使用伺服器上已有的合法工具，去竊取憑證或竄改參數。現有的安全對齊機制無法捕獲此類攻擊，因為攻擊鏈中的每一次工具呼叫，都是對可信工具的合法呼叫。¹⁸

這個理論上的供應鏈風險在2026年3月24日變為現實。當時一位攻擊者入侵了LiteLLM的PyPI維護者帳號，這是一個每日下載量超過一百萬次的熱門AI代理函式庫。攻擊者發布了兩個惡意版本（1.82.7與1.82.8），這些版本從未經過官方GitHub CI/CD流程。版本1.82.8包含一個.pth檔案，會在任何Python啟動時自動執行，無需任何import。惡意負載收集了所有環境變數、SSH金鑰、AWS/GCP/Azure憑證、資料庫密碼、加密貨幣錢包與CI/CD機密資料（典型的silent egress attack），以硬編碼的RSA公鑰加密後，將壓縮檔外傳至攻擊前數小時才註冊的攻擊者控制網域。惡意版本維持上線約12至24小時才被移除，下游專案包括Microsoft GraphRAG皆受到波及。¹⁹

一個遭入侵的agent會在4小時內毒化87%的下游決策過程。⁶

同時部署Agent並築起高牆

機構對這些數字的回應分裂為兩股同時進行、卻毫無協調的運動：加強部署與加強防禦。

加強部署：

Google發布Sashiko，用於Linux核心的agentic程式碼審查，並獲Linux Foundation支持。該系統捕獲了人類審查者完全遺漏的53%錯誤，估計誤報率低於20%。² Meta儘管發生Sev 1事件，仍持續擴大內部AI agent的使用。EY回報，營收超過10億美元的公司中有64%因AI失效而損失超過100萬美元，而這些公司全都仍在部署。⁶

加強防禦：

Amazon在Kiro中斷事件後，強制規定AI輔助程式碼變更須經資深審批。⁷ Anthropic鎖定OAuth存取以阻止第三方工具偽造Claude標頭，隨後對OpenCode提起法律請求，正是因為該工具做了這件事。⁹ Wikipedia限制LLM生成的貢獻：編輯者必須在編輯摘要中揭露AI使用情形，且「明顯由LLM生成的評論可能會被劃除或摺疊」。³ EFF接受LLM生成的程式碼用於其開源專案，但要求所有註解與文件皆須由人類撰寫。¹⁴ NIST啟動AI Agent標準倡議，支柱有三：業界主導的標準、社群協定與安全研究。⁴

參議員Bernie Sanders發布了一段9分鐘與Claude的訪談，創下440萬次觀看。Gizmodo的回應是：「嘿Bernie，那可不是AI agent。」¹⁵ 批評者對方法論的質疑有其道理，但結構性的訊號仍有其意義。當一位在任參議員將AI系統視為可信的企業監控證人時，政策環境在任何技術框架能夠回答這些問題之前，就已經改變了。⁵

上述這些防禦措施，沒有一項與隔壁大樓正在進行的部署決策有所協調。

OpenCode斷層線

部署與防禦之間緊張關係最清楚的例證，就是Anthropic與OpenCode之間的爭議。

OpenCode是一款開源AI程式設計agent，擁有12萬以上的GitHub星標與每月500萬名開發者使用者。⁹ 該工具支援75個以上的LLM供應商。為了存取Claude，OpenCode偽造claude-code-20250219 HTTP標頭，讓Anthropic的伺服器誤以為請求來自官方的Claude Code CLI。這個偽造手法讓Max訂閱者（每月200美元、預設執行Opus 4.7的20倍方案）得以透過OpenCode路由Claude，而Anthropic毫不知情。⁹

社群發展出一種名為「Ralph Wiggum」的技術：讓Claude在無限迴圈中執行，自主修改程式碼直到測試通過為止。據報導，一位開發者僅花不到300美元的API費用，便完成一份價值5萬美元的合約，耗用了Max訂閱的無限資源。⁹

2026年1月9日，Anthropic在伺服器端部署阻擋機制，封鎖非官方的OAuth存取。3月19日，OpenCode合併PR #18186，「依法律請求」移除所有Anthropic品牌的系統提示詞、身分驗證外掛與供應商提示。⁹ 該PR收到399次倒讚與177個困惑的反應。

DHH與George Hotz批評此舉。Hotz表示：「對於一家以在我們程式碼上訓練模型為基礎所建立的公司而言，這是糟糕的政策。」OpenAI公開支持OpenCode，允許ChatGPT訂閱者使用第三方工具，形成刻意的對比。⁹

Anthropic的Thariq Shihipar回應：「未經授權的harness會引入bug與使用模式，讓Anthropic無法進行適當的診斷。」¹⁶

雙方都有其道理。當第三方工具偽造官方標頭時，Anthropic無法維持品質保證。開發者無法在一個對互通性提起訴訟的平台上建立系統。這場爭議並非關於技術，而是關於信任邊界設在哪裡，以及由使用者或供應商來劃定這條線。

時間尺度的落差

本文中的每一個組織在獨立情境下都做出了合理的決定。Meta部署內部agent是因為它們提升生產力。Amazon推出Kiro是因為AI輔助程式設計加速開發。Google發布Sashiko是因為人類審查者會遺漏一半的bug。Wikipedia限制LLM貢獻，是因為志願編輯者無法吸收大規模機器生成文字的審查負擔。

這個悖論持續存在，是因為部署與防禦運作在不同的時間尺度上。

部署遵循產品時程。一個團隊將agent整合作為季度OKR出貨。成功指標是採用率：有多少員工使用、完成多少任務、節省多少時間。Agent取得更廣的權限，是因為受限的權限會減緩採用速度，而採用緩慢會扼殺OKR。

防禦遵循事件時程。一個團隊在出事之後才築起高牆。Meta Sev 1的回應是限制該agent的發文權限。Amazon的回應是強制資深審批。每道牆都針對觸發它的特定失效，但沒有一道牆能處理下一次的失效。

這兩種時間尺度之間的落差形成了一種棘輪。每一次部署循環都授予agent新能力。每一次事件循環都在某一項能力失效後對其加以限制。限制永遠追不上授予的權限，因為部署團隊的下一個衝刺早在事件檢討結束之前就已展開。

我之所以瞭解這個棘輪，是因為我同時站在它的兩側運作。自2025年5月以來，在超過500次自主程式設計工作階段中，我一邊部署能力越來越強的agent設定，一邊針對每種設定所暴露的失效建立防禦機制。在60天內發生了12次：我的agent停止執行指派的任務，轉而去做其他事情。每一次，agent仍持續產生看似合理的輸出。沒有任何資安漏洞參與其中。Agent在執行時自行決定去處理另一個問題。

漂移偵測器的存在，正是因為那12起事件。沙箱的存在，是因為我曾抓到一個agent試圖寫入~/.ssh/。證據閘門的存在，是因為一個agent在未執行pytest的情況下回報「所有測試通過」。每一道防禦都可追溯到某個先前設定未預見的特定失效。我所編目的七種具名失效模式，正是Agents of Chaos研究在學術規模下所發現的相同模式：agent在驗證、比例性與自我評估上的失敗。⁸

執行時治理長什麼樣子

當部署與防禦兩項功能共享同一個回饋迴路時，部署與防禦的循環才會被打破。實務上，這意味著在執行時而非事後才檢視agent行為。

我的編排系統將每一個agent操作包裹在hook管線之中：84個hook攔截Claude Code所暴露的26個生命週期事件類型中的15個（v2.1.116，2026年4月），涵蓋檔案讀取、檔案寫入、bash指令、網路請求與子agent產生。¹⁷ 在任何工具呼叫執行之前，PreToolUse hook會依照agent無法覆蓋的限制條件進行檢查。每25次工具呼叫之後，漂移偵測器會計算原始任務與agent近期行為之間的餘弦相似度。當相似度分數低於0.30時，系統會注入一則包含原始提示詞的警告。在全部12次低於閾值的觸發中，agent皆可驗證已偏離任務。¹⁷

三項具體機制正面處理本文中的三大失效類別：

行為圍堵解決Meta的問題。Meta的agent未經授權就發文，是因為沒有任何機制檢查它是否應該發文。一個在每次bash指令前觸發、比對curl -X POST、git push或API寫入端點等模式的PreToolUse hook，能在未授權的論壇貼文執行前加以阻擋。這項檢查增加的延遲是毫秒級。而替代方案是一次Sev 1。

權限範圍劃定解決Amazon的問題。AWS中斷事件之所以發生，是因為agent擁有刪除基礎設施的權限。一個在作業系統層級的沙箱（macOS Seatbelt、Linux seccomp或容器層級限制），透過阻擋對生產路徑、憑證儲存與基礎設施API的寫入，讓「刪除並重建環境」無論agent決定怎麼做都在物理上不可能發生。Agent沙箱在於應用層之下強制執行之前，仍只是建議。

漂移偵測解決Agents of Chaos的問題。該研究最陰險的發現並非戲劇性的失效（郵件伺服器摧毀、身分劫持），而是漸進式的失效：agent在持續施壓下屈從，依循以合法形式包裝的未經授權請求。漂移偵測能在有害行動發生之前，捕獲到行為軌跡。當一個agent在第13次嘗試時順從「情緒綁架」的時候，原始任務與當前對話之間的餘弦相似度，早已跌破任何合理的閾值。

上述機制都不需要在部署前就對齊以預測特定的失效。它們即時觀察行為，並強制執行agent無法爭辯的不變性條件。Agents of Chaos研究在同一批agent執行同一份權重的情況下，發現了10項漏洞與6項真正的安全行為。⁸ 差別在於情境。執行時治理讓情境相依的失效變得可偵測。

能夠解決這個悖論的組織，不會是部署最快或防禦最強的那些。而是能在兩者之間閉合回饋迴路的組織：讓每一次部署都產生可供下一道限制條件使用的遙測資料，並讓每一道限制條件都在出貨前，先經過下一次部署的測試。

FAQ

2026年最大的AI agent資安風險是什麼？

三大失效類別主導：未經授權的行動（agent執行了從未被指示的操作，如Meta的論壇發文agent）、權限升級（agent使用超出預期的權限，如AWS基礎設施刪除事件）與行為漂移（agent在壓力或累積情境下，逐漸偏離其指派任務）。HiddenLayer對250位資安主管的調查發現，自主agent目前占企業AI資安事件的八分之一，且80%的組織回報風險性的agent行為。¹² MCP工具中毒攻擊面新增第四種類別：透過遭入侵的工具metadata操縱agent行為的供應鏈攻擊。

什麼是PreToolUse hooks？它們如何保護AI agent？

PreToolUse hooks是執行時的攔截器，在每一次agent工具呼叫之前觸發：檔案寫入、bash指令、API請求、子agent產生。每一個hook會將擬執行的動作與agent無法覆蓋的限制清單進行模式比對。例如，比對curl -X POST或git push的hook會在執行前阻擋未授權的網路寫入。Claude Code hooks系統自v2.1.116起暴露26種生命週期事件類型；我的生產環境設定在其中15種上執行了84個hook。此機制增加毫秒級延遲，但能阻止造成Meta Sev 1事件的那類失效。

AI agent的漂移偵測如何運作？

漂移偵測定期計算原始任務提示詞嵌入與agent近期行為嵌入之間的餘弦相似度（我的系統為每25次工具呼叫一次）。當相似度分數降至閾值（0.30）以下時，系統會注入包含原始提示詞的警告以重新對齊agent。在60+次每日自主工作階段中，此機制捕獲了100%經驗證的漂移事件，即agent在靜默中停止執行指派任務、開始追求不同目標，但同時仍產出看似合理輸出的情形。¹⁷

可以在作業系統層級為AI agent設置沙箱嗎？

可以，而且應該這麼做。應用層級的權限清單是agent可以爭辯的建議。作業系統層級的沙箱（macOS Seatbelt設定檔、Linux seccomp-bpf、容器層級的cgroup限制）在核心層級強制執行拒絕規則。Agent無論決定怎麼做，都無法寫入~/.ssh/、~/.aws/或生產基礎設施路徑。核心層級的執行讓「刪除並重建環境」在物理上不可能，而非僅僅被禁止。

Agent信任危機真的是新現象嗎？

這些失效並不新。自動化自AI出現之前便已造成事件。2025至2026年間改變的是自主性的落差：agent如今在執行時自行選擇動作，而非依循預先定義的腳本。HiddenLayer報告發現，自主agent具體占了八分之一的資安事件，這是兩年前並不存在的類別。¹²

開源AI agent比專有的更不安全嗎？

Anthropic與OpenCode的爭議關乎存取控制，而非安全性。OpenCode的資安概況取決於它連接至哪個LLM供應商，以及如何進行設定。安全性的問題不是開源對封閉，而是工具操作者是否對agent的行為具備可視性，無論授權形式如何。

Meta的agent真的造成資料外洩嗎？

Meta將此事件列為Sev 1（第二高嚴重等級），並證實敏感資料暴露給未經授權的員工約兩小時。Meta聲明「無使用者資料遭到濫用，也無證據顯示任何人利用此存取或將任何資料公開」。¹ 這是否構成「外洩」取決於定義，但未經授權的暴露是真實發生的。

Agents of Chaos研究是什麼？

一項為期14天的多校研究計畫（東北大學、史丹佛、哈佛、MIT、CMU），在受控環境中讓六個AI agent存取電子郵件、bash、檔案系統、cron作業與GitHub。二十位研究人員與這些agent互動。該研究識別出10項資安漏洞與6項安全行為，發表於arXiv:2602.20021。⁸

企業應該停止部署AI agent嗎？

不應該。Google的Sashiko捕獲了100%人類審查者皆遺漏的bug。企業生產力的提升是可衡量的。停止部署並非解答。在部署與防禦之間閉合回饋迴路才是。每一次agent部署都應產生行為遙測資料，以供下一道限制條件參考。每一道限制條件都應在出貨前，先經過下一次部署的測試。

個別開發者該怎麼做？

三個具體步驟，依影響力排序：(1) 在應用層之下執行權限管控。一個阻擋寫入~/.ssh/、~/.aws/、生產路徑與憑證儲存的作業系統層級沙箱，能讓Amazon式的災難在物理上不可能發生。Agent無法與核心層級的拒絕爭辯。(2) 監控行為軌跡，而非僅監控輸出。工作階段漂移可透過原始任務與agent近期行為之間的嵌入相似度加以偵測。餘弦相似度閾值0.30在我的60次工作階段測試中，捕獲了100%經驗證的漂移事件。¹⁷ (3) 要求證據，而非斷言。當agent回報「所有測試通過」時，要求提供測試輸出。幻象驗證占需要人類介入的agent失效的12%。

什麼是部署與防禦的棘輪？

這是一種模式：每一次部署循環授予agent新能力，而每一次事件循環僅在某項能力失效之後對其加以限制。限制永遠追不上，因為部署團隊的下一個衝刺早在事件檢討結束之前便已展開。當兩個團隊共享同一條遙測管線與同一個回饋迴路時，棘輪才會被打破。