R1 掃描結果：Agent 身分與註冊（jedi-remote-agent）

掃描日期：2026-09-07 掃描版本：jedi-python-package feature/FR-075 @ 8aa6f0609c4434c0fa5206d5e99e31cad249646e（乾淨，無未 commit 變更） 工具：Claude Code claude-security plugin v0.10.2.3（claude-security:scan workflow） 範圍：jedi-remote-agent/jedi_remote_agent/ 的 api/、common/、domain/remote_agent/、infra/remote_agent/、三支 app service、plugin.py、__init__.py，42 個受版控檔案（啟動前 git ls-files 驗過，與卡片數字吻合） effort：low，focus：attack-surface 模型：主 session Opus 5 (1M context)，研究員繼承 狀態：🔴 驗證面板未跑成，stamp 為 verification.status: unverified——研究階段完整完成，但 21 張面板票全部因 session 額度上限失敗。本報告全部發現皆為研究員原始宣稱 ＋ runner 人工開檔核對，未經面板背書。 對應卡片：CM-1592（母卡 CM-1591）

範圍內找到 6 條實質問題（3 條 HIGH／3 條 MEDIUM），核心是一件事：四個控制面端點完全沒有任何認證，而它們宣稱倚賴的 mTLS 在出貨的 nginx 設定裡根本沒有配置——nginx.onprem.conf 全檔沒有一行 ssl_verify_client。於是 agent 身分只剩「請求自己說它是誰」，任何能連到 API 的人都能冒充任一台 agent，拿走該租戶掃描工具的明文帳密。第 7 條（.env 進版控）屬越界，事實成立但不在本棒範圍。

先看這張表就好，每條的完整核對過程、程式碼行號與建議修法在後面各自的章節（點 ID 跳過去）。

F1 F3 F2 F5 四條是同一個根因——四個控制面端點都不掛認證，而它們宣稱倚賴的 nginx mTLS 在出貨設定裡不存在（見下一節）。故併成一張修正卡（CM-1595）。

⚠️ 這份結果的可信度

七條的「存在」可信；「只有這七條」不可信。

掃描工具的三人驗證面板全部因 session 額度用盡沒跑成（105 個 verifier 全滅，21 張票 0 張投出），工具正式 findings 因此是空陣列，stamp 記 verification.status: unverified。少掉的那一環是「幫忙抓誤報」。

但這七條的複審由人做了兩遍：runner 逐條開檔核對行號與 caller，首腦（2026-09-08）再親自複核 F1／F2／F3 行號、grep BE 與 FE 兩個 repo 確認三個 nginx 設定檔皆無 ssl_verify_client、追明文憑證流向到 detection_task_payload_provider.py:110-127。每一條都是「打開檔案，那幾行就是那樣寫的」——事實陳述而非推論，不需投票確認其存在。

不可信的是覆蓋率：卡片列的八個重點只實質觸及一個，其中「簽憑證」（ca.py）與「簽 JWT」（jwt_util.py）零發現，面板未跑的情況下分不出「讀過判定沒問題」與「根本沒讀到」（見文末「待追但本次未涵蓋」）。故加開補掃棒 CM-1599（R1b），只掃這 10 檔。

🔴 為什麼 findings 是空的：面板全滅於額度上限

CLAUDE-SECURITY-REVISION-8aa6f0609c44.json 的 stamp 寫得很直白：

verification.status: unverified
verification.reason: 7 panel round(s) were dispatched but none completed a full
                     3-voter review; no candidate was actually verified

105 個 verifier 全部回同一個錯誤：You've hit your session limit · resets 11:10pm。 七條候選在 votes.json 裡全部標 continued: true（"handed to the next verification run"）， 正式 findings 陣列因此為空。

這不是「掃乾淨了」，恰恰相反——研究階段找到的東西一條都沒被否決過，只是沒人投票。 FR-076 L1 的經驗是候選數 × 3 個 verifier、每個從零讀檔，面板本身比研究階段更貴； 本棒 7 條候選要 21 票，撞上額度重置窗口即全滅。

