The identity problem nobody warned you about with AI agents

There is no shortage of opinions about what AI agents will do to enterprise productivity. Faster workflows. Smarter automation. Entire job functions augmented or restructured. The conversation is loud, optimistic, and almost entirely focused on capability.

What is not getting nearly enough airtime is what AI agents are doing to your identity attack surface right now, while the enthusiasm is high and the governance frameworks are still catching up.

I've spent the better part of my career helping enterprises untangle identity sprawl, and what I'm watching happen with agentic AI feels uncomfortably familiar. The same shortcuts, the same over-provisioning, the same "we'll clean it up later" mentality that turned service accounts and API keys into one of the most persistent security problems in the enterprise. But this time, the stakes are higher and the pace is faster. Machine identities, including AI agents, already vastly outnumber human identities, most operating with excessive privileges, many running unnoticed and unmonitored. That’s not a foundation you want to build an agentic strategy on top of.

The assumption that's getting organizations into trouble

When most teams deploy an AI agent, the instinct is to treat it like a service account. It's non-human, it authenticates to systems, it doesn't have a face or a badge. So it gets provisioned like automation, handed a set of credentials broad enough to make it functional, and pointed at the workflow it needs to run.

That logic falls apart quickly. A service account does one thing, in one system, following deterministic logic. An AI agent operates across multiple systems simultaneously, makes contextual decisions using significant amounts of data, acts asynchronously from the person who triggered it, and may be executing in multiple roles within a single workflow. The access requirements are dynamic by design. That is not a service account. That is something the identity governance playbook was not written for.

Applying service account governance to agentic AI gets you one of two outcomes. Either the agent is so constrained it cannot do its job, or you overprovision it to make it functional and quietly accept the risk. Based on what I see in real enterprise environments, the second outcome wins almost every time. Only 21.9% of teams treat AI agents as independent, identity-bearing entities with their own access scopes and audit trails. The rest are operating on assumptions that will not hold.

Where least privilege breaks down

Least privilege is a principle worth defending, but it was designed with human behavior as the baseline. Humans bring intent. They apply judgment. They self-limit in ways that are invisible but real, understanding when an action falls outside the spirit of what they were meant to do even if the technical access exists.

Agents don’t work that way. As Accenture's CISO Kris Burkhardt put it plainly at RSAC 2026: "Agents also don't have the judgment that you have. If they stumble across data that they shouldn't, they're not going to report it - they're going to use it." They operate on instructions and probabilistic reasoning. They will use whatever access they have been given, in whatever way their current task appears to require. There is no self-limiting. If the credentials are there, the action is possible.

This means governance has to be structural, not assumed. Rather than assigning a single broad identity to an agent and hoping it behaves responsibly, organizations need to issue ephemeral, scoped identities for each discrete task within a workflow. An agent pulling contacts from a CRM needs a read-only identity scoped specifically to that CRM. An agent sending follow-up emails needs a send-only identity tied to approved domains and specific templates. Those two identities should not inherit each other's permissions simply because they are adjacent steps in the same workflow.

There is also a layer that most organizations skip entirely: a broker between the agent and its credentials. An AI agent gateway that intercepts every tool invocation request, evaluates the request against enterprise policy, scores the risk of the intended action, and either approves or blocks the execution in real time removes significant risk from direct credential access and creates an audit trail that actually means something when something goes wrong. That combination is harder to build than handing an agent an API key, but it is also the difference between a governed system and a liability.

The ownership problem nobody has solved

When an agent retains access long after the initiative that created it has been cancelled, or when it does something unexpected, the first question is always the same. Who owns this?

The answer, far more often than it should be, is silence.

AI agents need ownership models that reflect how they actually operate. A personal agent acting on behalf of a single user is relatively straightforward. A shared agent serving an entire team requires a different ownership structure. An agent operating across departments as part of a brokered policy requires something different again. The NIST AI Risk Management Framework suggests that organizations assign responsibility to an individual or team, yet the responsible team could be the engineering team that developed the model, the third-party SaaS that deploys the technology, or the HR, security, or IT team that controls the data. That ambiguity does not resolve itself. It has to be designed out.

Applying one ownership model to all three creates the same orphaned identity problem that has plagued non-human identity management for years, now running at a faster pace and with broader system access than most legacy service accounts ever had. AI initiatives also move fast and change direction often. A pilot that made sense in one quarter gets deprioritized or abandoned in the next. The agent's credentials, if not time-bound and properly lifecycled, do not go away with it. Agent decommissioning must address the revocation of all credentials, API keys, and tool access authorities held by the agent, the notification of any external systems that maintained trust relationships with the agent's identity, and the preservation of audit logs for the retention periods required by compliance obligations. Most organizations are not doing any of this consistently.

The problem with keeping IAM out of the conversation

One of the most common things I see is organizations standing up AI agents without any IAM involvement in the process. Sometimes this happens because the AI initiative is moving fast and IAM feels like friction. Sometimes it happens because the organization has an "embrace AI quickly" mandate that nobody has thought to route through identity governance. A 2026 Gravitee survey found that only 24.4% of organizations have full visibility into which AI agents are communicating with each other, with more than half of all agents running without any security oversight or logging. Either way, you cannot govern what you cannot see, and right now most security teams cannot see most of their agents.

NIST's recently launched AI Agent Standards Initiative signals exactly how seriously this problem is being taken at a federal level, with a specific focus on identity, credentialing, and authorization mechanisms to authenticate AI agents, define and limit their permissions, and ensure they can be properly scoped, monitored, and governed within systems. The regulatory direction is clear. Organizations that have not started building that discipline internally will find themselves catching up to external requirements rather than ahead of them.

The organizations that are managing this well are doing something simple. They are treating agent provisioning as a workflow that belongs inside IAM, not alongside it. Agent identities go through the same intake, the same access review cycles, and the same offboarding processes as every other identity in the program. The governance principles are the same. The implementation details are different because agents are not humans and cannot be treated identically, but the discipline is the same.

Find out where you actually stand

Autonomous AI agents are poised to fundamentally redefine enterprise operations, but access defines the value and risk of those agents simultaneously. The non-human identity problem took years to become the crisis it is in most enterprise environments today. Agentic AI is accelerating that crisis significantly, because agents require broader access, operate more autonomously, and proliferate faster than the service accounts and API keys that came before them.

Most identity leaders I speak with already sense they have a gap here. What they don't have is a clear picture of how wide that gap is, or where to close it first. That's exactly what we dig into during our technical office hours, a focused 30-minute conversation where we work through your current agentic provisioning approach, identify the highest-risk exposure points, and give you a practical starting point rather than a generic framework.

If you'd rather start with a structured baseline, our identity maturity assessment covers how your program handles non-human identity governance today, including AI agents, and maps where the most urgent work is.

Either way, the right move is to understand your current posture before your agentic environment matures to the point where retrofitting controls becomes the expensive, slow, and unpleasant project it tends to be. The problem nobody warned you about is already here. The organizations that act now will be in a significantly better position than those who wait for an incident to make the case.

Schedule a technical office hour or take the identity maturity assessment to see where your program stands.