b4 驗證 V4：主機／版控殘留與日誌內容

卡：CM-2267（母卡 CM-2019）。2026-09-27 在 190（guidant-ai-be:1.21.0b4、agent 1.1.0b2）與本機四個 repo 驗。只驗不修。

最重要的兩件事：

1. #95 還沒修好。 AI 儀表板在問「使用者清單」時，後端一行紀錄把六個帳號的完整資料原文寫進容器紀錄，含密碼雜湊、加密鹽值、超級管理員旗標。回給畫面的內容乾淨，但紀錄那一端沒有遮。出處是 jedi-iam app/service/user_service.py 的 get_users 裡 logger.info(f"Get users: {users}")。這行寫到容器標準輸出，沒進 app.log 檔也沒進資料庫。
2. 版控殘留的清理全在 fix/security-b1，還沒合回 feature/review 與 main。 主 checkout 上 Google 四把金鑰與 JWT 簽章金鑰的殘留都還在，main 上也在。只要 fix/security-b1 如期合回，這幾條就會通過；但在那之前，任何從 main 或 feature/review clone 的人都拿得到。

• 版控：四個 repo（BE、FE、evidence-agent、套件 monorepo）用 git grep -I 對兩個 ref 各掃一次：fix/security-b1（出貨線，190 的 b4 就是從這條出的）與當下 HEAD（feature/review）。兩種掃法：
  • 字串形狀：AKIA…、AIza…、glpat-…、sk-…、lsv2_…、BEGIN … PRIVATE KEY、postgres://帳號:密碼@、redis://:密碼@、GOCSPX-…、ghp_…、ntn_…、JWT 三段式、password="…" 這類賦值。
  • 真值比對：從本機 .env 取 19 把現值，以及從修正卡 commit 的刪除行取出被清掉的舊值，逐一 git grep -F 計檔數。值只在記憶體比對，本報告只寫檔數。
• 190：用 API 實打觸發（登入、帳號欄帶換行、密碼帶雙引號、寄測試信到打不通的主機、偽造 X-Forwarded-For、叫 AI 儀表板查使用者），觸發字串帶一個本卡專用標記，再到 docker logs、/srv/guidant-ai/log/app.log、api_logs、system_logs 找標記與機密。DB 全部唯讀查詢。
• 分支版本：BE 12dee3157、FE 55ca905、agent 1b71a0c、套件 d94a472d（皆 fix/security-b1）。

190 的 api 容器 ENV=PRD、RUN_ENV=prod、DEBUG=false，沒設 LOG_LEVEL，所以走 jedi-common config_prod.py。

• 大宗是 ORM 對映紀錄：sqlalchemy.orm.mapper.Mapper、relationships、strategies.LazyLoader 在開機那一分鐘倒出約 6,000 行，全是 INFO。config_prod.py 裡 sqlalchemy.orm 設的是 INFO，註解說「調回 INFO」，但 SQLAlchemy 的對映設定紀錄本身就是 INFO 級，這個級別擋不掉。要擋得設 WARNING。
• 穩態主要是背景工作：drive_sync_worker 每 5 秒一行「system context entered」。
• app handler 級別寫死 DEBUG：config_prod.py 的 handlers.app.level 是 DEBUG，目前靠 logger 的 LOG_LEVEL 擋著所以沒冒出 DEBUG 行（app.log 內 DEBUG 0 行）。
• 本條原文說「三處已改一處，還剩兩處」，SUMMARY 標已修。實況是 pymongo 那處改了，sqlalchemy.orm 那處改成 INFO 仍不夠，是否算「還剩」的那兩處之一，要對原報告 M04-9 確認。

驗證清單把 #125 對到 CM-2178、#133 對到 CM-2180。兩張卡的標題分別是「合規範本七個寫入入口補權限」與「刪框架版本前改查資源庫」，都跟本條無關，應該是「總表第 N 項」與「SUMMARY 第 N 條」兩套編號撞號。本卡這兩條照白話自擬測法。

• OTP 驗證碼原文留在操作日誌：api_logs 的 /otp-verify 那筆 request 欄記的是完整六位數驗證碼，沒遮。驗證碼一次性、用過即失效，風險低於密碼；但它和帳號 uid 同一筆，在有效期內看得到操作日誌的人理論上可以搶先用。遮罩名單可考慮加 code。

• /mail/test 打不通時回 500：對方主機不回應時，要等整整 60 秒才回 COMMON_500001，使用者看不到「郵件伺服器連不上」。SMTP 轉接器對 TimeoutError 回 False，但例外還是往上冒到錯誤處理器。

• jedi-iam 登入成功會印整份 capability 清單：capability_service.get_capabilities:55 每次把所有能力點的完整物件寫成一行 INFO，一次約數 KB。屬 #125 的紀錄量問題。

• jedi-iam harness 有寫死的 smoke 密碼：jedi-iam/harness/dev_app.py:330。註解寫明「harness 本機專用，非任何環境憑證」，值跟 DEV 測試帳號不同。不是殘留憑證，記下避免之後掃描誤判。

出貨線全部是 0。以下是等 fix/security-b1 合回才會消失的：

main 上 Google 四項的檔數與 HEAD 相同。