| TL;DR: Enterprises can account for every employee’s access but not for what their AI agents can reach. Agents skip onboarding, collect permissions as they work, and keep running long after the engineer who built them has moved on. Most identity tools were never designed to record them at all. Oak raised $60 million to close that gap, and its conversations with more than 100 CISOs point to a harder problem waiting on the other side of visibility. |
Enterprises can tell you who their employees are and what those people can access. Ask the same question about an AI agent and the room goes quiet. The question usually comes from an auditor, a board member, or a CISO a few weeks into the job. By the time it lands, the team already knows the answer does not live in any tool they own. In fact, no system in the stack ever had a category for that identity.
Oak raised $60 million to close that gap. However, finding those agents is the easier half of the work. Yael Cinamon, who leads marketing and product growth at Oak, describes a second wall that hits right after the first.
Once the access is on screen, nobody can say who owns it. What happens next follows a sequence Oak now sees repeatedly, and it explains why identity buyers are moving earlier than forecast.
A Missing Category, Not a Broken Control
Oak’s co-founders spent months talking with more than 100 CISOs and identity leaders before writing any code, and the company says the pattern held almost everywhere they looked. Enterprises were running too many disconnected identity tools, with no clear view of how access was actually being used, and no way to govern agents at all.
What is striking is that none of those gaps were secrets. Security leaders could describe every one of them in detail. The tools simply had nowhere to record the thing being asked about, so hundreds of service accounts and agent tokens ended up sitting in a single environment with zero governance coverage.
Sitting underneath that is a different kind of failure than security teams are trained to look for. Nothing malfunctioned. There was no incident to investigate and nobody to hold responsible.
Cinamon put it this way:
That has consequences an audit committee would recognize. Attestations were signed, and reports went upstairs, and all of it was accurate about the population it measured. It was also completely silent about a population nobody had defined yet.
Why the First Finding Always Gets Challenged
The reaction Oak describes when it turns the graph on is not relief but argument.
According to Cinamon:
Buried in that sentence is the technical heart of the problem. The permission was never granted directly to anyone. It accumulated through nested groups, one membership inheriting from another, until an account nobody considered privileged could do something nobody intended. What the access records say and what the account can actually do have, quietly, come apart.
Traditional tools report what was provisioned, which is why the security team’s own documentation backs up the person doing the arguing. They are not being defensive. After all, they are reading the records they have, and the records are wrong in a way the records cannot show.
The Word That Stalls Most Identity Programs
Then comes the part of this story that has almost nothing to do with software.
Once the disbelief passes and the access is confirmed, the obvious next question would seem to be whether the exposure is dangerous. According to Oak, that is not what happens. The question that surfaces is not “is this risky?” It is “whose is it?”
Cinamon answered:
This is where most organizations stall, for a reason that has nothing to do with the finding itself. Every remediation process ever designed assumes a human on the other end. Someone requests access, someone else approves it, and someone entirely different gets notified when it is time to review.
An agent built during a sprint by an engineer who has since moved on has none of that scaffolding. No manager inherited it, no ticket queue that owns it, no team that would notice if it disappeared.
So the finding enters a state that will be familiar to anyone who has worked in a large company. It is real and documented, and it is nobody’s job.
And revoking it unilaterally is its own risk. Nobody can say with confidence what breaks if the agent stops running, which means the safest move is to leave it alone and flag it again next quarter. That, ultimately, is how a governance gap survives even after it has been discovered.
Agent sprawl, then, is not primarily a security failure. It is an organizational design failure that security teams have inherited, and no amount of detection alone resolves it.
Every Identity Tool Can Find the Problem. Almost None Can Fix It.
Detection is not the hard part anymore. What separates identity products now is whether anything actually closes. Cinamon said, “The industry’s failure mode is handing security teams another inventory of problems.”
Oak’s answer is to resolve each finding to an accountable human, fix the root cause rather than the symptom, and keep it fixed. Closure is the claim that separates products, and it is also the claim that is hardest to verify from the outside.
She is upfront about what that looks like at the start. “The first thing Oak delivers is usually bad news.” Dormant access, inherited admin rights, agents with no owner. For the buyer, the value shows up as work before it shows up as relief.
Two Signals That the Timeline Already Moved
The public forecast, from Gartner, is that 70% of CISOs will adopt identity visibility and intelligence capabilities by 2028. Oak’s read is that the field has already outrun it.
The company puts machine and AI agent identities at more than 100 to 1 against human ones in enterprise environments, a ratio it says compounds every quarter as agentic AI spreads. Even at a fraction of that ratio, it describes a population that identity tooling was never built to handle.
The stronger signal is what buyers are doing with their budgets. Identity has always been the stickiest category in enterprise software, where policies and integrations embed so deeply that switching is close to unthinkable. Oak argues that the stickiness is starting to give way.
As per Cinamon:
Enterprises are replacing identity tooling they bought recently and are still paying for, because a platform measuring integrations in quarters cannot keep pace with an estate adding agents weekly. Alongside it, the buying conversation has moved from compliance to security. Agent governance questions now arrive unprompted from security and platform teams instead of from audit at the end of a quarter.
Oak Is Betting the Barrier Was Never the Technology
Replacing an identity platform normally starts with weeks of meetings to work out which systems need connecting, followed by a schedule that builds those connections one at a time over the next several quarters. Oak says its own version starts with a single connection, with new connectors built in hours and a full environment live in days.
The more revealing decision is what the company does after that. A dedicated identity services team embeds with the customer and builds, migrates, and runs the program until Oak is at full strength. That is a heavy commitment, and it is aimed squarely at the reason most identity replacements never happen. Buyers rarely doubt that a new platform can do the job. The thing is, they doubt they can survive the year it takes to get there, and Oak has decided to carry that year itself.
That decision says something about where the company thinks this category is heading. Enterprises are adding agents every week. A review that happens once a quarter will always be looking at an estate that has already changed.
What Oak is selling, then, is not a better picture of who has access to what. It is the argument that every identity in that picture needs a name attached to it before the question gets asked, and that no enterprise gets there while its identity program is still measured in quarters.
