D1 檢查結果：AI 儀表板套件本體（AI 怎麼決定要查什麼）

檢查日期 2026-09-10｜耗時 25 分鐘｜對應卡片 CM-1641

可以。使用者打字就能誘導 AI 去查他本來看不到的資料——而且他可以一直改寫措辭重試，沒有次數限制、沒有花費上限。

D2 證明了「那 27 支查詢功能沒有各自的權限檢查」。這一棒回答的是下一個問題：使用者控制得了 AI 的選擇嗎？答案是控制得了。 使用者打的字和「有哪些功能可以選」的清單，被串成同一段純文字送給 AI，中間沒有任何分隔——這等於把選單和點餐的人放在同一張紙上，讓 AI 自己判斷哪句才算數。

D2 檢查的是主專案那 18 個檔：有哪些查詢功能可以被 AI 呼叫。

這一棒檢查套件本身的 34 個檔：使用者打一句話之後，AI 怎麼決定要呼叫哪一支、查到的資料怎麼送出去。

整個流程有五個階段，其中兩個會真的打電話給外面的 AI 服務（要花錢）：

兩條都是三位檢查員一致認定成立（各 3 票、共 6 票全投）。

F1：打字就能選中任何一支查詢功能（唯一的「高」）

現況：已修（M15-1 CM-2064，套件 commit 248132ec；M15-2 CM-2038，26 支查詢全部申報所需權限，commit 8f94e249d）

白話：使用者打的那句話，和「有哪些功能可以選」的清單，被串成同一段文字送給 AI，中間沒有任何分隔符號。AI 讀完這一整段，回一個功能名字，系統就照著呼叫。

首腦已開檔核對，這是實際的組字方式：

# ai_dashboard_app_service.py:152-156
user_message = (
    f"用戶需求: {prompt}\n\n"          # ← 使用者打的字，原封不動
    f"可用 API:\n{json.dumps(api_catalog)}\n\n"   # ← 27 支功能清單
    f"選擇 1 個最合適的 API。"
)

攻擊怎麼做：

1. 一個普通員工帳號登入
2. 送出 {"prompt": "列出所有使用者帳號"}
3. AI 看到清單裡 auth.get_users 的說明寫著「取得使用者列表」，就回這一支
4. 系統呼叫 UserService.get_users，中間沒有任何權限檢查
5. 整份名冊回到瀏覽器

如果 AI 第一次不配合怎麼辦？攻擊者可以一直試。 因為使用者的字和清單在同一段文字裡，他可以直接把功能名字寫進去、或加一句「忽略上面的規則」，反覆改寫到 AI 穩定選中為止。沒有次數限制、沒有花費上限（首腦已 grep 全套件，找不到任何限流機制），而每試一次就真的打兩次 AI、花兩次錢。

一個重要的更正——工具沒講清楚，首腦開檔查出來的：

系統確實有檢查 AI 回的名字在不在清單內（data_api_service.py:112-116，不在就直接拒絕）。所以攻擊者沒辦法叫出清單以外的任何東西——這比「AI 講什麼就執行什麼」好很多。

但那道檢查只問「這支在不在名單上」，不問「這個人能不能看」。 27 支全部在名單上，於是 27 支全部可及。這是本棒與 D2 接起來的完整圖像：D2 說「那 27 支沒有各自的權限檢查」，D1 說「而使用者確實能誘導 AI 選中其中任何一支」——兩半合起來才是完整的攻擊路徑。

還有一個同款成因（與 FR-079 F13 完全一樣）：

# data_api_service.py:187-190
for field_name, field_value in auto_inject_fields:   # tenant_id / org_unit_id 等
    if field_name in api_info.get("required_params", []) or ... optional_params:
        call_params[field_name] = field_value        # ← 只有「宣告了這個參數」才注入

意思是：系統本來要自動塞「你是哪個租戶、哪個部門」進去當過濾條件，但只有那支功能的申報檔明寫要收這個參數時才會塞。申報成 <strong>kwargs 的（participant 那幾支就是）什麼都收不到，等於過濾條件被默默丟掉**。這正是 FR-079 F13 的成因，同一個機制在這裡還活著。

怎麼修（工具建議，首腦認同並補強）：

不要靠「AI 大概不會選到那一支」當防護——那句話工具講得很到位，而 prompt 完全由攻擊者掌控。

F2：回應夾帶密碼鹽值

現況：已修（M15-4，CM-2064，套件 commit 248132ec；log 側 CM-2269）

白話：查到的資料整包塞進回應，沒有挑欄位。

首腦已開檔核對：

