私鑰存放有哪四個層次？各自的安全強度和適用場景是什麼？
從最基礎到最安全，Agent 的私鑰存放有四個層次：
層次一：明文環境變數（最危險，禁止在生產環境使用）
把私鑰直接存在 .env 文件或作業系統環境變數裡。常見的錯誤：.env 文件被不小心 commit 到 GitHub，或者 printenv 日誌把私鑰洩漏到日誌系統。這個層次在開發環境測試用可以接受，但生產環境絕對不應該使用。
層次二：加密的 Secret 服務（基準線，生產環境最低要求） Railway Secrets、AWS Secrets Manager、HashiCorp Vault——這些服務把私鑰加密存放，應用在運行時才解密取得，私鑰不以明文形式存在於應用代碼或版本控制系統裡。Railway 的 Secrets 功能對這個層次已夠用，且對開發者友好。主要風險：服務本身的權限管理——如果你的 Railway 帳號被劫持，攻擊者可以讀取所有 Secrets。建議開啟 Railway 的 2FA 和 IP 訪問限制。
層次三：HSM / KMS（硬體安全模組） AWS KMS、Google Cloud KMS、Azure Key Vault——私鑰從不以明文形式離開硬體安全模組，簽署操作在 HSM 內部完成，應用只能送入「待簽署的數據」、收到「簽署後的結果」，永遠看不到私鑰本身。對 Agent 的安全升級最大——即使應用代碼被完全攻陷，攻擊者也無法導出私鑰。適合高資金量的 Agent。成本：AWS KMS 約 $1-5/月 + 按 API 調用收費。
層次四：MPC（多方計算）錢包 私鑰從未以完整形式存在於任何地方——它被拆分成多個碎片（shards），需要門限數量的碎片合作才能完成簽署（例如 2-of-3）。Privy、Turnkey、Web3Auth 提供商用 MPC 方案。這是目前最高安全強度的私鑰管理方案，同時也是成本和工程複雜度最高的。
Agent 場景的私鑰有哪些人工持有沒有的特殊挑戰？
Agent 的私鑰管理和人工持有私鑰有幾個根本性的差異，這些差異帶來了普通錢包安全建議無法覆蓋的風險：
挑戰一：私鑰 24 小時可被程式碼調用 人工錢包的私鑰平時在硬體錢包或腦子裡，只有「你坐在電腦前操作」的時候才被使用，每天可能只有幾分鐘的暴露窗口。Agent 的私鑰在服務器上 24 小時可用——攻擊者不需要等你「在線」的那一刻，只要攻破服務器或注入惡意指令，任何時間都可以觸發簽署。這意味著 Agent 的私鑰攻擊面是人工錢包的 144 倍（24 小時 vs 10 分鐘）。
挑戰二：Prompt Injection 可以讓 Agent 「主動」用私鑰做壞事 人工持有私鑰時，攻擊者必須物理盜取設備或騙你親自操作。對 Agent，攻擊者可以通過 Prompt Injection 讓 LLM 推理相信「執行這個轉帳是正確的策略」，然後 Agent 主動調用私鑰完成惡意轉帳——整個過程中私鑰沒有「被盜」，但被「授權使用」完成了惡意操作。
挑戰三：持續運行意味著沒有「冷卻期」 人工操作時，如果你的電腦被攻擊，你通常在事後很快就會發現（電腦變慢、異常彈窗）。Agent 的服務可以被靜默地在後台操控，同時表面上正常運行，攻擊者利用「持續運行」積累小額的穩定損失，讓你難以察覺。
挑戰四：DevOps 流程帶來新的攻擊面
私鑰需要注入到 CI/CD 流程、部署腳本、日誌系統——每個接觸點都是潛在洩漏點。人工錢包不需要被集成到 DevOps 流程裡，但 Agent 的私鑰幾乎必然需要。這就是為什麼「加密 Secret 服務」是最低要求，而不是 .env 文件。
私鑰輪換（Key Rotation）是什麼？Onchain Agent 應該多久輪換一次私鑰？
私鑰輪換是指定期用新的私鑰替換舊的私鑰，並把 Agent 操作錢包的資產從舊地址遷移到新地址。輪換的目的：即使舊私鑰在某個時間點被靜默洩漏（但還沒有被攻擊者利用），輪換後舊私鑰失效，洩漏的影響被控制在輪換週期內。
為什麼靜默洩漏是真實風險：你的服務器、CI/CD 系統、日誌系統都可能在某個時間點被攻擊者靜默地訪問，但你並不知道。攻擊者可能在觀察你的系統一段時間後，選擇最佳時機利用已洩漏的私鑰。私鑰輪換確保即使這種靜默洩漏發生，攻擊者的可利用窗口也是有限的。
輪換頻率建議：
輪換流程：
自動化輪換的可行性：對 EOA + Secrets Manager 方案，可以寫自動化腳本完成步驟 1-4（定期觸發），步驟 5-6 建議人工確認。MPC 方案的輪換由服務商提供工具，更容易自動化。
私鑰在哪些 DevOps 場景裡最容易意外洩漏？怎麼建立防洩漏的 checklist？
在 Agent 的開發和部署流程裡，私鑰洩漏最常發生在以下幾個場景：
高風險場景一：版本控制系統（Git）
.env 文件意外被 commit（常見！尤其是新手開發者）git log 歷史記錄裡的私鑰——即使你刪除了那個 commit，git history 裡還有，需要用 git filter-branch 或 BFG Repo Cleaner 清除.gitignore 裡加入 .env；使用 git-secrets 或 trufflehog 掃描 commit 前是否有密鑰高風險場景二：CI/CD 日誌
echo $PRIVATE_KEY 調試時意外把私鑰打印到 CI 日誌echo 私鑰；在日誌系統裡設定密鑰遮蔽（Railway 自動遮蔽 Secrets，但自定義 echo 不會被遮蔽）高風險場景三：錯誤追蹤和監控系統
高風險場景四：Docker Image
RUN 步驟裡使用了 ARG PRIVATE_KEY，私鑰會被燒進 Docker Image Layer，即使後來刪除了也可以用 docker history 看到防洩漏 Checklist（每次部署前確認）：
.env 在 .gitignore 裡且沒有被 commitecho 或 print 私鑰對比：私鑰管理設計好 vs 設計差的 Agent，30 天的實際差異
設計差的 Agent（私鑰放在 .env 文件）：
.env 連同代碼 commit 到了 GitHub（忘記加 .gitignore）設計好的 Agent（私鑰放在 Railway Secrets + 定期輪換 + 小額操作錢包）：
.env 文件，.env 文件裡存的是「佔位符」（PRIVATE_KEY=your_key_here），真正的私鑰在 Railway Secrets 裡兩個 Agent 的技術能力和策略完全相同，唯一差別是私鑰管理設計。結果：損失 $3,500 vs 最壞損失 $500，且前者可能在幾小時內發生，後者有多層緩衝。
這個對比說明了私鑰管理設計不是「高級優化」，而是最基礎的風險控制——不做就是在裸奔。
私鑰管理越安全，運維複雜度越高、成本越高：明文 .env（零成本，極高風險）→ Secrets Manager（低成本，大幅降低風險）→ KMS（中成本，私鑰不以明文存在）→ MPC（高成本，最高安全強度）。實踐建議：以資金量為主要判斷標準，$5,000 以下用 Secrets Manager 夠用，$5,000-$50,000 加入 KMS，$50,000+ 考慮 MPC。不管哪個層次，小額操作錢包（只存幾天運作資金）和定期私鑰輪換是所有層次都應該做的基礎措施，成本幾乎為零但能大幅降低最壞情況的損失上限。