What Are Non-Human Identities? The Complete Guide to NHI Security

Understanding what are non-human identities and how to secure them has become critical for security teams in 2026, as 68% of IT security incidents now involve machine identities and half of enterprises surveyed have experienced a security breach due to unmanaged non-human identities

Key Takeaways

• Non-human identities (NHIs) are digital credentials that authenticate machines, applications, service accounts, OAuth tokens, API keys, and AI agents, operating outside traditional IAM controls
• NHIs outnumber humans 25-50x in modern enterprises, with the ratio accelerating as AI agent deployment scales in 2026
• Traditional security controls don't apply: NHIs bypass MFA, operate 24/7 without "normal" behavior patterns, and persist indefinitely without lifecycle management
• Token abuse and lateral movement exploit OAuth refresh tokens and service accounts to ride trusted connections across SaaS supply chains, as demonstrated in the Salesloft-Drift breach affecting 700+ companies
• Behavioral detection, not static inventory, is required to identify anomalous NHI activity, toxic permission combinations, and supply chain attack paths before they become breaches

The Identity Blind Spot Your IAM Program Misses

Most organizations believe their biggest identity risk lives with privileged human users. In reality, the exposure often sits one integration away, in the thousands of non-human identities operating silently across your SaaS environment.

Your IAM program likely includes robust controls for human identities: single sign-on, adaptive MFA, privileged access management, and quarterly access reviews tied to HR lifecycle events. But non-human identities don't have managers, don't take PTO, and don't trigger suspicious login alerts when they authenticate at 3 AM on Sunday.

These machine credentials power the automation and integration that make modern business possible. They also create blind spots where attackers operate undetected, using valid tokens and trusted connections to bypass every control designed for human behavior.

The security industry has focused on SaaS security posture management and human identity governance while NHIs proliferated in the background. Now, as organizations deploy AI agents with administrative privileges at scale, the governance deficit has become critical.

What Are Non-Human Identities?

Non-human identities are digital credentials that authenticate machines, applications, and automated processes to access systems and data without human intervention. Unlike human identities tied to employees with predictable lifecycle events, NHIs are created by developers, business users, third-party vendors, and increasingly by other machines.

These identities operate in the hidden layer between your SaaS applications, enabling the integrations, automations, and API connections that power modern workflows. They authenticate using tokens, keys, certificates, and service accounts rather than usernames and passwords.

Why Traditional IAM Programs Weren't Built for This

Traditional IAM systems assume:

• Human lifecycle events (hire, transfer, terminate) trigger access changes
• Managers review access during quarterly certification campaigns
• Authentication happens interactively with MFA and risk-based challenges
• "Normal" behavior patterns exist for baselining (working hours, locations, devices)

None of these assumptions hold true for non-human identities. A service account doesn't have a manager to certify its access. An OAuth token doesn't complete MFA. An API key doesn't have "normal working hours" to baseline against. This fundamental mismatch creates the blind spots where attackers operate.

The explosion of generative and agentic AI in 2026 has accelerated NHI proliferation beyond what manual governance processes can handle. Organizations now face machine-speed identity creation managed with human-speed processes, creating an unsustainable governance gap.

The Five Types of NHIs in Your Environment

Understanding what are non-human identities requires recognizing the distinct categories operating across your infrastructure. Each type presents unique security challenges and attack vectors.

1. OAuth Tokens and API Keys

OAuth tokens function as bearer tokens: whoever holds the token gains access, no additional authentication required. This design enables seamless integration between SaaS applications but creates significant risk when tokens are stolen or misused.

Access tokens are typically short-lived (minutes to hours) and grant specific permissions to resources. Refresh tokens persist for months or years, operating outside traditional login flows to generate new access tokens without reauthentication. This makes refresh tokens especially dangerous when compromised.

Real-world impact: The Salesloft-Drift breach in 2025 demonstrated how a single compromised OAuth integration could extend into tools like Gainsight and multiple Salesforce instances, multiplying the number of affected accounts to more than 700 companies. Attackers rode those trusted connections straight into customer environments, leveraging inherited permissions across the SaaS supply chain.

