AI Confidence Just Fell 17 Points. Non-Human Identity Governance Is Why.
A 17-point drop in self-reported AI maturity sounds like bad news. It isn’t. It’s what happens when IT leaders stop grading their AI programs on ambition and start grading them on evidence.
VentureBeat’s Q3 2026 trends survey, drawn from 800 IT leaders across the United States and United Kingdom, found that the share of respondents willing to call their organization “mature” in AI deployment fell from 40% six months earlier to 23% today. That’s not a sign that AI programs got worse. It’s a sign that the people running them finally looked closely enough to see what was actually there: agents deployed without owners, permissions that were never revisited, and a non-human workforce that grew faster than anyone tracked it.
The number driving that reassessment is stark. Non-human identities, meaning service accounts, API keys, and AI agents acting on behalf of employees and systems, now outnumber human users at 83% of the organizations VentureBeat surveyed. And the control measured least often in place to manage them, non-human identity governance, sits at just 21% adoption, the lowest of any AI security practice in the survey. Put those two figures together and the picture is unambiguous: most enterprises have more machine identities than people, and fewer than one in four have a real governance program covering them.
That’s also why this survey matters to Kiteworks. Kiteworks secure data exchange gives organizations a governed control point for how sensitive data moves between humans, systems, and AI agents, instead of leaving that traffic to sprawl across shared credentials and ungoverned connections. The confidence drop isn’t a setback. It’s a signal that the real work, closing the non-human identity gap, is only now getting started.
Key Takeaways
1. AI maturity self-assessments collapsed in six months.
VentureBeat’s Q3 2026 trends survey of 800 IT leaders across the US and UK found that the share describing their organization as “mature” in AI deployment fell from 40% to 23%, a 17-point drop that signals leaders are finally grading their programs against reality rather than ambition.
2. Non-human identities have already overtaken human users.
At 83% of organizations surveyed, machine and agent identities now outnumber the humans on staff, yet the controls built to manage human accounts were never designed for a workforce that spins up new identities by the hour.
3. Governance for those identities is the least mature control measured.
Only 21% of organizations have non-human identity governance in place, making it the biggest single gap in VentureBeat’s AI security maturity model, and the one most enterprises have yet to even scope.
4. Maturity correlates directly with the ability to scale.
Organizations in the survey’s top maturity tier were five times more likely to report no barriers to expanding their AI agent deployments, turning governance from a compliance checkbox into a growth lever.
5. Credential sharing is the default, not the exception.
Without per-agent identity and access controls, most organizations still route AI agents through shared service accounts or human credentials, a pattern that erases the audit trail the moment something goes wrong.
You Trust Your Organization is Secure. But Can You Verify It?
The 17-Point Drop: What Changed Between Two Surveys, Six Months Apart
Six months ago, 40% of the IT leaders VentureBeat surveys described their organization’s AI deployment as mature. In the Q3 2026 survey, that number is 23%. Read as a standalone figure, a 17-point decline looks like AI programs are regressing. Read against everything else that changed over those six months, it tells a different story.
Most enterprises didn’t slow down their AI rollouts in that window. They sped up. Departments kept standing up agents for customer support, coding help, document processing, internal research, pretty much any use case someone could justify. Vendors kept shipping agentic features turned on by default. And with each new deployment, another non-human identity entered the environment, usually without anyone filing a formal request, getting a sign-off, or being named as its owner. Confidence should have fallen in that environment, because the people closest to these deployments could see the governance work wasn’t keeping pace with how fast the identities were piling up.
That’s the healthier read of the data. A maturity score that kept climbing while non-human identity governance sat at 21% adoption would actually be the worse sign, because it would mean IT leaders were grading their programs against a scorecard that ignored the fastest-growing category of risk in the building. A score that falls as leaders discover how much ground they haven’t covered means the assessment itself got more rigorous. VentureBeat frames it about right: the drop shows organizations auditing themselves honestly instead of confidently, which has to happen before anyone can close the gap the survey exposes.
This distinction matters for how security and compliance teams should present these findings internally. A board member or CFO who sees “AI maturity fell 17 points” without context may read it as evidence that AI investment isn’t paying off. The more accurate framing, and the one worth bringing into budget conversations, is that the organization’s AI data governance program is now being measured against the actual scope of non-human identity growth, not the far smaller scope that existed when the last assessment was taken. A formal risk assessment that maps every agent currently running against its current permissions and its actual business justification gives compliance teams the evidentiary baseline they need to close gaps strategically rather than reactively.
Non-Human Identities Have Quietly Become the Majority
The statistic that should reorder every AI security roadmap for 2026 is this one: non-human identities now outnumber human users at 83% of organizations surveyed. That’s not a niche finding about a handful of AI-forward companies. It’s the norm.
Every AI agent an organization deploys typically needs its own identity, or more often, inherits someone else’s. Every API integration between a large language model and an internal system needs credentials. Every automated workflow that pulls a document, summarizes a contract, or drafts an email on a human’s behalf runs under some identity, whether that identity was deliberately provisioned or borrowed from whatever service account happened to be lying around. Multiply that across customer support bots, coding copilots, document summarization agents, internal research assistants, and the growing list of vendor tools that ship agentic features turned on by default, and it becomes clear why the non-human identity count in an enterprise adopting agentic AI at any real scale can climb well past the human headcount within a matter of months.
Most identity and access management programs were never built for this. IAM systems, access controls, and provisioning workflows were designed around a predictable rhythm: an employee joins, gets an account, gets access mapped to their role, and eventually leaves, at which point the account gets deprovisioned. Non-human identities don’t follow that lifecycle. An agent can be spun up in an afternoon by a developer testing a new integration, granted broad access to move fast, and then left running indefinitely because retiring it was never anyone’s job. There’s no HR system tracking when an agent started, and usually nobody who can say with confidence how many are even running or what they can reach. The CISO Dashboard provides the unified, real-time visibility across all AI-mediated data access events that makes this agent inventory visible to security leadership — the prerequisite for any governance program that aims to manage what it cannot currently see.
That’s the structural reason non-human identity governance lags every other AI security practice in VentureBeat’s survey. It isn’t that security teams don’t care about it. It’s that the tooling and processes most organizations rely on for identity governance were built around a human headcount that stayed relatively flat and predictable, and non-human identity growth breaks every assumption that model depends on.
Why Non-Human Identity Governance Is the Least-Adopted AI Security Practice
Of every AI security practice VentureBeat measured, non-human identity governance came in at the bottom, with just 21% of organizations reporting it’s in place. That ranking is worth sitting with, because it means the control most directly tied to the fastest-growing category of identities in the enterprise is also the one organizations have been slowest to build.
A few things converge to produce that gap. Non-human identity governance needs a different mental model than the human kind: a human employee’s access can be scoped to a role that rarely changes, while an AI agent’s needs can shift task by task, and an agent that’s over-permissioned “just in case” creates risk that compounds every time it runs, not only when someone provisions it. Most organizations also don’t keep a system of record for agents the way they do for employees, so governance can’t really start; you can’t govern what you can’t see. And responsibility for AI agents cuts across teams that don’t normally coordinate closely, security, data governance, application development, and whichever business unit asked for the agent in the first place, so each one tends to assume someone else owns the problem.
The consequence of leaving that 79% gap unaddressed isn’t abstract. An ungoverned agent sitting on standing access to a file repository, a CRM, or a document management system is exposure, whether or not anyone ever misuses it. Its credentials could be exfiltrated. Its permissions typically outlive whatever task they were granted for. And when it acts without a clear audit trail, a compliance team has no way to reconstruct what happened after the fact. Zero trust architecture, verify explicitly, grant least privilege, assume breach, applies just as directly to a non-human identity as to a human one. Most organizations haven’t extended that model to cover agents yet. Data minimization applied to agent permissions — provisioning each agent with access only to the specific data sources its designated task requires — is the operational implementation of least-privilege for non-human identities, and it directly reduces blast radius when an agent credential is exfiltrated or misused.
The Credential-Sharing Trap: How Shared Access Multiplies Risk
When an organization hasn’t built dedicated identity governance for its AI agents, the default fallback is almost always the same: agents inherit credentials from somewhere else. Picture a common, generic pattern playing out inside most enterprises right now: a developer reuses a service account that already has broad database access because provisioning a scoped one takes too long, an agent gets a copy of a human employee’s API token so it can pull data on that employee’s behalf, or a vendor’s agentic feature ships with a default integration credential that has more reach than the specific task requires.
Each of those shortcuts solves an immediate problem and creates a durable one. Shared credentials mean shared blast radius: if a single service account is compromised, every agent using it is compromised too, and every system that account can reach is exposed, not just the one the agent was meant to touch. They also erase accountability. When three different agents and two automated workflows all authenticate as the same service account, an audit log showing that account touched a sensitive file tells you nothing about which agent did it, what task it was running, or whether the access even made sense. That’s the opposite of what regulators and internal risk teams expect from an audit trail, and it’s precisely the failure mode non-human identity governance is supposed to prevent. A confirmed data breach routed through a shared service account that multiple agents use creates an exfiltration scope that no organization can confidently bound — notification obligations under HIPAA, GDPR, or comparable frameworks apply to the maximum possible scope unless affirmative evidence exists to narrow it.
Shadow AI makes this worse. Employees adopting AI tools on their own, outside any sanctioned deployment, routinely paste sensitive data into consumer AI interfaces or connect personal AI tools to corporate systems using their own credentials. Each of those unsanctioned connections is effectively another non-human identity the organization doesn’t know exists and can’t govern. Data loss prevention programs built around monitoring known applications and known egress points have limited visibility into what an ungoverned agent does with data once it’s inside, which is exactly why identity-level governance has to be part of the answer, not just content-level monitoring. A SIEM platform ingesting real-time agent access telemetry from governed connection points provides the behavioral baseline that makes anomalous agent activity detectable before it escalates to a breach-scope event.
What Separates the Top Tier: Governance as a Growth Enabler
The most useful finding in VentureBeat’s survey isn’t the confidence drop itself. It’s what the data shows about the organizations at the top of the maturity curve. Those organizations were five times more likely than the average respondent to report no barriers to expanding their AI agent deployments.
That correlation reframes the whole governance conversation. The intuitive assumption is that governance slows AI adoption down, that every control added between an agent and the data it needs to reach is friction standing between the business and the value AI promises. The survey data says the opposite happens at scale. Organizations that built real governance around their non-human identities, meaning they can see every agent, scope its access to what its task actually requires, and audit what it did, are the ones best positioned to add more agents without hitting a wall. Governance isn’t holding them back. It’s what let them keep scaling, because they’d already solved the problem everyone else is still stuck on: knowing what they have and controlling what it can touch.
Organizations without that foundation hit a different kind of ceiling. They can deploy their first handful of agents relatively easily, often by borrowing existing credentials and access, because the risk of doing so hasn’t caught up with them yet. But every additional agent deployed on that same ungoverned foundation adds risk faster than it adds value, until security, legal, or compliance teams step in and slow the whole program down precisely because no one can answer basic questions about what’s already running. That’s the barrier the top-tier organizations in VentureBeat’s survey have already cleared, and it’s a direct argument for building non-human identity governance early rather than retrofitting it after an incident forces the issue. Kiteworks provides the unified governance environment — one policy engine, one audit trail across all AI-mediated and human content flows — that makes scaling agents without hitting a compliance wall an operational reality rather than a planning aspiration.
Closing the Gap: What Per-Agent Access Governance Actually Requires
Getting non-human identity governance from 21% adoption to something closer to universal requires a different starting point than most existing IAM investments provide: treating every AI agent as its own governed identity, not as an extension of whatever human or service account happened to grant it access.
That starts with visibility. An organization can’t govern agents it doesn’t know exist, which means the first step is establishing a real inventory of every agent with access to sensitive data or systems, who requested it, what it can reach, and why. From there, access has to be scoped per agent and per task rather than inherited wholesale. An agent that summarizes contracts doesn’t need write access to the systems that store them. An agent that answers customer questions doesn’t need the same reach as the support team’s full CRM permissions. Attribute-based access control and role-based access control models both offer a path to that scoping, but only if they’re applied to agents deliberately rather than defaulted around. Applying data classification labels to the content agents can access — so that policy engines can enforce sensitivity-based restrictions at every request — is the prerequisite that makes ABAC governance precise rather than approximate.
Every interaction also needs to be logged at the agent level, not the shared-credential level, so that when a compliance team or auditor needs to reconstruct what happened, the answer is a specific agent’s specific action rather than a shrug and a shared service account. This is the design principle behind the Secure MCP Server, which gives AI agents a governed, audited connection point into an organization’s sensitive content rather than a standing, unscoped credential. Instead of an agent inheriting a human’s access or a broad service account’s reach, it authenticates through OAuth 2.0 with tokens held in the operating system’s credential store rather than exposed to the AI model itself, with every request evaluated against RBAC and ABAC policy in real time and rate limiting in place to contain what any single agent can extract.
The same principle extends to how organizations govern what data an AI model or agent can actually see and act on in the first place. Kiteworks Compliant AI enforces policy at the point where sensitive content meets an AI system, applying data classification and a data policy engine so that access decisions are made per request rather than assumed from a broad, standing grant. That combination, a governed access point for agents plus policy enforcement at the data layer, is what turns “non-human identity governance” from a survey category into an operational reality: every agent has its own identity, its own scoped permissions, and its own audit trail, and none of them are borrowing a human’s credentials to get their job done.
None of this requires organizations to slow down AI adoption to get there. It requires building the governance layer alongside the agents, rather than after them, which is exactly what separates the top-tier organizations in VentureBeat’s survey from the average respondent still waiting for a governance program to catch up with an agent population that’s already outgrown it.
To learn more about closing the non-human identity governance gap with per-agent access controls and audited AI connections, schedule a custom demo today.
Frequently Asked Questions
The drop reflects a more honest self-assessment, not a reversal in AI adoption. As non-human identities and AI agents proliferated across organizations, IT leaders got a clearer view of how much AI data governance work remained unfinished, and the maturity scores fell to match that reality rather than the earlier, more optimistic estimate. Adoption of AI tools continued to climb over the same period; what changed was how rigorously leaders graded their own governance against it. Organizations subject to regulatory compliance obligations — HIPAA, GDPR, CMMC — should use this survey as an external prompt to conduct a formal risk assessment of their own non-human identity posture, since regulators will eventually evaluate AI data access governance under the same frameworks that govern human user access.
Non-human identity governance refers to the policies, tools, and processes used to inventory, scope, monitor, and retire the identities assigned to AI agents, service accounts, and API integrations, as distinct from the identities assigned to human employees. It covers questions like who owns a given agent, what data and systems it can reach, whether that access matches its actual task, and whether its activity is logged in a way that supports an audit. Kiteworks addresses this through access controls and governed connection points that scope agent access per task rather than granting broad, standing permissions. Supply chain risk management programs should extend this governance to AI agents provisioned by third-party vendors — a vendor-deployed agent operating inside your environment under broad credentials is a supply chain risk that most current vendor governance frameworks do not explicitly address.
Every AI agent, automated workflow, and system-to-system integration typically requires its own identity to authenticate and operate, and organizations have been deploying these at a much faster rate than they hire employees. A single business unit adopting agentic AI for customer support, document processing, or coding assistance can add dozens of non-human identities in the time it takes to onboard one new employee, which is why VentureBeat found this majority already in place at 83% of organizations surveyed. Most identity and access management programs were not designed around that growth rate. Data governance frameworks that explicitly include non-human identities — with defined owners, access scope reviews, and retirement procedures — are the organizational mechanism for extending IAM disciplines to an identity population that grows faster than HR-driven provisioning processes can track.
The survey data suggests the opposite. Organizations in the top maturity tier, the ones with the most mature governance in place, were five times more likely to report no barriers to expanding their AI agent deployments, because they already have the visibility and access controls needed to add agents without introducing unmanaged risk. Organizations without that foundation tend to hit a wall later, when security or compliance teams have to intervene precisely because no one can account for what’s already running, which is a far more disruptive slowdown than building governance in from the start. Building that foundation early, rather than retrofitting it after agents are already running unchecked, is the difference between managing AI risk proactively and reacting to it under pressure. An incident response plan that explicitly covers agent misfire and credential exfiltration scenarios — with defined rollback procedures and regulatory notification thresholds — is the operational complement to the governance architecture: it defines what happens after detection, not only how detection works.
Start with an inventory: identify every AI agent, service account, and integration that currently has access to sensitive systems or data, and confirm who owns each one and why it has the access it has. From there, move toward scoping each agent’s permissions to its specific task rather than inheriting broad, shared credentials, and route agent access to sensitive content through a governed connection point like the Secure MCP Server so every action is logged against a specific, accountable identity rather than a shared one. Data classification of the content agents can access is the prerequisite that makes ABAC-based access scoping enforceable — without it, a policy engine cannot apply sensitivity-based restrictions to agent requests. Feeding the resulting agent access logs in real time into a SIEM platform gives security teams the behavioral baseline needed to detect anomalous agent activity before it escalates to a reportable breach.
Additional Resources
- Blog Post
Zero‑Trust Strategies for Affordable AI Privacy Protection - Blog Post
How 77% of Organizations Are Failing at AI Data Security - eBook
AI Governance Gap: Why 91% of Small Companies Are Playing Russian Roulette with Data Security in 2025 - Blog Post
There’s No “–dangerously-skip-permissions” for Your Data - Blog Post
Regulators Are Done Asking Whether You Have an AI Policy. They Want Proof It Works.