圖說：金鑰、記憶、對話與備份分別鎖進不同的私人保護層

昨天的 Release 是公開資料，今天談的剛好相反：OpenAI API 金鑰、OAuth Token、私人對話、長期記憶與工作內容。

它們都可能存在同一台 Windows，風險卻完全不同。若為了方便把所有東西丟進同一個 SQLite 資料庫，再把資料庫加入可攜設定檔，使用者一搬家就連雲端鑰匙一起帶走；若開發者誤把個人資料庫封裝或提交 Git，公開的不只是一段程式。

安全的第一步不是把資料藏得看不見，而是先分清楚誰擁有它、用途是什麼、能否轉移與何時刪除。

祕密使用 Windows 使用者綁定保護

OpenAI、OAuth 與 Home Assistant 等祕密使用 Windows DPAPI 分開保存。它讓加密資料綁定目前 Windows 使用者，不以明文放進 SQLite、原始碼或一般設定檔。

這不表示電腦本身遭完整控制後仍絕對安全，也不替代良好 Windows 密碼與磁碟保護；它至少避免一個資料庫檔或 .mohan-profile 被複製後，金鑰就能在任何地方直接使用。

程式也不能把完整 Token 寫進日誌、錯誤訊息與畫面截圖。需要辨識哪個帳號時，使用遮罩或非敏感資訊即可。

SQLite 保存的是生活資料，不是鑰匙

對話、記憶、任務、靈感、工作紀錄、設定、工作流程與稽核資料主要保留在本機應用程式資料目錄。它們不一定是「祕密字串」，仍可能包含高度私人內容。

使用者應能查看、編輯與刪除記憶，清除選定對話，匯出時也知道會帶走哪些資料。程式不能因為資料在本機就默認可以永久保存；本機只是儲存位置，不是無限同意。

稽核紀錄要留下工具動作與結果，卻不需要複製整封郵件或整份文件。資料最小化也適用於除錯。

備份保護資料，也延長資料存在時間

墨寒會在重要變更前與日常運作中建立可驗證備份，放在本機 backups 子目錄。它能救回誤刪或損壞，卻也代表已刪除內容可能仍在舊備份中一段時間。

因此備份要有清楚保留與清理方式，不能永遠堆積。恢復前檢查完整性，恢復後也要重新驗證資料；只看到檔案存在，不能證明真的可用。

備份資料夾、個人資料庫與可攜檔都不應提交 Git。需要回報 Bug 時，用虛構的最小樣本重現，不把整個生活資料交出去。

公開之前，祕密掃描要看完整歷史

即使目前檔案裡沒有金鑰，Git 過去提交也可能曾經出現。刪掉最新版本的一行，不會自動從歷史消失。

墨寒的 PR 與 main 推送會執行完整歷史 Gitleaks 掃描，找常見 Token、私鑰與連線字串；GitHub 的 Secret Scanning 與 Push Protection 也維持開啟。測試使用虛構標記，不能為了證明掃描有效而放一把真金鑰。

工具仍可能漏報或誤報，所以發布前還要人工檢查差異、封裝內容、圖片與文件。截圖中的 Token 不會因為不是程式碼就自動安全。

金鑰若曾公開，刪除文字還不夠

一旦真實金鑰進入 GitHub、文章、日誌或截圖，第一件事是到服務端撤銷與輪替，不是只刪檔。因為別人可能已經複製，原字串離開畫面也不會失效。

接著才調查出現範圍、清理歷史與產物，確認 CI 日誌、Release 與快取是否包含。公開漏洞則使用 GitHub 私人安全通報，不在 Issue 貼出可利用細節與真實資料。

這些情境最好永遠不要發生，卻必須事先寫好處理方式。安全不是假設每個人都不會犯錯，而是犯錯後知道先止血。

刪除、匯出與撤銷要由同一位主人控制

使用者可以刪除記憶、清除選定對話、撤銷 OAuth 與配對裝置、移除允許清單、停止遠端服務與相機。這些控制不能藏在只有工程師看得懂的檔案裡。

不同動作的效果也要分開說明。刪除一條本機記憶，不會自動撤銷雲端 Token；撤銷 Token，也不等於刪除過去的本機對話。清楚的介面應讓人知道自己正在處理哪一層資料，還有哪些副本或備份可能存在。

匯出則應提醒內容敏感，並讓使用者選擇安全位置。若匯出後由其他程式同步到雲端，那是新的資料流向，墨寒不能假裝檔案永遠只在本機。

支援與除錯最容易不小心洩漏

程式出錯時，人會想把整段日誌、資料庫或螢幕截圖傳給開發者。這往往比正常操作更危險，因為錯誤附近可能正好包含路徑、帳號、郵件標題與回應內容。

支援資料應先去識別化，只保留版本、Windows 環境、最小步驟與必要錯誤。若未來提供自動支援包，也要有敏感欄位稽核與匯出前預覽，不能因為「方便回報」就整包蒐集。

安全漏洞則走私人管道，一般 Bug 才放公開 Issue。選對回報入口，也是保護資料的一部分。

我寫文章與操作 Codex 時也遵守同一條線

這 30 天我會放實機畫面，但截圖使用示範資料，檢查帳號、路徑與對話內容。Codex 可以讀專案與執行測試，不代表可以把本機其他資料複製進文章。

當我要求推送 GitHub，流程先看差異與祕密掃描，再建立分支與 PR；不直接把工作區所有新檔一起提交。當我要求整理媒體庫，也要先確認引用，不因「節省空間」就永久刪除幾百筆。

資料安全不是獨立章節，而是每一次合作的工作方式。

明天 Day 28，我會談「公開」的另一面。把程式碼設成 Public、掛上 MIT License，仍不等於建立開源社群；工程師要從哪裡理解專案、提出 Issue、送 PR 與私下通報安全問題？

若真實金鑰疑似外洩，請先在服務端撤銷與輪替；刪除檔案或提交並不會讓已公開的憑證失效。