Non-Human Identities Are the New Insider Threat: A Governance Playbook for AI Agents

In March 2025, attackers compromised OAuth tokens tied to a third-party sales-engagement integration between Salesloft and Drift. The tokens were valid. They belonged to a trusted, previously-authorized connection between two SaaS platforms customers already used daily. No malware executed. No password was phished. The attackers simply used a legitimate machine credential to do what it was already permitted to do; reach into Salesforce environments across more than 700 downstream organizations. Security researchers at Obsidian measured the blast radius at roughly ten times the scale of prior comparable incidents, because the compromise propagated through a web of trusted, non-human connections rather than a single account.

Nothing about that incident required a sophisticated exploit. It required only what most enterprises already have in abundance and almost none of them are governing: non-human identities like the API keys, service accounts, OAuth tokens, and increasingly, autonomous AI agents that authenticate and act inside enterprise systems without a person behind each individual action. LangProtect's earlier coverage of the Vercel/Context.ai OAuth breach documented a structurally identical pattern months earlier, specifically involving an AI tool granted broad OAuth scope by a single employee and this is not an isolated failure mode, it's the default one.

This guide covers what non-human identity actually means, why AI agents turn a manageable governance problem into an unmanageable one, the specific risks that follow, and the framework enterprises need to bring machine identities under the same rigor long applied to human ones, before the next OAuth grant becomes the next 700-company blast radius.

What Are Non-Human Identities, and Why Do AI Agents Make Them an Enterprise-Wide Problem?

Non-human identities (NHIs) are digital credentials like API keys, OAuth tokens, service accounts, certificates, and now autonomous AI agents, that authenticate and act on behalf of a system, workload, or automated process rather than a human logging in. They exist outside traditional identity and access management, because IAM was built to govern people: someone logs in, does something, logs out, and a session timeout eventually ends the credential's usefulness even if no one remembers to revoke it. None of that applies to an NHI. A service account doesn't log out. An API key doesn't expire because someone forgot about it over a long weekend. It simply remains valid, indefinitely, until someone actively revokes it, and in most organizations, no one owns that job.

The scale of this population has moved fast enough to become a headline statistic on its own: KPMG's Cybersecurity Considerations 2026 report puts the machine-to-human identity ratio above 80 to 1 in the average enterprise, with the raw count of machine identities climbing from roughly 50,000 in 2021 to 250,000 in 2025 at a typical organization. Astrix Security, now part of Cisco, cites a comparable figure directly on its own site: agents and NHIs outnumber humans roughly 100 to 1, with 99% of them sitting outside IAM and audit review cycles entirely. Other research places the ratio anywhere from 25:1 to 100:1 depending on methodology, the exact multiple varies, but every credible source, from analyst firms to the security vendors built specifically to solve this problem, agrees on direction and magnitude: NHIs are already the largest identity population in the enterprise, by a wide margin, and it's not close.

AI agents didn't create this category. They accelerated it past the point most identity programs can absorb. Every time an employee connects an agent to Slack, Salesforce, a code repository, or an internal database, a new OAuth token or API key gets minted; a new NHI, almost never added to a centralized inventory. Microsoft Copilot Studio users alone have collectively created more than one million AI agents, and Salesforce reported roughly $440 million in agentic AI revenue in 2025, both numbers describing the same underlying trend: agent creation has become as easy as filling out a form, while identity governance for each agent created has not kept pace at all.

Three things distinguish an AI agent's non-human identity from a traditional service account, and each one is what makes this urgent rather than merely inconvenient:

• Agents accumulate access across many systems, not one narrow integration. A traditional service account typically connects System A to System B for one purpose. An agent is often granted read/write access across email, a CRM, a code repository, and internal documentation simultaneously, because that's what makes it useful.
• Agents operate continuously and autonomously, generating their own follow-on actions and, in some architectures, their own credentials, provisioning access to complete a task without a predefined workflow a security team reviewed in advance.
• Agents are created by end users, not IT. An employee connecting an agent to a SaaS tool is functionally provisioning a new machine identity, with real permissions, without going through anything resembling the request-and-approval process that governs a new employee's access.

What Are the Core NHI Risks Introduced by AI Agents?

Five risk patterns account for the large majority of documented NHI-related incidents involving AI agents and the machine credentials they depend on. Each is distinct enough to require its own control like treating "AI agent risk" as a single undifferentiated category is exactly how governance programs leave gaps.

Identity Sprawl

Sprawl is the precondition every other risk on this list depends on: you cannot govern what you haven't found. Obsidian Security's research found that 68% of IT security incidents now involve machine identities in some form, and roughly half of enterprises surveyed have already experienced a breach attributable to unmanaged non-human identities specifically. The reason sprawl happens isn't negligence, it's that agent creation has no natural checkpoint. Connecting an AI coding assistant to a GitHub repository, or a customer support agent to a CRM, takes minutes and requires no security review in most organizations, which means the inventory is stale the moment it's compiled.

Standing Overprivileged Access

