這張卡只改 docs/security-report/M01-remote-agent.md 一個檔，改完重 build。不碰需求中心的原始技術報告，不碰其他模組頁。母案 FR-077（遠端代理程式資安掃描）。格式比照 CM-1981（M02 內化修訂）。

這張卡在做什麼

資安總報告的 M01 頁已經寫好，但那是「工具查到什麼」的整理版。講者（決策者）逐條讀過、回程式碼與實機查證過，過程中發現多條描述不準或會誤導，查出一條報告完全沒抓到的問題，並對六件事下了判斷。這張卡把那些更正與判斷寫進文件。

為什麼要做：這份報告會被當成稽核證據拿給客戶與老闆看。M01 是全案唯一「最嚴重」等級那一塊，最可能被追問。目前頁面上有幾處描述在被追問時會站不住，必須先修。

一、第 1 條：mTLS 的敘述要整段重寫（最重要的更正）

E1 — 不是「nginx 設定裡少了那一行」，是 mTLS 從未實作

報告目前寫「程式註解說 nginx 會驗客戶端憑證，但出貨的三個 nginx 設定檔裡那一行不存在」。這個寫法會讓讀者以為是「設定漏填」。實際查證後要改成更準確的說法。

• 實查三支 nginx 設定（FE repo：nginx.conf / nginx.onprem.conf / nginx.e2e.conf）：ssl_verify_client 與 ssl_client_certificate 全部零命中。落地版那份確實有 HTTPS（443 + 憑證 + TLS 1.2/1.3），但那是單向的——我們向對方證明自己是 Guidant，不驗對方是誰。
• 實機查證 189（POC）與 190（E2E）兩台安裝版 stack，容器內 nginx 設定同樣零命中。安裝包那邊沒有另外補上。
• TLS 的機制是：伺服器不開口要憑證，客戶端就不會送。所以正確描述是「我們這端從來沒開口要」，不是「送來了沒人看」。
• 改法：把「設定檔少一行」的敘述改成「雙向憑證驗證從未實作——程式端假設由基礎設施把關，基礎設施端不知道有這個要求，中間那道門沒有人蓋」。這比原敘述更誠實，也更能解釋為什麼會發生。

E2 — 那段註解已經過期，agent 端的 nginx 一個月前就退役了

註解與套件 README 說「身分靠 mTLS（網路層由 nginx 終結）」。但 evidence-agent 的 nginx sidecar 在 2026-08-20 就整個退役了（commit 91cef8f，FR-066.3 D4），mTLS 邏輯收回 agent 內部自己承接。

• 位置：jedi-remote-agent/jedi_remote_agent/api/guards.py 檔頭、api/routes/remote_agent_route.py:8-11、api/routing.py:10-13、README.md:301-302。
• 這不是資安漏洞，但下一個接手的工程師會照著這句話判斷「已經有人在把關」——跟這次一樣。要一併改掉。
• 文件上要寫進「為什麼這種事會發生」那段：註解不會執行，所以它永遠不會報錯；沒有任何機制會檢查「註解裡的假設有沒有成真」。

E3 — 補上「憑證其實已經備齊」這個有利事實（實機證據）

報告目前只講缺什麼，沒講已經有什麼。實機查 190（唯一有真 agent 在跑的環境）：

• agent 手上有完整憑證三件套：agent.crt + 私鑰 + ca.crt（docker volume guidant-ai-agent_agent-certs）。
• 憑證是我們自己的 CA 簽的：issuer=CN=Guidant Agent CA, O=Guidant AI；subject 是這台機器的指紋。