The Access Path: Why Your Identity Program Can't See What AI Agents Are Doing

Every access model your organization has ever built was designed around one assumption.

There's a human on the other end.

A person gets hired. You provision them. They change roles. You update their access. They leave. You deprovision them. The entire architecture of identity governance — roles, lifecycles, entitlement reviews, joiner-mover-leaver workflows — is built on that loop. Human in, access out, repeat.

That assumption is now broken. And most identity programs haven't noticed yet.

AI agents don't get hired. They don't have a manager. They don't show up in your HR system. They spin up, execute a task, call fifteen APIs, touch production data, and spin back down, in the time it took you to read this paragraph. Service accounts have been a governance blind spot for years. AI agents make that problem an order of magnitude worse, and they're already inside your environment.

This isn't a future state problem. It's a right now problem.

The question isn't whether your identity program is ready for AI agents. The question is whether the model your program is built on can even see them — let alone govern them.

For most organizations, the honest answer is no. And the reason isn't a tooling gap. It's an architecture problem.

This past week I sat down with five different organizations — different industries, different sizes, different levels of IAM maturity. One conversation topic across all of them: NHI and AI agents.

Every single one of them knew they had a problem.

Not one of them knew how deep it went.

That's not a criticism. It's actually the most honest place an organization can be right now, because the visibility problem in this space is deceptive. It looks like an inventory problem. Count your service accounts, map your API keys, tag your OAuth tokens. Get to a number. Feel better.

The problem is deeper than that.

The list doesn't show you what that service account actually does once it authenticates. What application it reaches. What data that application touches. What other paths exist to get to that same data that you didn't know were open. The list gives you a noun. You need to understand the verb: the motion, the traversal, the chain of access events that happen after authentication that nobody is watching.

Most identity programs are governing the front door while the house has twelve other entrances.

The reason the depth catches organizations off guard is that NHI visibility and AI agent visibility feel like the same problem. They're not. A service account is relatively static. It was created for a purpose, it has credentials, it authenticates to something. You can find it, document it, rotate its credentials, put it in a vault. That's a solvable problem with existing tooling.

An AI agent is different in almost every dimension that matters. It's dynamic. It's often ephemeral. It doesn't have a fixed identity. It borrows one, or several. It makes decisions at runtime about what it needs to access. And it operates at machine speed, which means by the time your SIEM fires an alert, the transaction is already done.

When organizations tell me they have a visibility problem, what they're actually describing, without the language for it yet, is that they can't see the path.

And that's exactly where we need to start.