Curity looks to reinvent IAM with runtime authorization for AI agents

In 2026, enterprise developers are building and deploying the first generation of powerful, increasingly autonomous AI agents at incredible speed. Now comes the hard part: working out how to secure them.

Vendors in the space are facing multiple challenges. To begin with, traditional identity and access management (IAM) tools were never designed to secure anything as complex as agentic AI. In addition, the number of agents, both those sanctioned by the enterprise and the undocumented ‘shadow’ agents created by a new generation of powerful tools that barely existed a year ago, is increasing at unprecedented speed. And now it has started to dawn on organizations that this risks leaving yawning governance and security gaps whose weaknesses could one day return to haunt their creators.

While a growing list of companies, including large cloud platforms such as Okta, Ping Identity, and Microsoft’s Entra ID, is vying to fill the vacuum, a smaller competitor, Sweden’s Curity, argues that agents can’t be secured using traditional IAM. Instead, it is offering a different approach to the problem: This week, it announced Access Intelligence, an extension to its existing API identity and access management (IAM) platform, Identity Server.

The problem it addresses is that traditional IAM tools assume that applications are being accessed by human users or machine identities, governed by a one-time authentication process. But agents, which assume long chains of actions conducted at incredible speed, don’t work like this. Instead, access becomes ephemeral, complex, and non-deterministic, which is to say, hugely unpredictable. Lock them down too much and they stop working; let them run free, and weak security follows in their wake.

Runtime enforcement

Curity’s approach is to treat agents as a special type of application. Like applications, agents call APIs, MCP servers, and each other, and are credentialed using OAuth tokens. Through a feature called Token Intelligence, Curity extends the role of OAuth tokens to not simply permit access, but to carry information on the agent’s purpose and intent. In Curity’s scheme, an agent can only access resources based on that purpose.

Instead of using static, pre-granted permissions, agent access is granted at runtime, on-the-fly. Each requested action generates a separate token that describes the access it needs. When an agent starts a new task, it needs a new token specifying a new set of permissions. If necessary, human authorization can be required when an agent is trying to perform a high-risk action such as transferring funds.

“Curity has always been application-centric,” said Cofounder and CTO Jacob Ideskog. “Our focus has always been on how we broker access.”

Multiple approaches to agent security

Today, agent security falls into one of several camps, which include increasingly inadequate inline approaches such as API gateways and web application firewalls (WAFs), and out-of-band analysis systems that infer intent by analyzing agent behavior against a baseline.

Curity’s Access Intelligence, by contrast, is a self-hosted microservice that acts as a glorified IAM layer through which every agent request must pass. “Because we let an agent do something now doesn’t mean we should be allowing it to do this a minute later,” Ideskog explained.

Access Intelligence also uses Identity Server’s centralized token validation to ensure that developers can fire up agents or APIs without registering them. If they lack this validation, agents are isolated from real-world actions.

Nothing does the whole job

The appearance of systems such as Access Intelligence is good news for enterprises. It indicates that vendors are starting to address the problem of agent security, often by extending existing API security platforms. But that still leaves open the question of which approach to take.

Ideskog believes it would be a mistake to see the different approaches as mutually exclusive. Curity’s Access Intelligence can be used in combination with other layers of agent security, he emphasized. In short, no one solution can do the whole job.

“Up to this point, the IAM industry has focused on the identity part. But the real question is the access. Enterprises are asking their privilege access management (PAM) vendors how they’re going to deal with this [agent security] and I don’t think the PAM vendors have good answers yet,” he said.

This article originally appeared on CSOonline.