核心結論
短暫、完全由員工操作且不超出本人權限的助手，可能沿用使用者委派身分；但只要代理會排程執行、跨系統讀寫或在人員離線後持續工作，就應配置獨立代理身分。否則稽核、離職停權與事故追責會混在同一帳號。
執行摘要
核心觀察：AI 代理一旦能讀寫郵件、檔案、CRM 或工單，共用員工帳號就會把人的行為與代理行為混在一起。NIST 指出，分享人員或企業憑證給代理會造成問責缺口；一項由廠商資助、CSA 執行的 228 人調查中，68% 受訪組織無法清楚區分人與代理的活動。[1][6] 行動建議：每個正式代理建立獨立身分、具名負責人、任務範圍、短效權限、工具白名單、完整稽核欄位與撤銷演練，再決定是否擴大自動化。
共用帳號不是省事
AI 代理若直接使用員工帳號，系統看到的只會是同一個人登入、讀檔或修改資料。NIST 指出，共用人員或企業憑證給代理會造成安全、隱私、法律與問責缺口；要讓交易可信，代理應有自己的唯一識別、憑證與權限，並與啟動它的人或系統建立可查核的委派關係。[1]
這不代表每個短暫助手都要建立永久帳號。CNCF 區分，若代理只在使用者登入期間運作，且權限完全不超過該使用者，傳遞使用者身分可能足夠；一旦代理能排程執行、跨部門取資料、呼叫其他代理或在使用者離線後繼續工作，就需要獨立工作負載身分。[5]
權限要跟著任務走
獨立身分只是起點。Microsoft 建議維持穩定、可管理的代理身分，但把較高權限做成限時角色、短效 Token 或逐次核准，讓代理只在特定工作期間取得必要能力。[3] 對中小企業來說，最小單位不是『行政代理』或『業務代理』，而是讀取指定資料夾、建立草稿工單或更新特定 CRM 欄位。
同一流程同時需要讀取與修改時，應把權限分開。Microsoft 的實務文章建議，資料蒐集使用唯讀角色，刪除、匯出、付款或權限變更則透過不同工具或升級核准；每個下游服務仍要重新檢查身分、角色與範圍，不能只相信代理編排器已經檢查過。[4]
紀錄要能還原授權鏈
NIST NCCoE 把代理的識別、授權、稽核與不可否認性一起列入研究問題，因為只有聊天內容或最終輸出，無法回答代理用了哪個角色、碰到哪筆資料，以及當時代表誰行動。[2] 可用的稽核紀錄至少要串起使用者請求、代理身分、有效權限、工具呼叫、資源、動作、時間與關聯 ID。
CSA 的廠商資助調查收到 228 位 IT 與資安人員回覆，其中 68% 表示無法清楚區分人與代理活動，43% 使用共用服務帳號，31% 讓代理使用人類身分。[6] 這不是台灣母體調查，不能推估本地比例；它仍說明身分混用並非理論問題，而是企業代理進入正式流程後已出現的營運缺口。
先演練停權再上線
代理出錯時，企業需要只停掉這一個代理，而不是停掉整位員工或輪替所有共用系統的金鑰。Microsoft 指引要求測試停用代理、輪替憑證、使 Token 失效及移除殘留權限；工作流程、工具、資料範圍或部署環境發生重大變更時，也要重新審查有效權限。[3]
穹境建議正式接入前建立一張代理身分卡，至少包含代理 ID、具名 Owner、用途、可碰資料、允許動作、憑證期限、人工核准點與撤銷測試。Lead Measure 追蹤獨立身分覆蓋率、撤銷測試通過率及高風險動作核准覆蓋率；Lag Measure 追蹤孤兒身分、未授權呼叫及平均停權時間。這些是實務建議，不是上述來源的強制標準。
關鍵要點
共用帳號會消除責任邊界：同一帳號同時代表員工與代理時，紀錄無法單獨證明誰授權、誰執行。
每個代理都要有具名負責人：代理可以是非人身分，但核准、事件處理、停權與退役仍需由人負責。
短效權限優於永久開門：代理平時只保留最低權限，高風險任務才限時升權，完成後自動收回。
工具白名單要由系統執行：刪除、匯出、付款與權限變更不能只靠提示詞禁止，應在工具和下游系統再次授權。
停得掉才算可控：正式上線前要測試停用代理、撤銷 Token、輪替金鑰與移除下游權限是否同步生效。
參考來源
Back to the Future: Why Agentic AI Needs a Strong Identity Foundation
National Institute of Standards and Technology · 2026-08-27
https://www.nist.gov/blogs/cybersecurity-insights/back-future-why-agentic-ai-needs-strong-identity-foundationNew Concept Paper on Identity and Authority of Software Agents
National Institute of Standards and Technology · 2026-02-05
https://www.nist.gov/news-events/news/2026/02/new-concept-paper-identity-and-authority-software-agentsLeast privilege for AI agents with Microsoft Entra Agent ID
Microsoft Learn · 2026-07-15
https://learn.microsoft.com/en-us/security/zero-trust/sfi/least-privilege-for-ai-agentsLeast privilege for AI agents: Identity, access, and tool binding
Microsoft Security · 2026-07-16
https://www.microsoft.com/en-us/security/blog/2026/07/16/least-privilege-for-ai-agents-identity-access-and-tool-binding/Cloud native agentic standards
Cloud Native Computing Foundation · 2026-03-23
https://www.cncf.io/blog/2026/03/23/cloud-native-agentic-standards/More Than Two-Thirds of Organizations Cannot Clearly Distinguish AI Agent from Human Actions
Cloud Security Alliance · 2026-03-24
https://cloudsecurityalliance.org/press-releases/2026/03/24/more-than-two-thirds-of-organizations-cannot-clearly-distinguish-ai-agent-from-human-actions常見問題
Q：AI 代理可以直接使用員工的 Microsoft 或 Google 帳號嗎？
A：短暫、完全由員工操作且不超出本人權限的助手，可能沿用使用者委派身分；但只要代理會排程執行、跨系統讀寫或在人員離線後持續工作，就應配置獨立代理身分。否則稽核、離職停權與事故追責會混在同一帳號。
Q：每個 AI 代理都要建立不同帳號嗎？
A：正式且能自主操作的代理，原則上應有可唯一辨識的工作負載身分，不一定是傳統員工帳號。每個身分都要連到具名 Owner、用途、資料範圍與撤銷方式；同一身分跨多個代理重複使用，會讓停權與稽核變得不精準。
Q：AI 代理最小權限要怎麼設定？
A：先按任務拆角色，例如唯讀查詢、建立草稿、更新單一欄位，不要直接給部門級 Admin。刪除、匯出、付款及權限變更使用限時升權或人工核准，並由每個下游系統重新檢查身分、資源、動作與有效期限。
Q：如何證明某個動作是 AI 代理做的，不是員工做的？
A：代理必須有獨立身分，紀錄中同時保留代理 ID、代表的使用者、有效角色、工具、資源、動作、時間與關聯 ID。若人與代理共用帳號或金鑰，即使有系統 Log，也可能只能證明帳號做了事，無法還原完整授權鏈。
Q：中小企業在 AI 代理上線前，最低限度要測什麼？
A：至少測三件事：代理能否被單獨停用、已發出的 Token 能否失效、下游系統的殘留權限能否移除。再用測試資料確認唯讀代理不能寫入，高風險動作必須核准，稽核紀錄能從使用者請求一路追到實際變更。
由穹境科技 AI 情報系統生成 · 2026-09-11 · 資料來源見上方參考列表