安全否決是角色，不是氣氛

主張：沒有具名阻擋者的速度，不是安全流程

AI coding agents 擅長提出下一個 diff。它們也擅長聽起來很確定。

這種組合對零知識保管箱很危險。流暢的 agent 可以「修好」解鎖——把 salt「只為復原」上傳；讓保管箱 AES 金鑰可匯出「好讓測試比較容易」；因為每個 SaaS 教學都有，就加上忘記密碼的電子郵件路徑；或拉進一個沒人讀過 postinstall script 的密碼學套件。修補甚至可能通過型別檢查。威脅模型不在乎。

因此本篇主張是可操作的，不是激勵標語：

在 agent 迴圈裡，安全否決是具名角色，有權阻擋合併與發佈。自動化閘門是證據。人類仍對密碼學與安全決策負責。

這是 一人如何與 AI agents 共同開發並營運 NT² Vault 與 規格先於 agents 寫 code 之後的加深。規格界定可以做什麼。安全否決界定：即使 agent 很自信、清單看起來全綠，碰觸祕密的變更是否准許出貨。

約束：agents 優化「做完」；保管箱優化「拒絕」

三股壓力讓「CI 綠了就出貨」在產品是保管箱時失敗。

訓練先驗偏好好幫手伺服器。 模型看過數百萬行託管密碼、把 KDF 材料放雲端、把支援櫃檯當復原神諭的程式。沒有硬阻擋，「好心」就是預設補完。

安全表演看起來像盡責。 加個相依掃描徽章、一段模糊的「安全考量」段落，或自我審查寫「看起來沒問題」，都很容易。這些都不能取代：在碰觸解鎖／金鑰路徑的變更上，實際走一遍解鎖、錯誤密碼、鎖定與備份。

一人產出會放大沉默的權威轉移。 當同一個人請 agent 實作、agent 起草合併文字、又沒有別人審查時，很容易把 agent 的自信當成共同簽署。不是。問責不會轉移給模型。

因此約束很明確：你不能把否決外包給氣氛、模型自我評估，或「之後再加固」。 對已出貨的密碼神諭來說，「之後」永遠不會來。

設計：閘門是證據，否決是權威

我們把團隊常塌成一個詞——「安全」——的三件事拆開。

迴圈如下：

flowchart LR
  S[規格切片已核准]
  I[Agent 實作]
  G[自動化閘門]
  R[唯讀安全審查]
  V{人類否決？}
  M[合併／發佈]

  S --> I --> G --> R --> V
  V -->|阻擋| I
  V -->|接受| M

不變量活在 agent 每次 session 必須載入的專案憲法裡。精神上可執行：每條對應審查檢查、可能的話對應測試，以及碰觸解鎖或金鑰處理時的走查。公開產品選擇裡一再出現的例子：KDF salt 留在裝置上、我們無法重設你的主密碼，以及 加密金鑰不得活過重新整理。

自動化閘門在 commit、push 與 CI 執行。它們抓住機械失敗——型別壞掉、共用密碼學套件缺覆蓋、正式相依高嚴重度問題、禁止的 HTML 匯入點。它們必要。它們不足以回答「這個 PR 是否又造出伺服器端密碼神諭？」

否決盡可能先唯讀。若安全審查者立刻重寫修補、再核准自己的重寫，審查就塌成實作。偏好：分析威脅與不變量違規、回報阻擋項，留給實作者（人類，或在人類指揮下的 agent）去修。擁有產品的人類仍簽署接受／阻擋決策。

什麼觸發完整閘門

不是每個文件錯字都需要密碼學走查。風險升高閘門：

• 碰觸解鎖、金鑰衍生、金鑰包裝、備份匯出／匯入或雲端驗證 → 完整安全路徑：純邏輯測試、API 變更時的整合測試，以及解鎖、錯誤密碼、鎖定與備份的手動走查。
• 新相依 → 理由：目的、維護者信任、沒有可疑安裝腳本；密碼學／身分堆疊不是順便拉進來的。
• 共用密碼學或事件套件 → 比樹的其他部分更硬的覆蓋率下限。
• Dependabot 與正式稽核 → 人類合併判斷；正式環境的關鍵問題有短時計時，不是聳肩了事。

