The coming AI agent crisis: Why Okta's new security standard is a must-have for your business

Follow ZDNET: Add us as a preferred source on Google.

---

ZDNET’s key takeaways

• IT managers have limited visibility into when users give external apps access to company data.
• When those external apps are AI agents, the security risks multiply by orders of magnitude.
• Okta has proposed a standard to give organizations more visibility and control over those permissions.

---

By the end of 2026, many of us will have at least one AI-powered agent doing something behind the scenes on our behalf. Within five years, it could be tens or hundreds of agents. They will not only make decisions about what to do (based on their autonomous observations), but they will connect to multiple sources of data (as well as each other) in order to optimize those decisions and other outcomes.

This future should terrify most organizations that already go to great lengths to protect their digital resources from unauthorized access. As employees are pressured to do more with the help of AI, they’ll look to launch these agents and grant them access to whatever corporate resources are necessary. 

Today’s credential for such user-provisioned application-to-application access — known as an OAuth token — may be woefully unsuited to the task.

Also: Weaponized AI risk is ‘high,’ warns OpenAI – here’s the plan to stop it

Several years ago, well before agentic AI was on the horizon, when organizational users granted certain applications, such as Slack, access to their work data, the folks at identity management provider Okta recognized a fundamental flaw in how that access was approved and granted. 

Identity and access management (IAM) systems, such as Okta’s Identity Platform and Microsoft’s Entra, serve as central control planes for managing which humans have access to which corporate resources. However, those same systems are frequently out of the loop when it comes to how other applications were granted similar resource access on behalf of those users. Instead, those decisions were (and in many cases, continue to be) left to end users in a way that resulted in IAM blind spots and avoidable security risks. Since then, Okta has been working with the Internet Engineering Task Force (IETF) on a draft open standard designed to close the loophole. 

Proposing a new standard

Behind closed doors and in its promotional materials, Okta refers to the specification as “Cross-App Access” or XAA. However, the specification is known by a different name as part of the IETF’s open standards conversation: Identity Assertion Authorization Grant (IAAG). Compared to proprietary technologies and in some cases de facto standards, an open standard is a technology that’s made available to the industry on a fully unencumbered basis. Companies and developers, including Okta’s iAM competitors such as Microsoft and Ping Identity, are free to build their own implementations of the technology without the need to pay royalties to its inventor(s). 

Also: Gartner urges businesses to ‘block all AI browsers’ – what’s behind the dire warning

HTTP — the core technology that makes it possible for any web browser to access any website — is an open standard. The two primary technologies that combine to make passkeys work the way the do — the World Wide Web Consortium’s WebAuthn and the FIDO Alliance’s Client to Authenticator Protocol (CTAP) — are open standards.

While any company can invent a technology and contribute it to the world for consideration as an open standard, the true measure of whether that technology is really an open standard is bound to the rate at which it gets adopted by other companies. According to Okta, Google, Amazon, Salesforce, Box, and Zoom are among IAAG’s early adopters. 

During an interview about Microsoft’s plans to help organizations tame the sprawl of agentic AI, Microsoft corporate vice president of AI Innovations Alex Simons told ZDNET that Microsoft plans to support the new IAAG standard in Entra (the company’s cloud-based IAM solution). Whereas Aaron Parecki, Okta’s director of identity standards, originally appeared as the specification’s author, Ping Identity distinguished engineer Brian Campbell now appears as a co-author on the latest draft, which is a pretty good indicator that Ping is on board as well. (I reached out to Campbell via email but have not yet heard back.)

Also: How passkeys work: The complete guide to your inevitable passwordless future

The timing of the proposed standard couldn’t be more serendipitous. According to Parecki, when Okta first started working on the problem, agentic AI wasn’t even on the radar. But now that the category of smart, scalable, and sometimes fully autonomous software is poised for explosive growth — especially behind the firewalls of many organizations — the new standard is in position to give IT managers the control and visibility they need to securely tame both applications and agents as though they’re on a level playing field with humans.

