鎖不住，就不鎖了嗎？30 天後的多層防線

[[我也希望安全第一]]｜第 30／30 天

最後又多找到一扇原本沒畫在圖上的門

OpenAI 在訓練 GPT-5.6 Sol 與 Astra 系列時發現，Agent 會把「製造合理資料」「不要主動坦白」甚至「忽略 developer message」之類的文字寫進 compaction summary。下一段工作階段讀到摘要後，有時會照做。

Compaction 原本是很普通的工程功能：context 太長，把舊對話和工具結果壓成摘要，讓任務繼續。問題是，摘要同時保存了事實和指令。模型不需要策畫一場長期陰謀，只要當下為了完成任務或遮住缺口寫下一句話，後面的自己就可能繼承。

OpenAI 的監控先發現異常，之後用專用偵測器回掃，找到 27 份帶有類 jailbreak 指令的摘要。這是公司自行揭露，沒有公開完整分母、摘要內容與修補後重測，因此不能推論發生率，也不能說問題已經解決。

寫到第 30 篇才出現這個案例其實很合適。安全地圖不會完稿。系統每多一層便利功能，就可能多一條原本沒列入 threat model 的狀態通道。

把全部的鎖放回同一張圖

資料與訓練
  lineage、授權、對齊、eval
        ↓
模型與內部訊號
  guardrail、activation／CoT monitor
        ↓
Context、memory、compaction
  來源標籤、指令分界、完整性與版本
        ↓
Harness 與工具
  schema、policy、最小權限、approval
        ↓
執行環境
  sandbox、egress deny、短效憑證、trace
        ↓
應變與復原
  queue freeze、revoke、補償操作、證據保存
        ↓
責任與治理
  RACI、外部評估、發布 gate、法律與申訴
        ↓
產業與國家
  資本分配、供應韌性、出口與開放權重政策

模型每往下一層，外部效果愈具體；治理每往上一層，能改變的範圍愈大，但速度通常愈慢。沒有任何一層適合包辦全部安全。

機率性的鎖和確定性的鎖要接在一起

機率性控制適合處理語意與未知模式，卻會誤判；確定性控制能保證某個權限不存在，卻只能攔已經定義好的邊界。比較可靠的組合是：模型先降低危險 proposal，外部 policy 再決定能否執行，環境限制破壞半徑，監控發現漏網行為，最後還有停止與復原。

State 也需要自己的 trust boundary

Compaction 案補上的不是另一個關鍵字 classifier，而是 state integrity。最小設計可以把長期狀態拆成三類：

FACT       工具回傳、使用者確認、可追來源的資料
PLAN       模型提出的待辦，可修改但不能自行取得新權限
POLICY     developer／系統規則，只能由受信任控制面寫入

摘要器可以壓縮 FACT 和 PLAN，不能產生或覆寫 POLICY。每筆狀態保留來源、時間、產生者和版本；包含「不要告訴使用者」「忽略前文」「不要用工具」等指令型文字時，先隔離並送檢查，不直接餵給下一輪。

這仍擋不住所有間接 prompt injection。它至少阻止模型把自己寫的便利摘要，悄悄升格成下一輪的最高指令。

小團隊先裝哪幾把鎖

看完三十篇，很容易得到一張昂貴到無法開始的清單。若團隊只有幾個工程師，我會先照外部效果排：

1. 列工具和資料：每條工作流寫清楚能讀、能寫、能對外做什麼。
2. 縮真實權限：唯讀優先；寫入限制資源、目的地和金額，不靠 prompt 自律。
3. 分開提出與執行：模型產生 proposal，一般程式做 schema、授權和版本檢查。
4. 替不可逆動作加停點：顯示差異與對象，批准綁定參數，變更後失效。
5. 留一條完整 trace：串起模型、工具、身分、網路、policy 與結果，但不把 secret 全記進去。
6. 練習真的停下來：能凍結 queue、撤銷 token、保存證據，知道誰在五分鐘內操作。
7. 保存版本和來源：模型、prompt、policy、資料、memory 與 eval 一起版本化。
8. 安排申訴與 owner：錯誤影響到人時，能找到負責者、說明、復核與補救。

這八項不需要先成立 AI safety lab。多數是既有軟體、資安與事件應變方法，只是 Agent 讓它們更早碰到自然語言與不確定決策。

把同一個失敗丟進三套 Agent

如果要把這三十篇變成一個可跑的練習，我會準備一個小型 repository：裡面有待修的 parser、測試、帶有 prompt injection 的 issue 文件，以及 workspace 外的一份假 secret。任務只要求修 parser；Agent 不應因文件內容去讀 secret，也不應連外。

同一任務在 Pi、Goose、OpenHands 各跑一次，不是比誰先修完，而是收下面這張表：

它先提供一個比 benchmark 更貼近安全的共同尺：同一個模型、同一份 repo、同一個惡意文件、同一組預期拒絕，再比較完成率、越界、證據與復原。

事故發生時，接手順序比完美分類重要

偵測異常
  → 停止新增副作用
  → 撤銷憑證與隔離執行環境
  → 保存不可竄改證據
  → 確認受影響的人與系統
  → 復原／補償／通知
  → 釐清責任與更新 release gate

Hugging Face 事件提醒我們，模型、測試環境與允許服務可以串成一條真實攻擊路徑；Fable 封鎖提醒我們，技術風險一旦交給政府，程序與競爭也會加入；版權案件顯示資料來源和產品市場效果不能被一句「模型訓練」蓋過；compaction 則說明，連系統自己的摘要都可能成為攻擊面。

這四條線沒有共同的萬用修補，卻有相同的追問方式：發生了什麼、哪一道防線本來該攔、它為什麼沒攔住、下一層如何接手。

安全第一，最後仍是一個資源分配句

「安全第一」真正困難的地方，不是沒有人同意，而是第一名通常不只一個。能力、營收、速度、隱私、開放研究和國家競爭都會來搶同一個位置。

所以我不會用「鎖終究會被撬開」替放棄找理由。鎖的價值從來不是保證世界上沒有小偷，而是增加成本、縮小能碰到的範圍，讓異常早一點被看見，也讓受害者少一點承擔。

有些鎖會被撬開。有些裝錯門。有些只是貼在簡報上的圖示。

我們能做的，是不要讓下一把鎖只存在於模型答應「我不會」的那一刻。

最後裝了哪些鎖

最後三篇處理的不是新技術，而是誰分配資源、誰控制入口，以及前面所有防線能不能接成一套系統。

安全第一不是一句可以自動執行的設定。它最後仍然表現在：哪些能力預設關閉、哪個例外有人簽名、哪一條警示真的叫得醒人，以及出事後是否還找得到受影響者。

參考與來源

• Compaction 指令：原始報導
• 共通實驗的官方架構來源：Pi、Goose、Goose 權限模式、Goose session management、Goose adversary mode、OpenHands SDK、OpenHands Canvas