過去幾篇一直在提各種風險，以及事前的偵測、預防措施。在倒數第二天，我們來聊聊當 Shadow IT 造成的資安事件真的發生時，跟以往的資安事件會有什麼差異，以及該怎麼處理。

影子 AI 最大的問題在於企業很有可能完全不知道它們的存在，所以當企業以標準程序進行事件分析處理時，可能會陷入一團迷霧之中，例如沒有看到任何外部入侵或金鑰洩漏痕跡，但系統紀錄上卻出現了使用者無法說明的操作紀錄。或是兩個系統間明明沒有已知的資料連線，但資料卻互通了。

這種時候，事件處理團隊，就會需要擴大調查範圍，將未登記的 AI 工具或 AI Agent 也列入可能的事故成因。如果有跡證導向影子 AI，就需要調整事件調查的方向。從聚焦企業防禦邊界、尋找外部攻擊者，擴展到追蹤資料流向及端點紀錄及瀏覽器活動，以及原本企業未掌握的 AI 工具、Agent 或外部整合。

舉例來說，如果企業可以定位到資料是透過哪個 API Key 傳輸的，接下來就可以去 Server 端尋找連線的來源端點，並在該端點上尋找可能的 AI Agent 或可疑的應用程式、腳本等。或是透過瀏覽器的歷程紀錄、擴充功能等，確認是否有不該出現的外部 AI 工具連線紀錄。也可以透過 DNS 、HTTPS 流量特徵或 CASB 紀錄，尋找來自該端點的異常連線。

而如果是涉及影子 AI Agent 的事件，處理團隊還需要進一步思考「權限借用」、「AI 的長期記憶」、MCP等外部整合，以及相關軟體供應鏈的相依性等等面向，才能抽絲剝繭找出事件的真正成因。

在事件後的處理與檢討上，影子 AI 事件也會和傳統的事件處理不太一樣。除了基本的撤銷相關金鑰、憑證、權限，停止相關工具這些止血行為之外。影子 AI 的事件處理和後續檢討上，會牽涉更多內部治理、法律合規及人力資源（如懲處、教育訓練等）議題。而且因為大多數的影子 AI 事件，多半是員工秉持著正向的出發點，卻觸犯資安紅線引發的。因此比起祭出重罰，更重要的還是強化內規、教育訓練等，從制度面與技術面著手，來降低員工私自使用影子 AI 的行為。然而，如果發現員工是刻意規避企業偵測機制、蓄意或反覆違規時，也不能輕易放過。

具體來說，在事後的檢討上，企業至少應該多問幾個問題：

• 為什麼這項 AI 工具沒有經過正式審查
• 企業的偵測機制為什麼沒有及早發現這個工具
• 是否缺少必要的日誌等可以幫助事件分析的資訊
• 正式工具及申請流程是否符合員工需求
• 是否需要調整白名單、AUP、權限管理或是教育訓練內容

整體而言，企業並不需要對於影子 AI 引發的事件建立一個全新的流程，而是需要思考更多的可能性，在更多的地方尋找跡證，並補上原本制度上的其他缺口。

沒有滴水不漏的企業資安治理，零信任也不能保證黑魔法永遠不會入侵；成熟的企業治理，是在防線失效時，仍然知道如何止血、如何查清楚發生了什麼，以及如何避免同樣的問題再次出現。