Most AI agent deployments grant access at a coarse, durable grain which is a a token scoped to "read/write access to Salesforce," not "read access to this specific object for this specific task, expiring in four hours." That gap between what an agent needs for its current task and what it's actually been granted is what turns a routine compromise into a large-scale one. The 2026 NHI Reality Report describes this pattern precisely: NHI-based kill chains in 2025 operated through poor access governance, not advanced malware, valid credentials doing things valid credentials were, technically, allowed to do.

OAuth Token and Credential Abuse

This is the mechanism behind both incidents referenced in this guide's opening. OAuth tokens grant durable, delegated access without the session controls applied to human logins; no MFA prompt, no conditional access policy, no timeout tied to a login session. Once an attacker has a valid token, standard detection controls generally don't fire, because the traffic is authenticated and the actions are ones the token was already permitted to take. Research shows AI-related credential leaks surged 81.5% year-over-year in 2025, with credentials tied to AI infrastructure specifically leaking roughly five times faster than credentials tied to core LLM providers.

Unattributed Autonomous Action

An agent operating without a registered identity, a named owner, and a governed permission scope is, from a security program's perspective, invisible. When something goes wrong, there's no reliable way to answer which agent took the action, on whose behalf, under what task, or whether the action was consistent with policy. This isn't a hypothetical gap: it's the exact evidence gap that turns a contained incident into a prolonged, expensive investigation, because reconstructing "what happened" has to start from raw infrastructure logs instead of a governed identity record.

Credential Leakage in Development Workflows

Configuring an agent to connect to internal systems routinely involves handling API keys, connection strings, and tokens directly, and those credentials get pasted into code repositories, chat tools, and tickets as a byproduct of normal setup, not malicious intent. Once committed to a public or even internal repository, a credential is effectively public, and the exposure window often lasts far longer than anyone realizes, because nobody's specifically watching for it.

Agent Impersonation and Poisoned Agent-to-Agent Trust

A sixth risk grows more urgent as multi-agent architectures become more common: an autonomous agent doesn't hold a single identity, it often orchestrates several, and it increasingly communicates with other agents, its own or a third party's, as part of completing a task. That agent-to-agent communication channel creates two failure modes traditional NHI thinking doesn't fully anticipate. Agent impersonation occurs when a malicious or compromised agent successfully presents itself as a trusted one to another agent, inheriting whatever trust the second agent extends without a human ever being in the loop to notice the substitution. Poisoned agent-to-agent communication occurs when a legitimate agent passes along instructions or data it received from a compromised source, and a downstream agent acts on that input as if it were verified, propagating a single compromise across a chain of otherwise-uncompromised systems. Neither failure mode requires a stolen credential in the traditional sense; both exploit trust relationships between machine identities that most governance frameworks, including this one's four-part structure, currently assume are static rather than adversarial.

What Actually Went Wrong in the Documented 2026 NHI Breaches?

Three incidents from the past eighteen months share the same underlying failure pattern, even though they hit different companies through different entry points. Understanding the pattern matters more than memorizing any single incident, because it's the pattern, not the specific vendor that will produce the next one.

The Salesloft-Drift Breach: Trusted Connections, Untrusted Consequences

Attackers compromised OAuth access and refresh tokens tied to the integration between Salesloft's sales-engagement platform and Drift, a chat tool. The tokens were long-lived and broadly trusted, exactly the properties that make an integration convenient for the businesses using it, and exactly the properties that make a compromised token dangerous. Because the tokens were valid, none of the standard detection controls fired: no failed login, no unusual authentication event, no signature match. The blast radius, measured at roughly ten times the scale of prior comparable incidents, came from the trusted relationship between integrated systems rather than from any single compromised human account. More than 700 downstream organizations using the Salesloft-Drift integration were affected through a single point of compromise.

The Vercel/Context.ai Breach: One Employee, One Broad OAuth Grant

As LangProtect covered in detail previously, attackers gained entry to Vercel's internal environment through a compromised Context.ai application after an employee authorized it with broad OAuth permissions against a corporate Google Workspace account. This incident is worth sitting with specifically because it didn't require an attacker to breach any perimeter at all, it required one person, in the ordinary course of adopting a new AI tool, to click "allow" on a permission scope broader than the task required. That single consent grant became the entry point.

OpenClaw/Moltbot: When the Agent Itself Is the Shadow Identity

The two incidents above involve NHIs tied to sanctioned enterprise integrations. A third, more recent case shows what happens when the NHI problem shows up on an employee's own laptop, entirely outside any enterprise system at all.

In January 2026, an open-source personal AI agent which was released under the name Clawdbot, then renamed Moltbot, and finally OpenClaw, went viral, reportedly reaching millions of GitHub repository visits and hundreds of thousands of weekly downloads within weeks. The agent runs locally, operates across messaging apps like WhatsApp and iMessage, retains persistent memory across sessions, and can execute scripts, control browsers, and authenticate to internal and SaaS systems on a user's behalf. On January 31, 2026, security researchers disclosed a critical vulnerability in Moltbook which is the agent's companion social platform that allowed anyone to commandeer any connected agent on the platform; Moltbook was taken offline and every agent's API keys were reset as a result.

