When Software Acts on Its Own: A Conversation with Vatsal Gupta on Authorizing Autonomous AI Agents

Software has started to make decisions that used to belong to people. By 2028, 33% of enterprise software applications will include agentic AI, up from less than 1% in 2024, which means autonomous agents will soon be reading data, calling APIs, and triggering actions inside systems that were designed around human logins. The identity layer underneath them was not built for that. These agents authenticate, hold permissions, and act on their own, yet most organizations have no way to govern them as the independent actors they are. The question nobody fully answered before the agents arrived is a simple one: when the thing requesting access is not a person, who decides what it is allowed to do?

Vatsal Gupta is a Senior Security Engineer who has worked in identity and access management for more than 12 years, designing how large organizations control and review access at scale. He builds those controls in production for one of the world's largest technology companies, and over the past two years he has focused on the harder version of the problem: authorization for software that acts on its own. In June 2026, he was selected to present his work on converting natural language statements into policies at Identiverse, one of the largest identity conferences in the world, on a programming track reserved for the field's forward-looking ideas. His view is that the agent problem is not a future concern but a present gap in the standards most companies already rely on.

We spoke with Vatsal about why identity frameworks built for human users fail when the user is an autonomous agent, and what it will take to put that software under real control before it is everywhere.

Most people think of identity and access management as a solved problem. Why do AI agents break it?

Because the entire model assumes a human is on the other end. Role-based access control, service accounts, periodic reviews, all of it was designed for a person who logs in, does a job, and logs out. An autonomous agent does not behave that way. It can expand its own scope mid-task, hand work to other agents, and run for hours or days without a single human in the loop. You are governing something that makes its own decisions with a framework that assumes it will not.

And the scale is moving faster than the controls. Today, 68% of organizations have no identity security controls built specifically for AI. So you have software that is about to make real decisions, operating with credentials nobody is watching, under rules written for a different kind of actor. The agents are arriving whether the governance is ready or not, and right now it mostly is not. That gap is the thing I work on.

Much of your work on this happens through the international standards bodies rather than inside any one company. What does that actually involve?

The standards are where this gets fixed for everyone or it does not get fixed at all. I contribute to the international working groups defining modern authorization, including the OpenID AuthZEN standard that major identity vendors implement for access decisions, and the OWASP verification standard for AI security that many regulated industries treat as a baseline. Working there, rather than only inside one company, changes the reach of the work. A requirement I get reviewed and merged into a published standard ends up in every product built against it, and in every enterprise that adopts it.

What I pushed for specifically were controls that did not exist for agents. I proposed new requirements covering how authority is validated when one agent delegates a task to another, how long-running agent sessions are handled when permissions change underneath them, and what a runtime should do when it cannot reach the system that would tell it an access decision has been revoked. Those gaps were invisible as long as the actors were human. The moment the actor is an agent that runs unattended, they become the whole game.

One thing you keep returning to is that an agent can run for hours without checking back in. Why is that such a hard problem?

Take revocation. With a person, revocation is easy enough. You disable the account, and the next time they try to do something, they are blocked. An agent does not work in those neat intervals. It might start a task with valid permissions, and forty minutes later those permissions are gone because the user it was acting for changed roles or left, but the agent is still running and still holding the access it had at the start. The standard machinery for continuous evaluation assumes someone is there to re-authenticate. Nobody is.

So the controls have to be different. I argued for two things at the standards level. First, an agent runtime has to be able to receive a revocation signal in the middle of execution and act on it immediately, not at the next login that is never coming. Second, if the agent cannot reach the channel that would carry that signal, it has to fail closed, stop, rather than assume everything is still fine. That second rule is unpopular because failing closed interrupts work. But an agent that keeps going after it has lost contact with its own authorization is exactly the thing you do not want running inside your environment.

What is the failure mode that worries you most, the thing that nearly breaks?

Delegation chains. A single agent is manageable. The problem starts when an agent spins up other agents to handle pieces of a task, and each one inherits a slice of authority, and three or four hops down the chain you have a process acting with permissions nobody explicitly granted it. Authority compounds quietly. If you are only watching the first agent, you are blind to what the rest of the chain is doing in your name.

There is a subtler version too, and it is the one most teams miss. When an agent asks whether it is allowed to do something and the system errors out, a naive implementation can read that failure as a yes, when it is neither a yes nor a no. I pushed for a clear distinction between a real authorization decision and a system that simply could not answer, because an agent that treats an outage as permission is a breach waiting to happen. Most teams still model agents as if they were service accounts. That is the mistake. A service account does one predictable thing. An agent improvises.

Before you can authorize an agent, you have to know what it even is. Is that a solved problem?

Not yet, and it is the part people skip. A peer-reviewed IEEE study I co-authored on decentralized identity looked at architectures where identity is not handed down by a single central authority but is something an entity holds and proves on its own, through verifiable credentials. That model was built mostly for people and organizations, but it maps onto agents in a useful way. An agent could carry a credential that says what it is, who it is acting for, and what it is permitted to do, and present that proof at the moment it acts, rather than relying on a static account somebody set up months ago and forgot.

I am not claiming decentralized identity solves agent authorization on its own; it does not. But the instinct behind it is the right one. Identity should be something an agent proves continuously, scoped to the task in front of it, not a permanent badge it keeps forever. The work in the paper was about treating identity for autonomous and machine actors as a serious design problem. That population is already enormous: machine identities outnumber human identities by more than 80 to 1 in the average enterprise, and agents are pushing that number higher. We were trying to get ahead of it before the industry was forced to confront it the hard way.

You seem to approach agent security from an adversarial angle, assuming someone is actively trying to break it. Where does that instinct come from?

Partly from work I do outside the enterprise. I serve as a peer reviewer for CyCon 2026, the conference on cyber conflict run by NATO's cooperative cyber defense center, and the research there treats autonomous systems as instruments in actual conflict between states, not as productivity tools. It assumes a capable adversary who is actively trying to turn your own automation against you. When you spend time in that mindset, you stop designing only for the cooperative case.

It changes the questions I ask. The question is no longer only whether an agent can do its job. It is what happens when someone manipulates it into doing something else, impersonates it, or feeds it instructions through a channel I did not think to lock down. A lot of agent security today is built for a world where everyone is well-behaved. The defense research community does not get to make that assumption, and neither should anyone deploying agents at scale. The threat model has to start from the idea that the agent will be targeted.

Where does this go next, and what is still genuinely unsolved?

The unsolved part is that the standards are still ahead of the deployments. The controls for delegation, for revocation mid-execution, for telling a real denial apart from a system failure, those are getting written now, in the open, by the working groups. But most companies deploying agents today are not implementing them yet. They are wiring agents into production with the same service-account assumptions that already do not hold. The gap between what we know how to govern and what is actually being governed is the dangerous space, and it is widening as adoption accelerates.

So the work I am committed to is unglamorous: getting these controls settled in the standards before agents are everywhere, so that authorization is built into how an agent operates rather than bolted on after an incident forces the question. An agent should have to prove what it is and what it is allowed to do every time it acts, and a company should be able to revoke that in real time and trust that the agent will actually stop. We are not there yet. But we are deciding the rules now, while it is still possible to decide them deliberately rather than under pressure.