'The Gatekeeper' — Okta Expands AI Agent Controls, with Ambitions Beyond Security

Okta has announced new capabilities for discovering AI agents running on employee devices, governing their connections across applications and cutting off their access when things go wrong. Unveiled at its Oktane event in Las Vegas today, the updates to Okta for AI Agents sit alongside Agent SSO and anew Blueprint Alliance, bringing together vendors including AWS, Google Cloud, Salesforce and ServiceNow around a shared architecture for securing agents. The questions for buyers deploying agents often include: where are my agents, what can they access, what are they doing and how do I stop them? Unsurprisingly, these questions get harder to answer as agents spread across teams, applications and as more complex interactions take place. Okta’s argument is that the identity practices organizations already apply to people offer a starting point to tackle this complexity. Speaking with me at Oktane in Las Vegas this week, Ric Smith, President of Products and Technology at Okta, said: > We’re not walking people off the street and into the building as employees. We do background checks, we make sure that they have a badge that gives them access to certain things. We provision them rights and whatnot. We have to take the same practices around agents. What’s being announced? There are several parts to theproduct announcement, spanning discovery, access and the ability to intervene whilst an agent is working. Firstly, Okta wants to help security teams find agents they don’t know employees are using. A developer might, for example, be running a coding assistant on their laptop and connecting it to company systems without IT having a clear view of that activity. Shadow AI Agent Discovery for Endpoints uses existing software, including CrowdStrike and Okta Verify, to identify those agents, who owns them and what they connect to. Security teams can then bring them into the company’s central identity directory to manage their access. That visibility problem is familiar to CIOs in the diginomica network. In our June 2026 survey, only 23% said they had fully mapped every AI tool and integration across their business. Our latest AI governance and costs survey, found that 56 of 67 organizations run an approved list of AI tools in some form, and 31 of 67 have tightened their position on personal and experimental use over the past year. Secondly, Agent SSO aims to make connecting agents to applications simpler for employees and easier for IT to control. Take an assistant that needs to retrieve a document from Confluence and post an update in Slack. Rather than leaving employees to approve each connection themselves, IT sets the rules in advance, whilst the employee signs in once, and the assistant receives temporary permission to make the approved connections. The aim is to let it get on with the task without giving it a permanent set of keys to company systems. There are also controls for when one agent asks another to do something. A sales agent might, for example, ask a finance agent for information about an unpaid invoice. Agent-to-Agent Connections lets IT decide whether that handoff is allowed and keeps a record of it. Resource Access Certifications lets teams periodically review whether an agent still needs the access it has, allowing administrators to see and adjust what an agent connects to, including other agents. Then there is Agent Gateway, which checks an agent’s requests as it works. For example, an agent might be allowed to read Salesforce records but have no permission to change them. The gateway checks requests against those rules and records what happens, giving security teams a way to enforce the limits they have set. Okta also plans to extend its kill switch through this gateway. Its existing off switch prevents an agent from starting new sessions and the expanded version is intended to cut off access the agent is already using, stopping ongoing connections when something goes wrong. Putting the controls to work The pre-brief demonstration, which we had last week, saw a sales agent given read access to Salesforce and asked to summarize a seller’s top five accounts. So far, so useful. The seller then asked for the information to be sent to their personal email address. In the demonstration, that request was blocked, the Salesforce connection was severed and the security team received a Slack alert with details of the session. Asked during the briefing how long an agent would remain cut off, Smith said: > It lasts as long as the operator allows it to. So it could be momentary, or it could be a complete termination - and obviously this can be wired into operations in terms of incident response. Someone still needs to decide what access is appropriate and when to intervene. Smith said these decisions generally sit with the identity team under the CISO. Asked what was prompting customers to buy, he said: > Honestly, it’s the simplicity of it. Yes, they get very excited about having the common kill switch. They love the visibility that comes with the gateway. But at its root, it’s a very tangible way to solve the problem that they have. Working across the enterprise Of course, Okta is making this pitch in an enterprise market where several vendors want a role in governing agentic AI. I recently wrote aboutServiceNow’s security ambitions, including its ability to coordinate workflows and act on the risks it identifies. It recently bought Veza too, an identity management platform. I asked Smith where Okta fits for a buyer already using platforms such as Microsoft, Salesforce and ServiceNow. Where do the various responsibilities lie? He said: > Right now, our dominant role is the gatekeeper. When you talk about a ServiceNow, they’re really focused on the workflows and the data that’s resident on that. That’s not the space that we intend to play in. We have a strong partnership with ServiceNow. Smith added that the partnership includes providing ServiceNow with a kill switch for its agents. But I was also curious whether governing agents could change the kind of company Okta becomes. If it can see which systems agents access and how they interact, could that give it a role in understanding the work they do and the value they deliver? Smith said: > Presumably, if agents become more of a dominant force that we all interact with on a regular basis, then yes, Okta will start transitioning above and beyond security - start doing things like performance management of agents, maybe even eventually create its own agents. He described this as an opening to change the company’s direction, whilst acknowledging that where it leads remains uncertain. Customers have also asked Okta to help them understand the economics of their agents, an area Smith said it is exploring. These are possibilities for the business as agent adoption grows. For now, the product announcements focus on access and security. I’ll be following up on those broader ambitions in my interview with Okta’s CEO later. My take What I find useful about Okta’s approach is that it gives buyers something tangible to work with. AI governance can become abstract when a CIO is trying to decide what to do next. Identifying an agent, assigning an owner, limiting its permissions and having a way to withdraw access are understandable steps. Equally, the enterprise still has to make those decisions. Registering an agent doesn’t settle whether it should change a customer record, move money or pass work to another agent. The business and security teams need to understand the work being delegated. Smith identified cost, data hygiene and security as barriers to realizing value from AI. Okta is addressing security; buyers still need to tackle the other two. And the alliance’s value will depend on how well its members make their products work together. The test is whether an enterprise can apply its rules consistently as an agent moves across the systems it actually uses.