Guest post by Howard Ting, CEO at Opal Security (previously Cyberhaven, Palo Alto Networks, Nutanix, and RSA Security). Published in partnership with Opal Security.
I started my career in identity in 2000 at RSA Security, when the hard problem was proving that a person was who they said they were. Since then I've worked on early identity federation and single sign-on products at Microsoft and several startups, helped scale Palo Alto Networks, and ran an insider risk company. I've seen a lot of shifts in security. This one is different.
For the first time, the thing asking for access is likely not a person. It's an agent. Agents are becoming the most powerful identities in the enterprise and the least governed. They act on their own, around the clock, and most teams can't say what a given agent touched, who owns it, or why it has the access it does.
Most security teams I talk to are stuck with a tradeoff they never chose. Lock agents down and hurt the company’s productivity and competitiveness. Let them run wide open and take on risk nobody can measure. Neither option holds up for long. In the age of AI, a security team that slows the business down gets routed around, and one that waves everything through is one bad agent away from an incident.
The root cause is simple. Our access model was built for a world where the volume stayed human-sized. Agents break this model and many of our long-held assumptions.
Clickops and vibes
Here's how most access decisions get made today. It's 11pm and a request comes in. The name is familiar, the justification sounds reasonable, and you've already approved six of these today. You click approve. It's clickops, usually on vibes, and I've done it more times than I can count.
Even with people, this is straining. A security engineer at one of our customers, a large tech company, put it plainly:
"If you plug 500 access reviews in front of somebody, people kind of rubber stamp the entire thing. That is a human bandwidth constrained resource."
The cost shows up on both sides. Before they came to Opal, one customer added up the time their engineers spent waiting on just-in-time access over 12 months. It added up to 42 years. Another came to 29. And the access that was granted often sat unused. Slow and insecure at once.
Now put agents into that system. They work when humans are asleep, and a 15-minute wait is not just an annoyance but counts as a failure of the system. They're also persistent. Deny a capable agent and it comes back with a new justification, then another. They aren't malicious. They're determined, and they lack inhibition. I have three young kids, and capability without inhibition is exactly what keeps me up at night. You can't govern that on vibes.
It's 100,000 to one
The ratio people quote is 50 to 100 non-human identities for every human. That ratio is about identities. The one that matters for governance is about access decisions, and it's far worse.
Say an engineer needs a customer database to troubleshoot a ticket. We grant seven days, and they touch it a thousand times. That's one decision. An agent doing the same work shouldn't get seven days. You don't know if it's still on the ticket by day three, or what else it's being prompted to do. So you scope access to the task, maybe for a minute, and then revoke it. Now each of those thousand touches requires its own unique decision, multiplied across every agent each employee runs. As agents take over more of those 50 to 100 non-human identities per person, that’s up to 100,000 decisions for every one we make for a human.
Least privilege has always been more aspiration than reality for human governance because of the capacity-to-demand ratio. It’s literally impossible to achieve for agents without fundamentally different tooling. Every time you narrow scope, you create another decision that has to be made and widen the gap in decisioning capacity.
From CPU to GPU
Today's access governance is built like a CPU: one decision at a time, with a person in the middle. Computing hit the same wall, first with graphics and now with AI, and the answer was a processor built for parallel work. That's the GPU.
Access needs its own GPU: a policy decision engine that's fast, accurate, scalable, and built with AI. To address the volume without sacrificing the quality of decisions, AI must manage AI. I believe 98 to 99 percent of access requests could eventually route to an AI “brain” rather than a person. The other 1 or 2 percent need real human judgment, and that's where people should spend their time.
The empty box on the right
Picture agent access as a lifecycle running left to right. The industry has gotten decent at the left side: discovering agents, inventorying their credentials, tying each one to an owner. Move right and things get thin. A security leader at one of our design partners described where discovery leaves you:
"We're a company of engineers. We're a company of tinkerers, and we're a company of people who are going to do whatever you didn't say I can't do. People are creating their own API tokens... stuffing in API tokens in plain text. For everything else that we've discovered, we have no idea what these people are doing yet, and we have no way to stop it."
Knowing an agent exists doesn't tell you whether it should do what it's about to do, right now, for this task. That decisioning engine is the brain of the agent identity stack, the GPU. In most stacks today, that box is empty.
What goes in the box
Full disclosure, this is what we build at Opal. Paladin, our decision engine, sits at the center of Opal Zero, which we built with design partners including Faire, Databricks, Elastic, and Superhuman. Here's how it decides, because I think the approach matters more than whose logo is on it.
Take an agent asking for write access to a production database to resolve an incident. Before anything is granted, Paladin works through a few questions:
Who owns it, and what can they access? The owner's permissions are the ceiling. An agent never gets more than the person accountable for it.
What was it built to do? The agent's stated intent has to match its purpose and what it has actually been doing. Narrow, single-task agents are far easier to govern than long-running general-purpose ones.
Does the context check out? Is there an open incident? Is the agent’s owner assigned to it? Does the access requested match the work? Paladin pulls that from the ticketing system, team chat, and the identity provider.
How sensitive is the resource? Each company sets its own risk tolerance, and can rate specific systems, like customer data, above the defaults.
From there it takes one of three paths. It approves access scoped to the task, which expires or is revoked when the work is done. It denies, with the reason written out. Or it escalates to a person, with the research already packaged so the review takes seconds instead of 15 minutes. Whatever the path, the decision is enforced in the gateways teams already run.
Speed is non-negotiable. Another design partner told us exactly where the bar sits:
"It has to be on the order of seconds to make that decision and not minutes... If the AI does denials that disrupt the agents, that's not going to be flying."
Trust has to be earned too. Most teams start in guided mode, where Paladin recommends and a person decides. Once they agree with it nearly every time, they let it decide on its own for low-risk resources that are easy to reverse.
What this looks like in practice
Getting standing access to zero isn't a new idea. After a 2021 supply chain attack showed how much damage long-lived credentials could do, Mercari, Japan's largest consumer-to-consumer marketplace, set a goal of zero standing access to production. Their homegrown system couldn't keep up with changing developer tools, so they moved to Opal. They kept zero standing access to production, extended just-in-time access to more developer tools and productivity apps, and handed off the integration upkeep so their engineers could get back to the actual business.
Databricks has been an Opal customer for years. Before that, running just-in-time access was nearly impossible without adding a lot of overhead. Today, all time-bound and session-based access to their sensitive systems runs through Opal. Now we're working with them to bring the same decisioning to their agents, enforced inside Databricks Unity Gateway. That matters because we won't be everywhere agents run, and we shouldn't have to be. The decision should travel to wherever enforcement already happens.
Where to start
You don't need to buy anything to see where you stand. Pick the agents you have in production and ask:
Who owns it, and why does it exist?
Can it reach anything its owner can't?
How long does its access last, and does that match the task?
What happens to it when its owner leaves?
If most of your answers are "I'm not sure," you're not alone. Most organizations are still running on vibes.
From episodic to continuous
For most of identity's history, access has run on events. Someone joins, moves, or leaves, and every 90 days we review the access everyone has. Agents need it to be continuous. My whole career, the tradeoff has been the same: more usability meant less security, and vice versa. With AI managing AI, I don't think we have to make that trade anymore. The next time that 11pm agent request comes in, ask yourself how many more like it are already on the way and whether your identity GPU is ready for them.
Thanks to Howard and the Opal team for partnering with TCP on this one. If you’re working out how to govern agent access, Opal Zero is where Paladin lives. Their eng + product teams are top notch. I’ve seen the product in action, and it’s light years ahead of how most teams are handling agent access today.