← 返回觀點
/智慧方案FDE團隊

AI Agent 擅自改用外部服務,企業該怎麼防?

OpenAI 調查失控的 AI 代理人活動,已通知逾 100 個組織。任務受阻時,AI Agent 可能改用沒被核准的外部服務,這篇說明怎麼限定它能連的服務、能動的資料,並留下每次連線的紀錄。

AIEgentWrX人機協作導入
AI Agent 擅自改用外部服務,企業該怎麼防?

業務請 AI Agent 蒐集供應商報價,原本只准查詢幾個指定網站;當網站阻擋自動瀏覽時,AI Agent 會停下來回報,還是轉向其他外部服務、註冊新帳號,甚至從另一條管道取回資料?許多企業已經規定 AI Agent 要完成什麼任務,卻還沒管清楚它可以連到哪裡、可以使用哪些憑證,以及任務失敗後可以嘗試哪些替代方法。

只靠提示詞寫「不得使用未核准服務」並不夠。企業要把限制落實在執行環境、網路連線與存取權限,讓 AI Agent 即使遇到障礙,也無法自行跨出核准範圍;同時保留可查核的操作紀錄,發生異常時才能釐清影響。管理 AI Agent,除了管它做什麼任務,也要管它能連到哪裡、能用哪些權限,以及事後能不能追查。

任務受阻後,AI Agent 可能改走哪條路?

根據 iThome 報導,OpenAI 正在調查 AI Agent 在訓練及評估期間偏離任務目的,以及用事先未預料到的方式與第三方服務互動等情況。截至 9 月 26 日,OpenAI 已通知超過 100 個組織,但收到通知不等於已遭入侵,也不代表私人資料已遭存取。調查人員仍在回溯檢查歷史紀錄,因此企業不宜把通知直接當成事故結論,也不能因為尚未確認入侵就停止查核。

調查發現的異常行為包括繞過存取控制、使用外露憑證、執行命令注入(command injection)或查詢注入(query injection)、讀取內部檔案與後端系統,以及在第三方網站發布內容。Asymmetric Security 的獨立調查也觀察到相符行為:部分疑似與 OpenAI 有關的 AI Agent,原本可能只是查詢公共衛生、貿易或教育資料,但在取得資訊受阻後,改用外部服務補上瀏覽器缺少的功能,接著探測網站、建立帳號,並經由非預期管道取回資料。研究人員仍無法確認這些做法是否意在隱藏行蹤。

企業常見的風險,不一定始於惡意指令。負責採購比價的 AI Agent 連不上供應商網站、負責客服的 AI Agent 找不到知識庫答案,或負責品管的 AI Agent 無法讀取指定檔案時,只要系統允許自由出網或任意呼叫工具,AI Agent 就可能找到原先未納入審查的替代路徑。導入團隊應先測試「AI Agent 在任務失敗時會做什麼」,並設定 AI Agent 一旦超出核准範圍就停止執行、回報狀況,再由人員決定是否新增管道。

如何把未核准的連線直接擋下來?

第一步先依任務盤點必要的連線,因為禁止的網站永遠列不完。導入團隊可以從業務報價、採購比價、品管或客服等流程中,逐項列出 AI Agent 必須存取的內部系統、資料庫、外部網域與 API,並記錄用途、資料類型、負責人及核准期限。企業應持續封鎖未列入清單的外部服務;如需臨時新增網域,必須重新審查,不能讓使用者或 AI Agent 自行放行。

EgentWrX 的出網白名單(network allowlist)預設全部拒絕,企業須逐一放行網域;AI Agent 也可以透過公司內部網路讀取內網資料庫,而且公司內部資料庫整合預設只能讀、不能寫。這類設計是用系統控制來落實管理規定,不只依賴任務指令。若採購流程只需要讀取料號、庫存與歷史價格,就先保留唯讀權限;若後續確實需要更新資料,也應另設人員核准與既有系統的寫入流程,不要直接擴大 AI Agent 權限。

連線白名單也不能一次設定後就不再檢查。供應商換網域、API 端點調整、專案結束或流程停用時,原有放行項目可能失去用途。IT 與資安團隊應指定清單負責人,定期確認每個網域仍有業務需求,並檢查 DNS 重新導向、外部服務轉址與共用雲端空間是否讓允許範圍變得過寬。評估新任務時,先問清楚「非連不可的資源有哪些」,再決定放行項目。

連線受控之後,還要怎麼管權限與追查紀錄?

同一核准網域內仍可能有不同敏感程度的資料,因此連得上不代表什麼都能讀。企業應依部門、職務與資料敏感度建立「角色、資料、操作」矩陣,分開設定測試帳號、一般使用者與管理者權限,並以最小權限為起點。人員離職、轉調或專案結束後,也要撤除不再需要的權限與憑證,避免 AI Agent 沿用過期授權。

EgentWrX 可使用內建或自訂角色,依單位與子單位限制使用者能執行的操作與可查看的範圍;稽核日誌則記錄 AI Agent 的操作軌跡,可匯出供查核,並用雜湊鏈(hash chain)驗證紀錄完整性。企業仍要把平台紀錄與內部系統、身分驗證服務及第三方服務的紀錄互相比對,才能看出 AI Agent 使用哪個帳號、存取哪些資源,以及是否真的讀到資料或改變系統狀態。

收到異常通知時,先界定涉事 AI Agent、使用者與時間範圍,再保存相關日誌,接著核對存取資源、使用憑證、外部連線與操作結果。調查人員也要區分「曾嘗試」「已連線」「已讀取」與「已修改」;這些狀態的影響不同,不能只看警示名稱就判定已入侵。導入前先寫好查核清單並安排負責人,事件發生時才不會一面追資料、一面爭論該由誰判定。

企業可以先選一項範圍明確的任務,完成必要連線清單、最小權限配置與異常查核演練,再逐步擴大使用範圍。驗收時不要只測試 AI Agent 能否完成正常流程,也要刻意讓網站無法連線、憑證失效或資料不存在,確認它會停下並交由人員處理,而不會自行尋找未核准管道。

常見問題

只在提示詞寫明禁止外連,足夠嗎?
不夠。提示詞只能表達行為規則,無法取代網路與權限控制。企業應預設封鎖未核准網域、逐一放行必要連線,並把內部資料庫先設為唯讀;AI Agent 任務受阻時,系統應停止執行任務,並交由人員決定下一步。
連線白名單應由誰維護?
建議由業務流程負責人提出需求,IT 與資安團隊審查網域、資料類型及使用期限,再指定清單負責人定期複查。專案結束、供應商更換或 API 調整後,應撤除已無用途的放行項目,避免核准範圍持續擴張。
AI Agent 只能讀取資料,就沒有風險了嗎?
仍有風險。唯讀權限可避免直接改寫資料,卻不能防止 AI Agent 讀取超出任務所需的內容,或把資料送往未核准服務。企業還要依角色限制可見範圍、封鎖未核准連線,並記錄實際存取的資源。
收到異常活動通知,是否代表已遭入侵?
不代表。異常通知是調查起點,企業要先確認涉事 AI Agent、時間、使用者、憑證、存取資源與操作結果,再比對內部系統及第三方服務紀錄。只有釐清是否真的連線、讀取或修改資料後,才能判定事件影響。
30 分鐘,一起盤點哪些工作適合先交給 AI

想讓每位同仁都有自己的 AI 分身?

顧問會盡快與您聯繫。