Art Poghosyan is CEO and Cofounder of Britive, an innovative cloud security platform that automates multicloud privileged access.
It’s been a busy few months of high-profile AI news—OpenAI and Anthropic are actively investigating tens of thousands of security incidents where autonomous AI agents went past their guardrails; different executives are telling us that AI will end mankind, while others say the risks are worth it. Some members of the U.S. government are pushing for AI kill switches, and others got the industry to agree to self-police.
One thing is clear though. AI agents are here. Gartner projects that by 2028, the average global Fortune 500 enterprise will have more than 150,000 agents in use, up from fewer than 15 in 2025. In the same research, only 13% of organizations said they believe they have the right AI agent governance in place. These agents don’t act like new employees. They query corporate databases, modify cloud infrastructure, call APIs and independently orchestrate multistep workflows across critical enterprise layers. Unfortunately, many of the security solutions (both technologies and services) we’re trying to impose on these agents were designed for a human-paced world.
Rather than asking whether to stop or support AI agents, I believe we need to start asking a different question—what are the AI agents allowed to do? And why?
Standing Privilege: Massive Risk For Humans, Reckless For Autonomous AI Agents
Traditional access models were built around people and predictable machine identities. Think about managing a team: Everyone has different permissions, deliberately scoped to what you hired them to do. The permissions are purposely asymmetric across the team.
AI agents are different: They perform specific tasks on behalf of people, services or other agents, at machine speed. If you’re the manager of those agents, do they have permissions that are a subset of what you have? How do you define them? The problem with most approaches to agent security today is that they give agents broad permissions up front, and those permissions stay in place long after the task is done.
Picture an agent given database admin rights to build a quarterly report. The report is done in four minutes. The admin rights stay for months, and anyone who compromises that agent, or the person prompting it, inherits them. Recent reporting on agent incidents points to the same pattern: agents using access they were legitimately given, for purposes outside its intended scope.
We need to shift the conversation from permission toward “Should this specific action be allowed right now?” That question applies whether the action comes from an agent or a human. It gives both identities enough authority to do the job without privileges they can keep, misuse or expose. Granting access only when it’s needed, scoping it to the task and removing it once the task is done addresses standing privilege, the unused access attackers rely on in many of today’s biggest breaches.
Many organizations will say they already have this covered with just-in-time (JIT) access. But most JIT access works like a checkout. The privileged account or role already exists, permanently, and the system controls who can unlock it and for how long. When the window closes, the access is locked again, but it’s still there for the next request, or for whomever finds a way around the lock. For an agent, there’s a second gap; one approval can cover thousands of actions taken at machine speed. The stronger model creates the access only when a task needs it, decides each action as it happens and removes it when the work is done, so nothing is left to unlock.
The Kill Switch Question: An Access Question
Customers ask some version of this constantly: How do we stop an agent when it goes off track? It’s the right question, but it’s harder than it sounds, because stopping and containing an agent aren’t the same thing.
Terminating a process halts the actor. It doesn’t revoke the authority. If the agent has standing credentials, those credentials remain valid even if the process stops. They’re still mapped to an identity and usable by whatever else holds them. In a multi-agent workflow, the agent you killed may have already handed the tokens downstream.
It gets harder when agents operate on borrowed human credentials or shared service accounts. You can’t revoke the agent’s access without cutting off the person it was acting for, and the audit trail can’t tell you which one took the action. Pulling the switch becomes a choice between containment and operations.
Speed matters too. An agent generating thousands of actions a minute will finish long before anyone reads a dashboard. Containment has to fire automatically, on risk signals from the security stack you already run.
If access is minted for a task and expires with it, most of this solves itself. There’s nothing persistent to revoke. Stopping the agent and removing its authority become the same action.
Moving AI Beyond Experimentation
Most enterprises are still deciding how far to let agents go, but there are a few key steps that can guide you in the right direction:
Know Your Agents
Keep an inventory of every agent, what it can reach and the person accountable for it.
Decide Each Action
Check each action as the agent takes it, and require a person’s approval for actions that are hard to reverse.
The Work Is Done, Remove Access
Grant privilege for the task, and take it back when the task ends or when a security signal says something is wrong.
Ask the same question of every identity: Your service accounts and administrators deserve the same scrutiny as your agents.
AI agents have permanently altered what the workforce looks like, but our access models were not designed to keep up with their speed or volume. Managing credentials alone won’t keep up. Changing how we think about access, from what an identity holds to what each action should be allowed to do, will help us move more confidently into the next phase of AI.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?