OAuth scopes determine what actions a token can perform, but organizations rarely audit whether granted permissions align with actual usage. Overprivileged OAuth apps with write and delete permissions often sit idle for months, creating toxic combinations when combined with other access paths.

2. Service Accounts

Service accounts are system identities that never sleep, never take PTO, and never trigger the behavioral anomalies that would flag a compromised human user. They authenticate backend systems, run scheduled jobs, and enable application-to-application communication.

These accounts are often created with administrative privileges because configuring least privilege takes longer and might break functionality. The operational pressure to "just make it work" results in service accounts with broader access than any individual human would receive.

The Okta breach in January 2023 exploited a service account that should have been decommissioned months earlier. The account had no MFA protection, no password rotation policy, and no monitoring of its activity. It operated completely outside the controls protecting human identities, providing attackers persistent access to Okta's internal systems.

Service account sprawl accelerates as organizations adopt microservices architectures. Each service needs credentials to authenticate to databases, message queues, and other services. Without centralized visibility, these accounts proliferate across cloud environments and on-premises infrastructure.

3. Secrets and Credentials

Hard-coded passwords, SSH keys, database connection strings, and encryption keys represent another category of non-human identity. These secrets authenticate automated processes and enable secure communication between systems.

The credential exposure problem manifests in multiple ways:

• Developers commit secrets to GitHub repositories (public or private)
• CI/CD pipelines store credentials in environment variables
• Configuration files contain plaintext passwords
• Log files inadvertently capture authentication tokens

The Codecov breach demonstrated this risk when attackers compromised the company's CI environment and harvested customer credentials from build processes. Those stolen secrets provided access to customer repositories and infrastructure.

Organizations struggle to maintain secret hygiene at scale. Developers create credentials to solve immediate problems, often bypassing formal secret management systems. These credentials persist in code, configuration, and documentation long after projects complete.

4. Certificates and Keys

Digital certificates enable SSL/TLS encryption, code signing, and machine-to-machine authentication. Certificate-based authentication provides strong security when properly managed but creates operational challenges around rotation and expiration.

Certificate expiration causes outages; certificate theft enables impersonation. Organizations often discover certificate inventory gaps only when expired certificates break production systems. The pressure to restore service quickly can lead to extending certificate lifetimes rather than implementing proper rotation.

Code signing certificates present particular risk because they establish trust in software. Compromised code signing certificates allow attackers to distribute malware that appears legitimate, bypassing security controls that verify digital signatures.

5. AI Agents and Automation (Emerging)

Agentic AI represents the newest and fastest-growing category of non-human identity. These autonomous agents make decisions, take actions, and access data without human intervention. Unlike traditional automation that follows predetermined logic, AI agents adapt their behavior based on context and learning.

The triple threat facing enterprises in 2026 includes:

• Agentic risk: AI agents deployed with administrative privileges to "get things done"
• Governance deficits: Machine-speed identity creation overwhelming human-speed approval processes
• Visibility gaps: Inability to track which agents are active and what data they're accessing

RPA bots, CI/CD pipelines, and workflow automation tools have operated as non-human identities for years. Agentic AI differs in its autonomy and unpredictability. An AI agent might discover and exploit access paths that human developers never anticipated.

Organizations deploying AI agents at scale today often lack the safeguards and governance frameworks required to manage these identities securely. The upside of autonomous agents is enormous, but so is the risk when they operate with elevated privileges and limited oversight.

For more on securing AI deployments, see our AI security best practices and AI agent security framework.

Why NHIs Create Blind Spots Where Attackers Operate

Understanding what are non-human identities is only the first step. The real challenge lies in the structural blind spots these identities create across security operations, governance, and incident response.

The Visibility Problem

No single pane of glass exists across SaaS applications, cloud infrastructure, and on-premises systems to show all active non-human identities. Each platform maintains its own identity store:

• AWS IAM roles and access keys
• Azure service principals and managed identities
• Google Cloud service accounts
• Salesforce connected apps and OAuth tokens
• GitHub deploy keys and personal access tokens
• Kubernetes service accounts and secrets