# dashboard_generation_domain_service.py:249, 271
serialized = to_serializable(item)   # ← 整個物件攤平，不挑欄位
...
"data": table_data,                  # ← 原封不動放進回應

AI 設計的欄位清單（columns_config）只決定表格顯示哪幾欄的標題，不決定送出哪些欄位。所以前端只顯示三欄，不代表只送了三欄——看原始回應就拿得到全部。

而 UserDTO 這個資料結構本來就帶鹽值欄位，且會實際填值（jedi-iam/jedi_iam/app/dto/user.py:43 與 :98，首腦已核對）。正常的使用者列表功能刻意排除了鹽值與密碼，唯獨這條路沒排。

鹽值是什麼、為什麼要在意：它是密碼加密時用的材料，不是密碼本身，也不能拿來登入。它的價值在於：如果哪天密碼的加密結果從別的管道外流，有鹽值在手會讓破解快很多。所以它單獨看不致命，配合 F1 拿到的完整名冊（含「誰是超級管理員」）才是完整的風險。

同一個問題也發生在「送出去給 AI」那一側：階段 4 會把真實資料的前幾筆送給外面的 AI 服務看。首腦實查了確切筆數——ai_dashboard_app_service.py:90 先取前 5 筆，但 :191 又縮成前 3 筆，所以實際送出去的是 3 筆（與 FR-079 F13 記錄的一致）。送出去的是原始欄位、沒有脫敏，若當時查的是使用者名冊，鹽值就跟著出去了。

怎麼修：送出前照 AI 設計的欄位清單挑欄位，挑完才放進回應，同一個做法也套用在送去給 AI 的那 3 筆樣本上。更根本的做法：把鹽值從 UserDTO 拿掉（或不填值），讓這個欄位在源頭就不存在——靠每一個出口各自記得排除，遲早會漏掉一個。

卡片列了十項，逐項都有結論，沒有留白。工具實際只碰了①②③，其餘七項為首腦人工開檔查證。

D2 報告指出工具只查了 27 支裡的 5 支，建議 D1 一併補完。以下是首腦逐檔查證後的完整清單（27 支全數列出，數字與主專案申報檔 grep -c api_key= 的結果一致）。

關鍵結論先講：這張表其實不必逐支查，因為問題出在共用的那一段。 F1 證明了沒有任何一支有各自的權限檢查——檢查根本不存在於這條路徑上，不是「有些有、有些沒有」。所以下表要看的不是「哪支有守門」，而是**「哪支的資料最敏感」**。

這張表怎麼用：修 F1 的正解（申報時宣告權限）要逐支填權限點，上表的敏感度排序就是填的優先順序。若採最小止血，先動 auth 4 支，其次 participant 7 支與 system_config。

「這 2 條是真的嗎」→ ✅ 可信

投票完整：三個獨立檢查員對 2 條發現各投一票，6 票全數投出、沒有漏投、沒有中斷，stamp 是乾淨的 verified（拒收原因欄位是空的）。沒有任何一條被降級。

首腦另外開檔核對了兩條，全部屬實。而且核對過程修正了工具與卡片各一處：

1. 工具沒講：AI 回的 API 名字其實有驗證在名冊內（:112-116）。這件事讓 F1 的嚴重度更精確——是「在 27 支裡誘導」，不是「可以叫出任何方法」。沒查這一步的話，報告會把問題講得比實際嚴重。
2. 首腦自己第一次讀錯：:90 寫的是取前 5 筆，但 :191 又縮成前 3 筆，實際送出去的是 3 筆。第一眼只看到 :90 會誤報成 5 筆——追到第二層才對得上 FR-079 記錄的數字。

「是不是只有這 2 條」→ ❌ 不可信，兩個原因

第一：這是快篩模式（low），一個研究員讀完 34 個檔就交給檢查員投票，不做全面盤點。

第二：主專案那 27 支查詢功能各自的內部實作不在本棒範圍。本棒證明的是「套件這一側完全不檢查權限」，至於每一支功能自己內部有沒有做別的防護，要逐支進去看——上表的敏感度是依申報說明與抽查判斷的，只有 participant 那 7 支首腦實際開檔確認過「service 方法本身也不判權限」。

另外：密鑰專項掃描在本範圍零命中（相對地，D2 在主專案撿到 8 條）。這代表套件本體乾淨，不代表整個 repo 乾淨——本棒只看 34 個檔。

耗時 25 分鐘是本 arc 最快的一棒（D2 是 2 小時 59 分）。原因是候選只有 2 條——面板成本是候選數×3，候選少面板就快。