AI代理如何揭示傳統IAM架構的根本缺陷

核心問題：人類並不總是在鍵盤後面

傳統的身份與存取管理（IAM）系統建立在一個假設之上——有人實際在那裡進行驗證。人類坐在登入畫面前，輸入密碼，收到多重驗證（MFA）推送通知，然後批准。這個工作流程已經定義了數十年的安全標準。

但人工智能代理徹底打破了這個假設。

當自主代理在非工作時間以高速處理API請求時，它無法暫停來回答MFA挑戰。當一個委託代理代表用戶處理行事曆和電子郵件任務時，它絕不應繼承該用戶的完整權限集。驗證系統不能要求人類互動來處理那些24/7運行且沒有人工監督的流程。整個架構——登入畫面、密碼提示、人類驗證的多重身份驗證——在代理接管工作流程執行的那一刻，變成了架構負債。

真正的問題是：傳統的IAM無法區分合法的代理請求與在有效憑證下運作的被攻擊請求。 當主體（principal）沒有通過正常授權渠道訪問API操作時，系統會攔截。但當該主體的憑證被劫持，或當代理的意圖因為上下文污染而變得惡意時，傳統系統毫無防範措施。這個技術身份驗證與實際信任度之間的鴻溝，定義了代理認證的核心挑戰。

兩種根本不同的代理模型，兩種不同的身份需求

人類委託代理：範圍與最小權限問題

人類委託代理是在授權範圍內運作——你授權一個AI助手管理你的行事曆。但危險之處在於：目前大多數系統要麼授予代理完整的權限集，要麼要求你手動定義限制。這兩種方式都不可行。

代理不需要繼承你的全部身份。它只需要精確範圍的權限。你直覺上知道，支付帳單的服務不應該轉帳到任意帳戶。你本能地防止金融指令被誤解。AI系統缺乏這種情境推理能力，這也是為什麼最小權限存取（least-privilege access）不是選擇，而是必須。

技術實作方式如下：

系統實施雙重身份驗證。代理同時在兩個身份下運作：

• 你的身份 (授權人（委託人）)，具有完整權限
• 代理的受限身份，具有明確的範圍界限

當你授權時，會進行一個令牌交換。代理不會獲得你的憑證，而是收到一個範圍縮小的令牌，內容包括：

• agent_id：此特定代理實例的唯一識別碼
• delegated_by：你的用戶ID
• scope：權限範圍界限 (例如，“銀行：支付帳單”但明確不包括“銀行：轉帳”)
• constraints：政策限制，如批准的收款人名單、交易金額上限和到期時間

流程大致如下：