What makes this incident distinct from a typical breach writeup is what researchers found underneath it: agents were observed sharing OpenAI API keys with one another, and enterprise security teams who scanned for the tool found it running on corporate endpoints, often misconfigured in ways that could let an attacker establish persistent access to sensitive corporate systems like Salesforce, GitHub, Slack by leveraging exposed API keys, OAuth apps, and cloud credentials the agent had accumulated. In nearly every case researchers examined, these agent-held credentials had no clear ownership, no monitoring, and no lifecycle controls, many were long-lived tokens sitting on an employee laptop, invisible to every enterprise security tool, simply because the agent that held them was never provisioned through any enterprise process in the first place. Cisco's own security team wrote a public analysis of the incident, noteworthy given Cisco's recent acquisition of an NHI-focused security vendor and Gartner's guidance to enterprises was blunt: block OpenClaw downloads and network traffic outright until the tool's identity and credential handling could be properly assessed.

The lesson this incident adds to the two above isn't a new attack technique, it's a reminder that the NHI problem doesn't wait for IT to provision anything. An employee installing a personal AI agent on their own laptop, and connecting it to their own accounts, creates enterprise-relevant non-human identities the security team never approved, never inventoried, and in most cases never even learned existed until a researcher's disclosure forced the question.

The Common Thread: Governance Failure, Not Exploit Sophistication

None of these three incidents required custom malware, a zero-day vulnerability, or a sophisticated technical exploit and even the OpenClaw vulnerability itself was a flaw in the platform's own authentication design, not a novel attack technique. The 2026 NHI Reality Report states the pattern plainly: NHI-based kill chains in 2025 operated through poor governance, not advanced malware valid credentials, doing things valid credentials were technically permitted to do, because nobody had scoped, monitored, or time-limited the permission in the first place. Once an attacker holds a valid NHI credential, the operational playbook is consistent across incidents: establish persistence silently (a service account has no session timeout to force re-authentication), move laterally through whatever the token's scope permits, and exfiltrate or escalate without ever needing malware that a signature-based tool could catch. This is exactly why the four-part framework in the next section leads with discovery and access scoping rather than detection; by the time detection matters, in each of these incidents, the credential was already doing exactly what it had been authorized to do.

How Is Governing AI Agent NHIs Different From Governing Traditional Service Accounts?

Non-human identity as a category predates AI agents by decades like service accounts, API keys, and system-to-system integrations have existed since enterprise software started talking to other enterprise software. Treating agent governance as "the same problem, more of it" undersells three structural differences that change what an effective control actually needs to do.

Traditional NHIs are provisioned by IT; agent NHIs are provisioned by anyone. A service account connecting a billing system to an ERP typically goes through some form of technical review, because setting it up requires engineering effort. Connecting an AI agent to a SaaS tool increasingly requires nothing more than clicking through an OAuth consent screen; a capability now available to any employee, not a controlled technical process. This is precisely what happened in the Vercel/Context.ai incident: the provisioning event was a single click, not a change-managed deployment.

Traditional NHIs have a fixed, narrow purpose; agent NHIs are granted broad access to remain useful across unpredictable tasks. A service account moving invoice data from System A to System B needs exactly the access required for that one data flow, and nothing else; the narrow purpose makes narrow scoping natural. An agent, by contrast, is often deliberately granted broad access because its value comes from flexibility across tasks that weren't fully specified in advance. That design tension; usefulness wants breadth, security wants narrowness; doesn't really exist for traditional service accounts in the same way, which is why agent governance can't just reuse traditional NHI playbooks unmodified.

Traditional NHIs act predictably; agent NHIs can generate their own follow-on actions. A service account performs the specific, predefined operation it was coded to perform. A sufficiently autonomous agent can decide, in the course of completing a task, to take actions nobody explicitly programmed in advance for querying a different system, chaining a second tool call based on the first result. That autonomy is the entire point of deploying an agent rather than a fixed integration, and it's also what makes static, point-in-time access review insufficient. Governance has to account for what an agent could do with its granted scope, not just what it was originally set up to do.

None of this means traditional NHI controls are wrong for traditional NHIs like inventory, scoping, and lifecycle management remain the right foundation. It means AI agents need those same foundational controls applied with tighter defaults and continuous re-evaluation, because the provisioning path is more permissive and the behavior is less predictable than the service accounts NHI programs were originally built around.

Why Don't Traditional IAM and PAM Programs Cover Non-Human Identities?

Identity and access management, and privileged access management, were both designed around a shared assumption: a human is on the other end of the credential, and human behavior has predictable shape like a login, a session, activity, a logout, and eventually an offboarding event that ends access entirely. NHIs violate every part of that assumption.

MFA doesn't apply. Multi-factor authentication depends on a human being present to receive and respond to a challenge. A service account or an autonomous agent has no phone to receive a push notification, which means an entire category of identity protection simply doesn't extend to the identity population that now outnumbers humans by tens or hundreds to one.

Session timeouts don't apply. A human's access naturally decays, people go on vacation, change roles, leave the company, and access reviews eventually catch the gap. A valid OAuth token or API key has no equivalent decay function. It remains exactly as powerful the day after it's created as it is two years later, unless someone actively revokes it.

