本卡屬 FR-186（Agent 本體資安掃描第二輪），第 4 批 N1：網路診斷探測（Agent repo，11 檔／約 907 行）。只掃不修。工作坊用
.claude/workshop-prompts/dispatch-<本卡號>.md當開場 prompt 直接啟動掃描。
用 Claude Code 官方 claude-security plugin 掃 Guidant AI Agent（repo evidence-agent）的「網路診斷探測」，找出資安問題，寫成 PM 與新手工程師都看得懂的報告。只找問題、不修問題。
FR-177 掃過（舊卡 CM-3531），之後有改動；這次重掃要回答兩件事：上次修的有沒有守住、新改的程式有沒有新洞。 範圍按業務模組垂直切（入口→流程→資料），權限漏洞常在層與層的接縫上。
guidant_agent/netdiag/adapters/probes
檔數 11、約 907 行。驗檔數：git ls-files -- guidant_agent/netdiag/adapters/probes | grep -v /tests/ | wc -l 應為 11。scope 外的檔不要當發現報；為核對呼叫端翻範圍外的檔可以，報告標「只為查證」。
首腦標的思考起點，不是檢查清單。掃完後 runner 逐條對一遍：工具沒報的，開檔看一眼寫「人工查過：成立／不成立／為什麼」。FR-177 的人工補查抓到的問題不比工具少。（以下沿用 FR-177 舊卡的重點，行號是舊版、以檔名與函式名為準。）
traceroute.py:28 argv = ["traceroute", "-6"/"-4", "-n", "-q", "1", ...] 再加 ctx.target.ip、ping.py:27 同型：target.ip 是 IP 字串還是可能是主機名——若是使用者填的字串以 - 開頭（例如 -f），run_cmd 的 list 形式擋得住 shell 但擋不住 ping 自己把它當選項；有沒有在 argv 加 -- 或先驗 ipaddress.ip_address()。netdiag_routes → netdiag.check → 清冊（B2 看過路由層）之後到這裡的 target 型別。mtr.py:14-25：用 traceroute 逐 ttl 模擬 mtr，MAX_PROBES／deadline 上限；mtu.py:16 size 參數範圍（ping -s 65507 沒事，但來源是什麼）。cloud.py:45-97：到主系統的探測——host = parts.hostname 從 cloud_base_url 解析、getaddrinfo；步驟輸出 raw=str(e)[:300] 會不會把內網 DNS 回應、憑證主體原文帶進報告；TLS 探測（tls.py）有沒有真的驗證憑證鏈還是只拿資訊。dns.py／port.py／http.py／ssh.py：純 Python socket 的探測——http.py 對任意 target 發 GET 會不會跟重導向（SSRF 跳板）、回應 body 存多少；ssh.py 只讀 banner 還是會嘗試認證；port.py 掃幾個 port、上限（會不會被拿來當 port scanner）。__init__.py:63 行：十項探測的登記與 ProbeContext——ctx.timeout() 的來源、limits 由誰設（netdiag/domain/limits.py 在 C8）；有沒有探測繞過 run_cmd 直接 subprocess（守衛測試應擋，確認 grep -rn subprocess probes/ 只有 __init__ 的 import）。clip 到 64KB 後進報告——report.py（C8）會把 raw 輸出原文放進給使用者下載的報告，內網拓撲（每一跳的 IP）是刻意要給的，但有沒有把 Agent 自己的環境資訊（容器內 hostname、路徑）帶出去。FR-177 25 棒報告在 Agent repo docs/security-scan/FR-177/scan-*.md，已登記的 22 條在主系統 repo docs/features/security-scan-consolidated/README.md §3.1 第 219～240 項（全部已修）。已修而且修法成立的不重報；修法不完整、或同一族換個欄位又出現，才報並註明對應項次。