Guidant AI 資安檢視 · 模組報告
使用者打字問問題、系統轉給外部 AI 回答的那個聊天框。這是整輪檢視裡最乾淨的一塊——只找到一件事，但那一件事一個普通員工就能讓整個系統停止回應。
產品裡有一個聊天框：使用者打字問問題，系統把訊息原封不動送到外部的 AI 服務（Anthropic Claude），拿回答顯示回畫面。對話紀錄暫存在快取裡，一小時沒動就自動清掉。
功能本身很單純——它不查資料庫、不碰客戶資料、也不做任何權限判斷，就是一個轉接窗口。
這是全部模組裡唯一會把使用者輸入的原文送到公司網路外面的一塊，也是唯一每被呼叫一次就直接產生金錢成本的一塊。
風險的形狀跟其他模組完全不同——不是「誰看得到誰的資料」，而是「誰能把公司的資源用光」。
檢視期間：2026-09-10（單日完成）｜範圍：14 個檔案（套件本體；另有 3 個接線檔約 89 行由統籌者全文讀過）｜共 1 輪
原始技術報告放在需求中心的 FR-082 站，檔名見下表最後一欄。那裡有每一輪的完整技術細節、檔案清單與逐條推理，供需要深究或稽核抽查時查閱。
| 輪次 | 查什麼 | 檔數 | 覆核投票 | 結果 | 原始報告檔名 |
|---|---|---|---|---|---|
| A1 | 對話會不會跑到別人那裡、能不能無限次呼叫把資源用光 | 14 | 9 票全投完，零中斷 | 通過 1 條，這輪的品質是整批檢視裡最好的一次 | scan-A1-ai-bot |
為什麼說「這輪的品質是最好的一次」
覆核程序跑完時會留下一份紀錄，上面除了票數，還有一欄「被退回的項目」——前一個案子六輪裡有五輪帶著退回標記。這一輪那一欄是空的，九票全數投出、沒有任何一票中斷或漏投。
覆核者還主動追出模組之外去查：他們翻了主系統的設定與對外的網頁伺服器設定，確認那兩層也沒有任何次數限制。這不是讀這個模組就能知道的事，是自己追出去查的。
有一件事工具沒做，必須說清楚
派工時點名了兩個一定要有答案的問題（對話會不會跑到別人那裡、少了登入設定時會怎樣），工具一個都沒回答——兩個答案都是統籌者事後自己開檔查出來的。
兩個答案都是好消息（見下方「另外查證的兩件事」），但那不是工具給的。這一輪能宣稱的是「工具報的這一條是真的」，不能宣稱「這個模組只有這一條」。
沒有重跑補查的原因：這個模組只有 14 個檔案、且其中 4 個是空的，統籌者自己逐檔讀完比重跑一輪快。
只有一條。「出事會怎樣」那欄講的是業務影響——誰受影響、損失什麼，不是技術現象。
| # | 問題 | 風險 | 分類 | 出事會怎樣（誰受影響） | 怎麼修 | 狀態 |
|---|---|---|---|---|---|---|
| 1 | 聊天沒有長度上限，也沒有次數限制 | 🟡 中 | 資源耗盡 | 整個產品對所有人停止回應——不只聊天功能，連登入都會逾時。做得到的人是任何一個最基層的員工，四到八個連線就夠，不需要特殊權限。另一種後果是把公司共用的 AI 額度燒光，直接變成帳單 | 加訊息長度上限、加等待逾時、開一個「每人每分鐘最多問幾次」的插槽給主系統接。實際做法：訊息長度上限 4000 字、外部 AI 呼叫 60 秒逾時、每人每分鐘 10 次上限（超過回 429） | ✅ 已修（CM-2064） |
使用者在聊天框打什麼、打多長，系統完全不管，直接轉給外部 AI。也沒有「一個人一分鐘最多問幾次」這種限制。
為什麼「整個產品停不了」比「燒錢」更嚴重——覆核者把這條鏈追得很完整：
| 環節 | 實際狀況 |
|---|---|
| 系統同時能處理幾個請求 | 只有 4 個（正式部署的預設值） |
| 一個請求處理多久 | 呼叫外部 AI 本來就慢 |
| 外部 AI 沒回應時要等多久 | 10 分鐘（套件的預設值，我們從來沒改過） |
| 系統多久會強制砍掉卡住的請求 | 120 秒 |
把這四件事串起來：四到八個連線各送一則超大訊息，就把系統能同時處理的量全部佔滿。其他人這段時間連登入畫面都打不開。
系統確實有一道「整站請求不得超過 50MB」的限制擋在前面，但50MB 對一則聊天訊息來說等於沒擋。
| 步驟 | 做什麼 | 為什麼不能省 |
|---|---|---|
| 一 | 訊息長度設上限（建議 4000 字），超過就直接退回 | 這是最小、最快的止血，改一個檔就好 |
| 二 | 呼叫外部 AI 時設等待逾時 | 讓系統自己放棄，不要等到被強制砍掉——目前是等 10 分鐘、系統 120 秒就砍，這中間的落差正是被佔住的原因 |
| 三 | 開一個「每人每分鐘最多幾次」的插槽，由主系統接上既有的計次機制 | 「怎麼限制」是產品規則，該由主系統決定；但「有沒有這個插槽」該由這個模組提供。不開插槽，下一個接手的人只能在模組裡硬寫一套 |
已裁定與 AI 儀表板那塊的同款問題（見 AI 儀表板報告）合併處理——兩邊共用同一把 AI 金鑰，而且 AI 儀表板那邊一次請求會呼叫兩次 AI，情況更嚴重。
這兩件是派工時特別點名要查、但工具沒答，由統籌者事後自己開檔確認的。
| 要查的事 | 結論 |
|---|---|
| 對話紀錄會不會跑到別人那裡？ | ❌ 不會。 存放位置的第一段是使用者編號，而那一段由伺服器自己填、是純數字，呼叫端偽造不了。原本的擔心不成立。 ⚠️ 但這道保護完全靠「編號由伺服器填、而且排在最前面」這件事撐著——哪天有人調動順序，保護就沒了。建議在程式旁加一行說明，寫清楚順序為什麼不能動 |
| 主系統忘了設定登入檢查時會怎樣？ | ✅ 會直接啟動失敗，是安全的。 不會變成「不用登入就能用」的公開入口。錯誤訊息不如其他模組清楚，但安全性上沒有缺口 |
一句話：這塊只有一件事要修，而且工單早就開好躺著等排期——它是整輪檢視裡體質最好的一塊。
已裁定要修，照三步做：訊息長度上限、呼叫外部 AI 設等待逾時、開一個「每人每分鐘最多問幾次」的插槽。修起來很便宜（兩個小改動），而且裁定與 AI 儀表板那塊的同款問題合併處理，共用同一次改動。
不能宣稱的事：這一輪的覆核品質很高，但工具沒有留下逐檔閱讀紀錄，而且它跳過了派工時點名的兩個重點。能說的是「找到的這一條是真的」，不能說「這裡只有這一條」。
| 統計 | |
|---|---|
| 檢視輪數 | 1 輪、14 個檔案 |
| 通過的發現 | 1 條 |
| 最嚴重 | 0 條 |
| 已修 | 0 條 |
| 已開工單未排期 | 1 張（CM-1638） |