NHIs are created by developers provisioning cloud resources, business users installing SaaS integrations, and third-party vendors connecting to your APIs. Most of these identities are created without security review or centralized tracking.

Orphaned identities persist long after projects end. The developer who created the service account left the company. The integration that required the OAuth token was replaced by a different tool. The API key was generated for a proof-of-concept that never went to production. These forgotten credentials maintain their access indefinitely.

The Governance Gap

Traditional access certification assumes human identity patterns. Quarterly reviews ask managers: "Does this person still need access to these systems?" The question doesn't translate to non-human identities.

Who certifies a service account's access? The developer who created it may not remember its purpose six months later. The application owner may not know which backend service accounts support the application. The security team lacks context about whether the permissions are still required.

MFA doesn't apply to machine authentication. Service accounts and API keys authenticate using secrets, not interactive login flows. The security controls that protect human identities from credential theft and account takeover simply don't work for NHIs.

"Normal" behavior patterns don't exist for baselining. A service account might authenticate once per day at exactly 2 AM, or it might authenticate thousands of times per hour during business operations. An OAuth token might access the same three API endpoints every time, or it might access different endpoints based on user activity. Distinguishing malicious behavior from legitimate automation requires understanding the specific purpose of each identity.

The Toxic Combination Problem

Individual NHIs may have reasonable permissions in isolation. The risk emerges when multiple identities combine to create unexpected access paths.

Example toxic combination:

• OAuth app has read access to Salesforce customer data
• Service account has write access to data warehouse
• Integration connects Salesforce to data warehouse
• Result: Compromised OAuth token enables data exfiltration path that neither identity could execute alone

Inherited permissions compound this problem. When a third-party SaaS vendor integrates with your Salesforce instance, they inherit access to whatever data Salesforce connects to downstream. The vendor's OAuth token can now ride trusted connections into systems the vendor never directly integrated with.

"What's talking to my Salesforce?" becomes an unanswerable question without visibility into the full chain of integrations and inherited permissions. Security teams discover these toxic combinations only after incidents, when forensic analysis traces the attack path.

The Lifecycle Problem

NHIs are created in minutes and forgotten for years. The friction to create a new service account or API key is minimal. The discipline to decommission them when no longer needed is rare.

Industry data shows only 20% of organizations have formal API key offboarding processes. When an employee leaves, their user account gets disabled immediately. The service accounts they created, the API keys they generated, and the OAuth apps they authorized continue operating indefinitely.

The Okta breach exploited exactly this lifecycle gap: a service account that should have been decommissioned when a project ended instead persisted with administrative access, providing attackers an entry point months later.

Rotation policies for non-human credentials lag far behind password policies for humans. Organizations enforce 90-day password rotation for users but allow API keys and service account credentials to persist for years. The operational risk of breaking production systems during rotation outweighs the security benefit in many teams' risk calculations.

For guidance on managing these risks, explore our guide to Salesforce integration risk.

OWASP Non-Human Identities Top 10

The OWASP Non-Human Identities Top 10 provides a framework for understanding the most critical risks in NHI security[owasp.org]. These risks reflect real-world attack patterns and common misconfigurations that enable breaches.

1. Improper Offboarding

Tokens persist after employee departure or vendor relationship ends. When a developer leaves the company, their user account is disabled within hours. The service accounts they created, API keys they generated, and OAuth apps they authorized continue operating with full permissions.

Third-party vendor relationships present even greater risk. When you terminate a SaaS vendor contract, their OAuth tokens may retain access to your data until explicitly revoked. Many organizations discover months later that former vendors still have active integrations.

2. Secret Leakage

Credentials exposed in logs, repositories, error messages, and configuration files provide attackers immediate access. Developers commit secrets to GitHub repositories (public and private). CI/CD pipelines log authentication tokens. Error messages display database connection strings. Configuration files contain plaintext passwords.

Automated scanners continuously search public repositories for exposed credentials. The time between credential exposure and attacker exploitation is measured in minutes for public leaks, hours for private repositories.

