On April 30, Okta made its AI agent identity platform generally available. The product treats AI agents as first-class identities inside the same directory where companies manage employees. Each agent gets credentials, permissions, a human owner, and a kill switch.
That last part matters. Because according to Gravitee’s State of AI Agent Security report from February, 88% of organizations have already experienced a suspected or confirmed AI agent security incident. And only 22% of organizations treat their agents as independent, identity-bearing entities.
Read those two numbers together. Almost nine out of ten companies have had something go wrong with an agent. Fewer than one in four can tell you which agent did it, what it had access to, or who was responsible for it.
This is not a security problem. Security is the symptom. The problem is operational: most companies deployed a new kind of worker and never onboarded it.
The onboarding gap
When you hire a person, there is a process. They get credentials. They get scoped access to systems. Someone owns them in the org chart. If they do something wrong, there is a trail, a responsible party, and a way to revoke their access immediately.
When most companies deploy an AI agent today, none of that happens. The agent connects to APIs with long-lived tokens that nobody rotates. It accesses systems with permissions nobody scoped. No one in the org chart owns it. If it does something unexpected, the first question is usually: “Wait, who set this up?”
Okta’s framing is useful here. Their blueprint for what they call the “secure agentic enterprise” comes down to three questions. Where are my agents? What can they connect to? What can they do?
Most organizations cannot answer any of the three.
Why this is an operations problem, not a vendor problem
The instinct is to treat this as a purchasing decision. Buy the right governance tool, problem solved. But the 88% incident rate exists across companies that already have security stacks. The tools are there. The process is not.
Think about it the way you would think about a new hire. You would not hand someone a laptop with admin access to every system and say, “Figure it out.” But that is functionally what happens with most agent deployments. An engineering team spins up an agent, connects it to internal APIs, and moves on. Nobody filed a ticket with IT. Nobody scoped permissions. Nobody assigned ownership.
The result is shadow AI. Not the kind where employees use ChatGPT for emails. The kind where autonomous systems are making decisions, accessing data, and taking actions inside your infrastructure with no visibility, no audit trail, and no kill switch.
Okta’s data says 44% of organizations have no governance in place for AI agents at all. Not weak governance. None.
What the workflow looks like when it works
The companies getting this right are treating agent deployment like employee onboarding. Before an agent goes live, it gets:
A unique identity in the organization’s directory. Not a shared service account. Its own entry, same as a person.
Scoped permissions tied to what it actually needs to do. Least privilege, enforced at the identity layer.
A human owner — someone whose name is on it. If the agent does something unexpected at 2 AM, that person gets the call.
Short-lived credentials that rotate automatically. Not API keys hardcoded in a config file six months ago.
And a kill switch. One action revokes all access across every system the agent touches.
None of this is sophisticated technology. It is basic operational hygiene applied to a new category of worker. Most organizations just have not updated their playbook to include non-human team members.
Who owns this in your org
This is the question most companies have not answered. And it is the question that determines whether agent deployment scales or stalls.
In most organizations today, agents get deployed by engineering teams, occasionally by product teams, sometimes by individual employees experimenting. Nobody coordinates. Nobody maintains a registry. IT and security find out about agents after something breaks.
The fix is not to slow down deployment. It is to assign ownership the same way you would for any other class of resource. Someone needs to own the agent directory. Someone needs to enforce the onboarding process. Someone needs to run access reviews on agents the same way they run them on employees.
If you are deploying agents and nobody in your organization can answer Okta’s three questions, you are building a workforce you cannot manage. Eighty-eight percent of companies already have the incident reports to prove it.