FR-186.H4 掃 Agent「主機端升級與清除腳本」（8 檔／1292 行，Opus 1M effort low，只掃不修）

本卡屬 FR-186（Agent 本體資安掃描第二輪），第 4 批 H4：主機端升級與清除腳本（Agent repo，8 檔／約 1292 行）。只掃不修。工作坊用 .claude/workshop-prompts/dispatch-<本卡號>.md 當開場 prompt 直接啟動掃描。

這一棒在做什麼（白話）

用 Claude Code 官方 claude-security plugin 掃 Guidant AI Agent（repo evidence-agent）的「主機端升級與清除腳本」，找出資安問題，寫成 PM 與新手工程師都看得懂的報告。只找問題、不修問題。

為什麼切這一塊

FR-177 掃過（舊卡 CM-3524），之後有改動；這次重掃要回答兩件事：上次修的有沒有守住、新改的程式有沒有新洞。範圍按業務模組垂直切（入口→流程→資料），權限漏洞常在層與層的接縫上。

掃描範圍（scope，與開場 prompt 的 --scope 一致）

scripts/install/lib/upgrade_order.sh
scripts/install/lib/upgrade_runner.sh
scripts/install/lib/upgrade_guard.sh
scripts/install/lib/image_verify.sh
scripts/install/lib/wipe.sh
scripts/install/lib/systemd/guidant-agent-upgrade-boot-check.service
scripts/install/lib/systemd/guidant-agent-upgrade-order.path
scripts/install/lib/systemd/guidant-agent-upgrade-order.service

檔數 8、約 1292 行。驗檔數：git ls-files -- scripts/install/lib/upgrade_order.sh scripts/install/lib/upgrade_runner.sh scripts/install/lib/upgrade_guard.sh scripts/install/lib/image_verify.sh scripts/install/lib/wipe.sh scripts/install/lib/systemd/guidant-agent-upgrade-boot-check.service scripts/install/lib/systemd/guidant-agent-upgrade-order.path scripts/install/lib/systemd/guidant-agent-upgrade-order.service | grep -v /tests/ | wc -l 應為 8。scope 外的檔不要當發現報；為核對呼叫端翻範圍外的檔可以，報告標「只為查證」。

重點看什麼

首腦標的思考起點，不是檢查清單。掃完後 runner 逐條對一遍：工具沒報的，開檔看一眼寫「人工查過：成立／不成立／為什麼」。FR-177 的人工補查抓到的問題不比工具少。（以下沿用 FR-177 舊卡的重點，行號是舊版、以檔名與函式名為準。）

🔴 upgrade_runner.sh:50 _upr_source：source <(docker run ... cat 新映像裡的 install-lib/$1)——這行在 upgrade_order.sh:404-416 的驗章（用現行版 verify-tree 驗新映像程式樹）之前還是之後執行？若在之前，等於新映像的 bash 在驗章前就以 root 跑了，A3 「新版程式在這之前一行都沒執行」的結論不成立。追 _upr_source 的每個呼叫點（:195-196、:302、:434、:472）與 $1 來源，畫出時序。
upgrade_order.sh:265-276 _uo_precheck：target／bundle／sha 的格式驗證（regex）之後，這三個值進了哪些指令——有沒有未加引號的展開、eval、或拼進 docker run 的參數；升級單 JSON 怎麼解析（jq？python -c？自己 grep？），欄位值含換行或引號會怎樣。
upgrade_order.sh:404-416：docker run --rm --network none -v tree:/verify:ro --entrypoint .../evidence-agent $old_id verify-tree /verify——$old_id 怎麼取得（從 .env 的 AGENT_IMAGE？若 .env 被改成指向攻擊者映像，「現行版」就是攻擊者的）；cmp 比對 install.sh／docker-compose.yml 之後，實際執行的是哪一份（包內的還是樹內的）。
upgrade_runner.sh:204-263：rm -rf "$VERSION_DIR"／"$staging"／"$UPR_BACKUP_DIR"——這些變數有沒有可能為空或含空白（rm -rf "" 無害但 rm -rf "$X/" 在 X 空時是 /）；chown_agent_volumes 範圍；:242 .env 寫回時 0600 之前有沒有先以預設權限落地（同 A1 M1 病）。
upgrade_runner.sh:35 UPG_LIMIT_SWITCH、:464 UPG_TRIGGER_*、SUDO_USER：環境變數有哪些能影響流程（誰能設——systemd unit？容器？）；--rollback（:541）切回上一版的路徑有沒有同樣的驗章。
upgrade_guard.sh:16 docker exec "$AGENT_SERVICE" cat /data/db/$1：$1 來源、能不能是 ../；守衛判「有掃描在跑就不升級」的依據是容器內的檔，容器被控時能讓升級永遠擋住（DoS 更新）或永遠放行。
三支腳本有沒有 set -euo pipefail；錯誤時進度檔寫什麼（A3 觀察 2：Agent 只信進度檔，進度檔格式與誰能寫）。
回歸檢查：FR-177 在這塊修過 #234 手動升級路徑補驗章（新 image_verify.sh）——確認修法還在、沒被後來的 commit 弄回去、也沒有旁路。

已知背景

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 項（全部已修）。已修而且修法成立的不重報；修法不完整、或同一族換個欄位又出現，才報並註明對應項次。