3. Third-Party NHI Vulnerabilities

Your vendor's compromised token becomes your breach. The SaaS supply chain extends your attack surface to include every third-party integration. When a vendor suffers a security incident, their OAuth tokens to your systems may be compromised.

The Salesloft-Drift incident demonstrated this risk at scale. A breach at one vendor propagated through OAuth integrations to affect 700+ downstream customers. Each organization had to treat the incident as their own potential breach, conducting forensic analysis to determine what data the compromised tokens could access.

4. Overprivileged Access

"Admin" granted because least privilege takes longer. The operational pressure to deliver features quickly results in service accounts and OAuth apps receiving broader permissions than required. Developers request admin access to avoid troubleshooting permission errors. Business users authorize OAuth apps with all available scopes to ensure functionality.

These overprivileged identities create blast radius when compromised. An API key that needs read access to a single database table instead has write access to the entire database. An OAuth app that needs to read calendar availability has permissions to read email content.

5. NHI Reuse Across Environments

Same credentials across development, staging, and production multiply blast radius. Organizations often copy service accounts and API keys from development to production environments. When those credentials are exposed (in logs, repositories, or error messages from dev systems), attackers gain production access.

Credential reuse also occurs across different applications and services. A single API key might authenticate to multiple systems, creating a skeleton key effect where compromising one integration exposes many.

Additional Critical Risks

Lack of credential rotation allows compromised credentials to remain valid indefinitely. Insufficient monitoring means malicious NHI activity goes undetected. Missing rate limiting on API keys enables data exfiltration at scale. Weak authentication methods like long-lived passwords instead of certificate-based authentication create unnecessary risk.

Understanding these risks is foundational to building effective NHI security programs. For broader context on SaaS security challenges, see what is SaaS security.

Moving from Inventory to Behavioral Detection

Static inventories tell you what non-human identities exist at a point in time. They miss the changing relationships between SaaS applications, the behavioral anomalies that indicate compromise, and the toxic combinations that create attack paths.

The operational reality for most security teams involves tracking NHIs in spreadsheets, conducting quarterly access reviews that rubber-stamp existing permissions to avoid breaking production, and discovering integration blind spots only after vendor breach notifications arrive.

This inventory-based approach fails because:

• Inventories become stale immediately as developers create new service accounts and users authorize OAuth apps
• Point-in-time snapshots miss behavioral changes like tokens suddenly accessing different data or authenticating from new locations
• Static permission reviews can't detect toxic combinations that emerge from the interaction of multiple identities
• Manual tracking doesn't scale to thousands of NHIs changing daily

What Behavioral Detection Reveals

Behavioral detection identifies anomalies that indicate compromise or misuse, even when the NHI itself is legitimate and properly authorized:

Token used from unexpected ASN or geography: An OAuth token that normally authenticates from your corporate network suddenly authenticates from a residential proxy network in a different country. The token is valid, the permissions are correct, but the behavior is anomalous.

Service account suddenly accessing different data patterns: A service account that typically reads the same database tables every night suddenly queries customer PII tables it has never accessed before. The account has permission to access those tables, but the behavior change indicates potential compromise.

OAuth app requesting new scopes months after installation: A third-party integration that has operated with read-only permissions for months suddenly requests write and delete permissions. The scope change might be legitimate product evolution or it might indicate the vendor was compromised.

Third-party integration activity spiking before breach disclosure: Unusual data access patterns from a vendor's OAuth tokens days before they publicly disclose a security incident. Early behavioral indicators provide time to investigate and contain before official notification.

The Knowledge Graph Approach

Knowledge Graph technology maps the relationships between identities, applications, and data to reveal attack paths that static inventories miss[obsidiansecurity.com]. This approach:

• Tracks inherited permissions through chains of integrations
• Identifies toxic combinations where multiple identities combine to create excessive access
• Correlates behavioral anomalies across related identities and applications
• Reveals lateral movement paths through SaaS supply chains

