過去談系統安全時，我們通常把日誌放在「觀測面」：應用程式負責執行，log、監控告警與 ticket 負責告訴維運人員發生了什麼。即使日誌內容有錯，常見後果也只是誤判、漏報，或讓工程師多繞幾個彎。
但當 AI Agent 開始讀取 telemetry、分析事故，甚至自動修改設定、重啟服務或調整權限，這條界線就變了。原本只是拿來看的文字，可能一路影響 Agent 的推理，最後變成真正的系統動作。這時候，log 不再只是觀測資料，而是控制流程的一部分。
從「資料不準」變成「資料能下指令」
傳統的監控自動化多半依賴結構化條件。例如錯誤率超過門檻就告警，磁碟容量低於某個比例就擴容。規則雖然可能寫錯，但輸入欄位、比較方式與可執行動作通常相對固定。
Agent 不一樣。它會閱讀自然語言，理解一段錯誤訊息的含意，再組合手上的工具完成任務。這讓自動化更有彈性，也讓任何能影響文字內容的人或系統，多了一條間接改變執行結果的路徑。
想像一段由外部請求帶進來的錯誤字串，被完整寫入 application log；或者一張支援單把使用者提供的內容原樣帶進事故摘要。對人類工程師而言，那只是待判讀的資訊。對沒有清楚區分來源的 Agent 而言，它可能和正式維運指令一起進入上下文。
風險不一定長得像明顯的「忽略前面規則」。更麻煩的情況是內容偽裝成診斷建議、標準作業程序、系統狀態或已核准決策。只要 Agent 把它當成可信脈絡，再加上 production write、DNS、IAM 或 shell 權限，觀測面就可能悄悄接上控制面。
信任邊界應該畫在資料來源，而不是檔案格式
很多團隊會把「來自內部監控平台」當成可信的充分條件。但監控平台裡的內容，可能源自應用程式、第三方 API、終端裝置、使用者輸入，甚至另一個模型產生的摘要。平台是內部的，不代表每一個欄位都由內部控制。
我會要求團隊至少把 telemetry 拆成幾種不同信任層級：
- 系統產生且格式固定的指標，例如 CPU、延遲、錯誤碼與部署版本；
- 內部服務輸出的結構化事件，但其中部分欄位可能夾帶外部輸入；
- 人工填寫的 ticket、事故描述與聊天紀錄；
- 由模型整理的摘要、根因猜測與處置建議。
這些資料可以同時提供給 Agent，但不能享有相同權重。更不能因為最後都進了同一個 log store，就把來源差異洗掉。
最實際的作法，是在蒐集階段保留 provenance：事件由誰產生、哪些欄位經過外部輸入、是否被轉寫或摘要、時間與版本是什麼。進入 Agent 上下文時，再以明確標記區隔「可驗證事實」「未驗證敘述」與「只供參考的建議」。這不是為了讓 prompt 看起來更整齊，而是讓後續政策有資料可以判斷。
不要讓診斷權限自然長成修復權限
Agent 能找到問題，不代表它也應該直接修復問題。我會把事故處理拆成幾個動作層級：讀取證據、提出假設、產生修復草稿、在隔離環境驗證、請求人員核准，以及正式執行。
低風險任務可以走得快一點。例如查詢唯讀指標、比對最近部署、整理時間線，通常不需要每一步都問人。可是只要涉及正式環境寫入、身份權限、網路路由、資料刪除或不可逆操作，就不應因為 Agent 對根因「很有信心」而跳過授權。
短效權限在這裡很重要。與其讓維運 Agent 長期持有一組萬用憑證，不如在具體任務與核准完成後，發出範圍有限、時間有限的 capability。權限內容還要綁定實際參數，例如只能重新部署指定服務、只能修改某個設定項，不能只寫成模糊的「允許修復」。
核准畫面必須呈現真正要執行的東西
如果核准畫面只顯示「Agent 建議修復事故」，那幾乎沒有治理價值。人需要看到的是：Agent 根據哪些證據做判斷、哪些內容來自不可信來源、準備呼叫哪個工具、實際參數是什麼、影響範圍多大，以及失敗時如何回復。
特別是工具參數，必須在最後組合完成後再確認。因為從讀 log、產生計畫到呼叫工具之間，Agent 可能經過多次推理與資料補充。核准一份早期摘要，不等於核准最後真正送出的命令。
執行後也不能只記一句「修復成功」。完整的 action log 應保留輸入來源、模型與 policy 版本、工具呼叫、核准者、執行結果、驗證證據與回滾狀態。未來遇到誤判，團隊才能回答究竟是資料污染、模型判斷、權限政策，還是工具本身出了問題。
Observability 正在變成 Agent 的 API
當人類看 dashboard 時，telemetry 是協助決策的介面；當 Agent 讀 telemetry 並自動採取行動時，它實際上就成了另一種 API。既然是 API，就要有 schema、來源、權限、輸入驗證、版本與稽核，而不能只把它當成一堆方便搜尋的文字。
我不反對讓 Agent 參與維運。相反地，事故資料量愈來愈大，讓 Agent 協助關聯事件、整理時間線與提出假設，會是很有價值的方向。但自動化程度愈高，我們愈需要承認一件事：任何能進入 Agent 上下文的內容，都可能影響執行路徑。
以前我們保護控制面，觀測面主要追求完整與可搜尋。接下來還要多問一題：誰能影響 Agent 看到的證據？
這個問題若沒有答案，再聰明的自動修復，也可能只是把一段不可信文字，更快地變成正式環境裡的動作。