Agentic IAM in September 2026: What Okta Agent SSO, Ping, and JumpCloud Mean If You Run Keycloak

Last updated: September 2026

Three vendors shipped agentic IAM products in the last three weeks: Okta made Agent SSO generally available on 24 August 2026, Ping Identity launched Enterprise Personal Agent Access on 1 September 2026, and JumpCloud extended its Agentic IAM line on 10 September 2026. Underneath the category name, most of what they sell is four things: a distinct identity per agent, short-lived scoped tokens instead of static API keys, a binding from each agent back to a human owner, and discovery of the agents nobody registered. Keycloak can do the first three today with confidential clients, service accounts and token exchange. The fourth, discovery, is the genuine gap, and it is a gap in your inventory rather than in your identity provider.

That split is the useful way to read the announcements, so it is worth going through what each vendor added and where the equivalent control lives if you already run Keycloak.

What does “agentic IAM” actually mean?

Agentic IAM is the practice of giving an AI agent its own identity in your identity provider rather than letting it borrow a human’s credentials or a static API key. The category name is new, the underlying controls are not: they are OAuth 2.0 clients, scoped tokens, token exchange and audit events, applied to a caller that happens to be software acting semi-autonomously.

The problem the category exists to solve is real and specific. An agent that runs on a developer’s personal access token inherits everything that developer can reach, keeps working after they change teams, and produces audit entries attributed to a person who was asleep. Every vendor announcement in this window names some version of that failure.

Our read: the phrase “Agent SSO” is doing marketing work that obscures the engineering. There is no new sign-on protocol for agents. What the products ship is a bundle: an identity registry for agents, a policy layer over which agent may call which app, and a console that makes both legible. Two of those three are inventory and UX rather than protocol, which is exactly why a Keycloak shop can close most of the gap without buying anything.

What did Okta, Ping and JumpCloud actually announce?

Each of the three launches targets a different slice of the agent problem, and only one of them introduces a protocol you would need to implement.

Okta Agent SSO went generally available on 24 August 2026, according to Okta’s newsroom release “Okta brings first-class identity to AI agents with Agent SSO.” It models agents as first-class identities in the Okta directory and connects them to applications using Cross App Access, so an agent calling a downstream app gets a short-lived scoped token issued by the identity provider instead of a stored API key.

Ping Identity announced Enterprise Personal Agent Access on 1 September 2026, covered by Help Net Security under “Ping Identity introduces enterprise security for personal AI agents.” Its focus is the personal agent running on an employee’s machine, including desktop assistants and coding agents. The pitch is discovery of shadow agents, association of each agent session with the user and device behind it, and runtime control at the moment of action.

JumpCloud extended its Agentic IAM capabilities on 10 September 2026, per its press release “JumpCloud Extends IAM to Protect the New Agentic Workforce.” The named additions are unique agent identities with instant revocation, automated discovery of MCP setups routed through its AI gateway, and uniform policy across SaaS tools.

Read together, the common thread is governance of agents your security team did not provision. Ping and JumpCloud both lead with discovery, which tells you where the vendors think the money is.

What is Cross App Access, and do I need it?

Cross App Access is the informal name for the IETF OAuth working group draft “Identity Assertion JWT Authorization Grant,” which lets an application use an identity assertion to get an access token for a third-party API by coordinating through a shared identity provider. It combines OAuth 2.0 Token Exchange (RFC 8693) and the JWT profile for authorization grants (RFC 7523), and it registers the token type urn:ietf:params:oauth:token-type:id-jag plus the media type oauth-id-jag+jwt.

The mechanism is worth understanding even if you never adopt it. The ID-JAG replaces the refresh token held by the resource authorization server, which is the part that matters: today each SaaS app that an agent touches holds its own long-lived grant, invisible to your identity provider. With an ID-JAG in the path, the identity provider issues a short-lived assertion per interaction, so revoking the agent at the identity provider actually revokes it everywhere.

Whether you need it right now depends entirely on whether the downstream applications your agents call support it, and today most do not. The draft is an active IETF work item rather than a finished standard, and adoption on the receiving side is early. If your agents mostly call your own APIs, you can get the same revocation property with standard token exchange and short lifetimes, which Keycloak already supports. We walked through the receiver-side patterns in our guide to Cross App Access and ID-JAG for AI agents on Keycloak.

