在魔法世界裡，魔法開始在揮動魔杖的那一刻，但當魔法施放出去、甚至開始造成嚴重的連鎖反應時，巫師是不是有能力中斷這個魔法呢?

迪士尼經典動畫「魔法師的學徒」裡面，米奇為了省事，所以趁師父不在時，施法將掃帚變成了僕人幫忙打水，但卻因為指令不夠明確，在水缸滿了之後還持續把更多的水倒進水缸之中。米奇雖試圖叫掃帚停下來卻無法奏效，而在米奇試圖物理破壞掃帚時，碎片卻增生成更多的掃帚僕人，導致水患擴大。

這個情境其實也很有可能發生在現今的企業場景之中，而且不只有 Shadow Agent 可能失控，連企業正式使用的 AI Agent 也有機會遇到這樣的失控狀況。

當 AI Agent 只能回答問題時，失控的影響可能很有限。但當 AI Agent 已經可以接觸到企業內部資料、呼叫 API、自主執行各種行動時，企業除了要知道 AI Agent 可以做到什麼之外，還需要知道如何讓這個 Agent 停下來。

要停止一個執行中的程式，直覺的想像可能是直接停止程式本身就可以。然而遇到 AI Agent 時，單單只是停止正在執行中的 Agent 可能還不夠，因為 AI Agent 的運作可能不是單一服務，可能還有在背景執行的 Subagent 在進行著被指派的工作，可能還有透過 API 或 MCP 等方式呼叫著外部的系統，或是正在等待某個 Workflow 完成被交辦的任務。甚至像掃帚僕人一樣，可能在他被強制終止後，他又會被自動重啟。

因此，停止 AI Agent 本身，只是第一步。真正的問題是，它在停止之前取得了什麼、留下了什麼，以及還有哪些能力沒有被一起收回。

換言之，企業要能完全停止 AI Agent ，會需要先知道 Agent 是誰、他握有那些權限、他是透過什麼身分取得這些權限的、他正在做什麼。之後才能逐步收回身分、權限、切斷連線。這一切如果在事件發生之後才準備，企業絕對會措手不及，所以最好的時機，就是在建立 Agent 時就同時將「Kill Switch」及應變計畫準備好。

然而當遇到 Shadow Agent 時，企業恐怕完全沒有機會在事前準備好這樣的 Kill Switch ，這就讓應變計畫變得更加重要。畢竟我們無法保證 AI 永遠不出錯，但至少在他出錯之前，企業就應該準備好一套辦法可以回收他手中的魔杖。