TL;DR: AI agents are now accessing enterprise applications, inheriting user permissions, and acting at machine speed, which makes them a fast-growing class of non-human identity that traditional IAM was not built to govern. Cerby CEO Bel Lepe lays out five controls for governing agent access: give each agent its own identity, make its actions traceable to whoever authorized it, scope access to the task, monitor continuously, and revoke access fast. Emerging standards like Cross-App Access and Agent Gateways help, but many legacy apps will never support them, which is where Cerby extends identity controls so agent access can be governed consistently.
At Oktane, I had the opportunity to talk about a problem that a lot of enterprises are starting to run into: how do you govern AI agents when most of the identity infrastructure we have today was built for people?
Oktane was an important place to have that conversation because identity teams are going to be right in the middle of this. 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
One of the things we talked about at Oktane is that traditional identity models do not map cleanly to agents.
A lot of agents today still use delegated human permissions or shared service accounts. That creates a pretty obvious problem: the agent may end up with much 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
We laid out five things organizations should be thinking about.
- Give the agent its own identity.
- Make it traceable. Make sure you can trace what it is doing back to the person or system that authorized it.
- Right-size access. Make access fit the task instead of giving the agent a broad set of permissions and leaving them in place.
- Monitor continuously. Continuously monitor what the agent is doing.
- Enable fast revocation. Make sure you can stop it quickly if it starts doing something outside of that scope.
None of those ideas are new to identity teams. What changes is how continuously they need to be applied.
This Gets Complicated Fast
We shared an anonymized example during the session that showed how quickly this can get away from you.
Teams had started rolling out agents across engineering, support, and marketing. Access was being created 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 were able to stop the agent in a matter of 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.
A lot of the work happening around Cross-App Access and Agent Gateways is important because it gives organizations a way to bring authorization and visibility back into the identity layer.
But not every application is going to support those standards right away.
Some will have APIs. Some will not. Some will be legacy applications that were never designed for this at all.
That is just the reality of enterprise environments.
It is also where Cerby can help. We can extend those identity controls into applications that do not natively support the emerging standards, so organizations can still govern agent access in a consistent way.
You are not going to wake up one morning and have every application neatly supporting the same standard.
That is not the world we live in.
Start With What You Have
The last thing we talked about at Oktane was how to get started.
Do not try to solve this for every possible agent in the enterprise at once.
Find the agents people are already using.
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.
Frequently Asked Questions
What is an AI agent identity?
An AI agent identity is the digital identity assigned to an autonomous AI agent so it can be governed like any other account. AI agents are a type of non-human identity (NHI), alongside service accounts and API keys, but they act independently and at machine speed, which makes ownership, traceability, and revocation harder.
Why doesn't traditional IAM work for AI agents?
Traditional identity models assume a person behind each account. Many agents run on delegated human permissions or shared service accounts, so they can end up with more access than they need, and it becomes hard to answer who authorized the agent, why it had that access, and what it did.
How do you govern AI agent access?
Give each agent its own identity, tie its actions to the human or system that authorized it, scope access to the task, monitor continuously, and be able to revoke access fast.
What are Cross-App Access (XAA) and Agent Gateways?
They are emerging standards that bring agent authorization and visibility back into the identity layer. They help, but not every application supports them, and legacy apps may never be designed for them.
How do you govern agents in apps that don't support these standards?
Cerby extends identity controls into applications that do not natively support the emerging standards, so organizations can govern agent access consistently across modern and legacy apps.
Definitions
Non-human identity (NHI): Any identity that is not a person. Includes service accounts, API keys, tokens, machine identities, bots, and AI agents. NHIs now often outnumber human identities in the enterprise.
AI agent identity: The identity assigned to an autonomous AI agent. A subset of non-human identity. Unlike a static service account, an agent acts independently and at machine speed.
Cross-App Access (XAA): An emerging standard for bringing agent authorization and visibility back into the identity layer across applications.
Agent Gateway: Infrastructure that mediates how agents access applications, adding a control and visibility point.