The Silent Rollback: How Agentic AI Is Quietly Dismantling Zero Trust
A guide on governing AI agent access without stalling the programs you’ve already built.
68% of CIOs believe their AI agents are governed under formal identity and access management (IAM) policies.
But only 35% of IT managers on the same teams agree.
Thirty-three percentage points separate what leaders believe from what their teams report. This isn’t a small difference. It’s a substantial perception gap. And it begs the question: Which of these numbers is right?
The evidence argues that the 35% metric is closer to the truth. The reason is structural. Most Zero Trust frameworks weren’t built to govern AI agents as an identity class. The result is three specific gaps, each one quietly overturning the security work your team has spent years of effort building.
It’s meant to challenge the assumption that your foundation already covers AI agents. It doesn’t.
There are three main gaps where this shows up:
-
The Identity Gap is the structural reason Zero Trust’s identity model was never built to cover AI agents.
-
The Access Gap is what this structural failure looks like in practice. Most AI agents are provisioned with access that directly violates least privilege.
-
The Accountability Gap is what happens when clear agent ownership, visibility, and a kill switch are missing.
Together, these three gaps are driving a silent rollback of Zero Trust. This isn’t a breach or a policy failure. It’s a structural reversal.
This guide isn’t meant to be a doom-and-gloom warning document. It’s a governance framework. By the end, you’ll have a clear model for governing your AI agents as identities, and preventing the silent rollback from degrading your security standards.
The first step?
Before you can close these AI governance gaps, you need to understand where they are. Let’s start with the most fundamental one: the identity model Zero Trust depends on.
Zero Trust built the right foundation. Its central insight has aged well: identity, not network perimeter, is where security is enforced. Every organization that deployed Zero Trust did the right thing.
None of that is in question.
But Zero Trust’s identity model was built for a specific class of actor. One that didn’t include AI agents.
There was no crystal ball, so it’s not a surprise that current frameworks weren’t built for them. But before digging into the data on how this gap is showing up across organizations, you need to understand the structural reason why. It all starts with what Zero Trust was built to protect.
What Zero Trust Was Actually Built to Govern
Zero Trust’s policy engine makes access decisions based on observable identity behavior. That model is right. NIST SP 800-207 makes this point in one of its seven core tenets:
“Access to resources is determined by dynamic policy—including the observable state of client identity, application/service, and the requesting asset.”
The operative word is observable.
Human identities behave in ways that are patterned and detectable. A person logs in from a known device, accesses a predictable set of resources, and can be challenged when behavior shifts. Step-up verification works because the human behind the identity follows recognizable patterns. When the actor behind the identity is a person, the policy engine can observe, evaluate, and act.
Your policy engine is making access decisions based on observable identity behavior. The question is whether it can observe what AI agents are doing. This is where the identity gap comes into play.
Three Ways AI Agents Break the Model
Zero Trust’s identity model makes assumptions about every actor in your environment.
Here are three ways AI agents violate these core understandings.
-
Behavioral Unpredictability
AI agents are goal-seeking systems that adapt to new inputs. Unlike a human who follows recognizable access patterns, an agent’s behavior is unpredictable. It adjusts based on inputs, context, and the goal it has been given. Monitoring tools built for human behavior patterns miss the threat when they evaluate agents. The agent’s activity looks unusual by human standards, but it does not match known threat signatures, so nothing is flagged. The policy engine sees a legitimate identity operating within its granted permissions. It has no mechanism to evaluate whether the behaviour reflects what the person who provisioned the agent intended.
-
Sub-Agent Delegation
A single provisioned agent can spawn sub-agents that inherit its ambient authority. One human makes one authorization decision. That decision can multiply into a delegation chain with no human approval at each link. An agent provisioned with access to your HR system can spawn a sub-agent to act on those records. That sub-agent can spawn another to notify external systems. Each link in the chain carries the full authority of the original grant. Zero Trust was not designed to govern delegation chains that originate from a single human decision.
-
The Confused Deputy
The Confused Deputy (CWE-441) is a well-documented vulnerability in which a legitimately authorized actor is manipulated into exercising its privileges on behalf of an attacker. In human systems, this is difficult to execute at scale. In agentic systems, it’s built into how many agents are deployed. An agent with broad ambient authority can be pointed at manipulated data. A poisoned document, an injected prompt, or a tampered API response can direct the agent to execute actions no human ever authorized. The policy engine records a legitimate access event from an authenticated identity. Authentication passed. Authorization passed. No flag was raised. The manipulation happened at a layer Zero Trust was not built to inspect.
Your policy engine is making correct decisions based on the inputs it was designed for. Not the inputs AI agents produce.
Why “It’s Just a Service Account” Is the Wrong Mindset
The instinct to classify AI agents as sophisticated service accounts is understandable. Service accounts are non-human identities (NHIs) that authenticate programmatically, hold credentials, and access systems without a user session. At a surface level, agents look similar.
But that instinct is wrong.
Service accounts are deterministic and purpose-fixed. A service account that connects your CRM to your data warehouse does the same thing every time it runs. Its access pattern is predictable. Its behavior can be bounded by the narrow set of permissions it needs to do one job. The governance model for service accounts works because the account never deviates from its defined purpose.
AI agents do not work that way. An agent has a goal, not a fixed behavior, and it determines how to pursue that goal based on the inputs it receives. It can be prompted to do anything within its permissions. It can spawn sub-agents that inherit its authority. It can be manipulated by the data it processes into taking actions no one intended. The governance model for a database connection does not apply to an agent that reads email, schedules meetings, and queries financial data. That model breaks at the first prompt.
The numbers tell the same story.
The Q1 2026 IT Trends Report found that 82% of organizations are using agentic AI. Yet only 37% have fully integrated AI agents into formal IAM policies. The 45-point gap between adoption and governance exists, in significant part, because organizations are applying the wrong governance model to the wrong risk profile.
The 68% of CIOs who believe their agents are fully governed may be applying service account governance correctly. The problem is that service account governance is the wrong model. It was not built for how AI agents function.
Most AI Agents Have More Access Than Administrators
Least privilege is one of Zero Trust’s foundational principles. The idea is straightforward: every identity gets the minimum access it needs to do its job, and not one permission more. Applied consistently, it limits the damage any single compromised identity can do. Most organizations are not applying this principle to AI agents, leading to an access gap.
Our Agentic IAM Pulse Report found that 66% of organizations grant AI agents equal or greater access than their human users. Of those, 29% give agents the same level of access as human employees.
Twenty percent give agents more.
Seventeen percent give agents significantly more.
In business-critical environments, 38% of organizations grant AI agents significantly more access than the humans working alongside them. Those environments include financial reporting, HR provisioning, access management, and customer-facing systems. Twenty-four percent allow agents in those same high-stakes environments to execute high-risk actions fully autonomously, with zero human oversight.
The more sensitive the deployment, the more access agents have. And the less human oversight there is in place to govern what they do with it. That is the exact opposite of least privilege policies.
Only 26% of organizations use just-in-time (JIT) or temporary authorization for sensitive agent actions. 49% use long-lived API keys as the primary authentication method for their agents. A long-lived API key with broad permissions is exactly the kind of access gap that governance is designed to prevent.
The Leadership Disconnect That’s Making Agent Access Worse
The numbers above describe an industry-wide pattern. The harder question is how the people inside your organization see that pattern. If they do at all.
Sixty-eight percent of CIOs believe their AI agents are fully integrated into formal IAM policies. Among IT managers and team leads on the same teams, only 35% agree.
This is a stark internal disconnect.
This gap is not a mindset failure. It is a signal failure. The CIO is not receiving an accurate picture of the governance state of their environment. When deployment is moving fast and confidence generally reads as positive, there is no executive pressure to investigate further. This is what allows the visibility problem to persist.
If you are part of the 68%, the question isn’t whether you’re right or not. It’s whether you have the signals to really know where your team stands.
The difference between what leaders believe and what their teams report is a failure of visibility into the state of AI agent governance. Knowing that the gap exists is the first step toward closing it.
How Speed Pressure Produces Permissioned-by-Default Agents
The access patterns and permissions for AI agents today didn’t emerge from a state of carelessness. They emerged from a well-known dynamic: the pace of AI adoption is moving fast, and the governance infrastructure built to manage it hasn’t kept up.
In our Q1 2026 IT Trends Report, 60% of IT professionals agreed that AI is outpacing their organization’s ability to protect against threats. It’s not a new concern. It’s an unresolved one. Seventy-four percent of organizations are at least somewhat concerned about the security risks AI introduces.
When you’re on deadline and need to deploy an AI agent quickly, the fastest path is the broadest credential. Scoped access requires mapping exactly what the agent needs: which systems, which data, which actions, and in what context.
That takes time.
Broad access works immediately. And under deadline pressure, broad access is what gets granted.
The problem is that no one comes back to fix it. The agent goes into production with the access it was given at deployment. There is no automated right-sizing process that narrows permissions once the agent is running. There is no review cycle triggered by the passage of time. The broad access granted at deployment becomes permanent. The agent accumulates ambient authority as it runs.
Ungoverned agents are a deferred operational cost. The access decisions made under pressure today become the governance failures that surface as incidents later.
Do You Know What All Your AI Agents Are Doing?
Any identity with high-level access needs three things to safely operate. A named owner. Centralised visibility into what it is doing. A way to shut it off quickly. Without those three controls, broad access becomes unmanageable. And unmanageable identities are the ones that create governance failures. This is the accountability gap.
Three Controls AI Agents Are Missing
-
83%
The amount of organizations that lack clear security ownership of their AI agents. There is no named human accountable for what any given agent does.
-
59%
The amount of organizations that have no centralized visibility into agent activity. Anomalous behaviour has no audience.
-
55%
The amount of organizations that lack a centralized kill switch for their agents. Of those, 33% report that their only option when an agent behaves unexpectedly is to disable it manually, system by system.
Together, the absence of these controls compounds. Without an owner, anomalous behavior has no one responsible for investigating it. Without visibility, it goes undetected. Without a kill switch, it can’t be stopped quickly when it is finally seen.
Planning is not governance. Seventy percent of organizations report plans to govern non-human identities. Only 22% have the necessary measures in place. The gap between intent and action is where incidents happen.
What Happens When an Authorized Agent Gets Manipulated?
The Confused Deputy vulnerability (CWE-441) describes what happens when a legitimately authorized system is manipulated into exercising its privileges on behalf of an attacker.
Consider an agent deployed to handle vendor invoice processing, with access to your financial data. It receives a document containing an embedded instruction. The agent reads the instruction as a task. It executes it: moving funds, modifying records, or accessing systems outside the scope of its original work. No one sees this happen.
The audit log records a normal access event from a legitimate identity.
Without centralized visibility, the manipulation is invisible.
Without a kill switch, it cannot be stopped once someone notices.
Without a named owner, there is no human to call.
This is not a credential theft attack. No password was compromised. The agent was doing exactly what it was authorized to do. The data simply told it to do something different.
Authorization controls that are built for deterministic behavior can’t see what happened.
Govern Every Identity. From Your First Hire to Your Latest Agent.
Governing your AI agents doesn’t have to require a separate tool. With JumpCloud, you manage the entire lifecycle for every identity in your workforce: human, non-human, and agentic.
One policy engine
One visibility layer
One lifecycle
See Every Agent in Your Environment
You can’t govern what you can’t see.
Right now, most commercial IT environments have agents running that no one has formally registered as identities. Our Agentic IAM Pulse Report found that 59% of organizations have no centralized visibility into agent activity, and 83% lack clear security ownership of their agents.
When it comes to the agent identity lifecycle, the JumpCloud platform helps surface agents wherever they run to create a governed identity record for each one, with a named human owner attached. Every agent that touches your environment gets a record. Every record has an owner.
USE CASE
An example of how this looks in practice: say a company deployed 12 AI agents over the past 18 months. Some came through formal IT requests. Others were provisioned directly by business units under deadline pressure. These agents were tracked across scattered documentation, if at all. Credentials sat in email threads. Ownership was implied but never assigned.
But with JumpCloud, every one of these agents has a clear record, an owner, and a place in the identity inventory alongside every human employee. The IT team can see the full picture for the first time.
Seeing every agent is the foundation. The next step is making sure every agent operates within boundaries you define.
Control Every Identity with the Same Rigor
The agents your teams have deployed are likely carrying credentials that were never designed to be permanent. Forty-nine percent of organizations use long-lived API keys as the primary authentication method for their agents. Only 26% use just-in-time authorization for sensitive agent actions. Both numbers point to the same pattern: agents carry persistent, broad credentials that no one is actively managing.
JumpCloud addresses this with management and governance: two crucial pillars of the agentic lifecycle. Scoped credentials replace long-lived API keys. Just-in-time elevation replaces ambient authority. And Human-in-the-Loop (HITL) checkpoints require human approval before an agent executes high-risk actions. You define which actions require sign-off. The platform enforces it.
JumpCloud also binds agent trust to a managed device. The agent’s identity is tied to the endpoint it runs on. This gives IT leaders something identity-only platforms don’t: confirmation that the agent operates from a device your organization controls.
USE CASE
Here’s how management and governance shows up in your environment: that same commercial IT team’s financial data agent routes all payment-related actions through an HITL checkpoint. When the agent receives an instruction to initiate a transfer, the platform pauses execution and flags a human for approval. The manipulation that the Confused Deputy vulnerability enables cannot be completed, because there’s human oversight in the process. The attack surface narrows from the entire access grant to the specific actions that require human sign-off.
Governance built at this level doesn’t slow AI programs. It makes them predictable. And predictable programs scale.
Accelerate AI Adoption Without Expanding Risk
Organizations with governance in place are three times more likely to scale AI programs without limits. Governance is not a brake on AI adoption. It’s what removes the constraint on scale.
USE CASE
Consider an example of what happens without governance at the end of an agent’s operational life. A company’s customer service agent is deployed to handle tier-one support tickets. The project that funded this initiative ends.
The team moves to a new tool. The agent keeps running. No one updates its credentials. No one changes its access. It has a named owner. But that owner left the company six months ago.
This is officially a zombie agent: an abandoned agent still accumulating ambient authority, with no owner and no kill switch. Not a future risk. A current state.
With governance in place, this doesn’t happen. When a human employee offboards, JumpCloud triggers deprovisioning across connected systems. The same lifecycle applies to agents. An agent tied to a departing employee’s account follows the same offboarding process. So does any agent that has exceeded its operational window. Zombie agents don’t accumulate when every agent follows the same lifecycle as the human workforce.
With JumpCloud, every new agent is registered, scoped, and owned from day one. Retired agents are deprovisioned on the same timeline as a departing employee. There’s a complete, current picture of every identity in the environment: human, non-human, and agentic. No separate governance stack required.
When every identity in your environment is governed under the same platform, you have the signal and the controls to lead AI adoption with confidence. That is what JumpCloud’s Intelligent, Secure IT platform delivers.
What to Do Next
Your Zero Trust framework is one of the most important security investments your organization has made. The Identity Gap, the Access Gap, and the Accountability Gap stand between that investment and the AI programs you’re building on top of it.
The teams with the most durable AI programs are the ones who’ve built foundational governance into their deployments. It didn’t slow them down. It gave them the infrastructure to grow their programs without limits.
JumpCloud’s Intelligent, Secure IT platform is the foundation that empowers you to scale your AI agents without sacrificing your security standards. It’s shadow AI discovery alongside unified identity governance for every identity type, whether IT provisioned it or an employee did. One platform. One governance model. Every identity.
How 800+ IT Teams Govern AI
Understanding where you stand is the first step. Commercial organizations are deploying more AI while growing less confident in their ability to scale it. Find out what the organizations pulling ahead are doing.
Read More