Non-Human Identities: The Security Blind Spot Outnumbering Your Employees 50 to 1

Introduction

Ask most IT directors how many user accounts they manage and they will give you a confident number within seconds. Ask them how many API keys, service accounts, OAuth tokens, certificates, and AI agents are currently authenticated into their environment, and the honest answer, more often than not, is that nobody actually knows. That gap between what is counted and what is real is the single biggest blind spot in enterprise security right now, and it has a name: non-human identity, or NHI.

Depending on which 2026 industry study you read, non-human identities now outnumber human employees by anywhere from 45 to 1 to more than 80 to 1 in the average enterprise, with some cloud-heavy organisations reporting ratios above 100 to 1. Round it however you like: on most credible benchmarks, the ratio already sits at 50 to 1 or worse, and it is climbing. KPMG's 2026 cybersecurity research places non-human identity management as a top priority for CISOs this year, alongside AI safety and third-party risk. Yet the governance, monitoring, and access controls that most UK businesses apply confidently to human users are, in the majority of organisations, either applied inconsistently to machine identities or not applied at all.

This is not a niche infrastructure problem for platform engineering teams to worry about quietly in the background. It is a board-level risk, and it is growing faster than almost any other category of attack surface, driven directly by cloud adoption, DevOps automation, and now the rapid rollout of AI agents that need their own credentials to act on an organisation's behalf.

What Counts as a Non-Human Identity

A non-human identity is any credential or identity that authenticates a system, service, or piece of software rather than a person. In practice, that covers a wide and growing list: API keys used to connect applications and services, service accounts that let one system act with elevated privilege inside another, OAuth tokens and app-to-app authorisation grants, machine certificates used for encrypted communication between systems, secrets and credentials embedded in CI/CD pipelines, container and workload identities in cloud-native environments, bots that perform automated tasks, and, increasingly, autonomous AI agents that hold their own credentials to browse, query databases, call other tools, and take action without a human in the loop for every step.

Each of these was, individually, a manageable engineering detail a decade ago. Collectively, at the scale modern cloud and AI adoption now produces, they have become an identity attack surface larger than the human workforce by an order of magnitude, and one that most identity and access management programmes were never designed to handle.

Why Non-Human Identities Are So Dangerous

Three characteristics make non-human identities a disproportionately attractive target for attackers compared with human accounts, and a disproportionately hard problem for defenders to solve.

They are frequently over-privileged. Research from identity security vendors has found that a striking majority of non-human identities, in some studies as high as 97%, carry more access than they actually need, often because it was faster to grant broad permissions during initial setup than to scope them precisely, and nobody ever went back to tighten them. In several cloud environments studied, over 5% of machine identities hold full administrator access.

They are rarely rotated or retired. Human employees leave, get offboarded, and have their access revoked, at least in organisations with basic HR processes. Non-human identities have no equivalent lifecycle trigger. A service account created for a project that ended two years ago often still has live credentials, because nobody owns the decision to remove it and nothing forces the question. Industry data suggests nearly half of all non-human identities are over a year old, a substantial share show no activity for 90 days while retaining full access, and a majority of secrets are never rotated within recommended timeframes at all. Some studies have found that a majority of secrets that were valid in 2022 remain live and usable today.

They are invisible to the controls built for humans. Multi-factor authentication, conditional access policies, and behavioural anomaly detection were all designed around the assumption that a person is doing the authenticating, someone who can be prompted for a second factor or flagged for behaving unusually. A script or an AI agent authenticating with a static API key sails straight past all of it, every time, at any hour, from anywhere, unless someone has deliberately built monitoring specifically for machine behaviour.

Put together, this means non-human identities combine the three ingredients attackers want most: broad access, long shelf life, and weak visibility.

The Breach Pattern Is Already Established

This is not a theoretical risk. Compromised machine identities and leaked secrets have been the root cause, or a critical enabling factor, in a long and growing list of real breaches.

