Artificial intelligence is altering almost every aspect of digital technology, especially
application security. Today's app coders must overhaul the way they build and secure their projects, says Auth0 President Shiv Ramji, as the parameters and possibilities of AI-enabled applications are vastly different from those of traditional ones.
"You have to rethink how you build your applications, because you can no longer control the access point inside your application," said Ramji during an interview at the
Oktane conference in Las Vegas this past September. "Your security concerns, your security perimeter, have changed drastically."
Ramji listed the basic conditions that must be met to code
AI securely: Mutual authentication, secure API access, human supervision and finely grained permissions.
"These are the four requirements that are fairly common across all industries and across most agentic use cases," said Ramji.
Why developing for AI is so different
AI models and agents are like no other types of software we've dealt with before, explained Ramji. Until now, programs and applications have been built to do specific things, and specific things only.
The outcomes of regular programs are predetermined. Inputting X should always output Y, and so on. If that doesn't happen, then there's a problem.
"Say, for instance, you use the American Airlines app to travel here [to Oktane]," said Ramji. "What you can do once you log in inside the application is finite. It's predetermined, and so you're always going to go down known paths, and that's how you control access to data. That's your control point."
But with AI, inputting X will never result in the same thing twice. That's not a bug, but a feature of AI. Unpredictability — or "non-determinism" if you want to be polite, "chaos" if you don't — is the entire point. To paraphrase Forrest Gump, AI is like a box of chocolates: You never know what you're gonna get.
Because we're asking AIs to be creative and to think outside the box, that creativity brings with it new problems.
Another factor has to do with the way in which we interact with AI.
Large language models are designed to receive commands through natural human language, and subsequent forms of AI also get inputs through written or spoken natural language.
That shifts the point of external access to the application — the point at which an API is allowed to connect — from deep in the code to the presentation layer that faces the user, Ramji said.
"Your presentation layer is now the access point," he explained. "That's a pretty big change in how applications are going to be built."
Other applications and programs can also interface with AI using natural language, which by itself is non-deterministic. You can say the same thing many different ways, but AI has to understand them all. Natural language can also be deceptive, and that's why it's possible to carry out social-engineering attacks on AI models.
The implications for app development are vast.
"You have to now make your products AI-ready," said Ramji. "Now your products have to talk to other agents, other systems, other APIs — well, that's a whole new set of security concerns."
How to safely develop for AI
It's already a cliche that
identity is the new perimeter, but with AI, it may be the only possible perimeter. Accordingly, Ramji's four guidelines for safe AI application development lean heavily upon identity.
"You have to authenticate and validate who you are," he said, explaining the first requirement. "But there is something unique here. We need to make sure that not only is the agent authenticated, but the agent is authenticated on behalf of you. That linkage is super important."
In other words, the user and the agent need to mutually demonstrate that they are who they say they are, and that they are authorized to perform the actions to be carried out.
Second, Ramji said, "agents need to talk to different applications via APIs, and you need to do that securely." Other applications that interface with the AI agent need to be authenticated and authorized, and communications via APIs need to be secured.
Third, AI agents "will need human intervention or human verification" before making important decisions, Ramji said. AIs have already shown that they have trouble keeping secrets, and that they don't have any built-in morality. For those reasons, a human has to be involved.
"We call this human in the loop," Ramji explained.
And finally, he said, an AI agent can have no more permissions or privileges, and ideally far fewer, than the human upon whose behalf it is acting. Per the principle of least privilege, the AI agent should have only the abilities that it needs to do its job. That's the best way to make sure that chaos doesn't ensue.
"As a user, if you're using that agent," said Ramji, "you can only get to access to specific resources in that app based on your permissions."
How Auth0 helps with AI development
These requirements have been incorporated into
Cross App Access, a draft extension of the OAuth protocol that extends to AI agents the same sort of identity management that covers human users. Developers who use Auth0's tools will find that Cross App Access
is already part of their projects, Ramji said.
"We're doing everything we can to give builders everything they need from a standards-first perspective," he said. "Whatever it is that you're building, if it's built with Auth0, you're going to get all of these standards out of the box."
That's especially true if the developer's organization uses Okta internally, Ramji added. The Auth0-provisioned apps should be ready to mesh with the Okta AI-security framework right away.
"They're going to get the full security benefit in terms of session protection, or really, all of the identity threats that you have," he said. "There is no further configuration required. You don't have to change your applications. IT teams don't have to go do five other things."
Auth0 has done this to make identity security, especially where it concerns AI, an integral part of the build process that developers don't have to concern themselves with.
"Builders and engineers and developers, they are not security experts, and I don't think it's fair for us to expect them to be," said Ramji. "We make it really easy for a developer to use our products and APIs so they don't have to think about leaking credentials, storing tokens in clear text, in their code. We take away that burden."
