Helmwart
← Atlas · Mitigations Tier 2 · Real-composable

MITIGATION · m-identity-monitoring

Identity behaviour monitoring — continuous UEBA for non-human identities

An AI agent operates under a non-human identity (NHI): a service principal, a task role, or a workload credential. That identity produces a stream of access events that, for a well-scoped agent, forms a narrow and predictable behavioural baseline. Identity monitoring applies User and Entity Behaviour Analytics (UEBA) to that stream, alerting when an observed access pattern deviates statistically from the baseline. Because agent behavioural distributions are tighter than those of human users, a deviation is a higher-confidence signal, and a spoofed or stolen credential used from the wrong workload origin is exactly the anomaly the technique is built to detect.

Last reviewed 2026-05-12 · Status: published · Evidence →

At a glance

MATURITY
Tier 2
Available off-the-shelf or as a documented pattern, but newer or less broadly proven. Expect integration work and some operational nuance.
PLACES ON
node
Restricted to node kinds: agent
COVERAGE
1 threat
T9
TRADE-OFFS
LAT
low
COST
low
UX
low
DEV
medium
Latency · cost · UX friction · dev effort.
TL;DR
  • Build a per-identity baseline covering access frequency, workload origin, time-of-day pattern, and resource mix, then alert when any signal deviates statistically from that baseline.
  • Agent identities are tighter UEBA subjects than human users: their action distributions are narrower, so deviation carries a higher signal-to-noise ratio and fewer false positives.
  • A spoofed credential used from the wrong workload origin is the canonical T9 signal: behavioural monitoring is purpose-built to detect exactly that divergence between expected and observed access patterns.
  • The first 30 days after deploying a new agent identity are calibration, not detection. Baseline-independent controls must carry the detection load until the window is stable.

How it behaves

Agent identity emits a credential usage event (API call, auth token use, resource access)
Compare event attributes (workload origin, resource mix, time-of-day, call rate) against 30-day rolling baseline for this identity
Log event, no alert
Fire risk signal: suspend credential pending investigation, open incident ticket
Detection runs out-of-band against persisted telemetry; no latency added to the agent action path. Alert-to-suspension must complete within one hour of a confirmed T9 signal.

What it is

Every AI agent runs under a non-human identity: a service principal, an IAM role, or a workload credential issued at deployment. That identity produces a continuous stream of access events (API calls, resource reads, authentication tokens consumed) which, for a correctly scoped agent, follows a narrow and repeatable pattern. The action distribution of an agent is far tighter than that of a human user: it accesses a defined set of resources, from a known workload origin, at predictable times, in predictable volumes. That stability is what makes UEBA effective when applied to agent identities: any genuine deviation from the established pattern carries a higher signal-to-noise ratio than the equivalent signal would for a human account.

Identity Spoofing (OWASP T9) is the threat this control is built against. An attacker who obtains a valid agent credential can use it to access resources, exfiltrate data, or issue privileged API calls while appearing, to a static permission check, to be the legitimate workload. The spoofed credential will, however, exhibit access patterns that differ from the legitimate agent's baseline: a different source IP or execution environment, an unusual time of day, a resource mix the agent has never previously accessed, or an authentication failure pattern consistent with credential probing. Behavioural monitoring detects that divergence and fires a risk signal before the attacker can complete their objective.

The first 30 days after deploying a new agent identity are calibration, not detection: the baseline is still forming, and statistical confidence is low. Baseline-independent controls must carry the detection load during that window.

Pair with m-divergence-monitor for the model-output side and m-nhi-lifecycle so that credential revocation actually severs access when a risk signal fires.

Detection signals

  • Workload-origin divergence. An access event from a source IP or execution environment not in the identity's 30-day baseline is the canonical credential-theft signal.
  • Resource-mix shift. A sustained change in the categories of resources the identity accesses, against its rolling baseline, indicates lateral movement or scope escalation.

Threats it covers

  • T9 Identity Spoofing and Impersonation −1 severity step

    WHY IT HELPS Identity Spoofing is the use of a stolen or forged agent credential to impersonate a legitimate workload. The spoofed identity will access resources from an unexpected origin, at an unusual time, or with a resource mix that does not match the legitimate agent's baseline. Behavioural monitoring detects that divergence and fires a risk signal before the attacker can complete their objective.

