資安團隊讓 AI Agent 持續整理掃描結果，很快就會遇到一個實際問題：AI Agent 找到疑似漏洞後，可以自行確認嗎？如果已經產生修補程式，能不能直接更新正式系統？主管若只交代「重大操作由人負責」，卻沒有明確規定 AI Agent 執行到哪一步必須停下來等人核准，一旦出問題，也很難查清楚當時是誰同意執行。
雲端安全聯盟（Cloud Security Alliance，CSA）近期提出漏洞維運（VulnOps）模式，主張企業持續整合開發階段、已部署系統及外部揭露的漏洞資訊，不再只靠定期掃描與批次修補。對準備導入資安 AI Agent 的企業來說，這項主張也帶出一個更實際的問題：企業必須明確規定 AI Agent 的操作權限與人工核可關卡，並保留完整可查的紀錄，才能清楚界定 AI Agent 可以做到哪一步。
哪些前段工作可以先交給 AI Agent？
AI Agent 適合先處理不會更動系統的工作，例如彙整不同掃描工具與供應商公告、刪除重複項目、比對受影響的軟體版本，以及整理可能受影響的主機或應用程式。AI Agent 也可以依照既定規則排出處理順序並提出修補建議，不過，AI Agent 必須在結果中註明使用了哪些資料，以及哪些資產資訊還有待確認，不能把「可能受影響」直接寫成「已確認有漏洞」。
安排處理順序時，也不能只看通用漏洞評分系統（Common Vulnerability Scoring System，CVSS）的分數。CSA 建議企業一併考量系統是否暴露在公開網路、系統對營運的重要性、漏洞遭利用的可能性，以及是否已經出現實際利用的證據；團隊也可以參考 CISA 已知遭利用漏洞清單（Known Exploited Vulnerabilities，KEV）與漏洞利用機率評分系統（Exploit Prediction Scoring System，EPSS）。AI Agent 可以綜合這些條件排出待辦順序，但資安人員仍須確認資產及營運資訊是否正確。
因此，企業一開始可以只開放「讀取、整理、比對、提出建議」四類權限，並禁止 AI Agent 對外建立連線、執行攻擊指令或變更正式系統。開始試行前，團隊也要先確認 AI Agent 可以讀取哪些資料、呼叫哪些工具，以及輸出的結論能不能查到所依據的資料。
哪些漏洞操作一定要等人核准？
驗證漏洞時，AI Agent 可能真的會向系統送出攻擊內容、建立測試帳號或改變服務狀態。即使目的只是確認風險，仍可能造成資料異動、服務中斷或系統發出警示。因此，CSA 主張 AI Agent 在進行漏洞利用驗證前，必須先取得人員核准，而且只能在獲得授權的環境中執行。核准單至少要寫清楚目標系統、允許採用的測試方式、執行時段、停止條件及負責人，避免一句「同意測試」最後被解讀成範圍不受限制的授權。
正式環境的修補則要另外管理。AI Agent 可以準備修補建議、測試步驟、回復方案及變更單草稿；不過，安裝更新、修改設定、調整存取規則、重新啟動服務等會改變正式環境的操作，仍建議交由具名人員核准。雲端原生應用程式可以透過自動化部署加快更新，但傳統企業系統與工業控制系統還涉及相依關係、停機風險及維護時段，不能直接套用同一套自動更新方式。
對外揭露漏洞也不能由 AI Agent 自行送出，因為揭露內容可能涉及修補時程、受影響範圍及法律責任。企業應把「驗證測試、正式部署、對外揭露」分別設為必須停下來等人核准的三個關卡，並指定資安人員、系統負責人及對外溝通窗口負責。只要 AI Agent 超出核准的目標、工具或執行時段，工作流就應立即停止，不能繼續沿用原本的核准單。
怎麼把核准規則寫進工作流，而不是只留在會議紀錄裡？
企業可以先把漏洞處理流程拆成資訊蒐集、影響確認、驗證測試、修補建議、正式部署及對外揭露六個階段，再逐一標示哪些工作「可自動執行」、哪些「執行前需要核准」、哪些「不得交由 AI Agent 執行」。每個階段還要寫清楚輸入資料、可使用的工具、可以查看的資料範圍、負責核准的角色及例外狀況如何處理，開發、資安與 IT 維運團隊才能依照同一套規則做決定。
企業可以在 EgentWrX 的工作流交棒前設定人工核可。AI Agent 完成前段工作後，流程會先停下來，等人員核准後再繼續；企業也可以依照組織及職責，分層設定誰能使用 AI Agent，以及誰可以查看哪些資料。平台會記錄 AI Agent 執行過的操作，企業可以驗證稽核紀錄的完整性，也能將紀錄匯出；管理者下載稽核紀錄時，系統同樣會留下紀錄。企業可以利用這些機制設定核准關卡，並在事後查驗整個處理過程，不過，仍須事先定義由誰核准，以及核准時要依照哪些標準判斷。
企業至少要在每筆漏洞的處理紀錄中，保留 AI Agent 的執行內容、使用者、核准人、核准時間、部署結果及例外處置。評估成效時，也不能只看關閉了多少筆漏洞，還要追蹤變更失敗率、漏洞是否再次出現，以及還有哪些風險尚未處理。若漏洞暫時無法修補，可以先限制存取，或採取其他補償性控制（compensating controls），但仍須指定負責人與處理期限，並繼續追蹤後續修補進度。
CSA 提出的漏洞吸收率（Absorption Rate）是以最近 30 天內已解決的項目數，除以同一期間的新增項目數。數值低於 1，代表新增項目比已解決項目多；高於 1，則代表待處理項目正在逐步減少。企業可以先選擇部分正式運作的系統與開發流程試行，每月由資安與維運團隊共同抽查核准紀錄、變更失敗及漏洞再次出現的情況，再決定哪些前段工作可以擴大交由 AI Agent 自動執行。
