Jacob Ideskog, CTO of identity vendor Curity, published a piece this week arguing that the IAM stacks most enterprises run were designed around a model — a human logs in, gets a session token, takes actions within that session — that the current generation of AI agents is breaking. The headline statistic he cites is that non-human identities now account for more than 90% of all authentications in modern enterprise systems. Whether you trust Curity's exact number or not, the directional claim is consistent with what every cloud security team has been saying for the past year: service accounts, CI/CD pipelines, automation runners, and now LLM-driven agents are doing the bulk of the auth traffic, and the controls around them are downstream of human-centric design assumptions that no longer match the workload.
The specific architectural failure modes Ideskog catalogs are real. Current IAM assumes a single authentication gate at the start of a session. Agents do not work that way; they take multi-step API chains across services, often spanning minutes or hours, with no human in the loop between steps. They inherit the permissions of whoever launched them, which means a single compromised agent token gives an attacker the broad permission set of the user who started the agent rather than the narrow permission set of any individual action the agent was supposed to take. Standing access tokens that worked fine for a logged-in employee become a liability when an agent is making decisions on its own about which APIs to call. And the dual-identity problem — the agent has its own identity AND it acts on behalf of a user — has no clean primitive in most existing IAM stacks.
The recommended pattern is genuinely sensible and not actually proprietary to Curity. Application-centric authorization rather than user-centric. Just-in-time, least-privilege credentials scoped to specific actions and time windows rather than standing tokens. Continuous runtime authorization at every API call instead of a single gate at session start. Tokens that carry context: actor identity, represented user, intended action, current trust level. The technical primitives for all of this exist in OAuth 2.0 today — token exchange (RFC 8693) for dual-identity, dynamic client registration (RFC 7591) for ephemeral agent credentials, and rich authorization requests (RAR, RFC 9396) for action-scoped tokens. The gap is not the standards. It is that most enterprise IAM deployments either do not implement these endpoints, or implement them as toggles nobody uses.
For builders working on agent platforms, the practical reading is that the access-control work is real engineering and not a compliance afterthought. The agents your platform runs probably need their own identities (not borrowed from the user), short-lived scoped credentials issued per-task (not session-long), and a runtime authorization layer that can decline an action even after the token was issued (because trust signals can change mid-session). Curity sells products that do this; so do Okta with their Workload Identity work, AWS with IAM Identity Center and Verified Permissions, and a number of smaller players like Aembit and Astrix. The vendor pitch in Ideskog's piece is not wrong on the architecture, but builders should evaluate the OAuth 2.0 primitives directly and pick a deployment path rather than treating agent IAM as a sole-source category. The 90%-non-human number is the part that should make every security team review what they are running, regardless of which vendor they end up buying.