本卡屬 FR-075 掃描系列，母卡 CM-1546。掃描 jedi-iam 的「租戶與組織單位」模組。本棒是按業務模組垂直切——從 route 到 service 到 domain 到 repository 是一條完整的請求路徑。

這一棒在做什麼（白話）

用 Claude Code 的 claude-security plugin，掃 jedi-iam 裡「租戶與組織單位」這個模組（約 47 個檔），找出資安問題，產出一份報告。只找問題、不修問題——修正是後續另外開卡的事。

為什麼是「一條完整路徑」而不是「一層」：權限漏洞最常活在層與層的接縫上——route 收了一個 id，你要看到 service 才知道有沒有驗證那個 id 屬於呼叫者。只給 route 或只給 service，兩邊都看不出問題。所以這一棒把同一個模組的每一層都給你。

為什麼切這一塊

租戶是這個產品的隔離邊界——A 公司看不到 B 公司的資料，靠的就是這一層。而租戶歸屬（誰屬於哪個租戶、路徑長什麼樣）正是 RLS 判斷的輸入。已知 jedi-common 的 session_scope 會因為 tenant_id 是 falsy 值而給出 super admin，所以「租戶歸屬怎麼被寫入」是這一棒的核心問題。

重點看什麼

這些是給你的思考起點，不是檢查清單——掃描工具會自己找，這裡列的是這個模組最容易出事的地方：

• 建立租戶、改租戶、把使用者加進租戶，這些寫入誰能做
• 能不能把自己加進別的租戶，或改掉自己的租戶歸屬
• tenant path（那個決定 RLS 可見範圍的路徑字串）怎麼組、能不能被外部值影響
• org_unit 的樹狀結構有沒有迴圈或跨租戶掛載的可能
• root_admin_domain_service 的判定條件——什麼情況下一個人被認定為最高管理者
• tenant_provisioning（開通新租戶）這條路徑的權限與副作用

已知的舊發現（用來對照，不是答案）

2026-09-05 有一輪不完整的掃描（40 個 agent 只有 28 個回報、驗證面板從未執行），在這一塊找到過：

（第一輪未涵蓋這一塊，但 jedi-common 已知的 RLS fail-open 三條與此高度相關）

這份舊清單只是參照。你這一棒的價值在於跑完整條含驗證面板，所以：舊的沒被你的掃描找到，要在回報裡說明（是面板刪掉了，還是根本沒掃到）；你找到舊清單沒有的，那就是新收穫。完整舊清單見 compliance-manager-be repo 的 docs/features/FR-075-2609-jedi-package-security-audit/scan-findings-batch1.md。

怎麼做

第一步：確認 plugin 在