本卡屬 FR-077（母卡 CM-1591），由原 R2（CM-1593，29 檔）拆出的後半。範圍：jedi-detection 的 agent 相關全部 ＋ 重疊帶入 agent_task 的兩支關鍵檔。只掃不修。

這一棒在做什麼（白話）

客戶機房的 agent 要執行掃描，得先跟雲端拿東西：要掃的源碼壓縮包、檢測設定檔。這一棒掃的就是「agent 憑什麼可以下載這些檔案」——授權判定在 agent_file_access_service.py，以及雲端反過來主動連 agent 的兩條路徑（測試連線、取消掃描）。

用 claude-security plugin 掃 13 檔並產出報告。只找問題、不修問題。

為什麼拆成這一棒（重要，影響你怎麼讀範圍）

原本 R2 是 29 檔一棒（agent_task 全鏈 ＋ jedi-detection agent）。R1（42 檔）證明了這個量級的面板撐不住——21 張票 0 張投出。手上唯一一次面板跑完的是 FR-076 L1（10 檔）。故決策者 2026-09-08 裁拆成兩棒，本棒是後半。

但這一刀切在接縫上，所以做了重疊處理，你要知道為什麼：檔案下載的授權判定是「這個檔案 uid，是不是該 agent 名下未完成任務引用的？」——問題的前半在本棒（agent_file_access_service.py），後半在 R2a（任務狀態機）。只掃本棒會看不到「任務狀態」是怎麼被拿來當授權依據的。

故 scope 額外帶入兩支 R2a 的檔：agent_task_domain_service.py（list_for_agent_by_status() 在這裡）與 agent_task_repo_impl.py（實際 query）。這兩支 R2a 也會掃，重複報同一條沒關係，首腦驗收時會挑掉；接縫沒人看才是真的損失。

重點看什麼

首腦讀過全部程式碼後標的。是思考起點不是檢查清單——工具不照清單走（R1 的 CRITICAL 是 runner 照卡片重點人工追出來的）。

• ① 檔案下載授權的論證要親自驗（本棒最大嫌疑）。agent_file_access_service.py 的授權是「逐一問 resolver，任一認可即放行」，resolver 判的是 file_uid ∈ 該 agent 名下未完成任務引用的檔案 uid 集合。agent 身分來自 X-Agent-Uid header 自報（route 在主專案，屬 R3）。docstring 的辯護是「自報成別台也只能拿到那台名下任務正在用的檔案」——驗這句話：_active_task_file_uids() 用 get_one_remote_agent(uid=agent_uid) 查 agent，有沒有 tenant 檢查？這條路徑無 user context（super admin 繞 RLS），那麼「別台 agent」包不包括別的租戶的 agent？
• ② 「讀回空 → 404」是真拒絕還是假象。CM-1559 盤點標這支「看起來像權限正常，實際是全部拒絕」。要分清「授權判定正確地拒絕」與「查詢因 context 問題回空而全部拒絕」——後者會掩蓋真實的授權缺陷（等哪天 context 修好了，洞就露出來）。這是本棒最容易誤判的一點。
• ③ resolver 清單的擴充性風險。self._resolvers = [self._source_file_resolver, self._profile_ref_resolver]，兩個都比對 params[key].uid。要問：params 是 agent 或使用者可影響的嗎（建任務時傳的）？若能把任意 file_uid 塞進某個任務的 params，是不是就自己給自己開了授權？
• ④ 未接線就靜默降級成 mode=none。jedi-detection/jedi_detection/common/agent_auth.py 的 _DisabledSettings——provider 沒接線時回 enabled=False，等同資料面完全不加認證，且 warning 只發一次。追它的三個 caller（取報告檔／測連線／取消掃描）在 enabled=False 時各自退化成什麼：裸 HTTP 嗎？打的是 agent 自報的 base_url 嗎（SSRF）？
• ⑤ 兩個 connector 的出站請求（agent_probe_client.py、agent_cancel_client.py）。照 FR-039 規矩必須走 build_cloud_mtls_context() ＋ jwt_util.mint()。逐支確認有沒有照做——第三處裸 httpx 是新發現。同時看：URL 怎麼組（base_url 是 agent 自報）、逾時、例外有沒有被靜默吞掉。
• ⑥ job_execution_detection_tool_agent 這條線（domain／infra 五檔）。記錄「哪次執行派給哪台 agent」。查詢有沒有帶 tenant？agent_id 是 soft-ref（無 FK 約束）到 remote_agents.id——跨租戶的 id 塞進來會怎樣？
• ⑦ 重疊帶入的兩支（agent_task_domain_service.py、agent_task_repo_impl.py）：本棒只看它們與檔案授權的接縫——list_for_agent_by_status(agent_id, tenant_id, status) 的 query 真的同時用了 agent_id 與 tenant_id 嗎？_ACTIVE_TASK_STATUSES 涵蓋 pending/dispatched/running，任務進終態後參照失效——這個「授權窗口」有沒有辦法被延長（例如讓任務永遠不進終態）？狀態機本身的完整性屬 R2a，不必在本棒展開。

已知背景

本範圍從未被掃過。R2a（CM-1593）掃任務狀態機與派工單，與本棒相鄰、只在⑦的兩支檔重疊。

• R1（CM-1592）已報 7 條，修正卡已開：F1 心跳無認證取走明文憑證（CRITICAL，CM-1595）／F3 心跳可跨租戶（CM-1595）／F2＋F5 ack·result 無認證不查歸屬（CM-1595）／F4 check_health SSRF（CM-1596）／F6 enroll token 接管註冊列（CM-1597）／F7 .env 越界（CM-1598）。撞到這些標「重複 R1 Fn」即可。