TIDR vs NHIDR: Behavioral Detection for Non-Human Identities

The identity threat detection category has too many acronyms. ITDR. NHIDR. TIDR. The differences matter less than the underlying question: when an NHI does something unexpected, do you notice, and can you respond in real time?

This post is a working engineer's tour of behavioural detection for non-human identities: what signals actually work, where they fail, and how the detection pipeline needs to change when the "user" is a service account issuing 400 API calls per second.

The practical distinction between ITDR and NHIDR (Non-Human Identity Detection and Response) is primarily one of signal source and baseline assumptions. ITDR was built for humans. Humans log in infrequently. They authenticate from a small number of devices. They do not issue 400 API calls per second. When you apply ITDR tooling to NHIs, you inherit the assumptions of a system designed for a very different actor, and those assumptions fail in ways that are expensive to debug.

Why NHI detection is harder than human detection

Human ITDR is built on a relatively simple premise: a human's behaviour is consistent, slow, and geographically bounded. A login from a new country at 3 AM is suspicious because humans do not teleport. That premise does not apply to service accounts.

• High baseline volume. A healthy service account may issue thousands of API calls per hour. The signal-to-noise ratio at that volume makes simple threshold alerts unworkable.
• Legitimate variability. Batch jobs spike heavily at scheduled intervals. A billing export that runs at midnight looks like a DDoS by call-volume metrics. Detection needs to understand schedules, not just volumes.
• No geographic anchor. A service account running on a global CDN may legitimately make calls from every AWS region in the same minute. IP geolocation, the backbone of human ITDR, is meaningless here.
• Multiple identities per workload. A Kubernetes pod may carry a node identity, a service account identity, and a workload federation identity simultaneously. An anomaly on one may or may not correlate with the others.
• AI agent non-determinism. An AI agent's API call pattern changes every session based on what the LLM decided to do. Baselining is harder because the "normal" state is a probability distribution, not a deterministic pattern.

Signals that actually work

The permission usage signal deserves special attention because it is the highest-precision indicator of a compromised credential being used by an attacker. An attacker who obtains a service account credential will almost never know exactly what that credential has been used for historically. They will probe: call an API they know exists, see what is permitted, escalate to something more interesting. That probing looks, in the permission-usage signal, like a sudden expansion of the call vocabulary. It is detectable before any data leaves the environment.

Where naïve detection breaks

• Flat thresholds. "Alert if calls > 1000/hour." This tells you every deploy day is under attack.
• Single-source signals. Only looking at CloudTrail. Only looking at IdP logs. Real threats cross planes.
• Missing peer sets. Comparing an identity to itself, not to identities that share its role. A misconfigured identity looks normal against its own broken history.
• Detection without enforcement. The alert fires at 02:00; the analyst reads it at 09:00; the credential has already exfiltrated by 04:00.
• No session context for AI agents. AI agent calls need to be evaluated in session context — the sequence of tool calls matters, not just the individual call. A read followed immediately by a write to a different system is a different signal than either call in isolation.

The peer-set problem

One of the most underappreciated problems in NHI detection is peer-set construction. Most detection systems baseline an identity against its own history. This is insufficient because it normalises whatever the identity has done in the past — including any compromised behaviour that was never caught.

A stronger model baselines each identity against a peer set: all service accounts with the same role signature, deployed in the same environment, with the same owner team. If the peer set's median call rate is 200/hour and a specific identity is running at 1,800/hour, that is a signal even if the identity's own history shows it occasionally spiking that high. Peer-set comparison catches configuration drift and subtle compromises that self-comparison misses.

Peer sets are expensive to compute correctly — you need to define the right dimensions (role, environment, team, call target) and keep them fresh as the identity estate changes. This is one of the reasons NHI detection is hard to build in-house: the baselining infrastructure is a full data-platform problem, not a detection-rules problem.

A minimal detection pipeline

pipeline:
  ingest:
    sources: [cloudtrail, k8s_audit, mcp_gateway, idp, siem]
    delivery: at_least_once
    partitioning: per_tenant

  featurise:
    windows: [5m, 1h, 24h, 14d]
    features:
      - call_rate_delta
      - resource_fanout
      - permission_novelty
      - peer_set_drift
      - time_of_day_delta

  score:
    method: fusion       # weighted sum of features
    baseline: rolling_14d
    peer_group: role_signature
    weights_by: tenant_config

  act:
    thresholds:
      warn: 0.60
      elevate_assurance: 0.75
      revoke_session: 0.90
    handoff: decision-service

The `handoff: decision-service` line is where TIDR becomes TIDR rather than NHIDR or ITDR. When the anomaly score exceeds the `revoke_session` threshold, the event is not written to an alert queue — it is sent synchronously to the decision-service, which evaluates the current session's access and can revoke the credential in real time. The analyst queue receives a retrospective notification once the session has already been terminated.

Tuning for AI agents specifically

AI agents require a detection model that accounts for non-determinism. Unlike a batch job with a predictable call sequence, an agent's behaviour varies by session based on user intent and LLM reasoning. Standard baselines that assume a deterministic call pattern will produce either very high false-positive rates (the agent "deviates" from its baseline on every interesting session) or very low recall (the thresholds are so loose that real anomalies are missed).

The better model for agents is constraint-based rather than baseline-based. Instead of "this agent normally calls these APIs," define "this agent is permitted to call these APIs." Deviation from the permitted set is the signal, not deviation from historical behaviour. This aligns with how the MCP gateway works: per-call policy enforcement provides the permitted-set definition, and any call that hits a policy denial is an immediate anomaly — regardless of whether the agent has called that API before.

What to build vs. what to buy

The baselines and correlations are not the hard part. The hard part is plumbing: getting every event source into the same stream, keeping features fresh across tenants, and closing the loop back to enforcement in seconds. That is where dedicated platforms like TigerIdentity earn their spot.

If you build in-house: give yourself six months, budget for a data platform, and prototype on a single source (CloudTrail) before promising multi-source correlation. If you buy: insist on enforcement, not alerts.

The enforcement question is the most important purchasing criterion. Many vendors will show you beautiful anomaly dashboards. Ask them what happens when the anomaly score hits 0.90 at 2 AM on a Saturday. If the answer involves "your analyst reviews it in the morning," the product is not a detection-and-response system. It is an alert generator with a marketing rebrand.

TigerIdentity's TIDR module is architected with enforcement as the primary output. Alerts are a secondary artefact generated for compliance and audit purposes. The primary action — session revocation, credential expiry, assurance elevation — happens automatically, in seconds, based on policy thresholds you configure.