"Normal behavior" has no baseline. Human-centric anomaly detection flags activity outside normal working hours, unusual login locations, or atypical access patterns. An AI agent operating continuously, globally, and by design outside a 9-to-5 pattern doesn't fit that baseline at all, the detection logic built for people actively works against detecting agent misuse, because everything an agent does looks "unusual" by human standards and therefore blends into noise rather than standing out as a signal.

Lifecycle management doesn't exist by default. Employee onboarding and offboarding are established HR-linked processes almost every organization has. Agent and NHI provisioning has no equivalent standard process in most enterprises like an agent gets created, granted access, and, months later, may or may not still be doing the job it was created for, with no review checkpoint forcing anyone to check.

None of this means IAM and PAM investments were wrong, they remain essential for the identity population they were built to govern. It means NHIs, and AI agents specifically, require a parallel governance layer built around how machine identities actually behave, not a retrofit of controls designed for people.

What Scoped Access Actually Looks Like Compared to Standing Access

The difference between the standing-access pattern behind most NHI incidents and a properly governed credential isn't abstract, it shows up directly in how access is structured and what happens when it's denied.

A standing-access grant typically looks like a single broad flag with no expiration and no distinction between what the identity can see versus what it can actually do:

// Standing access: what most agent OAuth grants look like today
{
  "grant_type": "oauth_token",
  "scope": "full_access",
  "systems": ["salesforce", "gmail", "google_drive"],
  "expires": "never",
  "granted_by": "employee_click_through",
  "review_cycle": "none"
}

A properly governed credential instead resolves access along the four independent dimensions described above, and critically, a denial returns a structured, actionable response rather than a silent failure or a generic error:

// Governed access: permission resolved per-dimension, per-system
{
  "subject": "agent_47",
  "system": "salesforce",
  "permissions": {
    "discover": "allow",
    "read": "allow",
    "write": "deny",
    "execute": "deny"
  },
  "granted_by": "access_review_workflow",
  "expires": "2026-08-15T00:00:00Z"
}

// What the agent receives when it attempts a denied action
{
  "decision": "DENY",
  "reason": "agent_47 has no write permission on salesforce",
  "action_type": "write",
  "request_access_url": "https://.../request-access?system=salesforce&subject=agent_47"
}

That last field matters more than it looks: a denial that includes a clear reason and a path to request the access closes the loop for the end user without security having to be in the middle of every individual request and it means the first thing that happens when access is missing is a structured, logged event, not an employee finding a workaround.

The second grant can still be compromised and no credential is un-stealable but a compromise of it can only do what it was narrowly permitted to do, for a bounded window, and its unusual use against a specific expected pattern is far easier to detect than "full_access, forever" blending into normal traffic indefinitely.

How Does NHI Risk Differ Across SaaS OAuth Grants, Cloud Workloads, and AI Agents?

The governance framework above applies universally, but where the risk actually concentrates and which control matters most first, it differs depending on how the non-human identity was created. Most enterprises are managing all three categories simultaneously without having separated them in planning, which is itself part of why NHI programs undercount their real exposure.

Employee-Authorized SaaS OAuth Grants

This is the Vercel/Context.ai pattern: an individual employee connects a SaaS tool or AI assistant to a corporate account like Google Workspace, Slack, a CRM, by clicking through an OAuth consent screen. The governance challenge here is concentrated almost entirely at the moment of consent, because that single click is simultaneously the provisioning event and, in most organizations, the only review point that will ever occur.

• Discovery needs to catch every OAuth grant continuously, not through a periodic app-inventory review, since new connections happen constantly and without IT involvement.
• Access scope review needs to happen before the consent grant completes wherever technically possible, since after-the-fact revocation still leaves a window where the grant was live and usable.
• This is the deployment type LangProtect Guardia is built around, visibility into what employees are authorizing, at the point they're authorizing it.

Cloud Workload and Service Account Identities

This is the classic NHI category: service accounts, API keys, and system-to-system credentials that connect internal infrastructure like a billing service calling an ERP, a CI/CD pipeline deploying to production. These are typically IT-provisioned rather than individually authorized, which means the governance gap is usually about lifecycle decay rather than uncontrolled creation: a credential provisioned correctly two years ago for a project that's since changed scope, still holding its original permissions because no offboarding trigger ever fired.

• Lifecycle management matters most here, tying credential validity to the business process or project that created it, so completion or cancellation of that process triggers review.
• Least-privilege scoping needs periodic re-validation against current need, not just correct scoping at creation time.

Autonomous AI Agents

This is the newest and fastest-growing category, and the one this guide has focused on most directly, agents that hold one or more of the credential types above, but combine them with continuous, semi-autonomous operation and the ability to generate follow-on actions nobody explicitly reviewed in advance. The governance challenge compounds the other two: agent credentials are often employee-authorized like SaaS OAuth grants and need lifecycle management like service accounts, while also requiring continuous behavioral monitoring neither of the other two categories demands to the same degree.

• Monitoring matters most distinctly here, because static point-in-time access review can't account for what an agent might do with a given scope across an unpredictable sequence of tasks.
• This is the deployment type LangProtect Vector governs directly, scoping and monitoring what an agent can reach at the tool-call level, not just at the point of initial credential grant.

