🔴 一頁看完

要修 1 件事：AI 聊天功能沒有任何長度或次數限制——任何一個普通員工帳號，開四到八個連線就能讓整個系統停止回應，或者無限次呼叫把公司的 AI 額度燒光。

修正卡 CM-1638（🟡 中），已歸檔待 PM 安排。

系統裡有一個 AI 聊天機器人：使用者打字問問題，系統把訊息原封不動送給 Anthropic（Claude），拿回覆顯示給使用者。對話記錄存在 Redis，一小時沒動自動清掉。

跨 arc 總表的下一批建議是 jedi-common → jedi-integrity → jedi-file-upload，jedi-ai-bot 不在前五名（被歸在「攻擊面小」那組）。決策者 2026-09-10 指定先掃這支，首腦認為理由成立：

• 排名表的判準裡沒有「資料外流」這個維度。它按「檔數 × 授權鏈風險密度」排，而這支只有 13 檔、沒有複雜的權限判定——但它是 25 支裡唯一會把使用者輸入原文送到公司網路外面的，也是唯一每次呼叫都直接產生金錢成本的。
• 13 檔是六個 arc 以來最小的一棒，先拿它把新的白話報告規則跑順，再去啃 jedi-common 那 92 檔。

依 FR-079 換來的判準，開卡前先查了「這支有沒有宿主那一半」——有，但太小：

套件本體    jedi_ai_bot/ + harness/    13 檔  632 行
BE 宿主接線  api/ai/ + infra/ai/         3 檔   89 行

89 行不值得單獨跑一棒 40 分鐘，而 scanRoot 只能指一個目錄。處置：一棒掃套件，宿主那 3 檔由首腦全文讀完寫進卡片背景。 這與 jedi-bulletin（宿主 33 檔）、jedi-issue（宿主 31 檔）不同，那兩支的宿主側才是風險所在。

只找到這 1 條。 另兩條候選被檢查員否決（Redis 記錄增長、開發檔的 debug 開關），理由首腦認同。

兩項結論都是好消息，但那不是工具給的。

「這條是真的嗎」→ ✅ 可信。 stamp 是 verified 且連拒收原因欄位都是空的——六個 arc 以來最乾淨的一次（前一個案子六棒有五棒帶著 findings-refused 標記）。9 票全投、零漏投、零中斷。檢查員還主動去主專案與 nginx 設定裡查有沒有頻率限制（沒有）。

「是不是只有這一條」→ ❌ 不可信。 快篩模式，13 檔中 4 個是空檔案。而且工具沒照卡片的重點清單走——兩項指定查證是首腦補做的。

卡片寫「檔數 13」，工具報告寫 14。原因是工具算全部受版控檔，我給的驗證指令只算 .py，差的是 harness/docker-compose.yml。

掃描範圍沒問題，反而多掃一個檔（那個檔也確實該掃）。但驗證指令的口徑該跟工具一致。

• 首腦手冊：.claude/skills/security-scan-lead/SKILL.md（第十節白話規則、第 5.1 節跨 arc 總表）
• 跨 arc 總表：../security-scan-consolidated/README.md
• 各 arc 共用現況：../FR-075-2609-jedi-package-security-audit/handoff/security-scan-STATE.md
• branch：BE repo 與 jedi monorepo 都在 feature/FR-075

以下全部由 build 掃資料夾產生，新增檔案重 build 即自動出現。標題連結指向渲染後的 HTML，md 連向源檔。

其他文件

卡片內容（決策紀錄、驗收條件）以 Notion 為準，本頁只記座標。

相關需求：

• FR-075 — jedi-package-security-audit
• FR-076 — license-chain-security-scan
• FR-077 — remote-agent-security-scan
• FR-078 — notification-security-scan
• FR-079 — bulletin-security-scan
• FR-081 — issue-tracking-security-scan