Your API Keys Don't Have MFA: Why Non-Human Identities Are the Biggest Blind Spot in Enterprise Security

For every employee in your organization, somewhere between 25 and 50 non-human identities are running in the background: service accounts, API keys, OAuth tokens, automation credentials, certificates, and now AI agents. In some environments, ManageEngine's 2026 Identity Security Outlook found machine-to-human ratios as high as 500:1.

These non-human identities (NHIs) don't complete MFA challenges. They don't keep working hours you can baseline against. They don't quit, retire, or answer access review emails. And 71% of them aren't rotated within recommended timeframes, according to CSO Online. They sit in your environment, often with elevated privileges, working as permanent access keys nobody remembers to revoke.

The outcome is predictable. 68% of security incidents now involve machine identities. Only 12% of organizations report being highly confident in their ability to prevent attacks via NHIs. Half of all organizations have experienced breaches tied to unmanaged non-human identities. And the industry is settling on a consensus: machine identities will become the primary breach vector in cloud environments in 2026.

We locked the front door with MFA and Zero Trust. The back door — API keys hardcoded in repos, service accounts holding domain admin privileges, OAuth tokens from vendors who left two years ago — has been standing open the whole time.

When I build detection coverage for a customer, the human identities are usually the easy part. It's the machine identities that have no owner, no lifecycle, and no baseline that quietly become the gaps I have to design around.

How machine identities became the largest attack surface

The growth of non-human identities isn't a gentle trend. It's an exponential curve driven by three forces, all accelerating at once.

Cloud-native architectures mint identities at machine speed. Every Kubernetes pod that spins up during auto-scaling creates workload identities. Every GitHub Actions workflow generates tokens. Every Terraform run provisions service principals. A single deployment pipeline can create more machine identities in 20 minutes than your entire company has human users. Unlike human identities that HR carefully manages, NHIs multiply through automated processes with no central oversight.

AI agents are the newest explosion. These aren't chatbots answering questions. They're autonomous systems authorized to run commands, move production data, change configurations, and trigger downstream workflows. Microsoft Copilot has access to your SharePoint. GitHub Copilot can commit to your repos. Your marketing team's AI assistant pulls customer records from Salesforce. CyberArk predicts 2026 will bring the first major breach traced back to an over-privileged AI agent. The unnerving part is that it won't look like an attack. It will look like normal automation behavior. We unpack that risk further in our piece on AI credential theft and honeytokens.

Secrets sprawl is epidemic. Wiz research found that 65% of the top 50 AI companies had leaked verified secrets on GitHub: API keys, tokens, and credentials buried in deleted forks, gists, and developer repos. Cybernews analyzed 38,630 Android AI apps and found 72% contained at least one hardcoded secret, averaging 5.1 secrets per app. Truffle Security scanned the November 2025 Common Crawl dataset and identified 2,863 live Google API keys vulnerable to privilege escalation, belonging to major financial institutions, security companies, and even Google itself. Researchers studying the same Common Crawl data found nearly 12,000 live API keys and passwords sitting in publicly accessible web pages. The Toyota GitHub exposure is a reminder this happens to household names too.

The OWASP Non-Human Identities Top 10 for 2025 ranks improper offboarding as the number one risk. When a project gets cancelled, a vendor integration gets deprecated, or a developer leaves, does anyone remember to delete the service accounts? In most organizations, almost never. The Twitch incident revealed the company had 27,000 active service accounts with no centralized inventory. The credential that was compromised had been created in 2011 and never rotated, a decade of exposure sitting in a database.

Why your security stack can't see the NHI threat

The core problem is that every tool in your stack was designed for human identities. The assumptions baked into IAM, EDR, SIEM, and CASB don't hold for machines.

IAM assumes identities belong to people. Identity and access management systems expect identities to have managers who respond to access review emails. They expect lifecycle events — onboarding, role changes, offboarding — that line up with HR processes. NHIs have no manager. They never answer certification campaigns. They have no HR record. Legacy IAM is structurally incapable of governing identities that don't fit the human model, which is why less than a quarter of organizations have documented policies for creating or removing AI identities.

MFA doesn't apply. When an attacker steals a human credential, MFA is the safety net. When an attacker steals an API key, there's no second factor. The key is the entire authentication, and possession equals access. OAuth tokens bypass MFA by design, because they represent proof of already-completed authentication. That's why token theft accounted for 31% of Microsoft 365 breaches in 2025, surpassing traditional credential compromise.

Behavioral baselines break down. SIEM rules and UEBA detect anomalies by establishing patterns of normal behavior: login times, source IPs, access patterns. An API key has no normal working hours. A service account doesn't log in from a predictable location. An automation credential may legitimately touch thousands of resources in minutes. When normal behavior is indistinguishable from malicious behavior, anomaly detection produces nothing but noise. I've tuned enough UEBA deployments to know that machine identities are where those models quietly give up.

Secret sprawl defies inventory. You can't secure what you can't see. NHIs live in code repositories, CI/CD pipelines, environment variables, configuration files, documentation wikis, Slack messages, and dozens of other places no single tool watches. More than 16% of organizations don't even track the creation of new AI-related identities. When a machine credential is compromised, detection depends on knowing it existed at all, and most organizations don't.

How honeytokens catch compromised non-human identities

Cyber deception solves the NHI detection problem from a different direction. Instead of trying to monitor every machine identity (impossible when you have 50x more NHIs than humans), you plant honeytoken credentials — fake API keys, decoy service accounts, bogus OAuth tokens — in the exact places attackers find and exploit the real ones. Any attempt to use a honeytoken is unauthorized by definition. Zero false positives. Immediate signal.