What can Keycloak do today without a vendor SKU?

Keycloak covers most of what the September launches advertise, and the exceptions are specific enough to name. The table below maps each advertised capability onto the Keycloak primitive that provides it, and marks where nothing does.

The two gaps are worth stating plainly rather than talking around. Keycloak will not tell you that a developer wired a coding agent to a personal token last Tuesday, because Keycloak only sees callers that came through it. That is the problem Ping and JumpCloud are selling into, and it is a real one. The honest mitigation without buying a product is narrower: turn off the credential types you do not want agents using, alert on service accounts that suddenly change call volume or scope, and require that every confidential client carry an owner attribute before it reaches production.

For the base setup, our walkthrough of Keycloak AI agent authentication covers the confidential client and service account pattern end to end, and securing MCP servers with Keycloak and OAuth 2.0 covers the tool-server side.

How do I bind an agent to the human who owns it?

Bind the agent through token exchange when it acts for a person, and through a recorded owner attribute when it acts on its own. Those are two different architectures, and mixing them up is the most common design error in agent deployments.

A user-delegated agent does work on behalf of a specific person: a coding assistant opening a pull request, an assistant drafting an email. Here the agent should not hold standing authority at all. It takes the user’s token and exchanges it for a downstream token whose subject is still the user, with scopes narrowed to the task. When the user leaves, their token stops working and the agent stops with it.

The exchange itself is the standard RFC 8693 request shape, with the agent authenticating as its own client while the subject stays the human:

