為了「先讓它跑起來」，AI 代理拿到了整個資料庫的權限

那個「之後」一直沒有來

假設有一家四十人的電商公司，做了一個客服 AI 代理，幫客服查訂單、更新客戶資料。開發時為了省事，直接給了一組資料庫管理員帳號，想說「先讓它跑起來，之後再調權限」。上線之後大家都在忙別的事。某天，一位顧客在客服對話裡輸入了一段精心設計的文字，代理照做了，查出不屬於這位顧客的訂單資料。

先說清楚，這是示意情境，不是真實事件，公司與經過都是為了說明而設。事後檢查發現：代理其實只需要「讀取訂單」和「更新聯絡資料」兩個權限，卻擁有刪除資料表的能力。那個「之後」，一直沒有來。

這篇要講的只有一件事：代理的權限要等於它的任務，而且要用程式擋，不能只靠提示詞拜託它。

過度代理，風險在哪裡

OWASP 的 LLM 應用風險清單把這類問題稱為「過度代理」（Excessive Agency），並指出根本原因通常是三者之一或同時存在：功能過多、權限過大、自主性過高；觸發因素包括模型幻覺和提示注入。

放到示意情境裡，第一層是權限遠超任務：管理員帳號能做的事，代理理論上都做得到。第二層是輸入不可信：顧客輸入的內容會影響代理的行為，而任何人都能當顧客。第三層是影響範圍：一次被誘導，影響的是整個資料庫。最後是難以撤銷：共用的管理員帳號，收回會影響其他系統，所以出事時也不敢馬上停。

這篇示意情境裡，代理手上拿的是什麼

這是示意情境，憑證本身沒有外洩；下表列的是代理手上那把權限過大的鑰匙，以及它被誘導時實際被「借用」的範圍。

憑證沒有被偷，但代理被誘導時，攻擊者等於借用了這把鑰匙的全部權限。

能證明的、只能推論的

這篇是觀點文，情境是示意的，所以能證明的只有官方文件寫明的事；情境裡的經過只能算推論，不知道的就寫成缺口。

不花錢就能做的流程

到這裡，其實已經足夠理解問題在哪。如果你想直接動手，可以跳到「今天就可以來試試」；下面是完整的六步流程。

第一步，列出代理的任務和需要的動作。 例如「讀取訂單」「更新電話與地址」。只開這些權限。

第二步，給代理專屬帳號。 不要和人或其他系統共用，出事時才能單獨停用。

第三步，資料庫層面限制。 只讀帳號、限定資料表或欄位；能用檢視表或預存程序的，就不要開放任意查詢。

第四步，應用層再擋一次。 代理查詢客戶資料時，用程式強制加上「只能查這位顧客」的條件，不要只依賴提示詞。

第五步，高風險動作要人工確認。 刪除、退款、批次修改，保留人工核准。

第六步，找出多餘權限。 AWS IAM Access Analyzer 可以找出未使用的權限（這類發現需付費）；Google Cloud 的 IAM 建議工具可以提出縮小角色的建議。

什麼時候不需要買工具

只有一兩個代理、連接少數系統的話，「專屬帳號加最小權限加應用層檢查」用資料庫和雲端平台的原生功能就能做到。代理數量多、權限要動態調整時，才需要專門的平台。

市面上大致分四類。資料庫與雲端原生權限：資料庫角色、檢視表；AWS IAM、Google Cloud IAM 和其建議工具。開源密鑰管理：OpenBao（Vault 的開源分支）等方案，讓代理在執行時取得憑證，不把帳密寫在程式裡。基礎架構存取平台：例如 Teleport 的 Access Requests（屬於 Enterprise 功能）。商用特權存取：例如 1Password 在 2026/07/28 推出的 Privileged Access（建立在 2026 年 6 月加入的 Apono 技術上），官網說可以依需求配置範圍限定的權限，並在會話結束時移除；CyberArk 等傳統特權存取廠商也有相關產品線。

限制也要一起看：權限要給多少，工具無法替你決定，代理的任務範圍要由開發和業務團隊一起定義；應用層檢查仍然要自己寫。選的時候問三件事：代理數量（少的話用原生權限，多的話才需要集中管理）、連接的系統（確認方案支援你的資料庫和雲端平台）、稽核需求（需要逐次記錄代理的存取時，確認有完整紀錄）。

這篇提到的項目要花多少錢

來源沒有列任何價格，表裡的金額大多是估算或未公開，照實標出來。

縮權限的工時是一次性的；管理員帳號留在代理手上的每一天，都是一次可能的誘導。

你可以學到什麼

站在攻擊者那一側看，一個拿著管理員帳號、又願意聽任何人說話的客服代理，是一扇對所有人敞開的門。他不需要帳號密碼，也不需要碰你的資料庫，只要在對話框裡把要求包裝得夠像一個正常請求。

揭露：本文未受任何廠商贊助，提及的產品僅為舉例。