身份服務商 Curity 的 CTO Jacob Ideskog 這週發了一篇文章，論點是：大多數企業在跑的 IAM 堆疊是圍繞一個模型設計的——人登入、拿到會話 token、在那次會話裡採取動作——而當前這一代 AI 智能體正在打破這個模型。他引用的標題數字是：在現代企業系統中，非人類身份現在占了所有認證的 90% 以上。不論你信不信 Curity 的具體數字，方向性判斷和過去一年所有雲安全團隊都在說的事情一致：服務帳號、CI/CD 流水線、自動化 runner、現在加上 LLM 驅動的智能體，承擔了認證流量的大頭，而圍繞它們的控制是從「以人為中心」的設計假設裡繼承下來的，跟現在的工作負載已經對不上了。

Ideskog 列舉的具體架構失敗模式是真實的。當前的 IAM 假設一次會話開始時有一個單一認證門。智能體不是這樣工作的；它們跨服務做多步 API 呼叫鏈，往往跨越幾分鐘到幾小時，步驟之間沒有人在迴路裡。它們繼承啟動者的權限——意思是一個被攻破的智能體 token 給攻擊者的是啟動該智能體的使用者的「寬廣權限集」，而不是這個智能體本來要做的某個具體動作的「狹窄權限集」。對一個已登入員工原本工作得很好的常駐存取 token，當智能體自己決定呼叫哪個 API 時就成了風險。而雙重身份問題——智能體有自己的身份，同時它還代表某個使用者行動——在大多數現有 IAM 堆疊裡沒有乾淨的原語。

被推薦的模式是真有道理的，而且並不是 Curity 獨有的。以應用為中心而非以使用者為中心的授權。即時按需、最小權限、按動作和時間窗口範圍發的憑證，而不是常駐 token。每次 API 呼叫都做的執行時持續授權，不是會話開始的一次門控。帶上下文的 token：行動者身份、被代表的使用者、目標動作、當前信任級別。所有這些的技術原語在今天的 OAuth 2.0 裡就有——token exchange（RFC 8693）做雙重身份、dynamic client registration（RFC 7591）做短期智能體憑證、rich authorization requests（RAR，RFC 9396）做按動作範圍的 token。缺口不在標準上。缺口在大多數企業 IAM 部署要麼沒實作這些 endpoint，要麼把它們實作成沒人開的開關。

對做智能體平台的開發者來說，實際解讀是：存取控制工作是真正的工程，不是合規細節。你平台上跑的智能體大概需要自己的身份（不是從使用者那借來的）、按任務發出的短生命週期範圍化憑證（不是會話長度的）、以及一層執行時授權能在 token 已發出之後還能拒絕某個動作（因為信任訊號會在會話中途變化）。Curity 賣的產品做這些；Okta 的 Workload Identity、AWS 的 IAM Identity Center 加 Verified Permissions、以及一批更小的玩家像 Aembit、Astrix 也都在做。Ideskog 那篇裡的廠商推銷在架構層面並沒說錯，但開發者應該直接評估 OAuth 2.0 原語、自己選部署路徑，而不是把「智能體 IAM」當作單一貨源類別處理。90% 非人類這個數字才是應該讓每個安全團隊回頭審視自己跑的是什麼的部分，不管最後買的是哪家。