為了「先讓它跑起來」,
AI 代理拿到了整個資料庫的權限
為什麼現在很紅:代理只需要讀訂單和改電話地址,卻能刪掉整張資料表;管理員帳號能做的事,代理理論上都做得到。
- 一句話結論
- AI 代理開發時為了省事直接用資料庫管理員帳號,「之後再調權限」常常一直沒有發生。
- 他要的是什麼
- 他不用碰你的資料庫。他只要在客服對話框裡打一段話,讓那個拿著管理員帳號的代理替他去查。
- 你今天做一件事
- 今天就查一下客服代理連資料庫用的是哪個帳號、有哪些權限;只要看到刪除資料表的能力,就排進這週的工作。 直接去做 →
- 哪些能信
- 3 可證明2 推論2 缺口 每個主張都標了等級,缺口是誠實寫出來的。
- 破口速查
- 受害端一律去識別化;寫「未公開」代表公開資料查不到。
- 伺服器服務商
- 不適用(示意情境;涉及的是客服 AI 代理與後端資料庫)
- 網路服務商
- 不適用(同上)
- 漏洞出現的地方
- 應用與資料庫層:客服 AI 代理用共用的資料庫管理員帳號連線,權限遠超任務;顧客輸入是不可信的內容卻能影響代理行為;資料範圍只靠提示詞約束,沒有在應用層強制檢查
- 馬上自我檢測
列出每個代理的任務與需要的資料庫動作(不用指令) SELECT current_user; SHOW GRANTS FOR CURRENT_USER; 確認代理用的帳號是否也被其他系統或人共用(不用指令)- 漏洞修補方式
- 列出代理任務只開需要的權限;給代理專屬帳號不與人或其他系統共用;資料庫層用只讀帳號、限定資料表或欄位、能用檢視表或預存程序就不開放任意查詢;應用層用程式強制加上只能查這位顧客的條件;刪除、退款、批次修改保留人工核准;用雲端 IAM 工具找出多餘權限;開啟代理的查詢紀錄
有 15 分鐘再看:其餘 2 點
- OWASP 把這類問題稱為「過度代理」,根本原因是功能過多、權限過大、自主性過高,觸發因素包括模型幻覺與提示注入。
- 用原生功能就能先做:給代理專屬帳號、只開任務需要的權限、在應用層強制限定資料範圍、高風險動作保留人工確認。
客服 AI 代理只需要查訂單、更新聯絡資料,開發時卻直接給了一組資料庫管理員帳號,想說「之後再調權限」。上線之後,那個「之後」一直沒有來。這篇講怎麼把代理的權限縮回它真正要做的事。
本篇目錄
那個「之後」一直沒有來
假設有一家四十人的電商公司,做了一個客服 AI 代理,幫客服查訂單、更新客戶資料。開發時為了省事,直接給了一組資料庫管理員帳號,想說「先讓它跑起來,之後再調權限」。上線之後大家都在忙別的事。某天,一位顧客在客服對話裡輸入了一段精心設計的文字,代理照做了,查出不屬於這位顧客的訂單資料。
先說清楚,這是示意情境,不是真實事件,公司與經過都是為了說明而設。事後檢查發現:代理其實只需要「讀取訂單」和「更新聯絡資料」兩個權限,卻擁有刪除資料表的能力。那個「之後」,一直沒有來。
這篇要講的只有一件事:代理的權限要等於它的任務,而且要用程式擋,不能只靠提示詞拜託它。
過度代理,風險在哪裡
OWASP 的 LLM 應用風險清單把這類問題稱為「過度代理」(Excessive Agency),並指出根本原因通常是三者之一或同時存在:功能過多、權限過大、自主性過高;觸發因素包括模型幻覺和提示注入。
放到示意情境裡,第一層是權限遠超任務:管理員帳號能做的事,代理理論上都做得到。第二層是輸入不可信:顧客輸入的內容會影響代理的行為,而任何人都能當顧客。第三層是影響範圍:一次被誘導,影響的是整個資料庫。最後是難以撤銷:共用的管理員帳號,收回會影響其他系統,所以出事時也不敢馬上停。
這篇示意情境裡,代理手上拿的是什麼
這是示意情境,憑證本身沒有外洩;下表列的是代理手上那把權限過大的鑰匙,以及它被誘導時實際被「借用」的範圍。
| 服務 | 憑證類型 | 用途 | 存在形式 | 放在哪 | 權限範圍 | 狀態 |
|---|---|---|---|---|---|---|
| 後端資料庫 | 資料庫管理員帳號密碼 | 讓客服 AI 代理查訂單、更新客戶聯絡資料 | 應用程式設定中的連線字串(環境變數) | 客服代理的執行環境;同一組帳號也被其他系統使用 | 整個資料庫,包含刪除資料表 | 示意情境;仍在使用,因共用而難以單獨收回 |
| 同一個資料庫帳號的其他使用者 | 同上 | 其他系統連線 | 不明 | 還有哪些系統在用無法確認 | 同上 | 無法確認 |
憑證沒有被偷,但代理被誘導時,攻擊者等於借用了這把鑰匙的全部權限。
能證明的、只能推論的
這篇是觀點文,情境是示意的,所以能證明的只有官方文件寫明的事;情境裡的經過只能算推論,不知道的就寫成缺口。
不花錢就能做的流程
到這裡,其實已經足夠理解問題在哪。如果你想直接動手,可以跳到「今天就可以來試試」;下面是完整的六步流程。
第一步,列出代理的任務和需要的動作。 例如「讀取訂單」「更新電話與地址」。只開這些權限。
第二步,給代理專屬帳號。 不要和人或其他系統共用,出事時才能單獨停用。
第三步,資料庫層面限制。 只讀帳號、限定資料表或欄位;能用檢視表或預存程序的,就不要開放任意查詢。
第四步,應用層再擋一次。 代理查詢客戶資料時,用程式強制加上「只能查這位顧客」的條件,不要只依賴提示詞。
第五步,高風險動作要人工確認。 刪除、退款、批次修改,保留人工核准。
第六步,找出多餘權限。 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 等傳統特權存取廠商也有相關產品線。
限制也要一起看:權限要給多少,工具無法替你決定,代理的任務範圍要由開發和業務團隊一起定義;應用層檢查仍然要自己寫。選的時候問三件事:代理數量(少的話用原生權限,多的話才需要集中管理)、連接的系統(確認方案支援你的資料庫和雲端平台)、稽核需求(需要逐次記錄代理的存取時,確認有完整紀錄)。
這篇提到的項目要花多少錢
來源沒有列任何價格,表裡的金額大多是估算或未公開,照實標出來。
| 項目 | 用量 | 單價 | 期間 | US$ | NT$ | 舉證 |
|---|---|---|---|---|---|---|
| 列出代理任務並建立專屬最小權限帳號 估 | 工程師一人 | 估 2–4 小時/每個代理 | 一次性 | — | — | 本站估算 |
| 應用層資料範圍檢查 估 | 工程師一人 | 估 4–8 小時 | 一次性 | — | — | 本站估算,依系統複雜度而定 |
| AWS IAM Access Analyzer 未使用存取發現 | 依帳號與角色數 | 付費功能,本文未取得價格 | 每月 | — | — | AWS 官方文件註明需付費 |
| Teleport Access Requests | Enterprise 版 | 本文來源未列價格 | — | — | — | 官方文件註明為 Enterprise 功能 |
| 示意情境中越權查詢造成的損失 | 未知 | 未公開 | — | — | — | 示意情境;影響範圍要看查詢紀錄 |
| 合計(僅可證明列) | 0.00 | 0 | ||||
縮權限的工時是一次性的;管理員帳號留在代理手上的每一天,都是一次可能的誘導。
你可以學到什麼
站在攻擊者那一側看,一個拿著管理員帳號、又願意聽任何人說話的客服代理,是一扇對所有人敞開的門。他不需要帳號密碼,也不需要碰你的資料庫,只要在對話框裡把要求包裝得夠像一個正常請求。
- 01OWASP 把 AI 代理權限超過任務的問題稱為過度代理,根本原因是功能過多、權限過大、自主性過高,觸發因素包括模型幻覺與提示注入。
- 02代理的權限要等於它的任務:先列出要做的動作,只開這些權限,並給它不與人或其他系統共用的專屬帳號。
- 03資料範圍要在應用層用程式強制限定,例如只能查這位顧客;只靠提示詞約束,擋不住提示注入。
- 04刪除、退款、批次修改這類高風險動作保留人工核准,代理被誘導時才有最後一道關卡。
- 05開啟代理的查詢紀錄,出事時才答得出它做過什麼;沒有紀錄,「只有這一次」永遠只是推論。
- 01過度代理(Excessive Agency)這篇的主角:OWASP 對 AI 代理權限、功能、自主性超過任務的命名。
- 02最小權限代理的權限等於任務,決定被誘導時能造成多大損害。
- 03提示注入(Prompt Injection)顧客輸入能改變代理行為的原因,也是示意情境的觸發點。
- 04專屬服務帳號不與人或其他系統共用,出事時才能單獨停用。
- 05應用層資料範圍檢查用程式強制「只能查這位顧客」,不依賴模型守規矩。
- 06檢視表(View)/預存程序把代理能碰的資料限縮在固定形狀,不開放任意查詢。
- 07人工核准(Human-in-the-loop)高風險動作的最後一道關卡。
- 08IAM Access Analyzer找出雲端上未使用權限的 AWS 工具,注意這類發現需付費。
- 09IAM 角色建議Google Cloud 依實際使用建議縮小角色。
- 10查詢紀錄(Query Log)唯一能回答代理做過什麼的證據,沒有它就只剩推論。
全部唯讀,不改任何設定;做完你會知道自己有沒有同樣的破口。
- 列出每個 AI 代理的任務,以及每個任務需要的資料庫動作(不用指令)看到什麼代表什麼:寫出來的動作通常只有兩三個;拿去和下一步看到的權限比,差距就是要收回的部分。
- 用代理的連線設定登入資料庫,確認它實際用的是哪個帳號(唯讀)
SELECT current_user;看到什麼代表什麼:看到的是管理員或共用帳號,就是示意情境裡那一把。拆出來的專屬帳號取名像「agent_support_ro_s4」,下一步 SHOW GRANTS 時一眼就知道它該只有 SELECT 和 UPDATE。 - MySQL:列出這個帳號的權限(唯讀;PostgreSQL 可在 psql 用 \du 查看角色)
SHOW GRANTS FOR CURRENT_USER;看到什麼代表什麼:出現 ALL PRIVILEGES、DROP、DELETE 這類代理任務用不到的權限,就是過度代理。 - 確認同一個帳號是否也被其他系統或人共用(問負責人或看連線設定,不用指令)看到什麼代表什麼:有共用,代表出事時無法單獨停用,要先拆出專屬帳號。
- 確認代理的查詢有沒有被記錄、記錄留多久(唯讀)看到什麼代表什麼:沒有記錄,出事時就答不出代理做過什麼。
揭露:本文未受任何廠商贊助,提及的產品僅為舉例。
環境背景、時間線、攻擊鏈對照 ATT&CK、關鍵證據、根因、處置與檢討都在完整版,約 7 分鐘。
來源
- OWASP GenAI:LLM06:2025 過度代理(Excessive Agency)
- AWS IAM Access Analyzer:發現項目說明(含未使用存取)
- Google Cloud:IAM 角色建議總覽
- OpenBao(開源 Vault 分支)
- Teleport Docs:Access Requests
本文為公開報導與官方公告的整理與拆解,非第一手鑑識;證據等級依來源可信度標註。
本文由 AI 團隊協助研究與撰寫,經隱私與事實檢查後發布;證據等級依來源可信度標註。
複製下面這段,貼給你在用的 AI 工具(Claude Code、Cursor、Copilot、ChatGPT 都可以)。它會用本篇的破口位置、自我檢測與學習重點,對你的專案或環境做一次資安掃描,列出潛在問題與建議的調整或加強方式。
預設是唯讀:只發現問題、提出建議,不會改你任何檔案或設定。
M2 身分與金鑰 · 想在自己的環境做一次同樣的盤點,從 自我盤點 開始。
每篇新文章一封:三點摘要、關鍵字定義、今天能做的一件事。或先 加入會員 記錄你完成的任務。