Agents, and the Identity Underneath

I spent a few days at the ReThink! IAM event in Zürich recently, and one impression stuck with me more than any single talk. AI agents are developing quickly, faster than I’d appreciated from reading about them, and identity security, the thing that’s supposed to govern what those agents can actually do, tends to show up as an afterthought. The capability tends to come first, and the question of who or what is allowed to use it comes later.

That’s worth talking about, mostly because it’s a familiar story in a slightly new form.

A Quick Reminder: Non-Human Identities

If you’ve read my earlier post, you’ll remember that I think non-human identities came up as one of the places IAM quietly goes wrong at scale. Service accounts, API keys, machine identities, CI/CD credentials. The accounts that don’t have a person attached, don’t follow the joiner-mover-leaver lifecycle, rarely get rotated, and usually carry more privilege than they need because broad access was easier than figuring out exactly what they required.

None of that is new. NHIs have outnumbered human identities in most environments for years. The commonly cited ratio sits somewhere around 45 non-human identities for every human (or even more), and in cloud-native environments it climbs much higher. The point is that this was already a hard, under-managed problem before anyone deployed an agent.

AI agents don’t really help our challenge here - their numbers are growing, really quite quickly.

Why Agents Are Different

A traditional service account is, for all its flaws, predictable. It does roughly the same thing every day. It talks to the same systems. If you bothered to map what it needs, that map stays accurate for a long time.

An agent doesn’t really work like that. The whole point of an agent is that it decides what to do. It takes a goal, figures out the steps, and calls whatever tools and systems it needs to get there. A single request can branch out into a number of actions across multiple systems. It might spin up other agents to handle sub-tasks. It tends to act continuously, often without a human watching any individual step (unless you have human-in-the-loop already sorted ;) ). AI Agents will take their own path to get their task done, and you won’t always know why it is doing what it is doing, and how it thought that it is a great idea to go down that route. At the end the AI Agent will surely be proud of what its done though (we’ve seen enough cases already of AI Agents clearing productive databases/ systems because it was trying something out).

So the question “what does this identity have access to?” gets much harder to answer. With a service account, the access is static and you can at least go look it up. With an agent, the access is exercised dynamically, at runtime, based on what the agent decided to do in that moment. You’re no longer governing a fixed set of permissions. You’re governing the behaviour of something that improvises.

That, I think, is the main shift. And it’s part of why the tooling built for human users, the tooling built around someone logging in, holding a session, and getting reviewed once a quarter, doesn’t map onto agents particularly well.

The Afterthought Problem

Here’s what I kept noticing in the ReThink IAM Event. The agent capabilities being demonstrated were genuinely impressive. The identity story underneath them was usually thin.

The pattern goes something like this. A team wants an agent to do something useful, so they wire it up to the systems it needs. To make that work quickly, they hand it a credential, often a broad one, because scoping it tightly is fiddly and the goal is to get the thing working. The agent now has standing access to real systems, it was provisioned in an afternoon, and nobody really filed it anywhere. There’s no HR record for an agent, and no onboarding form. It simply starts operating with whatever access it was given. Usually noone is even assigned to the agent. In 5 days (or weeks, months, etc.) it’s unlikely that there are people who still really know what the agent is there for.

The discussions floating around the event backed up the impression. A large majority of organisations admit they have no formal policy for creating, tracking or removing AI identities, and not many are confident their existing IAM tooling can manage the risk. The capability tends to be in production well before the governance catches up with it.

Where the Risk Comes In

It’s worth thinking about what an over-privileged, poorly-tracked identity means when the thing holding it can act on its own.

A compromised service account is already a classic lateral movement path, because it usually has broad, persistent access and generates less suspicious-looking traffic than a human doing the same thing. An agent extends that picture. It can chain actions across many systems in a short space of time. If it’s compromised, or if it simply misreads its instructions and does something destructive, the blast radius is whatever access you handed it.

And there’s a subtler issue that came up more than once. When an agent acts on a user’s behalf, whose authority is it acting with? If you get this wrong, an agent ends up able to do things the user who triggered it could never do directly, because it’s running with its own broad credential rather than the user’s narrower one. The clean answer is that an agent’s effective permissions should be the overlap of what the user is allowed to do and what the agent is allowed to do, never the sum of the two. That’s easy to say and, like most things in IAM, harder to actually enforce.

What It Comes Down To

I don’t think the answer is to panic, and I’m wary of the vendor framing that every one of these problems happens to be solved by the product on the next slide. But a few things seem clearly right, and most of them are just good IAM applied to a new kind of actor.

Agents are identities, and they probably deserve the same lifecycle discipline as everything else. They need an owner, a reason to exist, scoped access rather than a broad credential grabbed for convenience, and a way to be switched off. The visibility problem from my last post applies here too. You can’t really govern what you can’t see, and at the moment a lot of organisations can’t see their agents at all, let alone what those agents are reaching into. Short-lived, scoped credentials are probably worth the effort, since a static key handed to something autonomous is a worse idea than a static key sitting in a config file. And the organisational seam is, as always, where it gets hard. Agents tend to be spun up by development teams chasing a capability, while the people who think about identity risk are usually somewhere else entirely. If those two groups aren’t talking, the gap I saw in Zürich is a fairly predictable result.

Where I’ve Landed

I’m early in my own IAM journey, so I perhaps am not one to give advice. I don’t have the agent identity problem solved but as far as I can tell right now noone has all the answers. Some people have some answers, some have good answers, but we’re still at the beginning. What I took away from ReThink IAM wasn’t a solution - it was more a sense of pace (or feeling, that we’re all in this together). The agents are already here and steadily getting more capable, and the identity layer that’s supposed to govern them is trying to catch up.

I’ll keep writing as I learn. If you’re working on this for real and I’ve got something wrong, I’m happy to discuss further! Please reach out to me (e.g. on LinkedIn).

Thanks for reading!