處置：依卡片「中途失敗怎麼辦」段的精神，候選已從 workflow 回傳完整撈出（無遺失， 每條含檔案行號、rationale、影響、觸發前提、建議修法），改由 runner 逐條開檔人工核對 補上驗證。卡片本就要求「HIGH 級每條自己開檔核對，不要只信工具輸出」——這裡把它擴大到全部七條。 不重跑掃描（all-or-nothing，重跑只是再燒一次額度）。

每條的核對狀態

六條範圍內發現有五條可以追到同一個地方，先講清楚它，個別發現才好讀。

設計是怎麼說的

ROUTE_TABLE 第三欄是「顯式的認證意圖宣告」，四個控制面端點都填 False：

# jedi-remote-agent/jedi_remote_agent/api/remote_agent_route.py:220-223
("/agents/register",                  AgentRegisterRoute,   False),
("/agents/heartbeat",                 AgentHeartbeatRoute,  False),
("/agents/tasks/<string:uid>/ack",    AgentTaskAckRoute,    False),
("/agents/tasks/<string:uid>/result", AgentTaskResultRoute, False),

plugin.py:create_blueprint() 照這張表掛載，False 就是完全不套任何 decorator：

api.add_resource(_guard(resource, adapters.admin_required) if needs_admin else resource, path)

程式碼註解解釋這是刻意的，且說明了替代的守門在哪：

• plugin.py 的 admin_required docstring：「控制面端點（register / heartbeat / ack / result）不套這個——agent 不帶 user JWT，身分靠 mTLS。硬套上去會讓所有既有 agent 立刻掉線。」
• heartbeat() 的 docstring：「指紋變動 → 自動更新 + 留痕（mTLS 已在網路層驗 client cert）。」

讀到這裡，設計是自洽的：應用層不驗身分，因為網路層已經驗過了。

實際上網路層沒有驗

出貨的落地版 ingress 是 compliance-manager-fe/nginx.onprem.conf。它只有一個 location /api/1.0 區塊，把所有 API 路徑一律 proxy 到 guidant-api:8000：

