Most security teams believe their biggest identity risk comes from compromised employee accounts. In reality, the apps/agents operating in your environment quietly outnumber humans 10-50x and often hold broader, more persistent access to critical systems. These non-human identities represent the invisible workforce powering modern SaaS environments, yet they receive a fraction of the security attention dedicated to human users.
When attackers compromise a service account or steal an OAuth token, they gain something more valuable than a single user's credentials: persistent, MFA-free access that can operate 24/7 without raising traditional security alarms. The risk is not theoretical. Incidents like Salesloft-Drift demonstrated how compromised non-human identities enabled attackers to escalate privileges and ride trusted connections across hundreds of downstream organizations.
Key Takeaways
● Non-human identities outnumber humans 10-50x in enterprise environments but receive minimal security oversight compared to human identity programs
● NHIs function independently of SSO/MFA by design, creating persistent access paths that bypass traditional authentication controls
● Compromised NHIs enabled major breaches: SolarWinds attackers used service accounts to escalate privileges; Salesloft-Drift OAuth tokens exposed 700+ companies
● Toxic combinations create high-risk scenarios: stale NHIs with overprivileged permissions represent low-resistance attack paths
● Behavioral monitoring matters more than inventory: static lists miss compromised credentials acting within normal parameters
What is a Non-Human Identity?
A non-human identity is an identity that authenticates and acts within systems without human intervention. These digital credentials serve as automated "passports" that allow applications, scripts, bots, devices, and AI agents to access systems and data, enabling the SaaS to SaaS and AI agent to SaaS interactions that power modern technology infrastructure.
Unlike human identities tied to individual employees, non-human identities authenticate automated entities. They include service accounts running scheduled jobs, OAuth tokens allowing one application to access another, API keys embedded in code repositories, service principals enabling app-to-app authentication, automation bots executing workflows, and increasingly, AI agents that chain actions across multiple platforms.
The scale of non-human identities dwarfs human identity populations. In most enterprise environments, NHIs outnumber human users by a factor of 10-50x. A company with 5,000 employees might have 50,000-250,000 active non-human identities spread across SaaS applications, cloud infrastructure, and integration platforms.
The blind spot emerges because security programs focus overwhelmingly on human access. Identity and Access Management (IAM) teams dedicate resources to onboarding, role changes, and offboarding for employees. Multi-factor authentication (MFA) policies target human login flows. Privileged Access Management (PAM) solutions protect human administrators. Meanwhile, non-human identities quietly accumulate elevated privileges, persist long after their original purpose ends, and create invisible attack paths that bypass every human-focused control.
Types of Non-Human Identities in SaaS Environments
Understanding the specific types of machine identities operating in your environment is essential for effective security. Each category functions differently and creates distinct risk patterns.
Service Accounts
Service accounts provide long-running automation with persistent access to systems. These accounts authenticate scheduled jobs, background processes, and system-level integrations that need to operate continuously without human involvement.
Service accounts typically hold admin-level permissions because they perform system-wide tasks: data synchronization between platforms, automated report generation, batch processing operations, and infrastructure monitoring. They operate 24/7, independent of human workforce schedules, executing thousands of API calls daily.
Critically, service accounts lack MFA by design. Machines cannot respond to push notifications, enter one-time codes, or complete biometric challenges. This architectural necessity means compromised service account credentials provide immediate, unobstructed access without triggering authentication alerts.
Service Principals
Service principals represent application identities for SaaS-to-SaaS authentication. When one cloud service needs to access another on behalf of the organization (not a specific user), it authenticates using a service principal.
Common in Microsoft Azure and similar platforms, service principals allow applications to request delegated or app-level access. For example, a business intelligence tool might use a service principal to query your data warehouse, or a security monitoring platform might authenticate to your identity provider to pull audit logs.
Service principals create inherited permissions chains. When you grant a service principal access to your environment, you're trusting not just that application but also the security posture of the vendor operating it. This creates the foundation of your SaaS supply chain, where trust relationships extend one integration away from your direct control.
OAuth Tokens (Access & Refresh Tokens)
OAuth tokens enable applications to access data on a user's behalf without sharing passwords. When you click "Sign in with Google" or authorize a Slack integration, you're creating OAuth tokens that grant specific permissions (scopes) to third-party applications.
Most SaaS apps implement OAuth tokens as bearer tokens, something like a key. Whoever has this key can use it. There's no additional authentication required. If an attacker steals an OAuth access token, they can immediately make API calls as if they were the authorized application.
Refresh tokens create even greater risk. While access tokens typically expire within hours, refresh tokens can persist for months or years, automatically minting new access tokens without user interaction. Refresh tokens function independently of your SSO/MFA infrastructure. Even if you revoke a user's password or disable their account, OAuth refresh tokens issued before that action may continue working.
The distinction between access token vs refresh token matters for security: access tokens provide short-term API access (usually 1-24 hours), while refresh tokens provide long-term credential renewal capabilities. Attackers prioritize refresh token theft because it provides persistent access that survives password resets and session terminations.
API Keys
API keys serve as static credentials for programmatic access to services. Developers embed API keys in application code, configuration files, CI/CD pipelines, and automation scripts to authenticate API requests.
Unlike OAuth tokens with defined scopes, API keys often grant broad access to entire platforms. A single Salesforce API key might provide read/write access across all objects. A cloud storage API key could enable data exfiltration from every bucket in your environment.
API keys rarely get rotated. Development teams create them for specific projects, hardcode them into applications, and forget about them. Years later, those API keys remain active with full permissions, even though the original project ended and the developer who created them left the company. API key management represents one of the most overlooked aspects of non-human identity security.
Bots & Automation Workflows
Automation workflows such as Zapier workflows, Workato processes, and scheduled scripts create dynamic API connections that traditional security tools struggle to track. These automation platforms allow business users to build integrations without IT involvement, spawning new non-human identities on demand.
A marketing team member might create a Zapier workflow that monitors form submissions in one system and automatically creates records in Salesforce. That workflow requires OAuth tokens or API keys for both platforms. The security team never reviewed the integration, and the permissions granted may far exceed what's necessary for the specific task.
Automation workflows often chain multiple applications together, creating complex permission inheritance patterns. A single workflow might touch five different SaaS platforms, each with its own authentication mechanism and permission model. Understanding the blast radius of a compromised automation bot requires mapping these interconnected relationships.
AI Agents
AI agents represent the newest and fastest-growing category of non-human identities. Autonomous AI systems like Microsoft Copilot, Salesforce Agentforce, and workflow automation platforms like n8n request broad permissions to operate independently across multiple applications.
Unlike traditional automation that follows predefined rules, AI agents make dynamic decisions about which systems to access and what actions to take. They chain API calls across platforms based on natural language instructions, creating unpredictable access patterns that defy traditional behavioral baselines.
AI agents often request expansive permissions because they need flexibility to accomplish varied tasks. A customer service AI agent might need access to CRM data, support ticketing systems, knowledge bases, billing platforms, and communication tools. The principle of least privilege becomes challenging when the agent's next action cannot be predetermined.
The emerging attack surface around AI agents lacks mature governance frameworks. Security teams struggle to answer basic questions: What data can this agent access? Which systems can it modify? Who authorized these permissions? How do we detect when an AI agent's behavior indicates compromise? AI agent risk assessment and visibility remain significant challenges for most organizations.
Why Non-Human Identities Are Harder to Secure
Non-human identities create security challenges that don't exist with human accounts. The architectural differences between how machines and humans authenticate create fundamental gaps in traditional security controls.
No MFA capability: Machines cannot complete multi-factor authentication challenges. Service accounts can't respond to push notifications. API keys can't enter one-time codes. OAuth tokens can't provide biometric verification. This design requirement means NHIs operate without the authentication layer that security teams rely on to protect human identities.
Persistent access by design: While human users log in and out, non-human identities maintain always-on access. A service account runs continuously, making thousands of API calls daily. There's no natural session timeout, no end-of-day logout, no vacation period when the account goes dormant. This persistence makes compromised NHIs more valuable to attackers than compromised human credentials.
Accumulated permissions over time: Non-human identities tend to accumulate permissions rather than shed them. When a service account needs additional access for a new integration, teams add permissions. When that integration changes or ends, the permissions rarely get removed. Years of permission accretion create service accounts with broad access across dozens of systems, far exceeding what any single human administrator would hold.
No behavioral baseline: Defining "normal" for automated systems proves difficult. A human user logging in from a new country at 3 AM triggers obvious alerts. But what does abnormal look like for a service account that already operates 24/7 from multiple IP addresses? Traditional User and Entity Behavior Analytics (UEBA) systems struggle to establish meaningful baselines for machine identities.
Shared credentials: Multiple processes, applications, or even teams often share service account credentials. This sharing makes attribution nearly impossible. When you detect suspicious activity from a shared service account, which process is responsible? Which team should investigate? Shared credentials dilute accountability and complicate incident response.
Forgotten accounts: Service accounts created for temporary projects often outlive their purpose by years. The project ends, the team moves on, but the service account persists with full permissions. Similarly, service accounts and OAuth tokens created by employees who have left the organization continue operating with their original access long after the employee’s departure. AI agents compound this problem, as they often require broad permissions across multiple systems to perform their automated tasks, creating additional NHIs that persist independently of any human oversight. These forgotten NHIs represent low-resistance attack paths because nobody monitors them, nobody expects activity from them, and nobody will notice when attackers start using them.
The Security Risks of Unmanaged NHIs
Unmanaged non-human identities create specific, exploitable vulnerabilities that attackers actively target. Understanding these risk patterns helps security teams prioritize NHI security investments.
Persistent Backdoors
A compromised non-human identity provides long-term, stealthy access that survives most remediation efforts. When attackers steal OAuth refresh tokens or service account credentials, they gain access that persists independently of user passwords, SSO sessions, and even account terminations.
Attackers don't need to phish passwords or bypass MFA. They simply use the stolen NHI credential to authenticate directly to APIs. The access looks legitimate because it is legitimate; the credential is valid, the permissions are authorized, and the activity falls within the NHI’s normal operational parameters.
Lateral Movement Enablers
Non-human identities often bridge multiple applications, making them ideal pivot points for lateral movement. A single compromised service account might have API access to your CRM, data warehouse, communication platform, and HR system. Attackers use these cross-application permissions to move from initial compromise to high-value targets.
The SaaS supply chain amplifies this risk. When you authorize a third-party integration, you're granting that vendor's systems access to your environment. If that vendor suffers a breach, attackers can ride those trusted connections straight into your applications.
Real incident: The Salesloft-Drift incident showed how a single OAuth integration could extend into tools like Gainsight and multiple Salesforce instances, multiplying the number of accounts affected to more than 700 companies being impacted. The OAuth tokens (a type of non-human identity) enabled attackers to access customer data across the entire downstream ecosystem. This wasn't a vulnerability in Salesloft or Drift themselves; it was the inherited permissions model of OAuth tokens creating blast radius multiplication.
Toxic Combinations
Toxic combinations occur when multiple risk factors converge in a single non-human identity: stale accounts that haven't been used in months, overprivileged permissions that grant admin access, and lack of monitoring that means nobody's watching for anomalies.
These combinations create low-resistance attack paths. Attackers specifically search for inactive service accounts with write/delete permissions because they know security teams aren't monitoring them. When activity suddenly appears from a dormant NHI, it often goes unnoticed because there's no baseline to compare against and no owner actively managing the account.
According to Obsidian's network data, organizations average 40-60 third-party integrations per core SaaS application, with 15-25% of those integrations inactive for 90+ days while retaining full permissions. These stale integrations with admin permissions represent the highest-risk toxic combinations in most environments.
Shadow NHIs
Shadow NHIs are created without IT or security awareness, typically by business users authorizing OAuth applications or automation platforms spawning service accounts dynamically. These identities operate completely outside security governance frameworks.
When a sales team member clicks "Connect to Salesforce" on a new productivity tool, they create an OAuth authorization (a non-human identity) that grants that tool ongoing API access. The security team never reviewed the vendor, never assessed the permissions granted, and may not even know the integration exists.
Automation platforms like Zapier, Make, and Power Automate allow business users to build integrations that create API connections to multiple systems. Each workflow creates new non-human identities (OAuth tokens, API keys, webhook subscriptions) that persist independently of the human user who created them. Even if that employee leaves the company, their automation workflows continue running with full access.
Why Traditional Identity Tools Miss NHIs
Security teams deploy sophisticated identity security tools, yet non-human identities slip through the gaps. Understanding why traditional tools fail to protect NHIs helps explain the need for specialized approaches.
IAM focuses on human lifecycle: Identity and Access Management platforms excel at human identity workflows: onboarding new employees, managing role changes, enforcing approval processes, and deprovisioning when people leave. These lifecycle events don’t apply to service accounts. There's no onboarding process for an OAuth token, no role change workflow for an API key, and no termination date for a service account.
PAM protects privileged human accounts: Privileged Access Management solutions secure human administrators through session recording, just-in-time access, and credential vaulting. These controls assume interactive sessions where humans log in, perform tasks, and log out. Service accounts don't have interactive sessions. API keys don't vault credentials between uses. OAuth tokens don't request just-in-time elevation.
SIEM monitors login events, not post-auth API activity: Security Information and Event Management platforms collect authentication logs: successful logins, failed attempts, MFA challenges. But non-human identities often authenticate once (or never, in the case of long-lived tokens) and then make thousands of API calls. The security-relevant activity happens post-authentication, in the API calls themselves, which many SIEMs don't collect or correlate effectively.
Static inventories lack behavioral context: Tools that inventory non-human identities provide valuable visibility into what exists, but they can't detect compromised credentials acting within normal parameters. A spreadsheet listing your service accounts doesn't tell you when one starts exfiltrating data. An OAuth token inventory doesn't alert you when a token begins accessing unusual data sets.
The gap isn't that traditional tools are poorly designed. The gap is that non-human identities operate fundamentally differently than human identities, requiring different security approaches. You need behavior vs inventory, not just knowing what NHIs exist, but understanding what they’re doing and detecting when that behavior indicates compromise.
Non-Human Identity Security Best Practices
Securing non-human identities requires specific practices that address their unique characteristics. Security teams need approaches that account for persistent access, lack of MFA, and behavioral complexity.
Inventory All NHIs Across SaaS Applications
You cannot secure what you cannot see. The first step is comprehensive discovery of all non-human identities across your SaaS estate: service accounts in Salesforce, Workday, ServiceNow; OAuth authorizations across all platforms; API keys embedded in repositories and CI/CD pipelines; webhook subscriptions receiving data from your systems; automation workflows in Zapier, Power Automate, Workato.
Include shadow NHIs created without security review. Business users authorize OAuth applications with one click. Developers create API keys for testing and forget to revoke them. Automation platforms spawn service accounts dynamically. Your inventory must capture these decentralized creation patterns.
Map which NHIs have access to which data and applications. A service account with read-only access to a test environment presents different risks than one with admin permissions across production systems. Understanding the blast radius of each NHI informs prioritization.
Enforce Least Privilege
Audit permissions against actual usage patterns. Many service accounts were granted admin access "just in case" or because it was easier than determining precise requirements. Review what data each NHI actually accesses and what operations it performs.
Identify NHIs with admin access that only need read permissions. Look for write/delete permissions granted to accounts that only perform queries. Find OAuth tokens with broad scopes when narrow scopes would suffice. OAuth scopes define what permissions an application receives; audit whether granted scopes match actual usage.
Remove stale integrations that no longer serve business purposes. An integration created for a project that ended two years ago shouldn't retain full API access to your CRM. Inactive NHIs with elevated permissions represent toxic combinations that attackers specifically target.
Implement Credential Lifecycle Management
Set expiration policies on tokens and API keys. While some NHIs need persistent access, many can operate with time-limited credentials that require periodic renewal. OAuth refresh tokens can be configured with maximum lifetimes. API keys can have expiration dates. Service accounts can require credential rotation.
Rotate credentials regularly, especially for high-privilege NHIs. Annual rotation of service account passwords and API keys limits the window of opportunity if credentials are compromised. Automated rotation reduces operational burden while improving security posture.
Revoke NHI access when projects end or employees leave. When the developer who created an API key leaves the company, revoke that key. When a project concludes, terminate the service accounts created for it. When an employee who authorized OAuth applications departs, review and revoke those authorizations if they're no longer needed.
Monitor NHI Behavior, Not Just Existence
Establish baselines for normal NHI activity patterns. What data does this service account typically access? What volume of API calls does it make? What time of day does it operate? Which IP addresses or ASN ranges does it use?
Detect anomalies that indicate potential compromise: unusual data exports that exceed historical patterns, IP address deviations where a service account suddenly authenticates from new geographic locations or suspicious ASN ranges, access pattern changes where an NHI begins accessing data it historically ignored, volume spikes in API calls that suggest data exfiltration, User-Agent attribution anomalies where the client making API calls changes unexpectedly.
Correlate NHI activity back to the humans who authorized them. When you detect suspicious activity from an OAuth token, identify which user authorized that application. When a service account behaves anomalously, determine which team owns it and who has access to its credentials. This human attribution enables effective incident response.
Govern NHI Creation
Implement approval workflows for new service accounts and integrations. Before a developer creates a service account with admin permissions, require security review. Before a business user authorizes a new OAuth application, validate the vendor and assess the permissions requested.
Periodic recertification for existing NHIs ensures continued business justification. Quarterly or semi-annual reviews where NHI owners must affirm that each identity still serves a valid purpose and that permissions remain appropriate to catch drift and identify abandonment.
Automatic deprovisioning for NHIs that fail review reduces manual burden. If an owner cannot justify a service account during recertification, automatically disable it (with a grace period for appeals). If an OAuth token hasn't been used in 90 days, flag it for revocation review.
How Obsidian Security Secures Non-Human Identities
Obsidian Security provides unified visibility and behavioral monitoring specifically designed for non-human identities in SaaS environments. The platform addresses the gaps that traditional identity tools leave exposed.
Unified visibility into all NHIs across core SaaS applications eliminates blind spots. Obsidian discovers service accounts, OAuth authorizations, API keys, and automation workflows across your entire SaaS estate. This includes shadow NHIs created without security review, giving you a complete inventory of your machine identity attack surface.
Distinguishes between internal and third-party NHIs, providing critical context for risk assessment. An internal service account you control directly presents different risks than an OAuth token granted to a third-party vendor. Obsidian maps these relationships, showing you which external parties have API access to your systems and what data they can reach.
Behavioral activity modeling detects compromised credentials operating within normal parameters. Rather than just inventorying what NHIs exist, Obsidian monitors what they're doing. The platform establishes baselines for each NHI's typical behavior and alerts on deviations: unusual data access patterns, geographic anomalies, volume spikes, and permission escalations.
Risk scoring identifies toxic combinations where multiple risk factors converge. Obsidian automatically flags stale NHIs with overprivileged permissions, inactive integrations with write/delete access, and service accounts that haven't been used in months but retain admin rights. This prioritization helps security teams focus on the highest-risk identities first.
Knowledge Graph correlates NHI activity back to authorizing identity. When Obsidian detects suspicious behavior from an OAuth token, it shows you which user authorized that application, when the authorization occurred, what permissions were granted, and what data has been accessed. This attribution enables rapid incident response and accountability.
Continuous discovery as new NHIs are created ensures your inventory stays current. As business users authorize new OAuth applications, developers create API keys, and automation platforms spawn service accounts, Obsidian automatically discovers and profiles these identities. You don't rely on periodic scans that go stale between runs.
The platform provides the behavioral context that static inventories lack, delivering the "hidden layer" visibility that SaaS security requires. By focusing on behavior vs inventory, Obsidian detects the compromised NHIs that operate within normal parameters and evade traditional detection.
Conclusion
Non-human identities outnumber human identities by 10-50x in most enterprise environments and often hold broader, more persistent access to critical systems. Yet they receive a fraction of the security attention dedicated to human identity programs.
This disparity creates exploitable blind spots where attackers operate. Compromised service accounts provide persistent backdoors. Stolen OAuth tokens enable lateral movement across your SaaS supply chain. Forgotten API keys with admin permissions represent low-resistance attack paths. Shadow NHIs created without security review accumulate into ungoverned attack surfaces.
Traditional identity tools focus on human lifecycle, privileged human access, and login events. They miss non-human identities that authenticate once and then make thousands of API calls, that lack MFA by design, and that accumulate permissions over years without review.
Securing non-human identities requires specific practices: comprehensive inventory including shadow NHIs, least privilege enforcement based on actual usage, credential lifecycle management with rotation and expiration, behavioral monitoring that detects compromised credentials acting normally, and governance over NHI creation and recertification.
The stakes are clear. Major breaches like Salesloft-Drift demonstrated how compromised non-human identities enable privilege escalation, persistent access, and supply chain compromise affecting hundreds of downstream organizations.
Next steps: Inventory your non-human identities across SaaS applications. Identify toxic combinations where stale NHIs retain overprivileged permissions. Implement behavioral monitoring that detects anomalies in NHI activity. Establish governance processes for NHI creation, recertification, and deprovisioning. Consider platforms purpose-built for NHI security in SaaS environments that provide the behavioral context and continuous discovery that traditional tools lack.
The invisible workforce of non-human identities powers your SaaS ecosystem. Securing that workforce requires visibility, behavioral understanding, and governance frameworks designed for machine identities, not human users.
