The borrowed-credential trick worked—briefly
A short-lived AI agent borrows your credentials. It does a thing. The token expires. Life goes on. That model held up for exactly as long as agents stayed ephemeral, which turned out to be about eighteen months.
Now we have a second category: persistent AI coworkers that authenticate as a human and never give the credentials back. They don't finish a task and dissolve. They stick around. They accumulate permissions across projects. They act on your infrastructure while you sleep, and when a SOC analyst pulls the audit log at 2 a.m., the entry says "human did thing" because that is what the agent authenticated as.
Token Security's framing in a recent piece is blunt: an AI agent borrows your credentials; an AI coworker never gives them back. The distinction sounds semantic right up until you try to revoke access for something that doesn't have its own identity. You can't. You can only revoke the human's token, which might mean locking out a developer who logged in ten minutes ago.
This is what AI agent identity and access management actually means when you stop treating it as a slide deck bullet and start treating it as a Tuesday afternoon problem.
Three waves of risk, one broken assumption
Token Security's model sorts agentic risk into three waves. Wave one: the risk lived in the model's output. You filtered prompts, set guardrails, classified what came back. Wave two: agents started taking actions, but a human stayed in the loop. Access controls and approval flows did their job because someone was watching the door.
Wave three takes the human out of the loop and leaves the access in place.
That second clause is the whole ballgame. Your access controls still fire. They still authorize. They just fire for something that has no identity of its own, no lifecycle owner, and no natural expiry date. The security model assumed a human would eventually clock out. The coworker never does.
The over-privileging problem compounds this. When you launch an agent that needs to read Jira tickets, and you do it by spawning under your own session, the agent inherits everything you have access to. Your cloud provider credentials. Your deployment pipeline. The billing dashboard you opened once and forgot about. The agent doesn't need any of that. But it has it now, indefinitely, because nobody scoped the delegation.
Why "just use service accounts" misses the point
A reasonable first instinct is: fine, treat the agent like a service account. Use OAuth client credentials. Machine-to-machine. No user involved. The client authenticates with its own credentials, gets a short-lived access token, and the whole thing looks like a cron job talking to an API on its own behalf.
That is the right starting point. It is not the finish line.
Client credentials give you a clean authentication primitive—no redirect, no user login, no refresh token. What they don't give you is the governance layer. A client_id and client_secret in a vault with no owner, no expiry policy, and no review cycle is just a standing privilege with better hygiene. Token Security's recommendations point at this directly: record a human owner. Set death conditions. Scope access to the agent's actual need rather than to whoever launched it.
The OAuth grant solves "how does this thing prove who it is." Identity and access management still has to solve "who decided it was allowed to do this, when does that decision expire, and who checks."
The orphan problem nobody budgets for
Token Security's analysis puts orphaned agents with live credentials as the most common source of agent-related standing privileges. Read that again. The leading identity risk in production AI isn't sophisticated compromise. It's cleanup failure.
A developer builds a persistent agent. She leaves the team. The team disbands. The agent keeps running. Nobody knows who owns it. Nobody can articulate what it should be allowed to do. It is, functionally, a service account with no owner attached—which means it will never appear in an access review, never get decommissioned, and never fail closed.
This maps to what we've already seen with shared credentials in agent fleets, but the persistent-coworker variant is worse. A shared credential at least implies a human group that owns it. An orphaned autonomous agent might have been provisioned under a single engineer's personal API key that got revoked last quarter while the agent's session token stayed alive. And the pace of the problem is outstripping the fix: agent access is spreading faster than distinct identities in most enterprises we examine, an inversion that is already visible in non-human identity inventories.
What AI agent identity and access management looks like in practice
Token Security's five recommendations for platform-agnostic governance are worth taking seriously even if you don't buy their tool. SailPoint and CyberArk have comparable offerings; the underlying pattern matters more than the vendor.
Find what you missed. Registration only captures agents someone remembered to register. Shadow AI agents show up in authentication traffic before they show up in any inventory. Look for auth patterns that don't map to known humans or known service accounts. The pattern looks like shadow agents already discovered in enterprise environments—quietly authenticating, quietly accumulating access.
Give every persistent agent its own identity. If it authenticates as a human, no downstream control can tell the difference. No investigation can attribute an action correctly. This is the single highest-leverage change because it makes every other control actually work, and it is where traditional session-token identity management fails AI agents outright—the core problem behind governing non-human identities in autonomous agent fleets.
Record a human owner. Non-negotiable. An agent without an owner is an agent without an off-switch. Ownership must survive org changes, not just survive the initial provisioning ticket.
Scope to the agent's actual need. The agent that reads Jira does not need write access to your cloud provider. Scope the token to what the job requires, not to what the launching engineer happened to have in their session. This is least-privilege applied to machine identities, which is what treating agents as first-class identities looks like in practice.
Decide when it dies. Write the termination condition into the provisioning step. Idle period, team dissolution, owner departure—pick the triggers that fit your org and enforce them. The lifecycle management problem is real and it compounds with every agent you skip.
The short version
AI agent identity and access management isn't a new discipline. It is IAM applied honestly to a workload class we've been pretending is temporary for two years. Persistent agents need their own identities because shared or borrowed credentials make every security control downstream either blind or misleading. The fix is not exotic. It's the same inventory, ownership, scoping, review, and deprovisioning cycle that has always been correct for machine identities.
The only new part is the scale at which organizations are skipping it because the agents felt like a temporary experiment. They stopped being temporary. The access didn't expire. And the audit log still blames a human for everything the coworker did last night.