When a vendor breach occurs, the Knowledge Graph immediately shows which of your systems the vendor's OAuth tokens can access, what data those tokens can reach through inherited permissions, and which downstream integrations extend the blast radius.

Real-Time Detection vs. Quarterly Reviews

Behavioral detection operates continuously, alerting on anomalies as they occur rather than waiting for scheduled reviews. This real-time approach is essential because:

• Attackers move quickly once they compromise credentials
• Vendor breaches aren't disclosed immediately, creating windows where compromised tokens operate undetected
• Integration changes happen daily, not quarterly
• AI agents and automation create dynamic access patterns that quarterly snapshots can't capture

Organizations implementing behavioral detection for NHI security report discovering active compromises that had operated undetected for months, identifying overprivileged integrations that failed previous audits, and preventing lateral movement before attackers could access sensitive data.

For more on identity threat detection, see our coverage of identity threat detection and response.

The Operational Reality: From Spreadsheets to Continuous Governance

Security teams managing non-human identities in 2026 face a common set of operational challenges that manual processes cannot solve at scale.

The Spreadsheet Problem

Tracking thousands of NHIs in spreadsheets creates multiple failure modes:

• Spreadsheets are updated manually, making them stale the moment they're created
• Different teams maintain separate inventories (cloud, SaaS, on-prem) with no unified view
• Ownership information becomes outdated as people change roles or leave
• Permission details are captured at high level, missing toxic combinations in the details

Organizations conducting compliance audits discover that their NHI inventory is 40-60% incomplete, missing service accounts created by developers, OAuth apps authorized by business users, and API keys generated for integrations.

Quarterly Access Reviews That Fail

Scheduled access certification campaigns designed for human identities don't work for NHIs:

• Reviewers lack context about whether service account permissions are still required
• The operational risk of breaking production by removing access leads to rubber-stamping approvals
• Reviews happen quarterly while NHI creation happens daily, creating ever-growing gaps
• No baseline exists for "normal" NHI behavior to inform certification decisions

The result: access reviews become compliance theater that checks boxes without reducing risk.

Vendor Breach Notifications

Vendor breach disclosures arrive after attackers have already moved laterally through your environment. The typical timeline:

1. Vendor discovers breach (days to months after initial compromise)
2. Vendor conducts internal investigation (weeks)
3. Vendor notifies affected customers (weeks to months after discovery)
4. Your security team investigates impact (days to weeks)

By the time you receive notification, attackers may have used the vendor's OAuth tokens to access your data, move laterally to connected systems, and establish persistence through additional compromised credentials.

What Detection Looks Like in Practice

Organizations implementing continuous NHI governance and behavioral detection report fundamentally different operational outcomes:

Proactive anomaly detection identifies compromised tokens before vendor breach notifications arrive. Behavioral baselines flag unusual activity from third-party integrations, triggering investigation that discovers breaches days or weeks before official disclosure.

Automated toxic combination identification surfaces overprivileged access paths that manual reviews miss. The system identifies when an OAuth app's read permissions combine with a service account's write permissions to create data exfiltration risk.

Real-time integration visibility answers "what's talking to my Salesforce?" with current data, not quarterly snapshots. Security teams can immediately see all active OAuth tokens, their permissions, recent activity, and behavioral anomalies.

Continuous compliance monitoring replaces quarterly access reviews with ongoing certification. When permissions change or behavior deviates, automated workflows route approval requests to appropriate owners with full context.

The ROI of Behavioral Detection

Organizations calculate ROI for NHI security programs based on:

• Reduced incident response time from weeks to hours when vendor breaches occur
• Prevented breaches through early detection of compromised tokens
• Audit efficiency from automated evidence collection vs. manual spreadsheet compilation
• Reduced operational burden on security teams managing NHI lifecycle

The cost of a single data breach involving compromised NHI credentials ($4.91 million average according to IBM) far exceeds the investment in proper NHI governance and detection capabilities.

Securing Non-Human Identities: A Framework for 2026

Building effective NHI security requires addressing visibility, governance, and detection across the complete lifecycle. Organizations in 2026 are implementing Identity Security Posture Management (ISPM) and identity observability as foundational capabilities.

