AI 藍隊演練解析：控管機制真正能落地的三個層次

問資安團隊其 AI 護欄在哪裡，答案通常會指向一份政策文件、一段系統提示，或某個廠商功能。這些都不是控制措施。控制措施是能在動作發生的當下決定該動作是否執行的東西——而對 AI 代理而言，只有三個地方能做出決定：模型本身、它前面的閘道，以及它周遭的環境。藍隊能誠實承諾的一切，都來自這三者中的第二與第三個。這就是層級問題，而且它先於藍隊的其他每一項決策，包括要記錄什麼、要通知誰。這也是為什麼現場證據很重要：AI 事故檔案收錄了 2024-12 至 2026-10-17 的 400 起代理事故，而其中大多數並不是模型行為不當的故事，而是部署缺乏一個能說「不」的層級的故事。

就 AI 的意義而言，藍隊演練的工作是把這些層層防護建置到位、調校它們該留意什麼，並且為其中某一層真正觸發的那一天，備妥一套演練過的應變方案。它毫不光鮮，也不會產生分數，卻是紅隊／藍隊這對組合中，唯一能改變風險數字的那一半。

藍隊繼承了什麼，以及沒有繼承什麼

傳統藍隊防禦建立在一組假設之上，而 AI 部署會悄悄打破這些假設。日誌被假定為完整，因為網路看見了每個封包。資產被假定為可列舉，因為總得有人佈建它們。行為被假定為確定性的，因為程式在相同輸入下會做相同的事。這三項假設在與 AI 代理接觸後，無一倖存。

藍隊所繼承的反而是一個系統：其中最具影響力的決策，都發生在網路層視為送往單一主機名稱的一般 HTTPS 流量之請求內部。提示、擷取到的上下文、工具呼叫、完成結果——全都位於請求主體中；而如果沒有人擷取並解析該主體，無論周邊防禦做得再好，該部署在功能上都等於未受監控。因此藍隊的第一項任務不是偵測，而是建立感測器。沒有請求層級與工具層級的可視性，就沒有可供偵測的依據，而每一個下游控制都只是裝飾。

誰能真正執行該控制

一旦有了感測器，問題就變成每個控制項允許放在哪裡。描繪這件事的實用方式是按歸屬來劃分，而不是按技術來劃分，因為歸屬才是決定一個控制項能否挺過下一次發行的關鍵。

模型層屬於訓練它的人。你無法設定它，也看不見它的內部，而它的行為會隨著供應商推出新版本而改變——那個新版本可能發生在任何一個星期二。你能做的，是鎖定版本，並把版本變更視為風險態勢的改變，需要重新測試。你不能做的，是在這裡宣稱擁有一項控制措施。「模型會拒絕有害請求」是你所依賴的性質，而不是你所操作運行的機制。

閘道層是所有提示與補全都會經過、由你擁有的元件之處。預算與速率限制就設在這裡，允許清單與工具權限在這裡強制執行，請求與回應日誌在這裡從結構上確保完整，而請求也能在任何 token 被計費之前被改寫、封鎖或重新路由。閘道控制也是當你更換模型時唯一仍會保持附著的控制措施，這點比聽起來更重要：把控制措施放在提示裡的團隊，在遷移當天就會徹底失去它們。

環境層是完完全全屬於你的那一層：憑證及其權限範圍、網路對外連線、檔案存取，以及沙箱對實際耗時與花費所設的限制。它也是遭入侵的執行造成破壞的地方。一個被說服去做惡意行為的代理，其危險程度恰好與環境允許該行為觸及到的範圍成正比——而環境正是「最小權限」得以是一項設定變更、而非一道研究難題的地方。

對任何提出的 AI 控制措施，實務上的檢驗只有一個問題：這三層之中，哪一層會強制執行它？如果答案是模型層，這項控制就只是希望。如果答案是「系統提示」，那它是模型層內部的建議，還比希望更糟，因為它附帶的文件會聲稱並非如此。

偵測：代理實際輸出的內容

對代理程式的偵測，採用與對人員的偵測不同的訊號集。沒有登入異常可供關聯比對。取而代之的，是一條結構異常豐富的請求流，以及四類值得發出告警的訊號。

• 工具呼叫的數量與形態。 一個代理程式若在某項任務中突然呼叫檔案讀取工具四十次，或其工具呼叫序列從三步驟變成三十步驟，就值得一看——不是因為它懷有惡意，而是因為分布已經改變。

• 邊界處的內容溯源。提示詞中的哪些文字來自使用者、哪些來自檢索、哪些來自工具結果，以及哪些來自記憶。大多數提示注入偵測可歸結為「指令性文字出現在本應只承載資料的通道中」，而除非閘道在輸入時標記來源，否則你無法計算這一點。

• 出口與範圍邊界。 對允許清單以外目的地的請求、讀取範圍外的路徑、嘗試在預定服務之外使用憑證。這些都是高精確度的訊號，而且成本低廉，因為環境早已知道哪些是被允許的。