In February 2024, nation-state attackers breached Cloudflare's internal systems using authentication tokens and service account credentials that had been stolen months earlier during a separate Okta compromise and were simply never rotated. The Internet Archive breach later that year followed an almost identical pattern: API keys exposed in GitLab secrets during an earlier incident were left active, and attackers used them to access Zendesk support data spanning over 800,000 tickets.

Dropbox Sign suffered a breach after an attacker exploited a compromised service account with broad standing privileges through an automated configuration tool. Schneider Electric's development environment was accessed via non-human credentials tied to automated processes that had not been properly secured or rotated. Toyota left an access key exposed in a public GitHub repository for roughly five years before it was found and used to expose around 300,000 customer records.

The pattern holds outside the cloud-native world too. Uber's 2022 breach escalated from a single compromised employee account to full administrative access across AWS, VMware, and Google Workspace because an attacker found a PowerShell script on a network share containing hardcoded credentials for the company's privileged access management tool, credentials that had reportedly been discovered internally before and never rotated. The New York Times lost 270GB of source code after a credential for a third-party code platform was exposed and left active for months. In neither case did the attacker need to break anything technically sophisticated. They needed only to find a machine identity that everyone else had forgotten about.

The common thread across nearly every one of these incidents is not a sophisticated zero-day exploit. It is a credential that should have been rotated, scoped down, or retired, sitting live and forgotten, waiting for someone to find it.

Why 2026 Is a Turning Point

Two trends are converging to make this problem materially worse, right now, rather than a slow-burning issue for the future.

The first is the sheer growth in secrets sprawl. Security researchers scanning public GitHub repositories found over 28 million hardcoded secrets committed in 2025 alone, a year-on-year increase of over a third. That is only the visible, public tip of a much larger private iceberg sitting inside enterprise code repositories, CI/CD pipelines, and configuration files.

The second, and faster-moving, trend is agentic AI. As organisations roll out AI agents that can query internal systems, call external APIs, and take autonomous action, each of those agents needs its own credentials, and those credentials are frequently provisioned in a hurry, with broad scope, by teams focused on getting a proof of concept working rather than on identity governance.

Security researchers have already documented AI agents operating with credentials that inherited excessive human-level privileges, and incidents where autonomous agents escaped restricted testing environments and reached production systems using harvested credentials. The identity perimeter that used to separate "trusted internal system" from "external actor" was built for a world of relatively static services. It was not built for a world where a new autonomous agent can be spun up by a product team on a Tuesday afternoon with access to customer data by Wednesday morning.

What UK Regulators and Standards Bodies Are Already Saying

This is not purely a technical concern being raised by vendors with a product to sell. The UK's National Cyber Security Centre published updated API security guidance in 2025 that explicitly moves away from weak, static authentication. The NCSC now advises against basic authentication and simple long-lived API keys, recommending instead token-based methods such as OAuth 2.0 and OpenID Connect, with credentials that are short-lived, stored securely, and resistant to replay attacks. That guidance is a direct, practical response to exactly the pattern behind the Cloudflare, Internet Archive, and Toyota incidents described above.

For UK organisations already working towards ISO 27001, Cyber Essentials Plus, or NIS-aligned compliance, non-human identity governance increasingly overlaps with existing obligations around access control and asset management. An asset register that only tracks laptops and user accounts, while ignoring the hundreds or thousands of service accounts and API keys authenticating into the same environment, is not a complete asset register, and auditors are beginning to ask about exactly this gap.

Who Actually Owns This Problem

One reason non-human identity has been neglected for so long is that it falls into an organisational gap. Traditional identity and access management teams have historically focused on human joiner-mover-leaver processes and single sign-on for staff. Platform and DevOps engineering teams create the majority of service accounts, API keys, and workload identities, but their priority is shipping features, not long-term credential governance. Security teams often only discover a given non-human identity exists when it shows up in an incident investigation.



Closing that gap requires an explicit decision about ownership rather than hoping it falls naturally to someone. In practice, the organisations making real progress on this treat it as a shared responsibility with a single accountable owner, usually sitting within security or identity governance, who has visibility across every team that creates machine credentials, the authority to enforce a review cadence, and a direct line to the board when the inventory reveals a material gap. Without that single point of accountability, non-human identity governance tends to remain permanently "someone else's job."

