CyberArk published a number last year that I keep coming back to. In the average organization, there are 82 machine identities for every human. Eighty-two. Service accounts, API keys, OAuth tokens, workload identities, certificates, bot accounts, CI/CD pipeline credentials. For every employee who logs in with a password and passes MFA, there are 82 non-human entities that authenticate without either.
And 42% of those machine identities have privileged or sensitive access.
Let that sit for a second. In a company with 1,000 employees, there are roughly 82,000 machine identities, and about 34,000 of them can access something sensitive. How many of those 34,000 are inventoried? How many are actively monitored? How many were created by someone who left the company two years ago and nobody revoked the credential?
If you’re honest about it, the answer to most of those questions is “we don’t know.” And that’s the problem.
How we got here
The 82:1 ratio isn’t an anomaly. It’s the natural result of how modern infrastructure works.
Every microservice needs a service account. Every CI/CD pipeline needs deployment credentials. Every SaaS integration needs an API key. Every monitoring tool needs read access. Every cloud function needs an execution role. Every container needs an identity. Every AI agent your team connected to Slack or Salesforce or Google Drive last month created an OAuth token with permissions that nobody reviewed.
Each individual decision to create a machine identity makes sense. The deployment pipeline needs to push code. The monitoring tool needs to read metrics. The SaaS integration needs to sync contacts. Nobody questions it. The credential gets created, stored somewhere (hopefully a vault, more likely a config file or an environment variable), and forgotten.
Then multiply by every team, every project, every tool, every year the company has been operating. The result is tens of thousands of credentials, most with no owner, no expiration, no rotation schedule, and no audit trail of what they’re actually accessing.
Veza’s research found that machine identities outnumber human users 17:1 even in their analysis, and that non-human identities persist indefinitely unless explicitly decommissioned. Unlike human users who go through HR offboarding when they leave, nobody offboards a service account. It just keeps running, with whatever permissions it was granted on the day it was created, which were almost certainly broader than necessary because the developer who created it was in a hurry and selected “admin” instead of scoping the permissions properly.
What the attackers already figured out
Here’s what makes this a security problem and not just a governance headache.
Attackers have figured out that machine credentials are the easiest path into an organization. Human accounts have MFA. They have login monitoring. They have anomaly detection. If someone logs into a human account from an unusual location at an unusual time, the SOC gets an alert.
Machine identities have none of this. An API key authenticates silently. A service account doesn’t trigger geographic anomaly detection because it doesn’t have a “normal” location. An OAuth token doesn’t get prompted for MFA because the authentication happened once, when the token was granted, and the token has been valid since then.
CyberArk found that 87% of organizations experienced at least two successful identity-based breaches in the past year. The Verizon DBIR consistently shows credential abuse as a top initial access vector. And the fastest-growing category within credential abuse is non-human credential compromise, because these credentials are simultaneously the most powerful and the least monitored.
Researchers documented a scenario that should make every SOC leader uncomfortable. An AI agent connected to a company’s systems via MCP, the Model Context Protocol, was compromised through a prompt injection. The agent had OAuth tokens for Slack, Google Drive, and the internal ticketing system. The attacker used the agent’s existing credentials to move laterally through the organization’s SaaS stack. No malware. No exploit. No MFA challenge. The agent’s credentials were valid. The agent’s permissions were broad. The agent’s activity looked like normal automated behavior to every monitoring tool in the stack.
Nearly 38% of MCP servers scanned in a recent study had no authentication enabled at all. That’s not a configuration oversight. That’s the default.
Why your SOC doesn’t see this
Your SIEM is configured to ingest authentication logs from Active Directory, your IdP, maybe your cloud provider’s IAM console. It generates alerts when human users do unusual things. Login from a new country. Multiple failed passwords. Privilege escalation.
It does not, in most environments, monitor machine-to-machine authentication at the same level. Service account activity isn’t baselined. API key usage isn’t tracked against expected patterns. OAuth token permissions aren’t audited after initial grant. Container identities aren’t inventoried across ephemeral workloads.
This means that the 82 machine identities per human are, from the SOC’s perspective, invisible. They exist. They authenticate. They access sensitive systems. But they don’t generate the alerts that the SOC is configured to investigate.
Your SOAR playbooks compound the problem. Investigate suspicious login. Check user’s recent activity. Verify with the user. These playbooks assume the identity is a human with a phone number you can call. When the compromised identity is a service account, the playbook doesn’t know who to ask, what normal behavior looks like, or what containment action to take. Disable it? That might bring down a
production system. Rotate the credential? That might break 15 integrations that depend on it.
The SOC’s entire investigation and response model was built for human identities. Machine identities are a different animal, and the SOC doesn’t have the tools, the playbooks, or the visibility to handle them.
The AI agent problem is making this worse
Every AI agent your organization deploys creates new machine identities. And these aren’t static service accounts with predictable behavior patterns. They’re autonomous systems that make decisions, access data, and take actions in ways that can vary from invocation to invocation.
When a marketing manager connects an AI writing tool to the company’s Google Drive, that tool gets an OAuth token with file-read permissions. Maybe file-write. Maybe access to shared drives containing sensitive documents. The token was granted through a legitimate OAuth consent flow. It’s valid, privileged, and completely invisible to the SOC.
When the engineering team deploys an AI coding assistant with access to the code repository, the CI/CD pipeline, and the production deployment system, that assistant operates with credentials that span the entire software delivery chain. A compromise of those credentials is a supply chain attack waiting to happen.
Security teams know this is a problem. CSA’s survey found that only 12% of organizations are highly confident in their ability to prevent attacks via non-human identities. More than 16% don’t even track when new AI-related identities are created. The gap between the speed of AI adoption and the speed of NHI governance is widening, not closing.
What needs to change
The uncomfortable answer is that machine identities need the same security treatment as human identities. Lifecycle management. Least-privilege enforcement. Continuous monitoring. Behavioral baselines. Automated response when patterns deviate.
For the SOC specifically, three things need to happen.
First, machine identity activity needs to be visible. Not just logged somewhere in a cloud console that nobody checks. Visible in the same investigation workflow, the same case management system, and the same alert queue as human identity events. If a service account starts accessing resources it’s never accessed before, the SOC should see that the same way it sees a human logging in from an unusual country.
Second, the investigation model needs to handle non-human identities. When a compromised machine identity is detected, the SOC needs to know: who created this credential, what systems depend on it, what’s the blast radius of disabling it, and what’s the safest containment action that doesn’t bring down production. This is a harder problem than human identity response, and it needs purpose-built workflows.
Third, the organization needs an inventory. You can’t secure what you can’t see. Most companies cannot produce, today, a complete list of every service account, API key, OAuth token, and machine credential in their environment. Until that inventory exists, the 82:1 ratio is a risk number with no mitigation attached. The 82 machines per human aren’t going away. The ratio is going up. Every cloud migration, every SaaS adoption, every AI deployment, every microservice architecture pushes the number higher. The question isn’t whether to address it. It’s whether you address it before one of those 82 machine identities becomes the breach you didn’t see coming because nobody was watching it.