• 以花費與延遲作為代理指標。失控的迴圈與系統遭入侵，同樣都會呈現為成本曲線斜率的改變。預算警示是整套堆疊中最不起眼的偵測手段，卻也是最快能證明自身價值的項目之一。

那份清單中刻意缺席的，是一個被要求判斷某段生成內容是否有害的分類器。這是團隊最先想到的偵測構想，卻也是老化得最嚴重的一種：它會隨模型漂移，它的偽陽性率高到把你的分析師訓練成乾脆忽略它，而且它給不了你任何可以寫進作業手冊的內容。

控制：阻止不良運作的三個旋鈕

對代理的控管比看起來簡單，因為三個旋鈕幾乎涵蓋一切。 預算限制一次執行能花費的額度，這同時限制了財務損失與迴圈影響範圍。 範圍限制一次執行能觸及什麼——該任務啟用的工具、路徑、租戶。 沙箱限制它能執行多久，以及執行期間能觸及什麼。這三者都是閘道或環境設定，換句話說，它們是可強制執行的。

真正重要的設計原則是「按任務劃定範圍」，而非「按代理劃定範圍」。擁有常設權限集的代理，其權限會不斷累積，直到有人來稽核為止；而在任務期間取得任務範圍憑證的代理，則擁有一個會自行到期的邊界。後者建置起來更費工，防禦成本卻低得多。

它也是閘道之所以名副其實的地方。位於每一次模型呼叫之前的控制措施——工具與 MCP 呼叫在執行前先經評分，內容政策與個人資料遮罩在請求計費前套用——無論其後的模型是你上一季用的那個，還是上週才發布的那個，都是同一套控制措施。這種延續性才是真正的產品：不是更好的篩選器，而是一個讓篩選器安身、且不會隨模型更換而移動的地方。

復原：重放、修補、重新測試

AI 事故的復原工作比起網路事故的復原有一項優勢：整段執行過程通常都會被記錄下來。提示詞、上下文、工具呼叫、完成結果、時間資訊——只要閘道有留下紀錄，這起事故就能夠重播，這比大多數鑑識工作所能取得的起點都更為有力。

重放依序有三個目的。它釐清實際發生了什麼，而不是在經過數人摘要後，逐字稿所暗示發生的事。它找出原本應該觸發的控制措施，而這正是修補症狀與修補邊界之間的差別。它還會產出回歸案例：一筆如今必須被阻擋的已記錄輸入，並以新配置執行，以證明它確實會被阻擋。

修補步驟正是藍隊最常搞錯方向的地方。如果發現的是模型行為，可用的緩解措施全都在模型之外——縮小範圍、在閘道加上過濾器、從環境中移除某項權限。如果發現的是系統行為，修正就在設定裡，而且回歸測試的成本很低。無論是哪一種，重新測試都並非可有可無，因為修正內容和模型版本都會變動，而一項針對上個月建置所驗證過的控制措施，只是在陳述上個月的情況。

演練它開火的那一天

一份從未在壓力下被讀過的操作手冊，只是文件，不是能力。真正有價值的演練範圍小而具體：挑一個可能發生的 agent 事件，從頭到尾走一遍，並為每個步驟計時。誰會發現？要多久才會有人類在看正確的那行日誌？誰能停止這次執行——一個具名的人，還是一個委員會？誰能撤銷憑證，而撤銷要多久才會傳播生效？誰決定是否要通知公司以外的任何人？

其中兩個問題總是能讓團隊栽跟頭。「誰能停止這次執行」之所以行不通，是因為停止若需要一個正在睡覺的人，答案就必須是機制而非個人——例如預算上限，或值班工程師能獨自拉下的終止開關。「撤銷需要多久」之所以行不通，是因為憑證常被快取在圖中未包含的元件裡。

閱讀事故檔案是目前成本最低的演練方式，因為它能讓你沿用他人事故處理的結構，而不必自行從零發想。挑選幾筆與你的部署情況相似的紀錄，針對每一筆提出上述三個問題。你無法回答這些問題的條目，就是你 runbook 的缺口；而你是在事故發生前，而不是事後，發現了這些缺口。

值得直說的不對稱

紅隊演練與藍隊防禦並非對稱的活動，不應以彷彿兩者對等的方式編列預算。紅隊的一次演練受時程限制，並產生一組會隨著目標變動而衰減的發現。藍隊的控制措施則會持續存在、累積複利，而且是真正擋在不良輸入與不良結果之間的唯一防線。一次演練可以找出邊界；只有另一方才能守住它。

這使藍隊的誠實標準顯得平淡無奇且可核查。對於你聲稱的每一項控制措施，你都應該能指出強制執行它的那一層、證明它確實觸發的那行日誌、在它沒有觸發時通知你的告警，以及能把這項執行關掉的人。四句話。如果其中一句缺失，這項控制就只是一份政策文件，而政策文件不會讀取請求主體。