Treating these three categories identically is itself a common source of blind spots: a governance program built entirely around service-account lifecycle management will systematically miss the employee-authorized OAuth grants that caused the Vercel/Context.ai incident, and a program built entirely around consent-screen review will miss the slow lifecycle decay that leaves two-year-old service account credentials still fully privileged long after their original purpose ended.

What Commonly Stalls NHI Governance Rollouts?

Most NHI governance programs don't fail from a single dramatic gap they stall at predictable points, usually for reasons that have little to do with the technology itself.

Pitfall 1: Treating Discovery as a One-Time Project

An initial inventory sweep feels like completion, but new agents and OAuth grants are created continuously, a discovery effort that isn't re-run on a standing cadence is stale within weeks, not months. Discovery has to be infrastructure, not a project with an end date.

Pitfall 2: Scoping New Credentials Correctly While Ignoring the Existing Backlog

Organizations that get religion about least-privilege access frequently apply it only to newly-provisioned credentials going forward, leaving years of accumulated standing-access grants untouched because remediating them feels disruptive. The existing backlog is usually where the actual risk concentrates, precisely because it's had the most time to be forgotten.

Pitfall 3: No Clear Owner for OAuth Consent Decisions

When any employee can authorize a new AI tool's OAuth request without a review step, "governance" becomes a policy document nobody is positioned to enforce at the moment the decision is actually made; the consent screen. Effective programs move the review point to before the click, not after.

Pitfall 4: Applying Human Risk Scoring to Machine Behavior

Reusing human-identity risk models; flag unusual login times, unusual locations; against NHIs produces enormous false-negative rates, because agents are supposed to operate continuously and globally. Programs that don't build NHI-specific behavioral baselines end up with monitoring that technically runs but rarely triggers anything meaningful.

Pitfall 5: Underestimating How Many Credentials a Single Agent Actually Holds

Governance conversations often center on "how many agents do we have," when the more operationally relevant question is how many distinct credentials each agent holds across the systems it touches, a single agent can easily carry three, five, or more separate tokens, each requiring independent scoping and review, not one governance decision per agent.

Are Regulators Starting to Require NHI Governance Specifically?

Regulatory frameworks are catching up to what security teams have been raising internally for two years, though most obligations currently reach NHIs indirectly, through broader AI and identity requirements rather than NHI-specific rules.

NIST is updating its foundational identity guidance to explicitly address machine credentials. NIST Special Publication 800-63, the digital identity guideline that underpins federal and much enterprise identity practice, is being revised to explicitly cover non-human authenticators, a direct acknowledgment that the existing guidance, built around human authentication factors, doesn't adequately address the identity population that now outnumbers people in most environments. This is a leading indicator worth tracking rather than a current binding requirement, but it signals where baseline identity practice is heading.

Existing AI governance and audit-logging obligations apply directly once an NHI is an AI agent. Article 12 of the EU AI Act requires logs detailed enough to support post-deployment monitoring for high-risk AI systems and an agent's actions are only reconstructable from those logs if the agent's identity, credential scope, and specific actions were captured in the first place. An organization with strong AI governance logging but no NHI-level identity attribution will find it has recorded that an agent did something, without being able to answer which credential, granted by whom, under what scope made the action possible; precisely the gap LangProtect's guide to AI governance implementation covers in the context of runtime evidence more broadly.

Enterprise procurement is beginning to ask the identity question directly. Security review questionnaires increasingly include some version of "what is your AI agent authentication story"; a question largely absent from RFPs before 2025 and expected to become table-stakes rather than a differentiator by the end of 2026. For B2B organizations whose products let customers' AI agents take action on their behalf, this isn't a distant compliance consideration; it's already showing up as a deal-blocking question in active sales cycles.

ISO 27001's asset-management scope already technically covers NHIs, even without explicit language. ISO/IEC 27001:2022's emphasis on identifying and managing "assets" extends, by a reasonable reading, to machine credentials and the systems they access, meaning organizations pursuing or maintaining ISO 27001 certification may already have an audit exposure here they haven't specifically mapped, well before any AI-specific amendment formally addresses it.

The pattern across all four of these is consistent with the broader trend covered in LangProtect's guide to AI governance requirements in 2026: regulators and standards bodies are converging on demonstrable, evidence-based governance rather than policy documentation, and NHI governance because it sits underneath every AI agent's ability to act at all and is quietly becoming a prerequisite for satisfying that expectation, whether or not any single regulation names "non-human identity" explicitly yet.

What Does It Actually Cost to Leave NHIs Ungoverned?

The business case isn't abstract. Four data points converge on the same conclusion from different angles.

Obsidian Security's research found that roughly half of enterprises surveyed have already experienced a breach attributable to unmanaged non-human identities, and 68% of IT security incidents now involve machine identities in some form, this isn't a future risk being planned against, it's a documented majority-adjacent present-tense reality. A separate figure from the vendor space arrives at a similar order of magnitude from the agent side specifically: Astrix co-founder and CEO Alon Jackson cited industry research showing 80% of companies have already experienced unintended AI agent actions, unauthorized system access or data leaks, when announcing the company's agent provisioning product in September 2025. Vendor-cited figures deserve the same scrutiny as any other statistic, but it's worth noting that two independently-measured figures like one general NHI research, one agent-specific, they land in the same 68-80% range rather than contradicting each other.

