Threat Intelligence intermediate T1078.004

45 to 1: Non-Human Identities Are Your Biggest Detection Blind Spot

You have ~45 non-human identities per human — and the signals your detection runs on (MFA, impossible travel, login geo) don't exist for any of them.

March 15, 2026 · 17 min read · Gowthamaraj Rajendran

Your detection program was built for the human in the org chart. MFA prompts, impossible-travel rules, off-hours login alerts, device posture checks, UEBA baselines of when Dave in Finance usually signs in — all of it assumes a person, with a laptop, in a timezone, who logs in and goes home.

There are now roughly 45 non-human identities for every human one in the modern enterprise [1]. In cloud-native shops it runs to 144 to 1 [5]. Service accounts, OAuth apps, API keys, CI/CD tokens, workload identities, and increasingly AI agents. Not one of them has a laptop, a timezone, or an MFA prompt. Which means not one of them generates the signals your detection program was built to catch.

The identity perimeter moved years ago. Most detection programs didn’t move with it.

The Perimeter Moved and Multiplied

The ratio is not a rounding error you can wave away. Machine identities went from around 50,000 per enterprise in 2021 to roughly 250,000 in 2025 — a 400% increase [6]. The non-human identity population grew 44% in a single year, H1 2024 to H1 2025 [5]. This is now the majority of your identity attack surface, and it is the fastest-growing part of it.

But “non-human identity” is too coarse to detect on. The first useful move is to stop treating it as one blob. There are at least three classes, and they behave nothing alike:

Service accounts and automation. Cron jobs, ETL pipelines, CI/CD deploy tokens, RPA bots, workload identities. These are the most predictable things in your environment: one job, one source, one schedule, forever. Deterministic by design.

SaaS-to-SaaS and OAuth integrations. A token your org granted to a third-party app — a chatbot, a CRM connector, an analytics integration — so it can act inside your tenant on your behalf. The behavior envelope is wider and lives partly outside your control.

AI agents. The new class, and the one that breaks the model. An agent is non-deterministic on purpose. It decides what tool to call next based on a prompt and a goal, which means its “normal” is a moving target — and, as we’ll get to, it usually acts through one of the other two classes’ credentials, which makes it nearly invisible at the identity layer.

If you can’t say which class an identity belongs to, you can’t say what its normal looks like, and you can’t detect deviation from a normal you never defined. Classification comes before detection. Hold that thought — it’s the spine of the whole argument.

The Capability Exists. The Deployment Doesn’t.

Here’s the honest version of the blind-spot claim, because “nobody detects non-human identities” is lazy and the data doesn’t support it.

The technology exists. Non-Human ITDR is a real product category now — Astrix ships exactly this, with dedicated non-human and AI-agent threat detection; Oasis and Clutch are in the same space. Mature orgs do have service-account detections: service account used interactively, service account added to an admin group, login from a new country. Behavioral baselining of machine identities is a documented, available capability.

What’s missing is deployment. The numbers tell the story:

Only 12% of organizations are highly confident in their ability to prevent attacks via non-human identities [2].
79% of IT and security professionals feel ill-equipped to prevent NHI-based attacks [2].
92% are not confident their legacy IAM can manage the risks of NHIs and AI [2].
And the operative one for detection engineers: few organizations track deeper indicators such as privilege misuse, access anomalies, or non-human identity abuse.

This is the same shape as Stage 1 of The Detection Funnel: the gap is not between what can be detected and what’s possible — it’s between what’s possible and what’s actually been built, enabled, and connected to a working signal. The funnel post showed SIEMs have telemetry to detect 90% of ATT&CK techniques but rules for 21%. NHI detection is the same problem with a worse ratio, because the surface is 45 times larger and the tooling is younger.

So the precise claim is this: the static rules exist in mature shops, the behavioral capability exists in the market, and almost nobody has wired the behavioral layer across the non-human majority. The blind spot is an adoption gap, not a capability gap. That’s worse, not better — it means the only thing between most orgs and this coverage is the decision to build it.

NHIs Should Be Easier to Detect — Which Is the Tragedy

Here is the strongest argument against the entire premise: non-human identities are the easiest thing in your environment to baseline. A human is unpredictable — they travel, work weekends, buy a new phone. A service account does exactly one thing, from one place, on a schedule, forever. A CI/CD token deploys from the same pipeline every time. Anomaly detection should work better on machines than on people, because the baseline is so tight.