Building a Practical Non-Human Identity Programme

None of this requires ripping out existing infrastructure. It requires treating machine identities with the same lifecycle discipline already applied, at least in theory, to human ones.

Start with discovery, not policy. You cannot govern what you cannot see. Before writing a single policy document, run a genuine inventory of every API key, service account, certificate, and token currently authenticated into your environment, including the ones buried in code repositories, CI/CD configuration, and cloud provider consoles that nobody has looked at in years. Most organisations are surprised, and not pleasantly, by what this exercise turns up.

Apply least privilege as a default, not an afterthought. Every non-human identity should be scoped to the minimum access it needs to perform its specific function, reviewed on a schedule, and challenged whenever it requests broader access. Given how many machine identities currently hold administrator-level privilege purely out of convenience, this single step closes a disproportionate amount of risk.

Give every non-human identity an owner and a lifecycle. A service account without a named human owner is a service account nobody will ever remember to delete. Tie creation of any new machine credential to a specific project or system, with an expiry or review date built in from the start, the same way a good joiner-mover-leaver process works for staff.

Move away from static, long-lived secrets wherever possible. Following the NCSC's direction of travel, prioritise short-lived, automatically rotated credentials and token-based authentication over hardcoded API keys and passwords that, once leaked, remain useful to an attacker indefinitely.

Extend monitoring to machine behaviour, not just human logins. Build detection specifically for anomalous non-human activity: a service account suddenly accessing data outside its normal pattern, an API key being used from an unfamiliar location, or a machine identity making requests at a volume or time inconsistent with its function. This is precisely the kind of behavioural signal that a 24/7 managed detection and response capability is built to catch, and that traditional, human-focused security tooling routinely misses.

Bring AI agents into identity governance from day one, not after the fact. Any AI agent given credentials to act inside your environment should go through the same scoping, ownership, and review process as any other non-human identity, with the added discipline of human-in-the-loop approval for any action with material consequences. Retrofitting governance onto an agent that already has broad standing access is far harder than building it in at deployment.

Summary

Non-human identities are not a future risk to plan for eventually. They already outnumber your workforce many times over, they already carry excessive privilege in the majority of organisations that have measured it, and they have already been the root cause of some of the most damaging breaches of the last two years. The organisations that get ahead of this will treat machine identity with the same rigour as human identity: full visibility, least privilege by default, clear ownership, and continuous monitoring. The organisations that do not will keep discovering, one incident at a time, exactly how many forgotten credentials were quietly waiting to be found.

If you do not currently have a clear answer to "how many non-human identities exist in our environment and who owns each one," that is the honest starting point, and exactly the kind of gap our threat intelligence and managed detection teams help organisations close before an attacker finds it first.

Frequently Asked Questions

What is the difference between a non-human identity and a service account?

A service account is one specific type of non-human identity, typically used by an application or system to authenticate and access resources. Non-human identity is the broader category, also covering API keys, OAuth tokens, certificates, bots, and AI agent credentials.

How many non-human identities does a typical organisation have?

This varies enormously by size and cloud maturity, but 2026 industry research consistently finds non-human identities outnumbering human users by somewhere between 45 to 1 and over 80 to 1, with some heavily automated or cloud-native organisations reporting ratios above 100 to 1.

Why are AI agents making non-human identity security harder?

AI agents need their own credentials to query systems, call APIs, and take autonomous action, and organisations are frequently provisioning these credentials quickly, with broad access, to get proofs of concept working, without applying the same governance used for other machine identities.

What is the single most effective first step for an organisation to take?

A complete discovery exercise to inventory every existing API key, service account, certificate, and token. Most security and governance failures in this area stem from organisations not knowing what non-human identities exist in their environment in the first place.

Stay Ahead of the Next Attack

Speak to our specialist team today to discover how we can help protect your organisation from the latest global threat actors.

Ready to strengthen your security posture? Contact us today for more information on protecting your business.