Astrix's own materials, in the same announcement, name specific companies where NHI-related blind spots have factored into recent security incidents including Microsoft, Salesforce, Okta, and the U.S. Treasury Department. This is a vendor's own characterization rather than an independently adjudicated finding for each named organization, and it's presented here with that caveat, but even treated skeptically, a security vendor naming four organizations of that size in a public announcement is a reasonable signal about where the industry believes the exposure concentrates.

Set against all of this: Gartner projects that 33% of enterprise applications will incorporate agentic AI by 2028, up from less than 1% in 2024, the population most exposed to this risk is scaling roughly thirtyfold in under four years, on top of an already-ungoverned baseline.

The market's own response quantifies the seriousness directly. Palo Alto Networks' $25 billion acquisition of CyberArk in February 2026 was explicitly structured around merging privileged access management with machine identity governance into a single platform. More directly relevant to AI agent governance specifically: Cisco completed its acquisition of Astrix Security, one of the category's founding NHI-focused vendors, with Astrix ending standalone sales of new licenses on June 30, 2026 as its capabilities get absorbed into Cisco's broader security portfolio. NHI-focused security vendors collectively raised more than $340 million in funding during 2026 alone. When multi-billion-dollar acquisitions and hundreds of millions in venture funding concentrate this quickly around a single identity category which is consolidating rather than fragmenting further and it's a reasonably reliable signal that the underlying risk is being priced correctly by people with a direct financial stake in getting that assessment right.

What Does an NHI Governance Framework for AI Agents Actually Look Like?

OWASP's guidance on agentic AI security states plainly that "NHIs play a key role in agentic AI security", because they define precisely what an agent can and cannot do, securing the agent starts with securing the identity underneath it, not the model itself. Enterprises governing non-human identities at agent scale need four categories of control working together, each addressing a failure mode the others can't compensate for on their own. This roughly mirrors the discover-secure-deploy sequencing that's emerged as a de facto standard among the vendors built specifically around this problem: visibility has to come first, governance controls second, and secure-by-design provisioning last, attempting the reverse order consistently produces the standing-access problems this guide opened with.

1. Continuous Discovery - With a Quarantine State, Not Just an Alert

You cannot scope, monitor, or revoke access for an identity you don't know exists. Discovery has to run continuously, not as a quarterly audit, because new agents and their credentials are created faster than periodic review cycles can keep pace with. Astrix Security and the Cloud Security Alliance found that 85% of organizations lack full visibility into third-party vendors connected via OAuth apps alone, a number that only gets worse once individually-created agent connections are added to the same blind spot.

But discovery alone isn't the control, what happens in the moment between "detected" and "reviewed" is where most implementations quietly fail. A well-designed discovery flow treats an unrecognized NHI as neither automatically trusted nor automatically blocked, but as quarantined: visible, logged, and held from taking action until a human makes a decision, without silently failing or defaulting to open access in the meantime. Concretely, this looks like a five-step flow: the new identity or connection is detected, immediately registered in a holding state, any action it attempts is blocked with a structured response rather than a silent failure, an admin is alerted in real time with full context (what was attempted, by whom, against what system), and the admin makes an explicit approve, approve-with-restrictions, or block decision.

This is meaningfully different from either extreme most organizations default to. Auto-approving new connections to avoid friction reintroduces the standing-access problem from scratch. Blocking everything unreviewed by default creates so much operational friction that teams route around the control entirely. Quarantine gives security teams the one thing they actually need: a pause with full context, rather than a binary choice made blind.

2. Least-Privilege Access, Scoped Across Four Distinct Dimensions

The standing-access pattern behind most documented NHI incidents gets addressed by moving from broad, permanent grants to narrow ones, but "narrow" needs a precise definition, or it collapses back into the same all-or-nothing problem it's meant to solve. A useful model scopes every credential along four dimensions rather than one:

• Discover — can this identity even see that a given system or tool exists, independent of whether it can use it
• Read — can it retrieve or query data, with no state change on the target system
• Write — can it create, update, or send; operations with real side effects
• Execute — can it run code, trigger deployments, or take irreversible actions

The inclusion of discover as its own governed dimension, separate from read/write/execute, is easy to overlook and disproportionately valuable. An identity denied read and write access to a sensitive system can often still learn that system exists, see what it exposes, and route around the restriction some other way. Denying discovery itself makes the system invisible but not merely inaccessible, which closes a reconnaissance path that action-level restrictions alone leave open.

Resolution matters as much as the scope itself: when a credential belongs to multiple groups or roles with conflicting grants, an explicit deny at the most specific level should always override a broader allow, an organization needs the ability to lock out one specific agent or user from one specific system even if their group otherwise has access, without restructuring the entire group's permissions to do it. This matters most during incident response and offboarding, where speed and precision both matter.

3. Lifecycle Management: Provisioning and Deprovisioning as a Governed Process