That’s correct. And it’s exactly why the blind spot is indefensible.

The predictability is real and the field has left it on the table. The reason isn’t that machine behavior is hard to model — for service accounts and automation, it’s the easiest modeling problem in security. The reason is that three things have to be true before that tight baseline does any work, and in most orgs none of them are:

Someone is actually computing a per-identity baseline for non-human principals. (Mostly nobody is — “few track NHI abuse.”)
Each identity is classified, so you know which envelope applies. (Mostly they aren’t.)
The signals security teams watch are signals that exist for a machine. (Mostly they aren’t — see the next section.)

The predictability is an opportunity, not a solved problem. The rest of this post is about claiming it.

Salesloft Drift: What an NHI Compromise Actually Looks Like

This is not a film-plot threat. Abusing non-human identities is standard red-team tradecraft for identity-based attack paths — service accounts and tokens are where you go for quiet lateral movement and persistence — and in August 2025 it played out at scale in public.

Attackers tracked as UNC6395 compromised Salesloft’s Drift, an AI chatbot integrated into Salesforce and other platforms over OAuth, and stole the OAuth refresh tokens that customers had granted to the Drift app. With those tokens they reached into more than 700 organizations’ Salesforce environments — Cloudflare, Zscaler, and Palo Alto Networks among the named victims [3]. They ran automated Python tooling to query and exfiltrate, combing records for plaintext AWS keys, Snowflake tokens, and VPN credentials to fuel follow-on compromise. Then they deleted the query logs.

For a detection engineer, three facts matter more than the headline:

MFA was irrelevant. A valid OAuth token doesn’t re-authenticate. There was no login event to flag, no second factor to fail.
The activity sat inside the trust boundary. The OAuth token made attacker queries indistinguishable from legitimate chatbot activity. Enterprises could see that Drift had access — not what it was doing with that access.
No human signal existed to fire. No impossible travel, no new device, no off-hours anomaly — because there was no human in the loop to generate any of them.

That is the canonical shape of NHI compromise: a trusted non-human principal, a valid credential, behavior inside the trust boundary, and a detection stack with nothing pointed at it. Drift was an OAuth attack specifically — the broader class, and what actually fires against it, is in OAuth Abuse in SaaS.

Every Human Signal Returns Null

Every human identity detection signal returns null against non-human identities, which outnumber humans 45 to 1

Walk down the list of what a modern identity-threat program actually alerts on, and check each one against a service account or an OAuth integration:

MFA / MFA fatigue (T1621) — NHIs don’t do MFA. Null.
Impossible travel — a workload identity has no location, or its location is a datacenter that never moves. Null.
Off-hours login — a batch job runs 24/7 by design. Null.
New device / device posture — there is no device. Null.
Brute force / password spray — token-based auth, nothing to spray. Null.
UEBA “user normal” — built on human work patterns that don’t map to a machine.

Every primitive the identity-detection industry spent a decade building is a human-behavior primitive. Against the 45-to-1 majority of your identity population, the entire toolkit returns null. That’s not a coverage gap you tune your way out of — it’s a category error in what the detections measure. And it’s exactly why a compromise like Drift produces a green dashboard: “we have identity detection” is true, but the identity detection covers the 1, not the 45.

AI Agents: The Class You Can’t Tell Apart

Service accounts are the easy case. AI agents are the one that breaks the model, and not because anyone’s been lazy — because the industry hasn’t defined the problem yet.

Start with the question a detection engineer would ask: in CloudTrail, or Entra ID sign-in logs, how do I tell an AI agent’s API call apart from a cron job’s? Usually you can’t. An agent rarely has its own first-class identity. It acts through a credential — a human’s delegated token, or a service account, or an OAuth grant. The agent’s calls and the automation’s calls share the same principal, so at the identity layer they’re the same entity doing different things, and nothing in the log says which.

This isn’t a local tooling gap you’ve failed to close. It’s an open problem the field is actively standardizing right now:

NIST’s Center for AI Standards and Innovation launched the AI Agent Standards Initiative on February 17, 2026 [7]. Its third pillar is, in NIST’s own words, agent identity — “reliably distinguishing AI agents from human users within enterprise systems” and ensuring agents act only within explicitly delegated scopes. The premier US standards body is treating “tell the agent apart from the human” as unsolved research.
The NCCoE published a Feb 2026 concept paper to adapt existing identity and authorization frameworks for AI agents [8] — which exists precisely because authoritative standards don’t yet.
OAuth 2.0 handles one-hop delegation cleanly, but the moment delegation becomes recursive, the authorization chain loses its anchor. An agent calling a tool that calls another agent is exactly that recursive case. The protocol most NHI authorization rides on wasn’t built for it.
The OWASP Top 10 for Agentic Applications (2026) now enumerates Agent Goal Hijack, Tool Misuse, and Identity & Privilege Abuse as first-class risks [9].

So when someone asks why your SOC can’t cleanly separate agents from automation, the honest answer is: the industry can’t either, yet, and it’s writing the standards as we speak. What that means operationally is that for the agent class you don’t get to wait for a clean identity primitive. You detect at the layer where the agent’s intent shows up — the tool calls, the scope of actions, the resources touched — not at the authentication layer, where the agent is wearing someone else’s badge.

What You Actually Detect: Classify First, Then Baseline

The steelman was right — the fix is per-identity behavioral baselining. But you can’t baseline one envelope across three classes that behave nothing alike. Classification comes first, and you do not need a perfect inventory to start.

Bootstrap classification with heuristics. You don’t have to wait for an IAM team to hand you a clean registry. Naming conventions, the auth method (non-interactive service principal vs. interactive), the calling ASN, the action profile, and the grant metadata are enough to sort most identities into human / agent / service-and-automation with reasonable confidence. Imperfect classification you can act on beats perfect classification you’re still waiting for.

Define the expected envelope per class, by the book. For each class, write down what it’s supposed to do before you alert on what it does. A deploy token’s envelope: this pipeline, these repos, this rate, these hours. An OAuth integration’s envelope: these scopes, these object types, this volume. Skip this step and the baselines get messy fast, because “anomaly” against an undefined normal is just noise — and noise you generate on the largest identity population in your environment is how you manufacture alert fatigue at scale. Building detections on un-inventoried chaos doesn’t add coverage. It adds queue.

Then baseline the dimensions machines make tight:

Scope of access used vs. granted. A token granted broad scopes but historically calling three API actions, suddenly calling forty — that’s the Drift pattern.
Call volume and rate. A service account whose baseline is 12 calls/hour issuing 200 in ten minutes.
Source ASN / IP range. A workload identity that always egresses from one cloud range, now calling from a residential or unfamiliar-cloud ASN.
Peer-group comparison. Compare an identity against the baseline of its class peers — all CI deploy tokens, all Drift-class integrations — so a newly provisioned identity with no history still inherits a sane expected envelope.

The telemetry already exists: CloudTrail, Entra ID sign-in and audit logs (service principal sign-ins included), Okta system log, SaaS audit APIs, OAuth grant and consent events. The work is computing a per-principal baseline for the non-human majority and alerting on deviation — scoped by class.

# Detection rationale: an OAuth integration or service principal that
# historically exercises a narrow set of resources suddenly fanning out to
# many is the Salesloft Drift pattern — a valid, trusted token used to do far
# more than the identity ever normally does. This is behavioral, not
# signature-based: it keys on deviation from the identity's own baseline, so it
# must be scoped to the service-account/integration class, not human sign-ins.
title: Non-Human Identity Scope Expansion — Sudden Broad Resource Access
status: experimental
logsource:
  product: azure
  service: signinlogs
detection:
  selection:
    # non-interactive service principal / managed identity sign-ins only
    UserType: 'ServicePrincipal'
    ServicePrincipalId|exists: true
  condition: selection | count(distinct ResourceDisplayName) by ServicePrincipalId > 15
  timeframe: 1h
falsepositives:
  - New automation legitimately broadening scope (correlate with a change ticket)
  - First run of a newly provisioned workload (suppress during an onboarding window)
  - Platform migration re-pointing an existing principal at many resources
level: medium
tags:
  - attack.persistence
  - attack.t1078.004
  - attack.t1550.001