POST /realms/{realm}/protocol/openid-connect/token
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&subject_token={the user's access token}
&subject_token_type=urn:ietf:params:oauth:token-type:access_token
&audience={the downstream API's client id}
&scope=repo:write

The audience parameter is the one to get right, because it is what stops the resulting token from being usable anywhere else. The rest of the mechanics are in our practical guide to Keycloak token exchange.

One caveat on maturity, since it changes what you can rely on. Standard token exchange reached officially supported status in Keycloak 26.2, back in 2025, and is enabled by default rather than sitting behind a feature flag. What that supported version covers is internal token to internal token exchange as RFC 8693 defines it, which is exactly the delegated-agent case above. It does not cover identity brokering or subject impersonation, so if your design has an agent acting as a different user rather than narrowing its own caller’s token, you are outside the supported path and should design around that rather than through it.

An autonomous workforce agent does work nobody asked for individually: a nightly reconciliation job, a monitoring agent. It gets its own service account, and the human owner is metadata rather than an authorization path. Record the owner as a client attribute so that the audit trail answers “who do I call about this” without implying the owner approved each action.

Our read: the failure we see most is the second pattern used where the first belongs. A team gives the assistant a service account because it is easier than plumbing token exchange, and now a tool that was supposed to act for one engineer has standing access to everything the service account can reach, permanently, with no link back to a person in the logs. The vendor products do not fix that either, because the choice of which pattern to use is made in your application code rather than in the identity provider.

Does an agent need an audience-restricted token?

Yes, and this is the control most often skipped. An access token with no audience restriction is a bearer credential that any service accepting your issuer will honour, which turns one compromised agent into lateral movement across every API in the realm.

Keycloak issues audience-restricted tokens when you configure them, and MCP servers in particular need to validate the audience on arrival. We wrote up the failure mode in detail after seeing it repeatedly: why your Keycloak MCP server returns 401 and what RFC 8707 has to do with it. Resource indicators are the mechanism, and configuring them is what keeps a stolen agent token useful only against the one API it was issued for.

Short token lifetimes are the other half. An agent that refreshes cleanly does not need a sixty-minute access token, and reducing the lifespan directly reduces how long a leaked token stays usable.

When is managed Keycloak the faster path?

When the work you want to do is agent architecture rather than Keycloak operations. Standing up confidential clients, token exchange and audience restrictions is configuration. Running the cluster that serves them, patching it on a security cadence, and keeping upgrades from breaking your token exchange configuration is a standing operational commitment.

Skycloak is identity management as a service built on upstream Keycloak, so the primitives in the table above are the actual Keycloak primitives rather than a reimplementation, and there is no proprietary “Agent SSO” tier gating them. The trade you are making is documented honestly in is self-hosting Keycloak worth it in 2026, and the provider landscape is in managed Keycloak providers compared.

The case for staying put is equally real. If you already run Keycloak well, have a patch cadence you trust, and your agents call your own APIs, the September launches do not describe a problem you have.

What if we are evaluating Okta Agent SSO while keeping Keycloak?

Coexistence is workable, and the seam to plan is the token boundary rather than the directory.

The common shape is Okta or another vendor platform as the workforce identity provider for employees and their personal agents, with Keycloak continuing to serve your own applications and their service identities. Those two can federate, and the agent story does not force consolidation. What it does force is a decision about which system issues the token a given agent presents, because two issuers with overlapping authority is how you end up unable to answer what an agent was allowed to do.

Pick per agent class. Personal agents attached to employees belong with whatever governs employees. Agents that are part of your product belong with whatever governs your product. It is worth writing that rule down before the pilot starts, since reassigning agent identities once both platforms already hold them means re-registering clients, reissuing credentials and rewriting whatever policy referenced the old issuer.

FAQ

Do AI agents need their own identity, or can they reuse a service account?
They need their own. A shared service account makes revocation all-or-nothing and makes the audit trail useless, because every agent action looks identical. One confidential client per agent costs almost nothing in Keycloak and gives you per-agent revocation and per-agent logs.

Does Keycloak support Cross App Access or ID-JAG?
Not as an issuer, as of September 2026. The Identity Assertion JWT Authorization Grant is an active IETF OAuth working group draft rather than a finished standard, and upstream Keycloak has not shipped issuer-side support. Standard token exchange under RFC 8693 covers many of the same revocation properties for APIs you control.

What is the difference between agentic IAM and non-human identity management?
Non-human identity is the broader category covering service accounts, workload identity and machine credentials generally. Agentic IAM is the subset where the non-human caller makes decisions, which adds the requirement to bind it to a human owner and to constrain what it may do at the moment of action rather than only at provisioning.

How do I find AI agents already running in my environment?
Keycloak will not tell you, because it only sees callers that authenticate through it. Start with what it can show: service accounts with unexplained call-volume changes, clients with no recorded owner, and long-lived tokens in use from new network locations. Discovery of agents using personal tokens is an endpoint and gateway problem, not an identity provider one.

Should I wait for Keycloak to ship an agent feature before deploying agents?
No. The controls that matter most, per-agent clients, audience-restricted short-lived tokens, and token exchange for delegated actions, all exist in Keycloak 26.x today. Waiting leaves agents running on static keys in the meantime, which is strictly worse than the pattern you would build now.

Sources

• Okta, “Okta brings first-class identity to AI agents with Agent SSO,” newsroom press release, 24 August 2026, https://www.okta.com/newsroom/press-releases/okta-brings-first-class-identity-to-ai-agents-with-agent-sso/
• Help Net Security, “Ping Identity introduces enterprise security for personal AI agents,” 1 September 2026, https://www.helpnetsecurity.com/2026/09/01/ping-identity-enterprise-personal-agent-access/
• JumpCloud, “JumpCloud Extends IAM to Protect the New Agentic Workforce,” press release, 10 September 2026, https://www.prnewswire.com/news-releases/jumpcloud-extends-iam-to-protect-the-new-agentic-workforce-302875486.html
• IETF OAuth Working Group, “Identity Assertion JWT Authorization Grant” (draft-ietf-oauth-identity-assertion-authz-grant), active Internet-Draft, https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/
• Keycloak, “Standard Token Exchange is now officially supported in Keycloak 26.2,” May 2025, https://www.keycloak.org/2025/05/standard-token-exchange-kc-26-2
• IETF, “OAuth 2.0 Token Exchange” (RFC 8693), https://datatracker.ietf.org/doc/html/rfc8693
• IETF, “JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants” (RFC 7523), https://datatracker.ietf.org/doc/html/rfc7523