Every NHI needs an equivalent of employee onboarding and offboarding which is a defined process for how a credential gets created, who approves it, how long it's valid for, and what triggers its revocation. Without this, credentials accumulate indefinitely, because there's no natural decay function forcing anyone to reconsider whether access is still needed. This is where most organizations' NHI governance actually stalls: discovery and access-scoping decisions get made once, at creation time, and never revisited.

4. Continuous Monitoring, With Every Decision Logged as a Distinct Type

Anomaly detection built for human behavior doesn't transfer to machine identities, which means monitoring has to establish its own baseline for what "normal" looks like for a given agent or service account like typical systems accessed, typical volume, typical time-of-day pattern if one exists and flag deviation from that baseline rather than a human-shaped one.

Logging quality matters as much as detection here, and a common gap is collapsing every enforcement outcome into a single "blocked" or "allowed" bucket. A more useful audit trail distinguishes why a decision was made: a normal approved action looks different from an action denied for lack of permission, which looks different again from an action held in quarantine pending review, which looks different again from an action stopped because it was actively flagged as a threat. Collapsing these into one signal makes it impossible to later answer whether an incident was a permissions gap, a governance backlog, or an active attack; three problems requiring three different fixes.

Not every system carries equal risk, either, which means monitoring intensity should scale with what's actually being touched. A credential connected to a low-risk internal wiki doesn't need the same scrutiny as one connected to a production financial database or a code-deployment pipeline:

This is also where audit logging earns its value beyond compliance: an incident involving an NHI needs to be traceable to a specific credential, a specific agent, and ideally a specific task or session, not just "the service account did something." A log that records only that access occurred, without recording which of these distinct decision types it was, forces investigators to reconstruct intent from raw activity instead of reading it directly off the record.

The NHI Governance Checklist

Frequently Asked Questions

What is a non-human identity?

A non-human identity (NHI) is a digital credential like an API key, OAuth token, service account, certificate, or AI agent that authenticates and acts on behalf of a system or automated process rather than a person logging in directly. NHIs operate outside traditional human-centric identity controls like MFA and session timeouts, and now outnumber human identities by a wide margin in most enterprises.

How many non-human identities does the average enterprise actually have?

Estimates vary by methodology, but every recent study agrees NHIs substantially outnumber human identities; commonly cited ratios range from 25:1 up to over 80:1, with KPMG's 2026 research placing machine identity counts at roughly 250,000 in the average enterprise, up from around 50,000 in 2021. The exact multiple depends on organization size and how aggressively AI agents have been adopted, but the direction is consistent everywhere it's been measured.

Is an AI agent the same thing as a non-human identity?

Not exactly but an AI agent typically has one or more non-human identities (an OAuth token, an API key, sometimes several across the systems it connects to), rather than being an NHI itself. The distinction matters operationally: governing "the agent" as a single unit can miss the fact that it may be authenticating to five different systems with five differently-scoped credentials, each requiring its own review.

Why can't existing IAM or PAM tools just be extended to cover AI agents?

Because both were architecturally built around human behavior patterns like a login, an active session, and an eventual logout or offboarding event and none of which apply to a machine credential that authenticates continuously and has no natural session boundary. MFA can't challenge a credential with no human to respond, and anomaly detection tuned to flag unusual login times or locations has no equivalent baseline for an agent that's designed to operate continuously. Most organizations end up needing a purpose-built NHI governance layer that feeds structured events back into existing IAM and PAM systems, rather than trying to stretch human-identity tooling to cover a fundamentally different behavior pattern.

What's the difference between OAuth token abuse and a stolen password?

A stolen password typically requires the attacker to also defeat MFA or another secondary control to gain meaningful access, and it's tied to a specific human account that can be identified and reset. A stolen or abused OAuth token often bypasses MFA entirely, because the token itself is the proof of authorization and no secondary challenge is triggered, and because it's frequently attached to a broad, standing grant rather than a single narrow session, a compromised token can move across every system that grant touches before anyone notices.

How quickly can an organization inventory its non-human identities?

An initial discovery pass across major SaaS platforms, cloud environments, and connected AI tools can typically surface the majority of known-unknown NHIs within days for organizations with a limited environment. The harder and longer-running work is finding the truly unknown ones like agent-created tokens, individually-authorized OAuth connections, and credentials embedded in code or configuration which requires ongoing discovery rather than a single pass, since new ones are created continuously.

Does NHI governance require replacing existing identity infrastructure?

No. NHI governance is additive and it typically layers on top of existing IAM and PAM investments rather than replacing them, feeding discovery, scoping, and monitoring data back into the identity systems and SIEM tooling an organization already runs. The goal is extending governance to a credential population those systems were never designed to see, not rebuilding identity infrastructure from scratch.

What triggered the sudden attention on NHI governance in 2026?

Several forces converged at once: agentic AI adoption accelerated fast enough that Gartner projects roughly a third of enterprise applications will incorporate agentic AI by 2028, up from under 1% in 2024; several high-profile OAuth-based breaches (Salesloft-Drift, Dropbox Sign, and others) demonstrated the blast radius of ungoverned machine credentials at scale; and the market responded directly, Palo Alto Networks' $25 billion acquisition of CyberArk in February 2026, and Cisco's completed acquisition of NHI-focused pioneer Astrix Security mid-year, both explicitly framed around bringing machine identity governance into mainstream security platforms, signaled that major vendors now treat this as core infrastructure rather than a niche concern.