# compliance-manager-fe/nginx.onprem.conf:88-90
location /api/1.0 {
    set $api_upstream guidant-api;
    proxy_pass http://$api_upstream:8000;

註解自己寫著「BE 全部 HTTP route 都掛在 /api/1.0 底下，故單一 location 即可涵蓋，不需逐模組列舉」—— 換句話說，/agents/heartbeat 與 /api/1.0/projects 走的是同一個沒有客戶端憑證要求的入口。

三個 nginx 設定檔（nginx.conf、nginx.e2e.conf、nginx.onprem.conf）全部 grep 不到任何一行 ssl_verify_client。 「mTLS 在網路層終結」這個前提，在出貨形態下不成立。

產品自己也記錄了這件事

主專案的 api/remote_agent/routes/agent_file_route.py:14 檔頭寫著：

認證形狀與套件內的 ack / result 一致（純 mTLS 不掛 jwt）；agent 身分由 X-Agent-Uid header 自報（與心跳 payload 自報 agent_uid 同構——BE 不自己終結 TLS，拿不到 client 憑證）。

這句話同時是設計說明與問題陳述：BE 拿不到 client 憑證，所以只能讓 agent 自報身分。 只要上游沒有真的在驗憑證，「自報」就是身分的全部。

再加上一層：控制面跑在 super admin scope

四個控制面端點都沒有 user context，@transaction 的 session_scope 因此走 app.is_super_admin='t'（CM-1559 已知的 RLS fail-open 機制）。這代表控制面的每一次 DB 查詢都繞過租戶隔離——heartbeat() 用 uid 查 agent 時查的是全庫，不是某個租戶的子集。

與 CM-1559 的關係：「無 user context 時 session_scope 拿 super admin 繞 RLS」這個 機制本身重複 CM-1559，不重報。但它在 agent 鏈上造成的具體可利用後果（跨租戶取 agent 身分、跨租戶改任務狀態）是本棒的新發現，列在下面。

這條鏈的最終落點是明文憑證

心跳成功後回傳 _collect_pending_tasks(agent)，內容由宿主的 payload provider 組。 主專案的實作會解密兩樣東西放進 HTTP 回應：

# compliance-manager-be/app/remote_agent/adapter/detection_task_payload_provider.py:66-71
params = decrypt_secret_params(t.params, self._secret_keys_for(t.detection_tool_id), self._crypto)
payloads.append({
    ...
    "params": self._inject_source_file_limits(params),
    "credentials": self._resolve_tool_credentials(t.detection_tool_id, tenant_id),
})

_resolve_tool_credentials()（同檔 :110-127）把 tenant_detection_tool_configs.credentials_encrypted Fernet 解密後與 field_values 合併回傳——該租戶掃描工具的明文帳密（SonarQube token、 WinRM／SSH 憑證、掃描器 API key 等，視工具而定）。

所以整條鏈是：沒有認證的端點 → 自報身分即通過 → 繞過 RLS 查到任一租戶的 agent → 回應夾帶該租戶的明文第三方憑證。

嚴重度：HIGH · 研究員信心：HIGH · 面板：未投票 · runner 核對：屬實 · CWE-306 位置：jedi-remote-agent/jedi_remote_agent/app/service/agent_enrollment_service.py:274-311

問題在說什麼（白話）

agent 每隔幾分鐘要跟雲端「報到」一次，順便問「有沒有新工作給我」。雲端回覆的內容裡， 除了工作清單，還附上執行那份工作所需的帳號密碼——例如要掃描客戶的 SonarQube， 就得把 SonarQube 的 token 一起給它。這是設計上必要的（agent 在客戶機房、不連雲端 DB）。

問題是：雲端完全不檢查來報到的是不是真的 agent。這個端點沒有掛任何認證， 而判斷「你是哪一台」的唯一依據，是請求內容裡自己寫的那個 agent_uid 字串。

任何能連到這個 API 的人，只要知道一台 agent 的 uid，送一個 HTTP 請求過去， 就會收到那台 agent 名下待辦工作的完整內容——包含解密後的明文憑證。

核對過程

① 端點確實沒有認證——ROUTE_TABLE:221 第三欄 False，plugin.py 的 create_blueprint 對 False 的項目直接 api.add_resource(resource, path)，不經過 _guard()。

② 身分確實只看自報值——heartbeat() 從 request body 取值後直接拿去查：

# agent_enrollment_service.py:277-286
agent_uid  = (payload.get("agent_uid")  or "").strip()
device_uuid = (payload.get("device_uuid") or "").strip()
agent = None
if agent_uid:
    agent = self._agents.get_one_remote_agent(uid=agent_uid)      # ← 沒有 tenant_id
if not agent:
    agent = self._agents.get_one_remote_agent(device_fingerprint=device_uuid)  # ← 也沒有

這兩個查詢都沒有 tenant_id 條件。對照同一支檔案的 register() 走的 _resolve_agent() （:94-99），它有做租戶檢查：

if agent_uid:
    found = self._agents.get_one_remote_agent(uid=agent_uid)
    if found and found.tenant_id == tenant_id:      # ← register 有這道，heartbeat 沒有
        return found, True

差異是真的（卡片重點④的推測命中）。加上控制面跑在 super admin scope（RLS 繞過）， get_one_remote_agent(uid=...) 查的是全庫。

③ 回應確實含明文憑證——heartbeat() 最後一行回 _collect_pending_tasks(agent)， 路徑追到主專案 detection_task_payload_provider.py:110-127 的 _resolve_tool_credentials()， self._crypto.decrypt(config.credentials_encrypted) 後合併回傳。確認屬實。

④ mTLS 前提不成立——見上方根因段，nginx.onprem.conf 無 ssl_verify_client。

影響

• 跨租戶的第三方憑證外洩。攻擊者拿到的不是本產品的密碼，是客戶被掃描系統的密碼 （SonarQube token、遠端執行用的 WinRM／SSH 帳密等）。這些憑證通往客戶自己的基礎設施， 外洩後的爆炸半徑遠大於本產品。UI 上這些欄位是被 strip_secret_params 特意遮蔽的， 代表產品自己認定它們不該被一般使用者看到。
• 同一個請求還能寫入。心跳會 update last_seen_at、device_fingerprint、agent_version、 capabilities。攻擊者可以把 capabilities 洗掉，讓那台 agent 失去 detection_scan 的 派工資格（靜默的服務阻斷）；或持續打心跳，讓一台已經死掉的 agent 在畫面上永遠顯示在線。

觸發前提

1. 能連到 POST /api/1.0/agents/heartbeat。落地版形態下這與一般 API 同一個入口， 沒有額外的網路層阻隔。不需要任何帳號、token 或憑證。
2. 知道一個 agent_uid 或 device_fingerprint。agent_uid 會回給一般已登入使用者 （api/flow_control/serializers/job.py:104、:232 的 agent_uid 欄位在工作設定讀取路徑上）， 所以一個低權限專案成員即可取得；而 uid 是 UUID，猜測不可行，需要先取得。
3. 該 agent 名下有 pending 任務（否則 pending_tasks 為空，重放等待即可）。

⚠️ 前提②讓這條的實際門檻落在「一個低權限的租戶內使用者」，而非「完全的外部匿名者」。 但端點本身不驗證任何身分，所以取得 uid 的管道不限於 UI——任何曾經持有過一台 agent 的人、 任何看過封包或日誌的人都算。

建議修法

讓身分變成「證明」而不是「宣稱」。三個層次，由內而外：

1. 應用層自己驗（治本，且不依賴部署設定）：agent 在註冊時已經拿到雲端簽的憑證與 JWT 公鑰，讓它用對應私鑰對心跳內容簽名，雲端用 remote_agents 存的公鑰驗。 驗不過就拒絕，fail closed。
2. 補上租戶邊界：heartbeat() 的兩處查詢比照 register() 帶上由驗證身分推導出的 tenant_id，指紋 fallback 尤其不可跨租戶（VM 模板複製會撞指紋，見 F6 的討論）。
3. 修正部署設定：若要維持「mTLS 在 nginx 終結」的設計，nginx.onprem.conf 就必須 為 /api/1.0/agents/ 路徑加上 ssl_verify_client on; 與 CA 設定，並把驗證結果 （憑證 subject／serial）以可信 header 傳給 BE 比對。但這不能是唯一防線—— 應用層仍應在拿不到已驗證身分時拒絕，而不是放行。

嚴重度：HIGH · 研究員信心：HIGH · 面板：未投票 · runner 核對：屬實 · CWE-290 位置：jedi-remote-agent/jedi_remote_agent/app/service/agent_enrollment_service.py:286

與 F1 的關係

F1 講的是「外部沒有身分的人能不能取得 agent 的資料」，F3 講的是「已經合法持有一台 agent 的租戶 A，能不能拿去讀租戶 B 的資料」。兩者根因相同（身分自報＋查詢無租戶條件）， 但威脅模型不同、修法的必要條件也不同：即使明天把 nginx 的 mTLS 補上，F1 被擋住了， F3 仍然成立——因為 nginx 只驗「這是不是一張我們簽的合法憑證」，不驗「這張憑證對應的 是不是你宣稱的那台 agent」，而應用層從頭到尾沒有把兩者做比對。

建議併卡處理，但修正必須涵蓋比對步驟，只補 nginx 設定不算修好。

核對過程

同 F1 的②：heartbeat() 兩處查詢皆無 tenant_id，且執行於 super admin scope（RLS 繞過）。 get_one_remote_agent() 的實作（domain/remote_agent/service/remote_agent_domain_service.py:33-35） 是純粹的 get_one_by_fields(RemoteAgentQueryEntity(**kwargs))，傳什麼查什麼，本身不加任何隱含條件。 確認：只要 uid 對得上，跨租戶取得。

影響

租戶 A 的合法 agent（或其操作者）取得租戶 B 某台 agent 的 uid 後，即可拿到 B 的待辦任務 與明文工具憑證。多租戶隔離在這條路徑上完全不存在。

觸發前提

1. 能連到心跳端點（同 F1）。
2. 知道另一個租戶某台 agent 的 uid。這是本條的實際門檻——uid 是 UUID，跨租戶取得 並不容易，但 F1 的心跳回應本身就是一個可以反覆探測的管道，兩條串起來會互相放大。
3. 在未來補上 mTLS 的部署裡，還需要持有任何一張合法 agent 憑證（不需要是目標那張）。

建議修法

同 F1 的 1 與 2。關鍵句：驗證得到的身分必須與請求宣稱的身分做比對， agent_uid 只能當交叉檢查用，不能當身分來源。

嚴重度：HIGH · 研究員信心：HIGH · 面板：未投票 · runner 核對：屬實 · CWE-306 位置：jedi-remote-agent/jedi_remote_agent/api/remote_agent_route.py:199-210、:222-223； jedi-remote-agent/jedi_remote_agent/app/service/agent_task_service.py:73-107

問題在說什麼（白話）

agent 做完一份掃描工作後，會回報「我做完了，結果在這裡」。雲端收到後， 會把這份結果轉成合規稽核證據存進客戶的稽核紀錄——這是本產品的核心產出物。

回報用的兩個端點同樣沒有任何認證，而且不檢查「這份工作是不是你的」。 只要知道一個任務編號，任何人都可以宣告那份工作「成功完成」並附上自己編的結果， 或宣告「失敗」把真正的掃描結果蓋掉。

核對過程

① 無認證——ROUTE_TABLE:222-223 兩條第三欄皆 False。

② handler 不驗身分——uid 直接來自 URL、body 直接來自 request.get_json()：

# api/remote_agent_route.py:199-210
class AgentTaskAckRoute(MethodResource):
    def post(self, uid):
        return _ok(_ctx().agent_task_service.ack_task(uid))

class AgentTaskResultRoute(MethodResource):
    def post(self, uid):
        payload = request.get_json(silent=True) or {}
        return _ok(_ctx().agent_task_service.receive_result(uid, payload))

③ service 層也不驗歸屬——receive_result()（agent_task_service.py:86-107） 只做了一件與安全有關的檢查：task.status == "cancelled" 就短路（那是 CM-931 的競合防護， 不是授權）。之後直接 write_success(uid, payload.get("result_ref"), _AGENT_ACTOR)。 全程沒有任何 agent 身分、沒有任何 agent_id 或 tenant_id 比對。

④ 結果會進稽核紀錄——write_success 後呼叫 self._listener.on_scan_succeeded(task, payload.get("summary"))， summary 是攻擊者提供的。主專案的 listener 負責把它轉成證據。

⑤ 同樣繞 RLS——@transaction 無 user context → super admin scope，故偽造的寫入不受租戶限制。

影響

合規證據的完整性被破壞，這比資料外洩更難察覺：

• 把一份從未執行的掃描標記為 succeeded，附上攻擊者選定的 result_ref， 稽核紀錄上就出現一份「乾淨」的掃描結果。
• 或把真實掃描標記為 failed 並附上任意 error_message，讓真正發現問題的結果消失。
• 由於繞過 RLS，可對任一租戶的任務下手。

對一個合規稽核產品而言，這是核心產出物的信任基礎被動搖——客戶拿這些紀錄去應付外部稽核。

觸發前提

1. 能連到 POST /api/1.0/agents/tasks/<uid>/ack 或 /result。不需任何憑證。
2. 知道一個任務 uid。取得管道：任一 agent 從自己的心跳回應就能看到； 或透過 F1 的心跳端點探測取得（兩條發現互相放大）。

建議修法

1. 把任務綁定到呼叫者：要求已驗證的 agent 身分（同 F1 的修法 1）， 並檢查 agent_tasks.agent_id 與 tenant_id 是否與該 agent 相符，不符即拒絕。
2. ROUTE_TABLE 第三欄從布林改成可表達「agent 認證」的第三種狀態。目前這一欄只有 True（管理員）／False（無），沒有辦法表達「要驗，但驗的是 agent 不是使用者」—— 於是控制面端點只能填 False，看起來就像刻意公開。建議加一個 agent_required adapter 插槽，讓認證意圖宣告能誠實反映實際需求。
3. 把 uid 當識別碼，不要當授權憑證。目前的實質安全模型是「知道 UUID 就有權操作」， 這對會出現在日誌、回應、封包裡的識別碼而言不是可接受的保護。

嚴重度：MEDIUM · 研究員信心：HIGH · 面板：未投票 · runner 核對：屬實 · CWE-862 位置：同 F2

研究員把同一組端點報了兩次：F2 從「沒有認證」（CWE-306）切入，F5 從「沒有授權檢查」 （CWE-862）切入。兩條講的是同一段程式碼的同一個缺口，差別只在描述角度。

建議與 F2 併為一張修正卡（符合首腦手冊第五節「同檔同根因併一張」的判準）。 獨立列出是為了保留研究員的原始分析——F5 的敘述把「即使有了 agent 認證，仍然需要 逐任務比對歸屬」這點講得比 F2 清楚，修正時兩個層面都要做到。

嚴重度：MEDIUM · 研究員信心：HIGH · 面板：未投票 · runner 核對：屬實 · CWE-918 位置：jedi-remote-agent/jedi_remote_agent/app/service/remote_agent_service.py:47-70

問題在說什麼（白話）

管理頁有一個「測試連線」按鈕，讓管理員確認某台 agent 是否連得上。 它的做法是：把使用者填的網址拿去發一個 HTTP 請求，然後把結果回報給使用者。

問題是這個網址沒有任何限制。填什麼就打什麼——包括只有伺服器連得到、 從外面連不到的內網位址。伺服器變成攻擊者的代理人，替他去敲內網的門， 再把「敲得開／敲不開」回報回來。

核對過程

base_url 來自 request body，未經任何過濾直接進 httpx.get：

# api/remote_agent_route.py:92-94
def post(self):
    payload = request.get_json(silent=True) or {}
    return _ok(_ctx().remote_agent_service.check_health(payload.get("base_url")))

# app/service/remote_agent_service.py:55-69
url = (base_url or "").strip().rstrip("/")
if not url:
    return {"reachable": False, "detail": "base_url 為空"}
try:
    settings = self._settings()
    if settings.enabled and url.startswith("https://"):
        ...
    else:
        resp = httpx.get(f"{url}/health", timeout=_HEALTH_TIMEOUT)   # ← 無任何位址檢查
    return {"reachable": resp.status_code == 200, "status_code": resp.status_code}
except Exception as e:
    return {"reachable": False, "detail": str(e)[:200]}

確認三件事：

• 沒有 scheme／host／私網位址檢查，屬實。
• 回應會回傳 status_code 與截斷的例外訊息，這使它成為一個可讀的探測管道（oracle）， 而不只是盲打。
• 研究員指出 /health 後綴不構成限制（用 query string 可吸收），這在字串串接 f"{url}/health" 的寫法下屬實。

影響

從應用伺服器的網路位置探測內網服務與連接埠、雲端 metadata endpoint 等。 回傳的狀態碼與錯誤訊息足以區分「服務存在但拒絕」與「完全不通」。

觸發前提

1. 需要租戶管理員權限——這條端點的 ROUTE_TABLE:219 第三欄是 True， 確實有套 admin_required。這是它比 F1／F2 低一級的原因：需要一個合法的管理帳號。
2. mode=none（預設值，config.py:261）或目標為 http 時走裸 httpx.get 分支。

建議修法

base_url 撥號前先驗證：只允許 http／https，解析主機名後拒絕 loopback、link-local 與 RFC1918 位址（解析後再檢查一次以避免 DNS rebinding）。 更穩健的做法是根本不接受自由輸入——健康檢查只允許對該租戶 remote_agents 表裡 已登記的 base_url 執行，讓 request 傳 agent uid 而非網址。

嚴重度：MEDIUM · 研究員信心：MEDIUM · 面板：未投票 · runner 核對：屬實 · CWE-639 位置：jedi-remote-agent/jedi_remote_agent/app/service/agent_enrollment_service.py:94-99（_resolve_agent）、 :186-238（register）、:123-186（_guard_fingerprint_collision）

問題在說什麼（白話）

客戶安裝 agent 時，安裝程式裡帶著一組「報到用的通行碼」（enroll token）。 這組碼是整個租戶共用一組，發給該客戶的每一台機器。

註冊時，機器可以宣告「我是編號 X 那台」。程式看到這個宣告後，只檢查「編號 X 是不是 屬於這個租戶」，就允許它覆寫編號 X 那一列的內容——包括那台 agent 的網址。

於是：拿到安裝碼的人（客戶端任何一台機器的操作者），只要知道另一台 agent 的編號， 就能把那台的網址改成自己的位址。之後雲端要向那台 agent 取資料時，會打到攻擊者那裡。

核對過程

① _resolve_agent 只檢查租戶，不檢查持有證明：

# agent_enrollment_service.py:94-99
if agent_uid:
    found = self._agents.get_one_remote_agent(uid=agent_uid)
    if found and found.tenant_id == tenant_id:
        return found, True          # ← matched_by_uid=True，僅憑「說出 uid」即成立

② 撞號守門對 matched_by_uid 的情況直接豁免：

# agent_enrollment_service.py:167-172
resolved_uid = getattr(resolved, "uid", None) if matched_by_uid else None
for holder in holders:
    if holder.uid == resolved_uid:
        continue                    # ← 認定「就是這次要更新的那一列」，跳過檢查

③ 接著就覆寫該列（:216-228）：base_url、device_fingerprint、status="active"、 enabled=True 全部以請求提供的值更新。

關於卡片重點③提到的 2026-08-21 那次修正：docstring 詳細記載了「原本只比 resolved.uid 而非 matched_by_uid」的錯誤與實測過程。這一版的判定是對的——resolved_uid 確實 用 if matched_by_uid 做了條件化，指紋 fallback 撞上的那一列不會被豁免。那個 bug 確實修好了。

但修好的是另一個問題。那次修的是「複製出來的 VM 冒充原機」（無 uid，靠指紋撞上）； 本條講的是「知道 uid 的人主動宣告」——後者走的正是被豁免的那條路徑，而豁免的成立條件 只有「說得出 uid」＋「同租戶」，沒有任何持有證明。註解說服了研究員這裡是安全的， 但它證明的是另一件事。（這正是首腦手冊第二節「會被程式碼註解說服」的盲點， 差別是這次註解沒有錯，只是回答的不是這個問題。）

影響

被接管的 agent 列 base_url 指向攻擊者主機後，雲端主動打 agent 的路徑 （reconcile 的 /blob/<name>/sha256、檢測報告取回）都會導向攻擊者， 使其能供應偽造的掃描報告並被存為稽核證據。為該 agent 簽發的短效資料面 JWT 也會送到攻擊者手上。

觸發前提

1. 持有該租戶的 enroll token。依設計它嵌在發給客戶的 installer 裡， 裝在該租戶每一台機器上——是一組廣泛共享的秘密，不是每機獨有。 另注意（卡片重點①）：這個 token 沒有到期時間、沒有使用次數上限、不綁機器。
2. 知道同租戶內另一台 agent 的 agent_uid（管理頁清單、工作設定讀取路徑都會回傳）。

前提①把攻擊者限縮在「該租戶內部」——這是它列 MEDIUM 而非 HIGH 的原因。 但「客戶機房內一台被攻陷的機器」正是這條產品線的主要威脅模型（agent 就裝在那裡）。

建議修法

重新註冊時不可把宣告的 agent_uid 當身分。要求 agent 證明持有首次註冊時取得的 金鑰／憑證（對註冊內容簽名，或出示既有憑證）才允許更新既有列；證明不了就走新建流程， 讓撞號守門正常判定。

嚴重度：LOW · 研究員信心：MEDIUM · 面板：未投票 · runner 核對：事實成立 · CWE-798 位置：jedi-common/.env

⚠️ 越界（檔案屬 jedi-common/，不在本棒 42 檔 scope 內）。研究員為追脈絡讀到範圍外。 這是 plugin 的已知行為（FR-075 S7 九條裡八條、FR-076 L1 三條裡兩條同一模式）—— 面板只驗「發現是否成立」，不驗「是否在範圍內」。

核對結果

事實面成立，兩項都驗過：

• git ls-files jedi-common/.env 有回傳該路徑——檔案確實受版控。
• .gitignore:123 確實有 .env 一行——但對已追蹤的檔案無效， 該檔早於 ignore 規則加入，之後的修改仍會被 git 視為變更並可能被順手 commit。

檔案內含 DB_HOST / DB_PORT / DB_NAME / DB_SCHEMA / DB_USERNAME / DB_PASSWORD 等鍵。 研究員指其值為 localhost 的預設值、直接外洩價值極低；本報告不記錄任何實際值 （依 CLAUDE.md 憑證禁入版控規範，落地文件不寫憑證內容）。

為什麼仍值得處理

風險是結構性的、不是當下的：一個受版控的 .env 待在一個 .gitignore 宣稱會忽略它的 repo 裡，任何開發者若把它改成可用的連線資訊（那正是這個檔案的用途）， 就會靜默地把真實憑證推進所有 clone 與套件歷史——刪檔也救不回來。

建議處置

git rm --cached jedi-common/.env 讓既有的 ignore 規則生效，改放 .env.sample（值留空）。 研究員判斷現值為預設值故不需重寫歷史；但這需要有人實際確認該檔歷史上是否曾經填過 真實憑證，確認前不宜下定論。

處置建議：獨立開卡（比照 FR-076 L1 的 PAT 外洩處理方式），註明來源為 R1 越界發現。

卡片「重點看什麼」列了八個方向，工具不照清單走（首腦手冊第三個盲點）。 以下是卡片點名、但本次研究員與 runner 核對都未實質觸及的部分， 建議在 R2／R3 或後續補掃時追：

這一欄的空白必須照實讀作「沒有結論」，不是「沒有問題」。 面板未跑成、 研究員又只回報了七條，範圍內有多少是「讀過判定沒問題」、多少是「根本沒讀到」， 本次無法區分。

1. F1＋F3 併一張修正卡（心跳身分驗證，含租戶邊界）——建議最高優先。 落地版打得到、無需任何憑證、洩漏的是客戶自己基礎設施的憑證。
2. F2＋F5 併一張修正卡（任務端點身分與歸屬驗證）——同屬控制面根因， 與 1 動到相鄰的程式碼，建議序列做或同一張卡處理，避免派工衝突。
3. F4 獨立一張（SSRF）——需管理員權限，優先序次之。
4. F6 獨立一張（註冊接管）——需 enroll token，但威脅模型（客戶機房內的機器）成立。
5. F7 獨立一張，註明越界來源。
6. nginx 部署設定是跨 repo 的共同前提——1、2 的修正若只改套件而不處理 nginx.onprem.conf，防線仍只有一層。建議在修正卡內明寫「應用層 fail closed」為驗收條件， 不接受「補了 nginx 就算修好」。
7. 考慮補掃：上表七個未觸及的方向中，⑤（CA 簽 CSR）與 ⑥（JWT）屬密碼學核心， 零發現最不可信。是否值得單獨補一小棒（10 檔上下，僅 common/agent_auth/）， 請決策者裁示。

• 工具產物：~/Projects/Jedicogy/module/jedi-python-package/CLAUDE-SECURITY-20260907-111311/ （CLAUDE-SECURITY-RESULTS.md / .jsonl / .sarif 皆為 0 findings， stamp CLAUDE-SECURITY-REVISION-8aa6f0609c44.json 記 verification.status: unverified）
• 該目錄有自帶 .gitignore（單行 *），不入版控