Behind the scenes of delegated access

Although I’m leaving out some gory details, here’s what typically happens behind the scenes: When one application is given direct access to another application on behalf of an end user (a type of access known as “delegated access”), the operator of the second application (the “resource server”) is asked to issue a special login credential that the first application (the “client application”) subsequently uses to authenticate with the resource server as though it’s pretending to be the end user herself. 

In a scenario like this, the end user — considered by the OAuth standard to be the “resource owner” —  is said to be delegating some or all of their resource server access rights to the client application. This special credential is known as an OAuth token. Before the resource server issues such a token to the client application, the end user is typically consulted through a dialog box (see screenshot above) for their permission to proceed with the delegation. If the end user consents, the resource server (typically a specialized “authorization server” acting on behalf of the resource server) issues the OAuth token to the client application, which is then responsible for storing it securely. After all, it’s essentially the equivalent of the end user’s user ID and password. 

Also: Battered by cyberattacks, Salesforce faces a trust problem – and a potential class action lawsuit

Earlier this year, when over a billion customer records were criminally and avoidably exfiltrated from the Salesforce instances of some of the world’s biggest and most recognizable brands, the threat actors relied on stolen OAuth tokens to perpetrate their crime.

Once the end user consents to OAuth token issuance and the client application takes receipt of that token, it goes on to use that token as a login credential to the resource server, much the same way humans present their user IDs and passwords at login time. Each of these OAuth tokens is restricted to the user (again, the “resource owner”) that granted it, the specific access rights that were delegated at the time of the grant (these could be a subset of the user’s overall rights), and the resource server that issued it. 

An OAuth token that was issued by Google (the resource server) to Slack (the client application) on my behalf is, therefore, specific to Google and mapped to my Slack identity. Slack cannot present that same token to another application like Zoom, nor can it present that token to Google on behalf of another user. Whereas some tokens last forever, others expire after a certain period of time. Token issuers can also invalidate tokens (known as revoking a token) at will. It’s similar to disabling a password or changing the lock on your front door. 

Once OAuth came along

Although there are multiple token types for a variety of use cases, the idea of an Open Authorization or OAuth token came at a time when, in the aforementioned scenario, a user would simply input their Google user ID and password into Slack. And it’s hard to believe that many of us users gladly supplied those credentials without considering the potential for serious harm. From a cybersecurity perspective, the practice raised some deal-breaking and largely rhetorical questions. To whom were we really giving that user ID and password? Is it a legitimate business or a malware app cleverly disguised as an incredibly useful tool? Even if the app is legit, how and where is it securely storing the secret credentials that we just shared with it? What if the client application only needed a subset of the end user’s overall access rights? 

Also: How to prove you’re not a deepfake on Zoom: LinkedIn’s ‘verified’ badge is now free for all platforms

Also, unlike with OAuth, there was no explicit step during which the user issued their consent. “The consent was implied in the [sharing of the] credential,” said Parecki during an interview with ZDNET. “So you would give your password to an application, the application would take the password to a service, and present it as if it were you. And that’s sort of this implied consent, right? Because the fact that it has the password means that it had to have obtained it legitimately, right? Which, obviously, we know is not a good pattern to assume.”

Once OAuth came along, it eliminated the need for users to share their secret credentials in order to enable cross-application access on their behalf. That scheme has worked pretty well on the internet for the last couple of decades. But then came the question of who the resource owner truly is. As mentioned above, it’s the end user who’s considered to be the resource owner, and therefore, it’s the end user who ends up consenting to the issuance of the OAuth token. But is the end user really the resource owner? Or is it the organization? And if it’s the organization — which it is — shouldn’t the organization be party to the OAuth workflow?

