Part 1 of 5 in a series on non-human identity.

Ask any IAM team how many people work at their organisation and they’ll tell you within a few percent. HR feeds the directory, the directory feeds the apps, leavers get disabled on Friday.

Now ask how many service accounts, API keys, certificates, cloud roles, pipeline tokens and application identities exist across the same estate.

You’ll get a pause. Then a guess. Then “it depends what you count.”

That pause is the whole problem.

The identities nobody hired

Every one of those non-human identities was created for a reason. A developer needed a database connection. A platform team needed a deployment pipeline. A vendor integration needed an API key. Someone stood up a cloud role so a workload could reach a bucket.

None of them went through a joiner process, because there was no joiner. None of them will go through a leaver process, because nothing ever leaves. The developer who created the database account moved teams in 2021; the account is still there, still privileged, password unchanged since the day it was created.

Multiply that across ten years of projects, three cloud providers and a few hundred SaaS integrations, and you get the number most organisations are surprised by when they finally count: somewhere between ten and fifty non-human identities for every human one. In a bank I worked with, the secrets platform held more credentials than the company had employees, and a meaningful share had no identifiable owner at all.

Why your IAM programme can’t see them

This isn’t negligence. It’s a design blind spot.

Enterprise IAM was built around the human lifecycle. Join, move, leave. Identity governance tools certify access by asking a manager “does this person still need this?” Privileged access tools vault admin passwords and record sessions.

Non-human identities break every one of those assumptions. There’s no manager to ask. There’s no session to record when a pipeline runs at 3am. There’s no HR event to trigger removal. And they’re created in places IAM has never been in the loop: Terraform modules, Kubernetes manifests, CI/CD variables, a vendor’s onboarding form.

So the IAM team governs what it can see, the platform teams create what they need, and the gap between them is where the risk lives. The identities in that gap belong to nobody, which means in practice they belong to whoever compromises them first.

Why it matters more now than it did a year ago

Three things have changed.

First, attackers noticed. The pattern in a growing number of recent breaches isn’t a phished employee; it’s a long-lived token or service credential, harvested from a repository or a build system, used quietly for weeks. Nobody’s MFA fired, because nothing human logged in.

Second, regulators noticed. In the UK, operational resilience and SM&CR expectations increasingly translate into a simple audit question: who owns this account, and when was that ownership last confirmed? “Nobody” is not an answer an audit committee accepts twice.

Third, AI agents arrived. Every Copilot, every agent framework, every “let the model call the tool” integration is a new non-human identity, often with broader access than any human on the team, created by people who have never met the IAM function. Organisations that never got service accounts under control are now adding a class of identity that reads, writes and acts, at machine speed. That’s the subject of a later post; for now the point is that the old problem just got a deadline.

A ten-minute check

You don’t need a discovery tool to find out whether you have this problem. Ask five questions and count the honest answers:

1. Can you produce a list of every service account with a named, current owner?

2. Do you know which of your API keys and tokens have no expiry?

3. When a member of the platform team leaves, does anything happen to the credentials they created?

4. Are non-human identities included in your access certification cycle?

5. Does your Copilot or AI agent rollout have an identity design, or just an integration?

Fewer than three confident yeses, and you have a non-human identity programme. It’s called “nobody”, and it’s running in production.

What comes next

The fix isn’t a product. It’s applying the discipline you already have for humans (ownership, lifecycle, least privilege, certification) to identities that were never designed to have any of it. That starts with inventory and ownership, which is harder than it sounds and the subject of the next post.

Over the next few weeks I’ll go through the practical side: how to find these identities, why “vault everything” is a stopover rather than a destination, what AI agents change, and a 90-day plan that a mid-sized organisation can actually run.

If you’re wrestling with this now, I’d be interested to hear what your pause sounded like when someone asked for the number.

Shailesh Kejadiwal is an identity architect who has spent the last decade designing IAM and CIAM platforms for UK banks, insurers and public bodies. He is the founder of United Kloud Technologies.