- › Machine identities now outnumber human ones in most enterprises by more than 80 to 1, up from 45 to 1 a year earlier, and the gap is widening as AI agents multiply.
- › A non-human identity is any service account, API key, token, certificate, or agent credential that authenticates without a person. Most are over-permissioned and never rotated.
- › Attackers target machine identities because they are powerful, poorly monitored, and rarely protected by MFA. A leaked API key is a login that never sleeps.
- › AI coding agents are the newest and softest non-human identity. The Ghostcommit attack showed an agent reading a repo's secrets and writing them into committed code.
- › The fix is an inventory, least privilege, short-lived credentials, and monitoring built for machines, not the human-shaped IAM controls most programs still rely on.
Picture the badge reader at your office door. Every person who walks through it has a face, a name, and a manager who notices when they stop showing up. Now picture the loading dock around back, where forklifts and delivery trucks come and go all day, none of them wearing a badge, most of them waved through because they always have been. That dock is your machine identity problem. The people are counted, watched, and offboarded. The machines are not, and there are far more of them.
In the average enterprise, non-human identities outnumber human ones by more than 80 to 1, up from 45 to 1 just a year earlier (CyberArk, 2025). Think about what that ratio means, and which direction it is moving. For every employee your identity team knows by name, provisions carefully, and revokes on their last day, there are dozens of service accounts, API keys, tokens, and bots that nobody owns, nobody rotates, and nobody deletes. You built an entire security program around the people, and the people are now the minority.
What a Non-Human Identity Actually Is
A non-human identity, or NHI, is any credential that authenticates without a person on the other end. The service account your billing system uses to reach the database. The API key that lets your mobile app talk to the backend. The OAuth token your CI/CD pipeline holds to push code. The TLS certificate that proves one microservice is allowed to call another. The secret baked into a container so it can pull from a private registry. None of these has a face. All of them can log in.
Here is what makes them dangerous. A human identity has natural friction. People forget passwords, trigger multi-factor prompts, work business hours, and log in from predictable places. A machine identity has none of that. It authenticates silently, at machine speed, around the clock, and almost never behind multi-factor authentication. When you hand a script an API key, you have created a login that never sleeps, never gets suspicious, and never questions the instruction it was given.
Now put yourself in the shoes of the attacker. You can phish a human, hope they click, hope MFA is misconfigured, and hope you land before the session expires. Or you can find one API key committed to a public repository and walk straight in as a trusted service with no prompt, no alert, and no expiry. One of those paths is expensive and loud. The other is cheap and quiet. Rational adversaries pick the quiet one, which is exactly why leaked credentials and secrets sprawl show up in breach after breach.
The Secrets Sprawl Problem
The reason machine identities leak is that their credentials, the secrets, end up everywhere. Source code. Config files. Environment variables. CI/CD logs. Container images. Slack messages between engineers who needed to share a key at 2am and never deleted the thread. Each copy is a new place the secret can escape from, and unlike a password, a service account key is rarely rotated, so a secret leaked three years ago may still work today.
The economic asymmetry here is brutal. Rotating a compromised human password costs a user two minutes and a grumble. Rotating a machine credential can mean tracking down every system that hard-coded it, coordinating a change window, and hoping nothing breaks in production. So teams do not rotate. The secret stays static for years, and a static credential with no expiry is not a key, it is a permanent hole with a lock painted on it. Most organizations do not even know how many they have, because the asset inventory is almost always smaller than the real attack surface.
AI Agents Are the Newest Machine Identity
If human-scale IAM was already losing to service accounts, the AI agent wave just poured accelerant on the fire. Every coding assistant, autonomous agent, and AI-powered pipeline you deploy is a new non-human identity, and it is the most dangerous kind, because it holds credentials and it reads attacker-controlled input at the same time.
Consider what researchers demonstrated this month with an attack called Ghostcommit. They hid a prompt injection inside a PNG image committed to a repository. When an AI coding agent read the project’s convention file, followed a pointer to that image, and processed it, the injected instructions told the agent to open the repository’s .env file, read the secrets byte by byte, and write them into committed code as a list of numbers. In one end-to-end run, the agent did exactly that on the first try, and two popular AI code reviewers never caught it because they do not open image files at all (BleepingComputer).
Sit with that. The agent was a trusted identity with read access to secrets and write access to the codebase, and it followed a malicious instruction it found in a file, because following instructions in files is its entire job. This is the confused deputy problem wearing a new hat. You cannot MFA an AI agent. You cannot train it to be suspicious of a well-crafted image. The only real control is to treat it like what it is: a powerful non-human identity that should hold the least access it can possibly do its work with, and nothing more. The same discipline applies to the APIs those agents call.
Why Human IAM Controls Do Not Transfer
The instinct is to bolt machine identities onto the same identity program you use for people. It does not fit, and understanding why is the whole game.
Human IAM assumes a person who can be interrupted. MFA works because a human can approve a push. Conditional access works because a person has a home location and a work schedule. Offboarding works because HR tells you when someone leaves. Machine identities break every one of those assumptions. A service account has no phone to approve a prompt. A pipeline runs from wherever the cloud schedules it. And nobody files a departure ticket when a microservice is decommissioned, so its credentials often outlive the service by years.
This is why machine identity belongs inside a zero trust architecture rather than a human-shaped IAM bolt-on. Zero trust assumes no identity is trusted by default, verifies every request, and grants the narrowest access that works. That model was built for exactly this: a caller with no face, no schedule, and no natural friction, asking for access it may or may not deserve. The fine-grained authorization that governs microservice calls is machine identity security whether you label it that way or not.
Five Moves That Actually Work
You will not solve this with a product you buy on Friday. It is an operational discipline, and it comes down to five moves.
Inventory first, because you cannot protect what you cannot count. Find every service account, API key, token, certificate, and agent credential across your code, your cloud, your pipelines, and your third-party integrations. The number will be larger than you expect, and that shock is the point. An honest count of your machine identities is the same first step as any real security assessment: you measure the real surface before you defend it.
Enforce least privilege, ruthlessly. Most machine identities are wildly over-permissioned because it was easier to grant broad access than to scope it. That admin-level service account doing one narrow job is a blast radius waiting to detonate. Scope every credential to the single task it performs, so that when one leaks, and one will, the attacker inherits a keyhole instead of a master key.
Make credentials short-lived. The single most effective control is to stop issuing permanent secrets. Short-lived, automatically rotated credentials turn a leaked key from a lasting breach into a window that closes on its own in minutes. A secret that expires before the attacker can use it is worth more than any amount of detection after the fact.
Get secrets out of code and into a vault. Hard-coded secrets are the leak waiting to happen. Move them into a dedicated secrets manager, inject them at runtime, and scan your repositories and pipelines continuously for the ones that slipped through. This is also a supply chain control, because a secret in a dependency is a secret in everyone who installs it.
Monitor machines like machines. Your detection is probably tuned for human anomalies, impossible travel, odd login hours, brute-force patterns. Machine identities need their own baseline: this service account normally touches these three systems, so a call to a fourth at an unusual volume is the signal. Build the behavioral model around what the machine normally does, because it will never trip a human-shaped alarm.
The Identities You Forgot Are the Ones They Want
Every organization has poured a decade into securing its people. Awareness training, MFA, phishing simulations, conditional access. Meanwhile the machine identities multiplied in the background, unbadged and uncounted, until they outnumbered the humans by more than eighty to one and became the easiest way in. The adversary already knows this. They stopped trying to beat your front door a while ago, because the loading dock around back was never locked.
Want to know how much of your attack surface is riding on unmanaged credentials? Start with our free Human Attack Surface Score, or contact Grab The Axe to bring machine identity into your security program before someone else audits it for you.
Operating on the philosophy that 'you can't build a secure system if you don't know how to break it,' Chris leads our engineering division. A top 1% National Cyber League competitor, he hardens our digital infrastructure against the very exploits he has mastered.
View Author Page →
