Short-lived tokens aren't AI agent lifecycle management

Okta made Agent SSO generally available on 24 August 2026 and put it in core SSO plans at no extra cost. It is good engineering. Agents get registered as real identities in the directory, and instead of a key someone pasted into an environment variable eighteen months ago, they get short-lived tokens brokered per call under least-privilege policy.

It solves the credential. It does not solve AI agent lifecycle management, and from the outside those two problems look identical.

TL;DR: Okta’s Agent SSO, GA on 24 August 2026, replaces static API keys and one-off OAuth grants with short-lived, identity-governed tokens. That closes the window in which a stolen credential is useful. It does not close the lifecycle: nobody requested the agent through a process, nobody re-reviews its scope on a schedule, and nobody retires it when the workflow it was built for stops existing. An auto-renewing short-lived token is a permanent grant with extra steps. AI agent lifecycle management is four owned transitions — request, scope, review, retire — and an identity platform gives you somewhere to record them, not a decision about who owns them.

What Okta actually shipped

The mechanics are straightforward. An agent is registered in Okta’s Universal Directory as its own identity. Administrators attach access policies to it. When the agent needs to act in another application on a user’s behalf, Okta verifies both the agent and the human behind the request, evaluates policy, and brokers a short-lived credential for that connection. It runs on Cross App Access, which Okta describes as “an open, vendor-neutral protocol that allows identity security to follow agents dynamically across applications.” Ric Smith, Okta’s President of Products and Technology, framed the goal in the announcement: “AI agents are fast becoming a primary interface for how work gets done, but granting them access to enterprise systems shouldn’t require trading away security or visibility.”

The most useful sentence in the release is the one describing the world it replaces. Most agents, Okta says, reach enterprise data through “static API keys, one-off OAuth grants, and custom integrations built application by application.”

Read that again as an operator rather than a security buyer. That is not a description of a weak security posture. It is a description of a seam — a set of connections built one at a time, by different people, at different times, for reasons that were obvious on the day and written down nowhere. The security exposure is a symptom. The integration nobody documented is the condition.

An expiry is not a review

Here is where the good engineering stops and the process work starts.

A short-lived token limits how long a stolen credential remains useful. That is real, and the industry has receipts for why it matters. OWASP’s Non-Human Identities Top 10 for 2025 ranks long-lived secrets at NHI7, and the data points it cites from the Cloud Security Alliance’s non-human identity research are blunt: 51% of organizations have no formal process to offboard or revoke long-lived API keys, and a lack of credential rotation was the cause in 45% of NHI-related security incidents.

Now read the 51% again, and notice the verb doing the work. It is offboard, not revoke. Those are not synonyms. Revoking is an action you take on a credential. Offboarding is a process you run on a worker.

Rotation is not retirement.

Picture the well-governed version. An agent authenticates through Agent SSO. Its token refreshes on a sixty-minute cycle, so it never appears on any expiring-credentials report — the report is built to find stale secrets, and this one is never stale. Its scope is least-privilege against the three endpoints someone chose in the first sprint. Its audit trail is complete. By every control the platform exposes, it is exemplary.

It will also still be running four years after the process it was built for was replaced, because nothing in a token lifecycle asks whether the agent should exist. The expiry is a clock. A review is a person. Buying the clock does not hire the person.

This is the same shape as the access contract nobody wrote, one step further down the timeline. That piece was about scoping on the way in. This one is about everything after — and the way out, which almost nobody has mapped at all.

The transitions an agent never gets

Every enterprise already runs a lifecycle process for workers. It has a name — joiner, mover, leaver — an owner in HR, and a trigger at each stage. Agents have the same transitions and none of the machinery.

Transition	Human employee	AI agent, as typically deployed
Request	Headcount request, budget approval, named hiring manager	A developer decides it would be useful on a Tuesday
Scope	Job description; access derived from role	Whatever the integration needed to work in testing
Change of role	Manager-initiated access review, old permissions removed	Scope only ever grows; nothing is subtracted
Periodic review	Performance cycle, access recertification	None; the agent is not on anyone’s review list
Departure	HR trigger, offboarding checklist, accounts disabled	No trigger exists

The last row is the whole problem. Every other row can be patched with tooling; Okta and its competitors are patching them now, and Agent SSO is a legitimate improvement on rows two and three. The last row cannot be patched with tooling, because it is not a missing control. It is a missing event. Nobody files a resignation letter on behalf of a service account.

Request. For a human, someone signs off and a budget line appears. For an agent, the cost lands as usage on a bill that nobody reconciles to a business process, so no approval gate is ever forced.

Scope. A person’s access derives from a role that exists in writing. An agent’s access derives from what made the integration work during testing, which is reliably broader than what the task needs, because narrowing it costs an afternoon and shipping was the goal.

Review. Access recertification exists in most regulated firms and runs on the identity directory. The agents that skip it are the ones that were never registered in the first place — the ones built on a platform someone expensed, which is an inventory problem before it is a policy problem.

Retire. The only one that matters, and the only one with no owner. A human leaves and a payroll line goes quiet. An agent’s process gets replaced and the agent keeps authenticating cleanly, on schedule, against a workflow that no longer exists.

Why the retirement never happens

There is a practical reason beyond neglect, and it is worth naming because it is fixable.

Google Cloud’s State of AI Infrastructure report, drawn from a survey of more than 1,400 senior IT leaders, found that 43% of IT leaders cite “difficulty integrating with legacy APIs and data sources” as their biggest agentic AI infrastructure gap. That number usually gets read as a build-side complaint. It is also a tear-down-side complaint.

An integration that was hard to build is one nobody wants to touch. The person who wrote it has moved teams. The undocumented part — the field mapping, the retry behaviour, the reason it hits the staging endpoint on Fridays — lives in their head. So when someone asks whether the agent can be switched off, the honest answer is that nobody knows what breaks, and the cheap answer is to leave it running. It costs a few dollars a day and it has a valid token. It becomes load-bearing by accident, which is how systems nobody owns always become load-bearing.

The working version

The fix is unglamorous and takes about twenty minutes per agent, at build time, when the context still exists.

Write down five things and store them next to the agent, not in a wiki someone will archive: the person who owns it, in one name rather than a team; the business process it serves, in one sentence; what it is allowed to touch and why each item is on the list; the date it gets reviewed; and the condition under which it gets switched off. That last line is the one that gets skipped and the only one that creates the missing event. “Retire when the quarterly close moves to the new ERP” is a trigger. “Review periodically” is not.

Then wire the trigger to something that actually fires. If the agent serves a process, the owner of that process should inherit the agent when the process changes — the same way a system gets reassigned, not the way a file gets orphaned. The identity platform will happily hold all of this. It will not generate any of it, in the same way it will not decide how long the agent’s state should be kept or who is accountable for an approval.

And do the inventory pass once, honestly. Take every automated actor with credentials in your environment and ask a single question about each: what business process does this serve, and who confirms it still runs? Most teams find two or three they cannot answer for. Those are not security findings. They are processes that ended without anyone noticing, still holding a valid token, refreshing every sixty minutes, forever.