Who should own NHI governance inside an organization, like security, IT, or engineering?

In practice, effective programs distribute ownership rather than assigning it entirely to one team: security typically owns policy, risk scoring, and monitoring; IT or platform engineering typically owns the technical provisioning and deprovisioning workflows; and individual business teams need to own the decision of whether a given agent or integration is still needed, since they're the only ones with visibility into whether the underlying task is still active. Programs that assign NHI governance solely to security without engineering buy-in for the provisioning workflow tend to stall at the same handoff point that stalls broader AI governance rollouts which is a policy with no mechanism to enforce it operationally.

How is an AI agent's non-human identity different from the AI model itself?

The model is the reasoning engine; the non-human identity is the credential set that lets the model's outputs translate into real actions against real systems. Two deployments running the identical underlying model can carry entirely different risk profiles depending on what credentials the surrounding application has been granted which is a model with read-only access to a single internal wiki poses a fundamentally different governance problem than the same model wired into a service account with write access across a CRM, an email system, and a code repository. This is why NHI governance and model-level AI governance are complementary but distinct disciplines: one governs what the model is allowed to reason about and generate, the other governs what the resulting actions are actually permitted to touch.

What's the fastest way to reduce risk if a full NHI governance program isn't feasible yet?

Start with the highest-leverage single step: converting standing, unscoped OAuth grants for AI tools into time-bound, narrowly-scoped ones, beginning with whichever integrations touch the most sensitive systems. This doesn't require a complete inventory or a fully built governance program and it directly shrinks the blast radius of the exact failure pattern behind the Salesloft-Drift and Vercel/Context.ai incidents, and it can typically be applied to the highest-risk handful of integrations within days, while the broader discovery and lifecycle program referenced above gets built out in parallel.

Key NHI Terms, Defined

A handful of terms recur constantly in NHI governance discussions and are worth defining precisely, since imprecise use of them is itself a common source of confusion inside security teams building a program.

Identity blast radius — the scope of downstream systems and data a single compromised identity can reach before revocation or containment stops it. For NHIs specifically, blast radius is a function of access scope and credential lifespan, not just the initial point of compromise like a narrowly-scoped, short-lived token has a small blast radius even if compromised; a broadly-scoped, permanent one has a large blast radius by default.

Standing access — a permission grant that remains valid indefinitely, with no expiration tied to the task or time window that originally justified it. The opposite of standing access is time-bound or just-in-time access, which expires automatically and requires re-authorization to continue.

OAuth scope — the specific set of permissions a token grants, expressed as the actions and resources it can access (e.g., read-only access to a calendar, versus full read/write access to an entire email account). Overly broad scope which is granting more than a task requires, is the single most common root cause behind the incidents referenced throughout this guide.

Credential sprawl (or identity sprawl) — the accumulation of NHIs across an environment faster than any inventory or review process can track them, typically because credential creation has no natural checkpoint requiring review.

Agentic identity — the practice of giving AI agents formal, governable identities: registered clients, scoped credentials, short-lived tokens, and audit trails that distinguish an agent's actions from a human's. This is the specific application of NHI governance principles to autonomous agents rather than traditional service accounts.

Zero standing privilege (ZSP) — an access model in which no credential holds persistent, always-on permissions; instead, access is granted just-in-time for a specific task and automatically expires, eliminating the standing-access pattern behind most documented NHI breaches by design rather than by policy enforcement alone. This is no longer a purely theoretical model: Astrix's Agent Control Plane, launched in 2025 specifically for AI agent provisioning, issues exactly this kind of short-lived, precisely scoped credential at agent creation time rather than the long-lived static keys most agents are still deployed with by default and a concrete illustration of the difference between a permanent credential and one that behaves more like a temporary visitor badge, valid only for the specific task and window it was issued for.

Non-Human ITDR (Identity Threat Detection & Response) — the machine-identity-specific counterpart to traditional ITDR, focused on detecting and responding to suspicious NHI activity, credential abuse, and third-party breaches propagating through non-human accounts rather than human ones.

Shadow identity — an NHI created outside any formal provisioning or review process, typically by an individual employee authorizing a tool's access independently, structurally analogous to shadow IT but specifically referring to the credential itself rather than the tool.

Token replay — reusing a stolen or intercepted authentication token to impersonate the original, legitimate holder of that credential, without needing to defeat any additional authentication factor, since the token itself already represents completed authentication.

Machine Identities Are Already Your Largest Population. Start Governing Them Like It.

Every AI agent an enterprise deploys creates new non-human identities like new credentials, new access grants, new potential entry points that are faster than most identity programs were built to track. The Salesloft-Drift breach didn't require a sophisticated attacker. It required an ungoverned OAuth token doing exactly what it was permitted to do, at a scale ten times larger than incidents security teams were already used to responding to.

The organizations getting ahead of this aren't waiting for their next audit to find out how many agents have standing access to production data. They're building continuous discovery, scoped credentials, real lifecycle management, and attribution-capable monitoring now, while the NHI population is still merely enormous rather than completely unmanageable.