Penough Logo

Non-Human Identities.Your Machines Have More Access Than Your Employees? That's a Crisis.

15 min read
Key Insight

Five major breaches-Dropbox Sign, Microsoft AI, Salesloft, Cloudflare, and The New York Times—share one critical flaw: compromised machine credentials. Non-Human Identities (NHIs) operate without human login checks or expiration dates, leaving doors wide open to attackers. Read our breakdown of how zombie NHIs persist undetected and how to extend Zero Trust principles across your entire machine footprint.

Share:

In August 2025, attackers compromised credentials associated with Salesloft's Drift integration and used them to gain unauthorized access to Salesforce environments connected to the application.

In 2024, Dropbox Sign's production environment was breached after attackers compromised a service account used by a backend automated system , a textbook example of a non-human identity.

In 2023, researchers discovered that Microsoft's AI research team exposure had inadvertently exposed 38TB of private data, including passwords, secret keys, workstation backups, and more than 30,000 internal Microsoft Teams messages, through a misconfigured Azure SAS token

Also in 2024, an exposed GitHub token belonging to The New York Times was used to access approximately 5,000 GitHub repositories containing around 270GB of data, including source code, infrastructure tools, API tokens, and secret keys.

And in 2023, Cloudflare rotated thousands of credentials following the Okta breach , but one service token and three service accounts were missed. The overlooked credentials were subsequently used to gain access to Cloudflare's Atlassian environment.

Five incidents. Five different organizations. One common thread.


The Pattern That Keeps Repeating

Incident

What Was Compromised

Why It Worked

Salesloft/Drift

OAuth tokens

Stolen OAuth tokens provided access through the trusted integration

Dropbox Sign

Service account

Compromised backend identity had production privileges

Microsoft AI

SAS token

Misconfigured token provided excessive access

New York Times

GitHub API token

Exposed credential provided repository access

Cloudflare

Service account token

Credentials were missed during post-Okta rotation

What These 5 Breaches Have in Common

  • No human passwords were stolen . Attackers used machine credentials

  • No interactive MFA challenge was triggered. Machine-to-machine authentication often happens without a human approval step.

  • Traditional security controls struggled to distinguish compromised machine identities from legitimate automation that activity looked like normal automation

  • Long-lived or poorly managed credentials increased the potential window of exposure.

  • The breaches persisted often for months or years


What Exactly Is a Non-Human Identity?

Let's break this down.

A non-human identity (NHI) is an identity associated with a machine, application, workload, service, or automated process that can authenticate and access resources without direct human interaction.

The credentials, tokens, certificates, and other authentication mechanisms used by that identity are what allow it to prove who it is.

Your employees log in. Your machines authenticate.

According to GitGuardian, secrets that remain valid for extended periods pose a significant risk . The Microsoft AI incident is a prime example, where an exposed access token remained active for over two years .


But, What Does That Actually Look Like?

Here are the most common types of NHIs you'll find in any modern environment:

NHI Type

What It Does

Examples

Service Accounts

Background processes, automation scripts, scheduled tasks

Active Directory service accounts, cloud service principals

API Keys

Authenticate machine-to-machine communication for integrations

Stripe API key, Google Maps API key, AWS access keys

OAuth Tokens

Enable delegated access between applications without sharing passwords

GitHub OAuth app, Salesforce integration tokens

Workload Identities

Identities for containers, microservices, and serverless functions

Kubernetes service accounts, Azure Managed Identities, AWS IAM roles

Certificates

Establish trust through PKI for secure communications

X.509 certificates, TLS/SSL certs

AI Agent Credentials

Credentials used by autonomous AI systems to access data and APIs

Copilot tokens, agentic workflow credentials


How NHIs Actually Work

No humans involved here. Unlike your employees who type a password and approve an MFA push, NHIs authenticate programmatically:

  • No MFA prompts - machines don't get push notifications

  • No human oversight - authentication happens in milliseconds

  • No interactive login - credentials are exchanged system-to-system

Common authentication flows:

Authentication Method

How It Works

When Used

OAuth 2.0 Client Credentials

App exchanges client ID/secret for access token

M2M communication

Workload Identity Federation

Cloud workload obtains temporary credentials via trust relationship

