Every AI agent an organization switches on is a new user holding credentials, and in most organizations nobody can say what those credentials are entitled to reach. AI agent identity, meaning the credentials an agent uses to act as a distinct user in your systems, is not a new failure. It is an old one arriving at a volume that makes it impossible to keep deferring.
Machine identities (service accounts, API keys, OAuth tokens, the credentials an agent carries when it acts on your behalf) now outnumber people across most enterprises, and agents issue more of them every week. The Cloud Security Alliance's State of Non-Human Identity and AI Security survey with Oasis Security, published in January 2026, found that 78% of organizations have no documented, formally adopted policy for creating or removing an AI identity. The market's answer is a new category of tooling to govern agent identity. We think most of that spend is an invoice for work that was deferred years ago.
We rebuilt single sign-on for Cambridge University Press, where the published results were "100M users supported globally" and a "Zero downtime SSO migration". The hard part was never the login. It was that five populations (public accounts, individual subscribers, universities on site licenses, federated campus logins, and token-based API access) each needed different handling, and no single place existed to see them together. Unifying them cost a dual-run migration: old and new systems in parallel, dual writes, populations moved region by region behind feature flags.
Identity becomes governable at the moment every credential resolves through one layer that can answer three questions: who owns this, what can it reach, and how do I revoke it now. Cambridge was not made safer by stronger authentication. It was made manageable because operations could look up any identity, read its history, and act on it on the spot. An agent credential is the same object with a much faster issuance rate, which means an organization that could not answer those three questions about a service account will not answer them about an agent either. Vendor guides on agent identity converge on the same controls: a distinct credential per agent, least-privilege scope, short-lived tokens, and every action traceable to the person who started it. Each of those controls assumes the three questions already have answers.
At Cambridge, the part that ran longer than we expected was federation. Universities around the world, each with its own identity system, its own standards and its own approval timeline, and every integration genuinely unique. That is the cost nobody budgets: not issuing credentials, but the long tail of systems that issue them on your behalf and belong to no one on your org chart. Agent frameworks sit exactly in that tail. They are onboarding themselves into your estate the way a federated university did, except they arrive weekly and nobody signs a contract first.
If you are running delivery and weighing an agent identity product, there is a cheaper test to run first. Take one credential already in production (a service account, an API key, the token behind an agent you shipped this quarter) and time how long it takes to establish who owns it, what systems it can reach, and how you would revoke it this afternoon without breaking a release. If that takes a week for a credential you issued to a human, the problem is not the agent, and no procurement cycle closes that gap. It is the same discipline as knowing what an agent actually costs to run: the answer either exists today or it does not, and finding out is the finding.
Treating agent identity as old debt is not an argument for slowing down AI integration. It is an argument for treating an agent as what it is: another identity in your estate, entitled to something, owned by someone.
Agents did not create credential sprawl. They just stopped it being survivable by ignoring it.