有人工審核，不等於有人真的在審核

這個陷阱是五個裡面最隱蔽的一個，因為它從流程圖上看完全正常：架構圖裡有一個「人工審核」的節點，稽核文件上也寫著「重要決策需經人工確認」。問題在於實際運作時，審核者面對的是每天數百則需要按「同意」的通知，而每一則的內容都又長又技術——結果就是機械式地全部按同意，人工審核淪為形式。

這比完全沒有人工審核更危險，因為它製造了一種「有人在把關」的錯誤安全感，讓組織以為風險已經被控制住。

兩個層次的問題

審計盲區：Agent 的某些行為根本沒有被記錄。Cloud Audit Logs 記錄的是 GCP API 層級的呼叫，但 Agent 內部的決策過程（為什麼選擇這個工具、為什麼做出這個判斷）通常不在其中——這需要應用層額外設計日誌，呼應 Day8 提過的「細粒度稽核」問題。

監督假象：有記錄、也有審核流程，但審核品質不足以真正攔截問題。

GCP 層面的對應機制

Cloud Audit Logs：確保 Agent 涉及的所有 GCP 資源操作都被完整記錄，這是追溯的基礎。但要注意 Audit Logs 有不同類型（管理活動、資料存取等），部分類型預設不啟用或有額外成本考量，需要主動確認涵蓋範圍。

IAM 核准流程機制：對高風險操作要求額外的核准步驟，讓「人工確認」不只是一個 UI 上的按鈕，而是有技術強制力的流程節點。

真正的解法不在技術，在設計審核的密度

技術機制只能保證「有記錄、有流程」，但要讓人工審核真的有效，關鍵設計原則是降低審核頻率、提高單次審核的資訊品質：與其讓審核者每天面對數百則低資訊量的通知，不如用自動化機制過濾掉明確安全的操作（例如透過 IAM Conditions 讓低風險情境自動放行），只把真正需要人類判斷的少數案例送到人面前，並且附上足夠的上下文讓審核者能在合理時間內做出判斷。

這篇的檢查清單

• [ ] Cloud Audit Logs 的涵蓋範圍是否包含所有 Agent 相關資源操作？
• [ ] Agent 的內部決策過程是否有應用層日誌記錄，而非只有 API 層級記錄？
• [ ] 人工審核的頻率與資訊品質是否經過設計，還是讓審核者淹沒在通知裡？

💡 關於作者 我是 Fngi，專注在 AI 安全與雲端資安領域。如果這篇對你有幫助，歡迎追蹤 Instagram @aid3fend，我在那裡分享更多 AI 資安的實務筆記與趨勢觀察。