FR-187.B 掃描報告：Agent 回報事件（狀態、日誌、升級進度、主控台稽核）

找到 3 個問題，都是低風險，而且都要先控制一台已註冊的 Agent 才打得到。最值得修的是第 3 條：被控制的 Agent 可以冒用主系統任何一個真實帳號的名字寫稽核紀錄。

Agent 裝在客戶機器上，會透過 POST /agents/events 回報自己的狀態、錯誤日誌、升級進度與結果，以及主控台上有人做了什麼（寫進主系統稽核）。這一棒假設 Agent 已經被人控制，檢查主系統收下這些回報時信了多少：能不能改到不該改的欄位、冒用別人名義、謊報升級成功、或把主系統灌爆。

範圍 10 個檔、約 870 行（清單見卡片 CM-3715）。

為什麼都是「低」不是「中」：三條的共同前提都是「Agent 已經被控制」。被控的 Agent 本來就能在它自己那台機器上做很多事；這三條的後果是讓主系統變慢或稽核紀錄失真，不會讓攻擊者讀到別的客戶資料，也拿不到主系統帳號權限。

第 1 條：非文字的日誌訊息不受長度上限

• 白話：Agent 回報錯誤日誌時，每筆的「訊息」主系統會截到 8KB。但截斷只在「訊息是文字」時才做（:60）；如果送一個陣列或物件，就跳過截斷，在 :67 被轉成文字整包寫進 public.agent_logs.message。
• 出事會怎樣：每個請求最多可塞到請求大小上限（掃描員估約 110MB），保留 90 天；支援頁的「最近錯誤」與診斷包 CSV 匯出會把這些列讀進記憶體。
• 要先有什麼：一台已註冊 Agent 的通行證與簽章金鑰。
• 在哪裡：domain/support/service/agent_log_domain_service.py:59-67（to_rows）。
• 怎麼修：在 to_rows 裡把 message 先轉成 str（或非文字直接丟掉），再套 message_max 截斷。
• 首腦核對註記：已開檔核對，:60 的 isinstance(message, str) 判斷與 :67 的 str(message) 確實如描述。

第 2 條：去重鍵長度沒上限，可灌爆 Redis

• 白話：主系統用「Agent 編號＋事件種類＋工單編號＋發生時間」當去重鍵（:92），處理成功後存進 Redis 24 小時（:119）。工單編號與發生時間都來自 Agent 送的內容，協定只檢查「是字串」，沒限長度。agent_status、agent_logs、console_events 三種事件的處理都沒檢查這兩欄（升級事件有用 clean_job_id 檢查工單編號、event_time 解析時間，但要等處理成功才寫鍵，格式錯會先 400，所以升級事件不受影響）。
• 出事會怎樣：送一個空的 agent_status、附超長的發生時間，每次換值就多一個大鍵，一天內不消失，Redis 記憶體可被填滿；Redis 同時存著所有 Agent 的防重放紀錄（DPoP，就是防止別人把攔到的請求重送一次的機制）。
• 要先有什麼：一台已註冊 Agent 的通行證與簽章金鑰；Redis 沒設記憶體上限與淘汰規則。
• 在哪裡：app/remote_agent/service/agent_event_dispatcher.py:92（組鍵）、:119（寫入）。
• 怎麼修：在 parse 或 dispatch 組鍵前，要求發生時間是 64 字以內且 fromisoformat 解得開的時間、工單編號符合 _JOB_ID_RE；或把這兩段做雜湊後再組鍵。
• 首腦核對註記：已開檔核對，組鍵與寫入行號正確。

第 3 條：稽核紀錄的操作者可以被 Agent 冒用

• 白話：Agent 主控台有人登入、改帳密、下載檔案時，Agent 送 console_events 給主系統寫稽核。每筆的 actor（操作者帳號）是 Agent 自己填的，主系統在 :102 直接把它當成這筆稽核的使用者，還去查真實使用者的暱稱（:148）。中間沒有核對「這個帳號真的拿過主系統發給這台 Agent 的主控台登入票」。
• 出事會怎樣：被控的 Agent 可以讓稽核報表顯示「客戶管理員在這台 Agent 下載了檔案／改了帳密」，嫁禍給真實的人，真正動手的人也可以推說不是他；偽造本機管理員登入事件還能隨時觸發寄給客戶管理員的告警信（:152）。
• 要先有什麼：控制一台屬於該客戶的已註冊 Agent。只能寫進它自己那個客戶的稽核（租戶只認通行證），不能寫到別家客戶。
• 在哪裡：core/plugins/_agent_console_audit.py:97-105（_write）、:148（查暱稱）。
• 怎麼修：Agent 每筆有操作者的事件附上主控台登入票的編號（jti）或簽過章的票內容；主系統核對該票是發給這台 Agent、票上的人就是 actor，才換成那個使用者寫稽核。核不到時不換使用者身分，改在稽核列標「Agent 自報：」。
• 首腦核對註記：已開檔核對，:98-102 確實直接取 event.get("actor") 設進 user context，沒有任何票據核對。

• 「這些存在嗎」：可信。三條都經過三個獨立檢查員（分別看「打得到嗎」「後果多大」「有沒有別的防線擋住」）投票，三條都是 3 票全數認定成立，首腦也自己開檔核對過行號與程式。
• 「只有這些嗎」：不能保證。這是 effort low 的掃描，只有一個研究員讀完整個範圍（另一個專掃寫死在程式裡的密碼，沒找到）。範圍外的套件（jedi_remote_agent、jedi_agent_protocol）與前門、通行證守門只追到接縫，沒深掃；掃描是讀程式碼推論，沒有實際執行任何攻擊。