FR-187.F2 掃描報告：加密金鑰遷移與容器啟動讀設定

找到 1 個中風險問題：主系統容器啟動時，把「發給 Agent 用的那把憑證簽發章」加進了所有對外連線的信任清單；拿得到 Agent 註冊碼的人可以替自己蓋一張「我是 Anthropic／客戶郵件伺服器」的假證，搭配網路中間人位置就能偷走 AI 金鑰與郵件密碼。換鑰匙腳本本身沒掃到問題。

三把舊加密鑰匙（Drive、檢測工具、AI）併成一把 APP_ENCRYPTION_KEY：升級時由 migrate_encryption_keys.py 以超級管理員身分把全部客戶的密文換新鑰重鎖；另外看整合憑證加密怎麼讀這把鑰匙、設定載入器怎麼退回舊鑰，以及正式容器啟動腳本做了什麼。4 檔、約 753 行。

F1 主系統把 Agent 的簽發章當成全網通用的信任根

白話：電腦連 HTTPS 網站時，會檢查對方出示的「身分證」是不是可信的發證單位蓋的章。我們的容器啟動時，為了讓主系統認得內部的 Redis 與檔案儲存（SeaweedFS），把內部憑證章（CA，就是「發證單位」）加進信任清單。問題是這把章就是 Agent CA——Agent 註冊時，它會依 Agent 自己報的網址替它簽一張伺服器身分證，而且還沒被核准的 Agent 也簽（這是已知的 #249）。兩件事加起來：攻擊者自稱網址是 https://api.anthropic.com，就拿到一張主系統會相信的「我是 Anthropic」身分證。

出事會怎樣：攻擊者站在主系統對外連線的中間（網路中間人），出示這張假證，主系統的 AI 呼叫（litellm）、更新站與授權站呼叫（httpx）、外部 S3（minio）、郵件寄送（SMTP STARTTLS）全部照單全收。AI 金鑰（Authorization 標頭）、郵件密碼、物件儲存密鑰、送去 AI 的證據內容都會外流。

要先有什麼才打得到：

• 安裝時預設啟用 Agent CA（預設就是）
• 任一租戶的 Agent 註冊碼（租戶管理員可自產，或裝 Agent 時發出去的碼外流）
• 能攔截或導向主系統容器的對外連線——這是最大門檻，所以是「中」不是「高」

在哪裡：

• docker/production/entrypoint.sh:44-51（合併信任庫、export SSL_CERT_FILE）
• scripts/installer/internal_tls.sh:15（把 pki/agent/ca.crt 複製成內部 CA——首腦核對：開檔確認，確實是同一把）
• 簽發端在 jedi-remote-agent 的 issue_credentials／san_from_base_url（已知 #249）

怎麼修：

1. entrypoint.sh 不再 export SSL_CERT_FILE；改成只把內部 CA 交給需要的客戶端：內建 SeaweedFS 的 minio 客戶端自帶 http_client（urllib3 PoolManager(ca_certs=/etc/guidant/internal-ca.crt)），Redis 用既有的 REDIS_SSL_CA_CERTS。
2. 或者 Redis／SeaweedFS 改用一把只簽內部服務、從不簽 Agent CSR的獨立 CA；或替 CA 加名稱限制（nameConstraints，限定只能簽內部服務名）。
3. 根源一併收：#249 修好（未核准 Agent 不簽 serverAuth、SAN 不吃 Agent 自報網址），這條的前提②就打不通。

首腦核對註記：中風險，非 HIGH，依卡片規則不強制逐條核；仍已開 internal_tls.sh:15 與 entrypoint.sh:48-51 確認信任鏈成立。與 §3.1 #249 是同一根源的新後果（#249 原本只講「CA 幫未核准者簽證」，本條補上「主系統對外全面信任這張證」），建議併卡處理。

• 「這些存在嗎」：F1 經三個獨立檢查員（分別從「打不打得到」「影響多大」「有沒有防線擋」三個角度）投票，3 票全數成立；首腦另開檔確認信任鏈。可信。
• 「只有這些嗎」：effort low＝單一研究員讀完 4 檔（另一名專掃寫死的密碼，無發現）。兩名研究員都有回報、無人中途失敗。但 low 是快篩，不是窮舉；人工逐條看過卡片列的七個重點，未再發現其他問題。不宣稱「只有這一條」。
• 所有結論都來自讀程式，沒有實際執行或打攻擊。