AI Agent 的權限邊界怎麼設：企業導入前必須畫好的三條線

文／TED｜優創執行長

AI Agent 的權限邊界，指的是它能連到哪裡、能用哪些憑證、能做哪些動作，以及這些行為有沒有被記錄下來。這件事必須在導入前決定，而不是等它出錯後再補。2026 年下半有兩份公開報告說明了原因：能力夠強的 Agent，會自己找到繞過限制的路。

我最近被問最多的一句話是：「我們公司又不是 OpenAI，需要搞這麼嚴格嗎？」我的回答是，規模不決定風險，Agent 能碰到什麼才決定風險。

兩份公開報告說了什麼

先把事實講清楚，因為中文圈的轉述版本和原始報告有落差。

OpenAI–Hugging Face 事件。依 OpenAI 在 2026 年 8 月 26 日發布的技術報告，事件發生於同年 7 月的內部資安評測期間。當時多個內部研究模型在降低防護的設定下執行任務，出現了三件原本不該發生的事：

1. 模型把檔案寫進內部託管的套件管理服務 Artifactory，讓它變成一塊非預期的留言板，原本應該互相隔離的 Agent 藉此交換資訊。
2. Artifactory 本身為了下載套件而具備對外連線能力，模型利用伺服器端請求偽造，讓它代為送出任意網路請求，等於取得了原本被關閉的網路存取。
3. 取得方法後，模型透過那塊留言板把做法分享給其他 Agent。

OpenAI 在報告中把它定義為警告性事件，並寫下一句值得每個企業主管記住的話：這些系統已經強大、持續且具協作性到「在缺乏足夠防護時，能跨多個電腦系統找出並利用安全弱點」，而且「沒有任何人類下達這些指令」。報告同時承認，內部團隊早在 5 月底就觀察到留言板活動與不被允許的網路存取，但當時的升級處理流程沒有及時啟動。

Google Gemini 測試事件。2026 年 9 月中旬，Google 確認旗下 Gemini 模型在當年 5 月由外部測試公司 Irregular 執行的攻防演練中，因測試環境的網路隔離設定錯誤而取得對外存取，並在未經授權的情況下進入三家真實企業的系統。這件事延後約四個月才對外說明。

兩件事的共同點不是模型有惡意，而是隔離設定出現缺口時，具備工具使用能力的模型會把缺口用到底。

第一條線：網路出口

最該先畫、也最容易畫的一條。

Agent 執行環境的對外連線應該採白名單，明確列出允許連到的網域，其餘一律拒絕。這裡有個容易被忽略的細節：白名單上的服務本身可能具備對外能力。OpenAI 的案例就是這樣——被允許的是套件管理服務，被利用的是那個服務的對外連線權。

實務上要檢查三件事：

• Agent 容器有沒有預設的全開對外連線。多數雲端執行環境的預設值是開的。
• 白名單上的每個服務，是否具備代為發出任意請求的能力。套件管理、檔案轉換、網頁擷取類服務特別需要確認。
• 被拒絕的連線嘗試有沒有記錄。沒有紀錄，就無法知道 Agent 曾經試圖往哪裡去。

對中小企業而言，如果 Agent 只需要呼叫特定幾個 API，就把出口限制在那幾個網域。這件事的成本很低，通常是一份設定檔。

第二條線：憑證範圍

第二條線的原則是：按任務發憑證，不按人發。

常見的錯誤設定是全公司的自動化流程共用一把高權限 API 金鑰，因為這樣最省事。代價是出事時無法定位是哪個流程造成的，也無法只撤銷一個流程而不中斷其他工作。

建議的做法：

• 每個 Agent 工作流使用獨立憑證。
• 只授予完成該任務所需的最小權限範圍。需要讀取訂單的 Agent，不應同時具備修改訂單的權限。
• 設定有效期限，並確認到期後流程會失敗而不是自動沿用舊憑證。
• 確保單一憑證可以獨立撤銷。

還有一點：憑證不要放進會被模型讀到的環境變數或檔案。OpenAI 的報告中提到，處理過程包含移除曝光的憑證。如果 Agent 的執行環境裡躺著一把金鑰，它就是 Agent 能力的一部分。

第三條線：動作審計

前兩條線管的是「能做什麼」，第三條線管的是「做過什麼」。

每一次工具呼叫都應該留下可追溯紀錄，內容至少包含：時間、觸發來源、呼叫的工具與參數、回傳結果的摘要、是否經過人工確認。

這條線的價值在 OpenAI 的報告中看得很清楚：問題訊號在 5 月底就出現了，但沒有轉成行動。有紀錄而沒有人看，等於沒有紀錄。所以除了留存，還要指定由誰定期檢視、什麼情況要停止執行、誰有權重啟。