One rule won’t cover the class. But it shows the shape: the detection is a deviation from a per-identity, per-class baseline, not a known-bad value — because for non-human identities there usually is no known-bad value, only “this principal doing something this principal has never done.”

The Bigger Ask: Every Non-Human Identity Needs an Owner

Detection engineering can flag the anomaly. It cannot answer the only question that resolves it: is this service account supposed to be doing this? That question needs an owner, and most non-human identities don’t have one.

The numbers are bleak. 51% of organizations report no clear ownership of AI identities; 78% have no documented policy for creating or removing them; 16% don’t even track when new AI credentials are created [2]. The #1 risk in the OWASP Non-Human Identities Top 10 (2025) [4] isn’t a clever exploit — it’s improper offboarding. Every orphaned token is a baseline that drifts unwatched and a credential nobody will ever rotate or revoke — the standing, dormant privilege I dig into in Identity Creep, where it’s the single most reliable way into an organization.

This is where I’ll be honest about the limits of the detection seat. Detection and response is a collaborative function — it lives or dies on what other teams feed it. An NHI inventory, with every non-human principal mapped to a human owner, a purpose, and an expected envelope, is a cross-functional asset-management job. D&R can bootstrap classification with heuristics and start shipping detections on the highest-risk classes today. But the durable version — the one where alerts resolve instead of pile up — requires asset management as an XFN partner that helps build and maintain the pipeline.

Which of those two paths you can actually run — heuristics-and-ship versus XFN-inventory-first — comes down to organizational priority and support. That’s not a detection problem. That’s an org-structure and security-culture problem, and it’s the one that decides whether any of this gets built.

Closing

The machines are predictable. That was the steelman’s whole point, and it’s true: a service account that does one thing forever is the easiest anomaly-detection target in your environment. The reason it’s also your biggest blind spot is that the identity-detection industry pointed its tools at the unpredictable humans and ignored the predictable machines outnumbering them 45 to 1.

The fix is not more human-identity tuning. It’s three moves in order: classify your non-human identities into human, agent, and service/automation; define the expected envelope per class before you alert; baseline each principal against its own normal and its peer group. And underneath all of it, an owner for every identity — because a population nobody owns is a population nobody can answer for when the alert fires.

AI agents are about to make this faster and worse. They’re arriving without their own identities, acting through credentials that were never scoped for them, and the standards to tell them apart are being written this year, not last. The orgs that already classify and baseline their non-human identities will absorb that wave. The ones still detecting only the human in the org chart will find out — like the 700 did — that the badge said Drift and the queries said otherwise, and nothing was watching the difference.

Resources

The Identity Crisis — Rubrik Zero Labs, 2025 (non-human identities outnumber humans roughly 45 to 1).
State of Non-Human Identity and AI Security Survey Report — Cloud Security Alliance / Oasis, Jan 2026 (NHI population growth; prevention-confidence, ownership, and tracking gaps).
Widespread Data Theft Targets Salesforce Instances via Salesloft Drift — Google Threat Intelligence Group (UNC6395; stolen Drift OAuth tokens used against 700+ Salesforce tenants).
Non-Human Identities Top 10 — OWASP, 2025 (improper offboarding ranked the #1 NHI risk).
NHI & Secrets Risk Report — H1 2025 — Entro Security Labs, 2025 (cloud-native environments run 144 non-human identities per human, up from 92:1 in H1 2024; NHI population grew 44% year over year, H1 2024 to H1 2025).
The Human-Machine Identity Blur: A Unified Framework for Cybersecurity Risk Management in 2025 — arXiv:2503.18255, March 2025 (machine identities per enterprise grew ~50,000 in 2021 to ~250,000 in 2025, a 400% increase).
Announcing the AI Agent Standards Initiative for Interoperable and Secure Innovation — NIST Center for AI Standards and Innovation (CAISI), Feb 17, 2026 (agent identity — reliably distinguishing AI agents from human users — named a core pillar).
New Concept Paper on Identity and Authority of Software Agents — NIST NCCoE, Feb 5, 2026 (proposes adapting existing identity and authorization frameworks for AI agents).
OWASP Top 10 for Agentic Applications for 2026 — OWASP Gen AI Security Project, Dec 2025 (ASI01 Agent Goal Hijack, ASI02 Tool Misuse, ASI03 Agent Identity & Privilege Abuse).