What this means:
AI agent identity governance became more practical in June 2026. Planned, enterprise-owned agents can now be registered, governed and lifecycle-managed through tools such as Okta for AI Agents and Auth0 for AI Agents. However, shadow AI, unmanaged personal connectors, service accounts, static keys and runtime intent remain unresolved. Identity is now a control plane for agentic AI, but it is not the whole control room.
Back in April, I argued that 2026 was looking a lot like 2006 - that AI agents were recreating the identity sprawl SaaS once caused, and that we already knew the playbook for turning that sprawl into structure. This is the update. In June, the playbook started running.
The first deals between the model vendors and the identity platforms have landed, and the standards underneath have firmed up. The planned, deployed agents you own and run on purpose can be governed today with Okta for AI Agents and Auth0 for AI Agents. The ephemeral agents spun up by tools like Claude act under delegation. That is a big part of the problem space, but not all of it.
A few weeks ago, writing about agentic identity mostly meant writing about drafts and direction of travel. The honest answer to "what can I deploy today" was "less than the noise suggests." I said as much at the time and stand by it. Then June happened, and three things crossed the line from announcement to available.
Okta became the identity layer for Claude Enterprise. This is the headline. Through something called Enterprise-Managed Authorization, an admin approves a connector once, your people inherit access through the groups and roles they already have, and the tool is simply there the first time they open it. Nobody clicks through a string of consent screens, nobody pastes a token into an app. When someone leaves, their agent access leaves with them on the same offboarding you already run, and your security team gets visibility into the rest through posture management and a compliance API. If you have spent any time near an IAM project you will recognise exactly what this is. It is single sign-on and joiner-mover-leaver, applied to an AI tool, working the way it always should have. Full disclosure: I haven't seen it running yet, but understand the moving parts well enough to say this is win, win and win.
Static keys started to disappear. On 17 June, Anthropic made Workload Identity Federation generally available on its platform. That retires the long-lived key sitting in code or a config file. Instead a workload presents a short-lived, scoped credential at the moment of each request, exchanged from your identity provider, Okta among them. Anyone who has gone looking for where the API keys are buried in an estate, and who actually knows about them, will understand why this matters. The model vendor is now happy to federate to your identity provider rather than ask you to mint and mind another secret.
Cross App Access kept growing. The first two are built on XAA, the open protocol Okta has been driving to extend OAuth so agents and apps can reach each other under enterprise control. This month the ecosystem passed 25 integrations, names like Asana, Atlassian, Canva, Cursor, Figma, Glean, Slack and Zoom, with Okta Workforce customers able to reach them through the Okta Integration Network from August. The list matters more than it looks. A protocol with no adopters is a slide. A protocol with a growing roster of real applications is starting to become infrastructure.
Because none of it is one vendor's proprietary cleverness, and that is the point. Workload Identity Federation runs on OIDC. Enterprise-Managed Authorization is an official extension within the Model Context Protocol. Cross App Access extends OAuth. Token exchange is a published standard. The reason these landed at once is that the standards underneath finally have enough agreement to be built on.
I will stay careful not to overstate it. The standards race is still live. XAA, ID-JAG, the various OAuth extensions and non-OAuth protocols (AAuth) for agentic contexts, the workload identity work in WIMSE, SPIFFE and SPIRE at the machine-to-machine end. Nobody yet knows which of these wins at scale, and a deep implementation against any single emerging spec still carries real risk. But there is a difference between a draft and a product you can buy, and in June a few of these crossed it. The foundations are being laid in the open, deliberately, by the right people. That is worth more than any one vendor's complete story.
We have, and that is the reassuring part. This is the first step in the commoditisation of agent security, and it follows a path the identity industry has already walked.
Think about how we secure applications today. Single sign-on felt specialist once. There were a handful of services that spoke SAML, then a few more that spoke OIDC, and wiring an application properly into your identity provider was a project in its own right. Now it is the default. You would not buy a serious SaaS tool that could not federate. The capability moved from differentiator to table stakes, and the work moved from "can we even do this" to "how well do we do this across the whole estate."
Agent security is on the same road, just faster. What feels like frontier work this year becomes the assumed baseline next year. The first deals between the model vendors and the identity platforms are the moment that road opens. The organisations that get ahead are the ones treating agent identity as a design assumption to adopt early, not a procurement decision to defer.
Quite a lot, and I want to be as confident about this as about the gaps, because it is my main position. The strongest answer applies to the agents you plan, build and deploy on purpose. The known ones, with an owner, that you stood up deliberately to do a job. If that describes an agent in your enterprise, you can govern it today.
Okta for AI Agents, generally available since 30 April, is built for exactly this. You register the agent, or its MCP server, as a first-class identity in your directory and give it a named human owner, so there is always a person accountable for what it does. You scope it to least privilege with short-lived tokens instead of standing keys. You run it through a real lifecycle, from onboarding to decommissioning, with access reviews along the way. And if it misbehaves you have a kill switch and a full audit trail. This is identity governance, applied to a non-human you have decided to treat like any other. You cannot just throw any agent from any platform at it and assume it is governed, though.
If you are the one building the agent, including for internal use, Auth0 for AI Agents lets you design that governance in from day one rather than bolt it on later. The agent authenticates as itself and stays tied back to a real user. Token Vault holds its third-party credentials so they never sit in its code or logs. Asynchronous approval, using CIBA, puts a human in the loop before a sensitive action goes through.
Put the two together and you have the whole arc for a planned agent: built secure by design with Auth0 for AI Agents, governed across its life with Okta for AI Agents. As Okta puts it, a well-built agent without enterprise governance is just invisible shadow AI, and governance without secure-by-design agents is policy with no enforcement. You need both.
So here is my position, plainly. If you are building or running agents inside the enterprise that are known, planned and deployed, you can govern them now. The hard problems start with the agents that are none of those things.
Now the straight bat, because a state of the nation that only reports the wins is just marketing.
What shipped in June secures a specific kind of agent very well: the one a person sets running, acting on their behalf, against applications that support the protocol. That is a large and important slice of what enterprises actually run, and it is deployable today. It is not the whole problem.
Start with the agents nobody planned. Call it shadow AI, and assume some of it is already running in your estate. A few high-level examples worth going to look for:
Okta for AI Agents can discover a good deal of this, and that is genuinely the first move, because you cannot govern what you cannot see. But finding is not governing. Some of it you bring under control by registering it and treating it like the planned agents above. Some of it, like data pasted into a personal account, or an agent behaving badly inside permissions it was correctly given, sits beyond what identity alone can fix. That is the runtime and data problem, and it is where the rest of the village earns its place.
The agent with no human behind it, the pure workload running on its own, still needs attestation that none of this provides. The hijacked or prompt-injected agent will pass every identity check you put in front of it, because identity governs authority, not intent, and stopping the manipulation itself happens at a runtime layer that is still maturing across the market.
The ephemeral sub-agent a tool spawns for a ninety-second task is a subtler case than it was a month ago. When it reaches a connected enterprise app through an Okta-governed connector, that access is delegated on your behalf, scoped, logged and revocable, and if Okta has not entitled you to that connector the agent gets nothing at all. So the access itself is no longer the blind spot. What you still do not get is the agent's own attested identity, attribution at the level of the individual agent rather than your session, or any check on what it does with the authority it has legitimately inherited. That last one, runtime intent, is the hard part that remains.
And notice the condition buried in that sentence. All of it holds when the access runs through the enterprise-managed connector. Claude also lets people add their own personal connectors, and an agent can in principle reach a resource by a path your identity provider never sees. An administrator can insist a connector only ever connects through the identity provider, and should, but the point stands: the governed path protects you only when access actually travels down it. So keep your wits about you. The brokered channel is a real step forward, not a perimeter.
Which is the same conclusion I keep arriving at, and I will not apologise for the repetition. You still need the village of services I have written about before (see 2026 Looks a Lot Like 2006 and "Drawing the Map While the Ground Is Shifting"): the detection that finds the agent and the access nobody provisioned, and the controls that prevent what identity alone cannot. Identity is the control plane. It is not the whole control room.
Agents talking to other agents across organisations is still largely roadmap. And the clock is real. The EU AI Act's high-risk obligations become enforceable on 2 August, and you cannot demonstrate that an agent acted within its authority if you never gave it an identity in the first place.
None of these are failings. They are deliberate scope, and the honest vendors are clear about where their line sits. But they are real use cases, in real estates, right now, and the announcements above do not close them.
The same thing good IAM has always asked of you. Resist the pull towards the single platform that resolves all of this cleanly, because it is not coming, at least not soon and possibly not at all. Agentic identity will be a village of services, the way IAM always has been, assembled from specialised parts that each do their job.
So sort your agents into the ones a person drives and the ones that run on their own. Deploy the ready half now, because it genuinely is ready and waiting is its own decision. Plan the rest against the standards as they settle and against the August clock, with the risks documented, understood and parked rather than ignored. A risk you have named and sequenced is a step forward. A risk you have not looked at is the one that finds you.
That is the work, and it is exactly the work we do. If you want help drawing your own map while the ground is still shifting, come and talk to us.
Agentic identity is the practice of giving AI agents, workloads and automated systems a governed digital identity, so their access can be owned, scoped, monitored, reviewed and revoked.
Yes, but mainly when they are known, planned and enterprise-owned. AI agents that are built, registered and connected through supported identity frameworks can be governed through lifecycle controls, ownership, access policies and audit trails.
The hardest problems are shadow AI, personal connectors, unmanaged service accounts, static keys, prompt-injected agents and runtime intent. Identity can govern authority, but it cannot always determine whether an agent is acting safely with the access it has.
AI agents can access applications, data and workflows on behalf of people or workloads. Without identity governance, organisations may not know which agents exist, who owns them, what they can access or how to revoke their permissions.
Start by inventorying AI agents, service accounts, automation, API keys and personal connectors. Separate planned enterprise-owned agents from unmanaged activity, then apply ownership, least privilege, lifecycle controls and monitoring.