Principle coverage

Defence-in-Depth stage: Detect — and it advances:

  • Continuous Verification Identity monitoring operationalises continuous verification at the credential layer: each access event is checked against the established baseline rather than trusted on the strength of a prior authentication, so a compromised identity is detected when its behaviour diverges rather than after the fact.
  • Observability / Non-repudiation Per-identity behavioural telemetry gives the observability layer the structured stream it needs to answer post-incident questions about what a specific workload credential accessed, when, from where, and whether that pattern matched the legitimate agent's baseline.
  • Accountability Behavioural monitoring creates a continuous, attributed access record for every agent identity, making it possible to reconstruct the full action sequence of a given credential and determine whether observed activity was consistent with the legitimate workload or with a spoofed one.

Design & governance principles (open design, economy of mechanism, accountability, …) are architectural, not advanced by a single placed control.

Implementation options

Five verified options spanning cloud-native managed detection, cross-cloud SIEM, and a self-build statistical baseline. Cloud-native paths (Entra ID Protection, GuardDuty) are the fastest to adopt for their respective clouds. Datadog Cloud SIEM and Splunk UBA cover multi-cloud deployments. The self-build option applies when no managed service covers the agent's action surface.

Microsoft Entra ID Protection Extends the Entra risk-detection engine to workload identities (service principals and app registrations). Detects anomalous service principal activity, unusual Graph API call volume, suspicious sign-ins from unfamiliar IP or ASN, and leaked credentials. Risk-based Conditional Access policies can automatically suspend a flagged workload identity.

Why choose it: Best when your agent identities are Entra-registered service principals running in Azure or calling the Microsoft Graph. The baseline learning period is 2-60 days; once stable, the engine fires on anomalous directory changes, unusual resource access, and reconnaissance patterns without custom rule authoring. Requires Workload Identities Premium licensing. Managed identities are currently out of scope.

More details:

AWS GuardDuty GuardDuty's ML model evaluates all CloudTrail management events and fires per-MITRE-tactic findings when an IAM principal (including AssumedRole identities used by agents) invokes APIs in a way that deviates from its historical pattern. Finding types map to credential access, privilege escalation, persistence, defense evasion, exfiltration, and impact tactics, each tagged to the specific user identity and the anomalous factors (new region, new API class, new call rate). The UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS finding catches credentials used from outside the expected workload.

Why choose it: Best for AWS-native agentic workloads using IAM roles or task roles. GuardDuty consumes CloudTrail automatically; no log routing or schema mapping is needed. The per-principal ML model adapts as the baseline evolves, which reduces noise but means a slow-drift attack can eventually become invisible. Enable GuardDuty at the organisation level so agent accounts cannot disable it.

More details:

Datadog Cloud SIEM Ships out-of-the-box detection rules covering identity-based anomalies across AWS, Azure, and GCP: impossible travel, anomalous number of assumed roles from a single IAM identity, an unfamiliar IAM principal retrieving secrets from Secrets Manager or SSM Parameter Store, AWS access key creation by a previously unseen identity, and brute-forced ConsoleLogin correlated with an assumed role event. Rules fire on ingested CloudTrail, Azure Activity, and GCP Audit logs without a separate UEBA product.

Why choose it: Best for multi-cloud deployments where a single SIEM must cover agent identities across AWS, Azure, and GCP. The out-of-the-box rules require no baseline tuning: they use Datadog's entity graph to identify new or unfamiliar identity patterns. Custom correlation rules can extend coverage to internal API logs if those are forwarded to Datadog. Pricing is log-volume-based; high-verbosity CloudTrail data events add cost.

More details:

Splunk UBA Builds per-entity behavioural models across machine time, peer-group norms, and longitudinal access patterns, applied to service accounts and machine identities as well as human users. Anomaly types include access from a new workload origin, unusual time-of-day activity, peer-group divergence, and lateral movement indicators. Threats are ranked by a risk score aggregated across contributing anomalies rather than individual rule fires, reducing alert fatigue.

