Why Every AI Agent Needs Its Own Identity (And How to Implement It).

5 Identity Controls to Consider and Implement for AI Agents

How do you govern AI agents when most of today’s identity infrastructure was built for people?

This was the core problem (and one many enterprises face today) that I had the chance to discuss at Oktane 2026.

Oktane was an important place to have this conversation because identity teams are right in the middle of it. Agents are already accessing applications, inheriting user permissions, and taking actions across systems. That means this is not just an AI problem. It is an identity problem.

The good news is that identity teams already know how to do a lot of this. We know how to establish identity, assign ownership, govern access, create audit trails, and revoke permissions.

The difference is that agents move faster, act more independently, and can create problems much faster than a human can.

Where Traditional IAM Starts to Break

Traditional identity models don’t map cleanly to agents.

Many agents today still use delegated human permissions or shared service accounts. That creates a clear problem: the agent may end up with more access than it needs, and when something goes wrong, it can be hard to answer who authorized it, why it had that access, and what it actually did.

That gets more serious when the agent is moving at machine speed. The question cannot just be, “Is this credential still valid?”

It has to be, “Is this agent still doing what we intended it to do?”

Five Controls That Matter

When it comes to what governance actually requires, there are five points of control organizations should consider. Thanks to Sean Frazier, Federal Chief Security Officer at Okta, for sharing these insights on stage with me at Oktane:

1. Give the agent its own identity. Stop routing agents through a developer’s login or a shared service account. Each agent needs its own identity, separate from the person who built it and from every other agent doing similar work. This is what makes everything else on this list possible.
2. Make it traceable. Every agent identity needs a clear line back to the person or system that authorized it. And that line has to survive the agent creating downstream access for other agents. This is where traceability breaks down fastest in practice.
3. Right-size access. Make access fit the task instead of giving the agent a broad set of permissions and leaving them in place. This is least privilege, which identity teams already know by name. A person who does things outside their job tend to get noticed. An agent doing something outside its intended scope often doesn’t, at least not until it shows up in a log no one has reviewed yet.
4. Monitor continuously. Continuously monitor what the agent is doing. A valid credential tells you an agent is allowed to act. It doesn’t tell you whether what it’s doing right now still matches what you built it to do. Those are two different questions, and most identity infrastructure today is built only to answer the first. Continuous monitoring is what catches the gap between “this agent can do X” and “this agent is currently doing something it was never meant to do.”
5. Enable fast revocation. Make sure you can stop it quickly if it starts doing something outside of that scope. When something goes wrong, you need a way to cut access in minutes, not after a change request works its way through a queue. Most teams already understand this instinct for humans. Agents just raise the bar on what “fast” has to mean.

None of those ideas are new to identity teams. What changes is how continuously they need to be applied.

This Process Gets Complicated Fast

We shared an anonymized example during the session that showed how quickly this can get out of control.

Teams had started rolling out agents across engineering, support, and marketing. They created access application by application. Then agents started creating access for other agents.

Eventually, the organization was three or four steps removed from the original human authorization. When something went wrong, they could stop the agent within minutes.

Figuring out everything the agent had done over the previous few months took weeks. That is the part I think people need to pay attention to.

Stopping the agent is one thing. Understanding everything it did before you stopped it is another.

The Standards Will Help. But They Will Not Solve Everything.

Much of the work happening around Cross-App Access and Agent Gateways matters because it gives organizations a way to bring authorization and visibility back into the identity layer.

But not every application will support those standards right away. Some will have APIs. Some will not. Some will be legacy applications that were never designed for this. That is just the reality of enterprise environments.

It is also where Cerby can help. We can extend those identity controls to applications that don’t natively support emerging standards, so organizations can still govern agent access consistently.

You won’t wake up one morning and have every application neatly supporting the same standard. That’s simply not the world we live in.

Start With What You Have

So how do you start putting this into practice?

My advice is don’t try to solve this for every possible agent in the enterprise at once.

Find the agents people are already using and pick the ones with the most meaningful access.

Give them identities. Tie them to owners. Bring them into your governance model. Make sure you can see what they are doing and stop them when you need to.

Then expand from there. The technology is moving quickly, but the underlying problem is familiar.

We still need to know who (or what) has access, why they have it, what they are doing with it, and how to take that access away when something goes wrong.