A Question Most Leadership Teams Cannot Answer
Ask a CTO or a CISO how many employees their organisation has, and the answer comes instantly. Ask the same person how many non-human identities exist in their environment right now, and in most organisations, silence follows. Service accounts. API keys. OAuth tokens. Automation scripts. CI/CD pipeline credentials. And, increasingly, autonomous AI agents that log in, act, and spawn other agents entirely on their own.
Industry research in 2026 converges on an uncomfortable picture. Depending on the study, non-human identities now outnumber human ones by anywhere from 80 to 1 in a typical enterprise to well over 140 to 1 in cloud-native environments, and that ratio has roughly doubled in under two years. Some analyses put the average enterprise cloud estate at north of a quarter of a million non-human identities, the large majority carrying more privilege than the task actually requires. AI agents are the fastest-growing slice of that population, with projected growth outpacing both machine identities generally and human headcount by a wide margin.
This is not a niche infrastructure detail. It is the identity layer underneath every digital transformation, every AI adoption programme, and every cloud migration currently underway, and for most organisations, nobody owns it end to end.
The uncomfortable truth: the fastest-growing category of "user" in your organisation right now is not a person. It does not attend onboarding, does not get offboarded when a project ends, and does not appear on any org chart. It just accumulates.
How We Got Here: Three Waves of Automation
Non-human identities are not new. What has changed is the pace, the autonomy, and the privilege involved.
Wave 1: Service Accounts and Scripts
The first wave was straightforward: a scheduled job needs a database credential, a monitoring tool needs read access to logs, a backup script needs write access to storage. These accounts were created deliberately, usually one at a time, and while they were frequently over-privileged and rarely rotated, at least a human had made a conscious decision to create each one.
Wave 2: Cloud-Native and CI/CD Sprawl
The second wave arrived with microservices, containers, and continuous deployment. Every service now needs to authenticate to every other service. Every pipeline stage needs its own credentials. Infrastructure-as-code templates spin up new roles and service principals as a side effect of a deployment, often without anyone reviewing the permissions attached. This is the wave that pushed non-human identity counts from "more than headcount" to "orders of magnitude more than headcount."
Wave 3: Agentic AI
The third wave is happening now, and it is qualitatively different from the first two. An AI agent is not a static credential sitting quietly in a configuration file. It is an autonomous actor that requests permissions dynamically at runtime, calls external APIs on its own initiative, writes and executes code, and, in increasingly common architectures, spawns sub-agents to complete parts of its task. A single approved AI coding assistant, deployment agent, or customer-service bot can generate a cascade of downstream identities that nobody explicitly provisioned and nobody is explicitly tracking.
This is the layer where governance has fallen furthest behind reality. Recent industry surveys find that a meaningful share of organisations do not track the creation of AI-related identities at all, and a large majority of security leaders admit they lack confidence in their ability to prevent an attack that abuses one.
Why This Is a Business Problem, Not Just a Security Footnote
It is tempting to file non-human identity sprawl under "something the security team should handle." That framing misses the scale of the exposure. This sits at the intersection of technology architecture, operational resilience, and cost control, which is exactly why it belongs on the same agenda as your cloud strategy and your AI roadmap, not in a separate compliance binder.
It Is an Architecture Problem
How you design your AI agents, your microservices, and your cloud infrastructure determines how many non-human identities you create and how much privilege each one carries. Teams that adopt agentic AI without an identity architecture in place are, in effect, making hundreds of ad hoc access-control decisions per week without a review process. That is a technology design failure as much as a security one, and it is one we see repeatedly when reviewing client cloud environments and CI/CD pipelines.
It Is an Operational Resilience Problem
2026 has already delivered a reminder that the underlying cloud infrastructure everyone depends on is not infallible. A billing-console permissions flaw at a major hyperscaler exposed cross-account cost and usage data to customers who should never have seen it. Regulators across Europe have responded by formally designating the largest cloud providers as critical third parties subject to direct operational resilience supervision, precisely because so much of the economy, including large parts of the financial sector, now depends on a small handful of providers. Every non-human identity your organisation creates in that shared infrastructure is a thread connecting your operational resilience to theirs. The more of those threads exist without an owner, the harder it becomes to answer a simple regulatory question: what happens to our operations if this credential, this vendor, or this provider fails?
It Is a Cost Problem
Every unmanaged non-human identity, every orphaned service account, every AI agent quietly calling a paid API in a retry loop, is also a cost-control blind spot. Finance teams increasingly report AI-related cloud spend that has scaled faster than anyone modelled, in no small part because nobody has a clean inventory of what is actually calling what.
It Is a Software Supply Chain Problem
The same period has seen a critical, widely exploited vulnerability chain affecting hundreds of millions of websites built on common platforms, and a single monthly vendor patch cycle addressing well over 500 distinct vulnerabilities. Every one of those systems authenticates to something else using a non-human identity. Patch management, secure development practice, and identity governance are not three separate disciplines; they are three views of the same underlying exposure.
What Failure Actually Looks Like
Non-human identity failures rarely look like a Hollywood hack. They look mundane, right up until they are not.
Scenario 1: The Over-Privileged Coding Assistant
A development team adopts an AI coding assistant with access to the organisation's source repositories to speed up delivery, a genuinely sound decision on its own merits. The assistant is granted a broad access token "to avoid friction," rather than a scoped, task-specific one. Months later, a misconfigured integration or a compromised developer laptop exposes that token. Because it was never scoped down, the blast radius is not one repository, it is every repository the assistant could reach, plus every secret hardcoded inside them. Public repository scans in 2025 alone found tens of millions of exposed secrets, and AI-assisted coding tools have measurably accelerated that leakage, precisely because agents are fast at finding and reusing credentials that a human developer might have paused over.
Scenario 2: The Silent Sub-Agent
An organisation deploys an autonomous agent to triage and route customer support tickets. To handle a subset of requests, the agent is designed to spawn a specialised sub-agent with access to billing systems. Nobody registers the sub-agent as a distinct identity, so it inherits broad permissions from its parent rather than a narrowly scoped set of its own. Eighteen months later, an internal audit discovers the sub-agent has been active the entire time, its permissions were never reviewed, and nobody in the organisation can say with certainty who is accountable for what it has touched.
Scenario 3: The Forgotten Third-Party Integration
A finance department connects a spreadsheet automation tool to a cloud accounting platform via an API key, generated once, during a proof of concept two years ago. The project owner has since left the company. The key still works. It was never rotated, never scoped to read-only access, and never tied to an owner who would notice if it were misused. This is precisely the kind of orphaned credential that recent incidents at major professional services and support platforms have shown attackers actively hunting for: not the front door, but the side door nobody remembered was unlocked.
Why Traditional Identity Management Does Not Solve This
Most identity and access management programmes were designed around humans: a person joins, a manager approves access, HR triggers offboarding, and periodic access reviews catch drift. Apply that model to non-human identities and it breaks down on almost every assumption.
- There is no HR trigger. A service account or an AI agent is not "hired" or "terminated" through a process anyone monitors. It is created by a deployment script and often outlives the project, the team, or even the vendor relationship that justified it.
- Multi-factor authentication does not apply. A machine cannot be asked for a second factor at 2 a.m. Non-human identities typically rely on static secrets, which is exactly why secrets management, not password policy, is the control that matters here.
- Ownership is rarely assigned at creation. A human account has a named owner from day one. A service principal spun up as a side effect of an infrastructure template frequently does not, and by the time anyone asks "whose is this," the honest answer is often "nobody knows."
- Privilege is requested dynamically, not provisioned once. An autonomous agent can acquire new permissions at runtime as it chains tasks together, which means a snapshot access review taken today can be meaningfully out of date within days.
A Practical Non-Human Identity Governance Framework
We work with clients across technology and security functions to close this gap using a framework built around five practical dimensions, deliberately designed so that a technology team and a security team can execute it jointly rather than in separate workstreams.
Dimension 1: Discovery and Inventory
You cannot govern what you cannot see. The starting point is always a full inventory: every service account, API key, OAuth grant, service principal, and AI agent, across every cloud account, SaaS platform, and CI/CD system in use. Most organisations that run this exercise for the first time are surprised, and rarely pleasantly, by the count.
Dimension 2: Ownership and Lifecycle
Every non-human identity should have a named human or team owner, a documented purpose, and a defined lifecycle: a creation date, an expected review date, and a deprovisioning trigger tied to the project or system it supports. An identity without an owner is an identity nobody will notice being misused.
Dimension 3: Least Privilege and Just-in-Time Access
Default to the narrowest scope a task requires, and prefer short-lived, just-in-time credentials over long-lived static ones wherever the architecture allows it. For AI agents specifically, this means explicit permission boundaries per agent and per sub-agent, with high-impact actions gated behind human approval rather than granted by default.
Dimension 4: Secrets Management and Rotation
Hardcoded credentials in source code, configuration files, or CI/CD pipelines should be treated as an incident waiting to happen, because the data consistently shows they are exactly that. A managed secrets vault with automated rotation closes the largest single gap we see in client environments.
Dimension 5: Monitoring and Behavioural Baselines
Human identity monitoring looks for anomalous logins. Non-human identity monitoring needs to look for anomalous behaviour: a service account suddenly accessing data outside its normal pattern, an AI agent making calls to APIs it has never used before, a credential authenticating from an unexpected location or at an unexpected volume. This is where cyber monitoring and AI governance genuinely converge into a single capability.
Where to Start, in Practice
- Run a non-human identity discovery pass across your cloud and SaaS estate. Treat the first result as a baseline, not a target; the point is to know the true number before you try to reduce it.
- Identify and remediate orphaned credentials first. Accounts with no clear owner are the highest-risk, lowest-effort fix: disable, rotate, or delete.
- Assign ownership going forward as a hard requirement. No new service account, integration, or AI agent should be provisioned without a named owner and a documented purpose, enforced through your deployment process, not a policy document nobody reads.
- Bring AI agent deployment into the same governance process as any other production system. If a new microservice would require an architecture review, a new AI agent with system access should too.
- Deploy a secrets manager if you have not already. This is one of the highest-return, lowest-disruption steps available and should not wait for a broader programme to be designed.
- Extend monitoring to cover non-human behaviour, not just human logins. If your current monitoring stack cannot answer "what did this service account do differently this week," that is a gap worth closing before it is tested by an incident.
The Luxembourg and European Context
For organisations operating in Luxembourg's financial services, fund administration, and professional services sectors, non-human identity governance is not an abstract best practice, it increasingly intersects directly with supervisory expectations. DORA's ICT risk management requirements apply to the systems and credentials your AI agents and automated pipelines depend on, not only to the applications your employees log into by hand. As European regulators formalise oversight of the hyperscale cloud providers that host most of this infrastructure, and as the EU's broader push for technology sovereignty reshapes where sensitive workloads can run, organisations that already have a clean, owned inventory of their non-human identities are simply better positioned to answer the questions a regulator, an auditor, or an insurer will eventually ask.
The same applies to the growing number of Luxembourg businesses accelerating AI adoption, including through the SME Package AI subsidy programme. A well-governed AI deployment and a well-governed non-human identity estate are, in practice, the same project viewed from two angles.
Technology and Security, Not Technology or Security
Non-human identity governance sits precisely where our own practice does: at the intersection of building the technology (cloud architecture, DevSecOps pipelines, AI agent deployment) and securing it (identity governance, risk assessment, monitoring). Treating these as separate projects run by separate teams is exactly how organisations end up with 250,000 unmanaged identities and no clear answer to "who owns this."
If your organisation is adopting AI agents, scaling cloud infrastructure, or simply cannot currently answer how many non-human identities exist in your environment, that is a conversation worth having before an audit, an incident, or a regulator forces the issue. We would be glad to help you map the exposure and build a governance programme that fits how your technology teams actually work.