Establish Comprehensive Visibility

Discover all NHIs across SaaS, cloud, and on-premises environments:

• Service accounts in AWS, Azure, GCP
• OAuth tokens and connected apps in Salesforce, Microsoft 365, Google Workspace
• API keys and personal access tokens in GitHub, GitLab, CI/CD platforms
• Kubernetes service accounts and secrets
• Database credentials and application secrets
• AI agents and RPA bots

Automated discovery tools continuously scan environments to identify new NHIs as they're created. Integration with cloud APIs, SaaS platforms, and secret management systems provides real-time inventory.

Implement Lifecycle Governance

Establish ownership and accountability for every NHI:

• Assign owners responsible for certifying access and approving changes
• Define approval workflows for creating new NHIs
• Implement automated decommissioning when projects end or vendors are offboarded
• Enforce credential rotation policies with automated renewal

Just-in-time access models for NHIs reduce standing privileges. Service accounts receive elevated permissions only when needed for specific tasks, then permissions are automatically revoked.

Deploy Behavioral Detection

Continuous monitoring identifies anomalous NHI activity:

• Authentication from unexpected networks or geographies (ASN deviation)
• Access to data or systems outside normal patterns
• Permission scope changes or privilege escalation
• Unusual API call volumes or data transfer patterns
• Correlation with threat intelligence about vendor breaches

Machine learning baselines establish normal behavior for each NHI, enabling detection of subtle deviations that indicate compromise.

Enforce Least Privilege

Audit and right-size NHI permissions:

• Identify overprivileged service accounts with admin access
• Review OAuth app scopes against actual API usage
• Remove unused permissions from stale integrations
• Implement permission boundaries for new NHIs

Toxic combination analysis identifies where multiple NHIs combine to create excessive access, even when individual permissions appear reasonable.

Integrate with Incident Response

NHI security must connect to broader security operations:

• Feed NHI behavioral anomalies to SIEM and SOAR platforms
• Include NHI forensics in incident response playbooks
• Automate token revocation when compromise is detected
• Correlate NHI activity with endpoint and network telemetry

When a vendor breach notification arrives, integrated systems immediately show which OAuth tokens are affected, what data they can access, and whether any anomalous activity occurred.

For comprehensive SaaS security strategies, see our guide to SaaS security.

See the NHIs Operating in Your Environment

Understanding what are non-human identities is the first step toward securing the hidden layer between your SaaS applications. The challenge extends far beyond inventory to encompass governance, behavioral detection, and continuous monitoring of machine identities that operate outside traditional IAM controls.

The facts are clear: Non-human identities outnumber humans 25-50x in modern enterprises[1], 68% of security incidents involve machine identities[3], and half of organizations have experienced breaches due to unmanaged NHIs[appviewx.com]. As AI agent deployment accelerates in 2026, the governance gap will only widen without fundamental changes to how organizations manage non-human access.

Static inventories and quarterly reviews cannot solve this problem. The changing relationships between SaaS applications, the behavioral anomalies that indicate compromise, and the toxic combinations that create attack paths require continuous detection and real-time response.

Take Action Now

Your organization likely has thousands of non-human identities operating right now, many with permissions that would fail your next audit. Service accounts created by developers who left months ago. OAuth tokens from vendors you no longer use. API keys hard-coded in repositories. AI agents deployed with administrative privileges.

The question isn't whether these identities exist—it's whether you can see them, govern them, and detect when they're being abused.

Obsidian Security surfaces the hidden identities operating in your environment, maps their access through Knowledge Graph technology, and detects when their behavior deviates from baseline. Our platform reveals:

• Which OAuth tokens have access to your Salesforce, what data they can reach through inherited permissions, and whether their activity is anomalous
• Which service accounts have overprivileged access, when they were last used, and who owns them
• Which toxic combinations create unexpected attack paths that static reviews miss
• Which vendor integrations show behavioral indicators of compromise before breach notifications arrive

Request a demo to see the non-human identities in your environment that traditional IAM misses. Discover the blind spots where attackers operate.

‍