CI 可在稽核與靜態分析上 fail closed。它仍無法感覺「忘記密碼」是否當成支援體貼溜進來。

問責留在人類

Agents 可以分析並建議否決。它們可以起草威脅筆記。它們不把建議沉默轉成合併權威，也不因為 README 裡有指令就部署。生命週期一文的作業模型仍然成立：產出供審查的決策；不要推論同意。

對 NT² 而言，這也表示保管箱明文永不成為 coding assistant 的提示詞材料，而碰觸帳戶的客戶回覆仍由人類審查。安全否決不只關乎 code；也關乎 AI 被允許看見哪些資料平面。

取捨：較慢的合併，較少不可逆的密碼學錯誤

在迴圈裡放具名否決要花時間。一人商店立刻感受到成本：你既是實作者的贊助人，也是必須說不的審查者。

我們放棄的：

• 綠了就合併的表演 —— 把 CI 當成唯一安全審查者。
• Agent 自我簽署 ——「我審過自己的 diff，看起來很安全。」
• 好心復原功能 —— 因為教學說使用者預期，就重造託管、神諭或可匯出金鑰。
• 順便拉來的密碼學函式庫 —— 只因 agent「找到一個什麼 DID 都做的套件」。

我們得到的：

• 持久的拒絕軌跡 —— 阻擋時理由對應不變量，不是氣氛。
• 證據與權威分離 —— 閘門證明機械健康；人類接受剩餘風險。
• 相容的 agent 速度 —— agents 仍起草與修復；它們不能在 PR 中途重寫威脅模型。
• 產品誠實 ——「無密碼重設」「salt 留在裝置」等公開主張維持為真，因為流程拒絕反面。

昂貴的失敗模式不是「花一小時做安全走查」，而是「出貨一個便利，教會之後每個 agent：憲法是可選的」。

我們拒絕什麼

我們拒絕把安全當情緒。「對密碼學小心一點」不是閘門。具名不變量、自動化證據與人類否決才是。

我們拒絕把綠 CI 當成解鎖與金鑰路徑的合併權威。 測試與稽核是必要證據。它們不能取代走查工作階段：解鎖、錯誤密碼、鎖定、匯出。

我們拒絕「為了除錯」而可匯出的保管箱金鑰。 若金鑰能匯出到 JavaScript，XSS 就有竊取路徑。測試用其他接縫。

我們拒絕偽裝成復原的雲端解鎖神諭： 上傳的 salt、伺服器持有的驗證器，或能解密使用者資料的支援工具。產品無法重設遺忘的主密碼——流程也不得發明與該承諾矛盾的後門。

我們拒絕未經人類明確授權的 agent 合併或部署。 知道指令不等於持有權威。

我們拒絕自我核准的安全審查。 實作者可以修；否決角色保持唯讀取向，並向人類擁有者負責。

我們拒絕未經明確產品決策的新密碼學或身分堆疊。 選擇性標準是設計選擇，不是最近 npm 套件的購物清單。

我們拒絕把保管箱明文餵進 AI 服務。 Coding 與營運助手處理原始碼、測試與最小化的營運 context——不是解密後的使用者內容。

這些拒絕，讓 agent 產出速度仍能與「邊緣盲目、解鎖材料永不變成別人『好心』問題」的保管箱相容。

比模型更長壽的角色

安全否決不是謹慎工程師的性格特質。它是迴圈裡的角色：每次 session 載入不變量、閘門產出證據、人類可阻擋，問責不轉移給模型。

權威表與發佈紀律見 一人如何與 AI agents 共同開發並營運 NT² Vault。讓 agents 不發明錯產品的契約見 規格先於 agents 寫 code。此流程所保護的產品側拒絕，是像 刻意不做密碼重設、KDF salt 留在裝置上，以及 加密金鑰不得活過重新整理 這類文章。

若你想要一座流程與密碼學拒絕同一批捷徑的保管箱——試 NT² Vault，或到 nt2.me 多讀一些。