Kubernetes, serverless

API Key

Static key included in API request header

Third-party integrations

X.509 Certificate

Digital certificate validates service identity

mTLS, IoT devices


The NHI Lifecycle (And Why It Breaks)

Every NHI follows a lifecycle:

code
Creation → Provisioning → Active Use → Rotation → Deprovisioning

Most organizations only manage the "Active Use" phase. Creation happens through code. Provisioning happens through automation. And deprovisioning? That almost never happens.

Result in Orphaned identities. Credentials that outlive their purpose. Tokens that never expire.

The OWASP NHI Top 10 identifies "Improper Offboarding" (NHI1:2025) as the top risk . When service accounts and access keys aren't properly disabled or removed when no longer needed, they become "zombie NHIs" waiting to be exploited .


Why NHIs Are So Hard to Manage

They're everywhere. Modern environments can contain far more machine and workload identities than human users, making visibility and lifecycle management increasingly difficult. A large organization might have thousands of human users and millions of machine identities .

They're over-privileged. Most of the NHIs carry more permissions than they actually need . Developers over-provision "just in case," permissions accumulate, and no one reviews them.

They store secrets everywhere. API keys end up in GitHub repos. Tokens get shared in Slack. Certificates sit in outdated config files. The attack surface is massive .According to GitGuardian, internally leaked secrets and publicly leaked secrets are two of the most common policy breaches that expose organizations to risk

They operate at machine speed. An exposed API key can be exploited almost immediately, leaving security teams little time to detect and respond.

They don't expire. Many NHIs aren't rotated within recommended timeframes . A token created for a test project years ago might still grant admin access today.

The OWASP NHI Top 10 lists "Long-Lived Secrets" (NHI7:2025) as a critical risk, citing the Microsoft AI incident as a real-world example


What This Means for Your Organization Security

Let's be honest. These five challenges are why NHIs are becoming the preferred target for attackers and why your current security controls probably aren't ready.

No MFA - the door is wide open

Your employees have to approve a push notification or enter a code. Machines don't. When an attacker steals an API key or an OAuth token, there's no second factor to stop them. No "did you just try to log in?" alert. No approval required. They're in.

A single exposed credential can let an attacker access your entire environment without ever triggering a single MFA challenge. According to the OWASP NHI Top 10, many platforms still support insecure authentication methods like implicit OAuth flows and app passwords that bypass MFA entirely

Think about what that means: a single exposed credential, and an attacker can access your entire environment without ever triggering a single MFA challenge .

Over-privileged by default the "just in case" problem

Here's the uncomfortable truth: most NHIs have way more access than they actually need. Why? Because developers and admins grant broad permissions "just in case" to avoid breaking things later. The result? A compromised service account often has admin-level access across multiple systems.

Take the Microsoft AI breach. A misconfigured SAS token didn't just expose data , it had "full control" permissions. Attackers could delete, overwrite, and exfiltrate 38TB of internal data . Over-privileged credentials are a backdoor waiting to be exploited .

Never expire - the ghost credentials

Static credentials are a ticking time bomb. They don't expire. They don't rotate. They just sit there, often for years, granting access long after they should have been revoked.

The Cloudflare incident is a powerful example. After the Okta compromise, Cloudflare rotated thousands of affected credentials but failed to rotate one service token and three service accounts because they were mistakenly believed to be unused. The overlooked credentials were later used to gain access to Cloudflare's Atlassian environment, where the threat actor established persistent access.

No owner - the accountability gap

Who created that API key? Who's responsible for rotating it? Who approves changes to its permissions?

Many organizations can't answer these questions for their NHIs. Without a named human owner, even a perfectly inventoried identity becomes a dead end during an incident. No one to contact. No one to notify. No one to hold accountable.

Hard to detect - the silent attack

Here's the scariest part: NHI activity looks exactly like normal automation traffic. Your SIEM may be tuned primarily for human activity, making machine-identity abuse harder to detect without the right behavioral context.

When attackers used stolen OAuth tokens to access Salesforce environments at hundreds of organizations, it looked like routine API traffic . No alarms triggered. No suspicious logins flagged. Just machines doing what machines do except they weren't your machines anymore.


The Result?

