本卡為 FR-082 母案。掃 jedi-ai-bot（13 檔、632 行）——25 支套件裡唯一會「把使用者打的字原文送到公司外面、而且花公司的錢」的一支。只掃不修，修正卡另開、由 PM 統一安排。

這在做什麼（白話）

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

這一棒要回答的是：使用者能不能看到別人的對話、能不能塞東西進別人的記錄、能不能無限次呼叫把公司的錢燒光、以及送出去的內容有沒有人管。

為什麼掃它（跟總表建議的順序不同，理由寫清楚）

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

• 排名表的判準裡沒有「資料外流」這個維度。它按「檔數 × 授權鏈風險密度」排，而這支只有 13 檔、沒有複雜的權限判定——但它是唯一一支會把使用者輸入原文送到公司網路外面的套件，也是唯一一支每次呼叫都直接產生金錢成本的。這個風險形狀在排名表裡沒有位置。
• 13 檔是六個 arc 以來最小的一棒，一次掃完、面板幾乎不可能撐不住（對照：FR-076 L1 的 10 檔是第一次面板完整跑完的紀錄）。先拿它把新的白話報告規則跑順，再去啃 jedi-common 那 92 檔，順序合理。

🔴 為什麼是一棒不是兩棒（宿主那一半的判斷）

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

套件本體   jedi_ai_bot/ + harness/     13 檔  632 行
BE 宿主接線  api/ai/__init__.py           57 行
            infra/ai/redis_chat_history_store.py  32 行
            infra/ai/__init__.py          0 行
            ------------------------------------------
                                          3 檔   89 行

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

首腦讀完後的重點（未經驗證，是研究員的思考起點）

• ① 使用者訊息原文送出，沒有任何過濾或長度上限。 ai_bot_route.py:57 只做 .strip()，ai_bot_service.py:92 直接 history.append 就送給 Anthropic。使用者可以貼一整份客戶資料進去。
• ② 沒有次數限制，每次呼叫都花公司的錢。 max_tokens=4096，任何登入者可無限次呼叫。這是成本面的洞，不只是資安面。
• ③ session_id 完全由呼叫端指定，直接進 Redis key。 ai_bot_route.py:58 取 payload.get('session_id') 只 .strip()，ai_bot_service.py:60 組成 chat_history:{user_id}:{session_id}。本棒最值得追的一條。
• ④ API key 與 AI Dashboard 共用同一把。 api/ai/__init__.py:42 的 os.getenv("ANTHROPIC_API_KEY")。key 沒設時 Anthropic(api_key=None) 會怎樣？
• ⑤ 例外處理把所有錯誤吞成一句中文，但會 logger.exception 印出完整例外。 ai_bot_service.py:102-104。要確認 Anthropic 的例外物件裡會不會帶 API key。
• ⑥ 認證是動態掛上去的，而且沒有 fail-closed 檢查。 plugin.py:223-224 用 type() 動態產生子類再套 auth_required。首腦已 grep 確認：這支套件沒有任何 raise、沒有 __post_init__ 驗證——與 jedi-issue（plugin.py:222-233 會 raise RuntimeError 拒絕掛載）不同，這支只靠 dataclass 必填欄位擋。要驗這道夠不夠。

怎麼拆