前言
Day 13,我們提前建立了機敏資料的核心原則——哪些欄位不能餵給 AI、該怎麼處理。今天,我們要把這份原則延伸到整個自動化流程的每一個環節。因為當系統從「人工操作」變成「自動化串接」之後,風險並沒有消失,只是換了位置出現。

一、為什麼自動化之後,反而需要更謹慎看待安全性
手動操作時,每一次「把資料丟給 AI」,都是你親眼看過、親手執行的動作,任何不對勁,你當下就可能發現。但自動化之後,程式會按表操課、日復一日地重複執行同一套流程,如果流程裡藏著一個資安漏洞,它不會只出錯一次,而是每次執行都在重複曝露同樣的風險——而且因為沒有人每次盯著看,問題可能潛伏很久才被發現。
這正是為什麼,今天不是要重複 Day 13 已經談過的內容,而是要專門檢視:自動化串接這個動作本身,新增了哪些 Day 13 沒有涵蓋到的風險。
二、風險一:API 金鑰的保管
回顧 Day 26,我們特別提醒過「金鑰不能寫死在程式碼裡」。這裡要更具體地說明為什麼,以及該怎麼做:

• 絕對不要把金鑰直接寫在程式碼中,尤其是如果這份程式碼未來可能被上傳到版本控制系統(例如公司內部的 Git 儲存庫)——即使是私有儲存庫,金鑰一旦進了版本歷史紀錄,要徹底清除也相當麻煩
• 建議做法:把金鑰存放在獨立的設定檔或環境變數裡,程式執行時再讀取進來,並確保這個設定檔不會被誤傳、誤分享
• 定期檢查金鑰的使用權限範圍:確認這組金鑰能存取的功能,是不是剛好符合你這個自動化流程實際需要的範圍,而不是被授予了超出需求的過大權限
  三、風險二:Log(日誌)是否意外留存機敏內容
  這是一個容易被忽略的隱藏風險。程式在執行過程中,為了方便除錯,常常會把「這次處理了什麼資料」「送出去的 prompt 內容是什麼」記錄成日誌檔案。如果日誌裡完整保留了原始資料(包含 Day 13 定義過的機敏欄位),等於是把原本該被保護的資訊,複製了一份存放在另一個你可能沒特別留意管理的地方。
  建議做法:設計日誌記錄邏輯時,遵守「最小揭露原則」——只記錄除錯真正需要的資訊(例如「本次成功處理 15 筆事件」),而不是把完整的原始資料內容整份寫進日誌。如果真的需要保留完整紀錄以供追查,確保日誌檔案本身,也受到跟原始資料同等級的存取權限保護。
  四、風險三:推送管道是否被非預期的人看到
  回顧 Day 27 的推送機制,自動化之後,報告會直接送進 Slack 頻道、Teams 群組或 Email 信箱。這裡要確認:
• 推送的目標頻道或群組,權限設定是否正確? 例如頻道成員是否僅限該看到這份報告的人,有沒有可能誤設成公開頻道
• Email 收件人清單,是否只包含真正該收到的對象? 尤其如果收件清單未來需要調整增減,要確保修改流程本身也有適當的把關,不是隨便誰都能直接改動收件清單
• Webhook 網址本身是否洩漏? 知道 Webhook 網址的人,理論上就能任意發訊息到你的頻道,這組網址也該被視為需要保護的機敏資訊,不宜隨意分享或貼在公開的地方
  五、一個簡單的自我檢查清單
  在正式讓自動化系統長期上線運行之前,建議對照以下清單逐項確認:
• API 金鑰是否存放在程式碼之外的安全位置?
• 金鑰的存取權限,是否僅限於這個流程實際需要的範圍?
• 日誌記錄的內容,是否遵守最小揭露原則,沒有完整保留機敏資料?
• 推送管道(頻道、群組、信箱清單)的權限設定,是否只有該看到的人能看到?
• Webhook 網址等敏感連結,是否有妥善保管,沒有外流風險?
• Day 13 建立的機敏資料處理原則,是否確實貫穿在自動化流程的每個環節,而不只是最初手動測試時有遵守?
  六、今天的行動練習
  拿出你目前的自動化腳本與流程設計,依照上面的檢查清單逐項確認。如果發現任何一項還沒落實(例如金鑰目前還寫在程式碼裡),優先處理這些項目,再考慮讓系統正式上線長期運行。

小結
自動化的價值,建立在「它會被長期、重複執行」這個特性上——但這個特性,同時也代表任何一個安全性疏漏,都會被長期、重複地曝露。今天我們把 Day 13 建立的核心原則,延伸檢視到金鑰保管、日誌記錄、推送權限這三個自動化串接特有的風險點,讓整套系統不只「產出的內容」符合資安要求,連「運作的過程本身」也經得起檢視。
明天,是這個系列的最後一天——我們要回顧整個 30 天的旅程,並且談談,學完這一切之後,下一步可以往哪裡走。