Attackers can now:

1. Steal credentials through exposed GitHub repos, misconfigured storage, or compromised third-party apps

2. Log in as the machine — no MFA, no alerts, no human approval

3. Move laterally using over-privileged NHIs

4. Persist indefinitely because credentials never expire and no one monitors them

5. Exfiltrate your data — and you won't even know until it's too late

That's why these five challenges matter. And that's why you can't ignore them anymore.


6 Steps to Secure Your Non-Human Identity Footprint

Here's what actually works against the NHI problem based on real world experience from security teams who've been through this.


1. Discovery First

You can't secure what you don't know exists. Most organizations underestimate the NHI sprawl . In one real-world project, what was expected to take two weeks ended up taking five months .

What to do: Build a complete inventory across cloud platforms, SaaS apps, container environments, and AI platforms. Capture owner, purpose, last-used date, and access scope .


2. Assign Human Owners

Every NHI needs a named human owner responsible for rotation, permission reviews, and incident response. Without ownership, even a perfect inventory becomes a dead end when something goes wrong .

For AI agents specifically, CSA recommends both a human sponsor and an oversight owner . Because agents can create sub-identities on their own .

The OWASP NHI Top 10 identifies "Improper Offboarding" (NHI1:2025) as the top risk because NHIs are created outside the typical HR-driven lifecycle making ownership and decommissioning uniquely challenging .


3. Enforce Least Privilege

Treat this like human access reviews but for machines. Audit credentials and remove excessive permissions. Many NHIs carry more access than they need . High-risk operations should use Just-In-Time (JIT) access controls with short-lived permissions .

GitGuardian flags overprivileged identities as a key risk area, noting that overprivileged NHIs widen the "blast radius" if their secret is compromised


4. Automate Rotation & Move Away from Static Secrets

Static credentials are a ticking time bomb. Push for short-lived tokens, workload identity federation, and temporary credentials. Where secrets remain necessary, centralize vaulting and automate rotation .

The alternative: Automated rotation and expiration policies close the window of exposure by ensuring credentials live only as long as needed .


5. Monitor for Machine Behavior

Many SIEM environments are optimized around human identity and endpoint activity, which can make compromised machine identities harder to distinguish from legitimate automation.

So What to monitor:

  • Unusual API call volumes

  • Off-hours activity

  • Access to new resources

  • Delegation chains — agents creating sub-agents

Key pattern:

code
A help desk interaction → MFA reset → new token creation

is a high-confidence indicator of compromise. Traditional detection would miss this but cross-domain correlation catches it .

The Hugging Face incident showed that a single over-scoped worker token could assume additional roles and traverse production clusters executing more than 17,000 actions


6. Extend Zero Trust to Machines

"Never trust, always verify" applies to machines too. Every access request human or machine should be continuously authenticated and authorized . For AI agents, this means defining action boundaries and approval workflows before the agent receives access. High-risk operations should require human involvement .


How Penough Can Help

Securing non-human identities requires more than discovering credentials. Organizations need to identify exposure, validate permissions, detect abuse, and respond when an identity is compromised.

Penough helps organizations strengthen this security lifecycle through:

Service

How It Helps

Vulnerability Assessment & Penetration Testing (VAPT)

Uncovers exposed credentials, over-privileged service accounts, and insecure configurations

Red Teaming

Simulates real-world attacks targeting NHIs exposing gaps before criminals find them

Security Operations Center (SOC)

Continuous monitoring to catch anomalous NHI activity

Threat Hunting

Proactively searches for signs of NHI compromise before escalation

Digital Forensics & Incident Response (DFIR)

Investigates and contains NHI-related breaches

Cybersecurity Training

Equips your teams to securely manage NHIs


NHIs now carry excessive privileges by default. They lack ownership and lifecycle management. And attackers have already figured out how to exploit them.

Your employees aren't the only ones accessing your systems anymore. Machines, workloads, applications, and AI agents are making decisions and accessing data every second.


Not sure where your machine identities end and your risks begin? Penough can help you assess your NHI exposure, identify high-risk identities, and prioritize remediation.

So what are you waiting for?

AUTHOR

Abrar

Cybersecurity researcher and technical contributor at Penough Ltd.