Why choose it: Best for organisations that already run Splunk Enterprise Security and want UEBA coverage unified in the same platform. Splunk UBA ingests from Splunk indexes, so any log source already forwarded to Splunk (CloudTrail, Okta, Active Directory, internal APIs) is automatically in scope. Per-entity risk scoring handles the many-low-severity-signals pattern that single-event rules miss. Requires a separate Splunk UBA licence and deployment.

More details:

Self-build KS-test baseline Collect per-agent-identity telemetry into a time-series store (CloudWatch, Prometheus, or a SIEM index). For each signal class (calls per hour, resource-type mix, source-IP set, time-of-day distribution), store a rolling 30-day window as the baseline distribution. On each evaluation cycle, run a two-sample Kolmogorov-Smirnov test (scipy.stats.ks_2samp) between the current window and the baseline; alert when the KS statistic exceeds a configured threshold (typically p < 0.05). Route alerts to PagerDuty, Slack, or an incident management system.

Why choose it: The only option when the agent's action surface does not appear in CloudTrail, Entra ID audit logs, or any supported SIEM source; for example, agents that call internal REST APIs or mutate a local database. The KS test is distribution-agnostic, requires no normality assumption, works on small samples, and is straightforward to explain to an auditor. The operational cost is baseline curation: each agent class needs its own threshold calibration, and the evaluation loop must be scheduled and monitored.

More details:

Trade-offs

  • Detection runs out-of-band against telemetry, adding no latency to the agent action path, but alert-to-suspension latency is 5-15 minutes depending on SIEM ingestion cadence. A fast-moving attacker can exfiltrate within that window.
  • Cloud-native options (Entra ID Protection, GuardDuty) adapt their models as the baseline evolves. A slow-moving adversary that drifts behaviour over weeks can eventually make malicious patterns appear normal to the ML model.
  • SIEM-based options (Datadog, Splunk UBA) add log-volume cost. CloudTrail data events are particularly verbose; evaluate the cost impact before enabling full data-plane logging.
  • The self-build KS approach requires per-identity threshold calibration. Agents whose legitimate behaviour changes frequently will generate elevated false-positive rates until thresholds are tuned per agent class.

When NOT to use

  • Do not deploy this control as the primary gate for brand-new agents with no baseline. The calibration period (typically 30 days) is not a detection window. Use baseline-independent controls (output moderation, human-in-the-loop, policy-bound autonomy) during that period.
  • Do not use UEBA monitoring as the primary control for agents whose legitimate action distribution changes on a weekly cadence by design; the alert-to-noise ratio will be too high to act on reliably.
  • Do not substitute behavioural monitoring for credential scoping. Monitoring a wide-scope credential is not a replacement for restricting its scope in the first place.

Limitations

  • A slow-moving adversary that re-establishes the baseline at a new normal defeats the monitor. Pair with periodic full-permission audits (m-cross-system-audit) to catch sub-threshold accumulation that the rolling window cannot see.
  • GuardDuty's per-principal ML model stops generating findings for activity it learns is normal from a given source. Once a compromised credential is used regularly from a new origin, GuardDuty suppresses the finding, which is the designed behaviour but a residual risk for persistent attackers.
  • Entra ID Protection workload identity risk detections exclude managed identities as of mid-2026. Agent workloads that use managed identities instead of service principals have no coverage under this option.
  • The self-build KS approach detects distribution-level divergence but not point-in-time anomalies. A single unusual API call that does not shift the overall distribution will not fire an alert. Pair with threshold-based event rules for point-anomaly coverage.

Maturity tier reasoning

  • Tier 2 fits because every option here is production-available: Entra ID Protection workload identity risk is GA, GuardDuty IAM anomaly findings are GA, Datadog SIEM out-of-the-box rules are GA, and Splunk UBA is a shipping product.
  • What keeps this out of Tier 1 is that none of the managed options has been designed specifically for AI agent workloads. They all apply human-identity or general-IAM baselines to non-human identities. Agent-specific baseline templates with narrower action distributions and workload-origin attestation as a first-class signal are not yet a default product feature in any of these platforms.
  • The self-build KS option has no vendor maintenance path and no off-the-shelf design specification; each deployment makes its own choices about window size, signal classes, and threshold calibration.

Last verified against upstream docs: 2026-05-30.