AI Agents Have Outgrown Human-Era IAM. Here’s How Midmarket IT Can Respond

AI agents can inherit, delegate and retain access in ways conventional IAM wasn't built to track. Here are four ways IT teams can regain control.

(Image: Getty)

Identity and access management have long depended on identities that behave in ways that are relatively predictable. But as AI agents gain more ground, and more freedom, inside organizations, the traditional IAM model has struggled to keep their identities in check.

Every agent adds to the pool of non-human identities that IT leaders must track, govern and secure as they move through corporate systems. In many environments, hundreds of AI agents can connect to databases, internal chat channels, APIs and cloud storage, each operating autonomously and creating access patterns that can be difficult for conventional IAM controls to account for.

For midmarket IT teams, a new IAM question is beginning to emerge: How far can existing IAM controls stretch as agentic identities multiply?

"The sheer speed and scale of these identities, and the fact that they can often circumvent existing governance controls, is creating a massive issue for IT teams,” said Scott Goree, senior vice president of channel and alliances at Delinea, an identity security firm.

Agents Outrun Standing Access Checks

Existing IAM systems were built around the employee lifecycle, where the human resources system gives a new hire access based on their role and switches it off when they leave.

According to Goree, agents break that model because they act autonomously at machine speed across dozens of environments.

Beyond the challenges of speed and scale, Goree argues that the way many organizations delegate authority to autonomous systems can create another IAM headache.

Goree said he has encountered midmarket firms using standing access across the board, potentially giving attackers more time to exploit legitimate credentials.

Many organizations also authenticate an agent at the start of a session but not at runtime, even though agents challenge "the long-standing IT assumption that because a session is safe at entry, it will remain safe throughout its lifespan,” he added.

The Hidden Authority Behind Agent Identities

An agent’s permissions may tell only part of the story about what it is able to do.

According to Allan Dabre, technology compliance and AI lead at PricewaterhouseCoopers, an agent “logs in once and then acts like a dozen people.” Within a single session, it can plan, call tools, delegate to other agents and touch data across systems. Each of those steps can carry authority that never appears on the agent’s own identity, Dabre told MES Computing.

Dabre gave the example of an agent that starts with read-only access to an organization's enterprise resource planning (ERP) system:

The agent needs a purchase order posted. It calls an accounts payable automation bot that holds write access, which the bot posts the order on its behalf.

The agent’s own permissions have not changed, yet “the action traveled through a chain of permissions nobody drew on the access diagram,” he said.

As a result, the next access review would come back clean, because the review only asks about the permissions assigned to the agent directly. Part of the problem, Dabre argues, lies in how some IT teams initially integrate agents into existing IAM. The agent is often configured as a service account with an API key, so access certifications continue asking whether that account still needs access to the ERP system.

“That’s the wrong question now,” Dabre said. The right question, he explained, is what the agent can reach through every tool in its chain, “because that’s where its real permissions live.”

The burden of tracing those paths grows with every agent a business deploys, and Goree noted that “a small team may be responsible for controlling hundreds, if not thousands, of agents operating across multiple environments at machine speed.”

ServiceNow is among the vendors trying to address that problem. Its AI Passport capability, part of AI Control Tower, is designed to establish and enforce what an AI agent is authorized to access and what actions it can perform.

Whether approaches like this can give IAM teams sufficient visibility and control as agent identities proliferate remains to be seen.

Closing Access Gaps Around AI Agents

As organizations deploy more AI agents, experts say there are four practical steps IT leaders can take to tighten access around agentic identities:

1. Define Every Agent’s Purpose and Access

Goree suggests that each agent should have a “defined purpose, and access that’s limited to the appropriate task and timeframe.” For midmarket teams, keeping those boundaries clear gives IT a basis for deciding what an agent should be able to do and when that access should expire.

2. Log the Full Chain of Delegation

“After an incident, you’re reconstructing intent from login timestamps,” Dabre said of current logging methods, which may record a successful login when agents hand work to one another but reveal little about which agents decided what, or why.

An audit trail that follows an agent across every tool it touches, under one identity so that each action leads back to the person or process that started it, is what he recommends.

3. Review Every Tool an Agent Can Reach

Dabre suggests IT leaders map the tools, services and other agents an agent can invoke, and establish how least privilege applies when that access changes during a session, along with who approves the change.

4. Check Access Throughout the Session and Keep a Kill Switch Ready

Goree suggests midmarket IT teams move away from authenticating an agent at login and trusting it for the duration of its session.

Rather, he recommends establishing continuous authorization at runtime, checking an agent’s access when it attempts an action, and having a kill switch that can revoke credentials and terminate active sessions when suspicious behavior is detected.

But terminating an agent's session may not eliminate all of the access associated with its identity.

Dabre cautions that disabling an agent at the identity provider may not be enough. Doing so “kills the central session, but that’s only half the identity,” he said.

Long-lived API keys, OAuth grants in third-party apps and scheduled runs using stored credentials can continue working until each is revoked. Dabre said many midmarket teams do not maintain an inventory of those credentials, potentially leaving teams to identify and revoke lingering access only after something has gone wrong.