Honeytoken API keys in code repositories

Attackers and automated scanners systematically harvest credentials from GitHub repos, including commit history, deleted forks, and gist files. Wiz found 65% of top AI companies leaked secrets this way. Mine2 honeytokens — fake AWS access keys, bogus database connection strings, decoy API tokens — planted in code repositories, CI/CD configs, and environment variable files create tripwires that fire the moment a harvested credential gets used. The attacker can't tell which keys are real and which are traps. Any attempt to authenticate with a honeytoken triggers an immediate alert that exposes both the compromised repository and the attacker's infrastructure.

Decoy service accounts in Active Directory

Service accounts are the crown jewels of NHI abuse. They often hold domain-level privileges, never expire, and rarely get monitored. Mine2 deploys decoy service accounts in Active Directory — names like svc_azure_sync, automation_backup, legacy_api_bridge — that read like exactly the kind of high-value, forgotten machine identities attackers target. Any authentication attempt against a decoy service account is a guaranteed indicator of compromise: someone is either testing harvested credentials or running Active Directory reconnaissance. We go deeper on how attackers abuse service accounts in our breakdown of service account lateral movement and credential Mines.

Honeytoken cloud credentials in cloud environments

Cloud environments are ground zero for NHI sprawl. AWS IAM roles, Azure service principals, and GCP service account keys multiply with every deployment. Mine2's Cloud Mines include honeytoken IAM credentials and fake cloud resource endpoints scattered across your cloud footprint. When a compromised cloud credential gets used to enumerate resources, or a stolen IAM key tries to reach a phantom S3 bucket, the alert fires immediately. This catches external attackers who've harvested cloud credentials and insider threats reaching beyond their authorization alike.

MineField decoy services catch NHI-driven lateral movement

When an attacker compromises a service account or API key, the next step is reconnaissance: probing the network to find out what the credential can reach. Mine2's MineField deploys decoy TCP services that look like real API endpoints, database servers, and internal services. When a compromised NHI is used to scan or connect to a MineField decoy, the alert fires, catching lateral movement that SIEM rules and network monitoring would write off as normal machine-to-machine traffic.

Honeytoken secrets in config files and documentation

The most damaging NHI compromises often start in the most mundane places: .env files, Docker configs, internal wikis, Confluence pages, shared drives. Developers stash credentials there for convenience, and attackers know exactly where to look. Mine2 honeytokens planted in those same spots — fake database passwords in .env files, bogus API keys in documentation, decoy cloud credentials in config templates — catch credential harvesting whether the attacker is an external threat actor, an insider, or an automated infostealer.

A practical playbook: securing NHIs with deception

1. Audit your NHI estate, then plant honeytokens alongside real credentials

Map your service accounts, API keys, OAuth integrations, and cloud credentials. For every category of real NHI, deploy matching honeytokens in the same locations and formats. Attackers can't separate real from fake, so the honeytokens act as canaries across your entire NHI landscape.

2. Seed honeytoken API keys in every code repository

Plant fake AWS keys, database credentials, and API tokens in your Git repositories: in active code, in deleted branches, in CI/CD configuration files. These are the exact places automated scanners and attackers harvest from. Every honeytoken use attempt exposes a compromised repository.

3. Deploy decoy service accounts with enticing privilege indicators

Create AD service accounts with names that suggest high-value access: svc_prod_db, automation_admin, backup_dc. Wire up monitoring so any authentication attempt fires an immediate alert. These decoys catch both credential stuffing and targeted Active Directory reconnaissance.

4. Scatter cloud honeytokens across IAM and resource boundaries

Deploy honeytoken IAM credentials in your cloud environments. Create fake S3 buckets, phantom Lambda functions, and decoy RDS instances that exist only as tripwires. Any resource enumeration that touches a cloud honeytoken exposes compromised cloud access.

5. Harden with Fortify, then layer deception

Use Mine2's Fortify to put NHI hygiene in place: enforce least privilege on service accounts, rotate credentials on schedule, disable dormant machine identities, and restrict API key scopes. Then layer honeytokens on top, so even when an attacker finds a real credential that slipped through hardening, the next credential they test is a trap.

6. Integrate honeytoken alerts with NHI lifecycle management

Wire honeytoken alerts into your SOAR platform with automated responses: revoke the compromised credential, disable the associated service account, audit all NHIs in the same repository or cloud project, and start incident response. Because honeytokens carry zero false positives, automated response won't disrupt legitimate machine-to-machine operations.

Where this leaves your machine identities

Non-human identities are the largest unmanaged attack surface in modern enterprise environments. They outnumber humans 50:1, drive 68% of security incidents, and operate entirely outside the IAM, MFA, and behavioral analytics frameworks we've spent a decade building for human users.

Traditional tools can't solve this because they rest on assumptions that don't hold for machines. API keys don't complete MFA. Service accounts don't have managers. OAuth tokens don't keep normal hours. You can't baseline what has no pattern, and you can't monitor what you can't inventory.

Honeytokens take a fundamentally different approach. Rather than trying to monitor every machine identity (impossible at 50:1 ratios), they plant fake credentials in the exact places attackers find real ones. The result is a detection layer that fires with certainty the moment a compromised NHI gets used, whether it's an API key harvested from a GitHub repo, a service account credential pulled from AD, or an OAuth token stolen in a supply chain breach.

When a single forgotten service account from 2011 can be the entry point for a billion-dollar breach, certainty of detection isn't optional. It's the only thing standing between you and the 68% of incidents that started with a machine identity nobody remembered existed.

---

Want to catch compromised non-human identities before they're weaponized? See how Mine2's honeytokens protect your NHI estate →