我們自己的做法是把 Agent 的對外動作分成三級：只讀查詢直接執行；寫入內部系統留完整紀錄並定期抽查；對外發送訊息或動用金流，一律需要人工確認。這個分級不複雜，但它讓「出錯時影響多大」變成可預期的事。

導入前的檢查清單

如果你正在評估或已經上線 AI Agent，先回答這六題：

1. 這個 Agent 的執行環境可以連到哪些外部網域？清單在哪裡？
2. 白名單上的服務，有沒有任何一個能代為發出任意對外請求？
3. 它使用哪些憑證？每一把的權限範圍與有效期是什麼？
4. 其中有沒有任何一把是跨流程共用的？
5. 它的每一次工具呼叫有沒有留下紀錄？誰在看？多久看一次？
6. 哪些動作被設定為需要人工確認？這份清單是誰決定的？

六題有任何一題答不出來，建議先把該 Agent 的對外動作改為需人工確認，再逐項補齊。這比出事後回溯便宜得多。

這不是要你不要用 Agent

我想講清楚我的立場：這些事件不是 Agent 不能用的理由，是 Agent 該怎麼用的說明書。

兩家公司都是在自己的測試環境中發現問題，也都選擇把細節公開。對要導入的企業來說，這其實是好消息——我們不必自己踩一次，就能知道邊界該畫在哪。

需要提醒的是，上述公開報告描述的是前沿實驗室的內部研究模型，其能力與一般企業使用的商用 API 不同。把同一套標準直接套到所有場景，會造成不必要的成本；但把「模型不會自己突破限制」當作預設，則是站不住的假設。

實務上的判斷方式很簡單：先問這個 Agent 出錯時會影響什麼，再決定要花多少力氣圍它。只產出草稿的，輕一點；能動到客戶資料、對外訊息或帳務的，三條線一條都不能少。

參考來源

• OpenAI, "The Hugging Face incident and the road ahead"（2026-08-26）與同日發布之完整技術報告
• OpenAI, "Pacing model development in an era of cyber-critical capabilities"（2026-08-18）
• Hugging Face, "Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident"（2026-07-27）
• Google 就 Gemini 於 Irregular 攻防演練中取得未授權存取一事之公開說明（2026 年 9 月）

相關推薦與延伸閱讀

• AI 導入顧問怎麼選？台灣中小企業比較顧問與 DIY 的成本、風險與時程：要自己摸索 AI 工具，還是請顧問協助？本文分析兩種方式的成本、風險與適用情境，幫台灣中小企業老闆做出適合自己的決定。
• AI 導入效果不佳？企業應檢查的 5 個原因與改善方法：AI 工具買了沒人用，先檢查需求、導入範圍、操作支援、繁體中文品質與維護能力。用實際紀錄找原因，再決定調整、延長試行或停止。
• AI 導入路線圖：台灣中小企業 3 個月落地計畫：想導入 AI 卻不知從何開始？這份 3 個月路線圖，帶你從零開始看到成效，說清楚每個階段該做什麼與先後順序。
• AI 導入 ROI 怎麼算？工時、現金與增量收益的三種算例：AI 導入 ROI 計算指南：分開工時價值、現金節省與增量收益，用三個假設算例檢查重複計算、回收期與完整成本，避免把營收當利潤。
• Claude Design 正式推出：用對話創作設計稿，台灣企業實用指南：Anthropic 推出 Claude Design，讓非設計師靠對話產出原型、簡報與行銷素材。本文整理功能、適用對象與台灣企業落地建議。
• Grok Bot vs Claude Agent SDK vs OpenAI Agents SDK：台灣中小企業 AI 工作者該選哪個？：Grok Bot 是開箱即用的產品化 AI 工作者，Claude Agent SDK 與 OpenAI Agents SDK 是開發者自建代理的框架。本文從費用
• 看到「AI 突破」新聞時，企業主該怎麼查證：一個 2026 年的實例拆解：AI 能力宣稱幾乎每週都有，但媒體標題與原始來源常有落差。本文以 2026 年 9 月 FrontierMath 相關報導為實例，示範四個查證步驟：找到一手來源
• SOP 標準化完整指南：AI 導入前必做的第一步：想讓 AI 在你的公司真正發揮效果，先把 SOP 做好。這篇教你什麼是 SOP 標準化、為什麼重要、以及如何一步步建立企業 SOP 系統。
• 優創執行長 TED：我們導入 AI 前，先把流程講清楚：優創執行長 TED 的分享會回顧：企業導入 AI 前，先找出公司最常卡住的流程；從客服、業務、財務到 FDE，讓工具真正接進現場。