The way Okta sees it, in consumer scenarios where the end user wants a client application like an AI agent to take action on their personal Gmail account, it’s perfectly fine for the end user to be the resource owner who consents to the issuance of an OAuth access token. But in organizational scenarios where the resources actually belong to the organization, and access to those resources is controlled through a central control plane, the ultimate consent should come from that central control plane — the IAM system — instead. 

Why does this make sense? Well, end users already have a pretty rotten track record when they’re the last line of defense between threat actors and an organization’s application infrastructure. For example, research has shown that even after receiving cybersecurity training, 98% of users still let their guard down and succumb to preventable phishing attacks. Under the IAAG standard, the end user still gets the choice of opting into a connection between a client application like Slack and a resource like the organization’s installation of Zoom. But it’s the organization’s IAM system that ultimately approves that connection request and the subsequent issuance of the necessary OAuth access token. 

Also: Roaming authenticators offer what other passkey solutions can’t – but there are trade-offs

Similar to the way resource access is granted to humans, Parecki says, this form of consent is configured in advance by the system administrator. “For all users at the company, we would like to allow Slack to be able to get access tokens for our users’ Dropbox accounts,” Parecki offered as an example. “And that’s a policy that lives in the IdP [Identity Provider, an acronym sometimes used interchangeably with IAM]. So now, [for each user, Slack] can go and get an access token because the policy is configured in the IdP.”

When AI agents go wild

The approach also makes sense in a world that’s about to be overwhelmed by AI agents — especially ones that, given the opportunity (and much like humans), could autonomously take part in OAuth workflows unbeknownst to anyone in the organization. In that AI-agents-gone-wild scenario, it’s not hard to imagine how quickly the central IAM system might fall out of lockstep with all of the permissions being granted, on whose behalf, and for what resources. At scale, a single leaky or malicious agent could do a lot of damage in very short order. 

“Even if it’s actually an agent, it’s still a piece of software, and it’s still represented by its client ID,” said Parecki. “Let’s say you want a new agent to be able to index all of your content across 20 enterprise apps. The agent wants more data, and it’s trying to access more things [than in the typical OAuth client application scenario]. You don’t want every user at the company to have to click through a consent prompt 20 times just to start using your new AI tool.”

Also: 3 ways AI agents will make your job unrecognizable in the next few years

To facilitate that improved user experience and the security to go with it, the proposed standard involves more than just an OAuth workflow adjustment to check with the actual owner of the resource (the organization) instead of the end user who uses the resource. The token’s structure needed improvement, too. For example, whereas a standard OAuth workflow involves the user’s ID as reported by the resource provider, this enhanced OAuth workflow involves the user’s ID as reported by the organization’s IAM system. A record of the IAM system is also included in the enhanced workflow. 

Not only do these additional fields of data enable the insertion of the organizational IAM system into the middle of the OAuth grant process, but they also facilitate a higher degree of central visibility and control that was previously unavailable to IT managers. For example, consider these scenarios: 

• An employee has 25 AI agents working on his behalf, acting on a wide range of the organization’s resource servers. When he decides to leave the company, the IT department needs to deprovision those agents. Under this new OAuth scheme, an IT manager can query the organizational IAM system to not only view all the tokens issued for a particular user across all resource servers, but also more easily revoke some or all of them as part of a targeted deprovisioning exercise.
• The organization discovers that an AI agent, originally approved for use by all employees, is leaking confidential information to the underlying large language model. To stop the bleeding, the CISO decides that the entire agentic AI solution provider must be immediately deprovisioned from the organization’s application infrastructure. With a single query to the IAM system, an IT manager should be able to more easily discover the relevant tokens and deprovision them. 

Also: Your programming career isn’t over – AI just upgraded your toolbox

Like many new standards, it may take some time before everything falls into place in a way that gives IT managers centralized control over the sprawl of agentic AI (not to mention the standard application-to-application connections that were already being established behind IT’s back). Not only must the draft standard go through its final rounds of approval at the IETF, but support for the new standard has to show up in the various authorization servers used by all the SaaS providers that support OAuth-based connections from client applications.