UEBA was built to catch the employee who hesitates before doing something they know is wrong. An agent never hesitates — which is why it needs a different instrument entirely.
Why Agent Drift Matters Now
User and Entity Behavior Analytics has been the workhorse of insider-threat detection for a decade. It builds a behavioral baseline for each user and flags deviation — a login from a new geography, a bulk download at 2 a.m., a directory the user has never touched. The premise is sound: humans are creatures of habit, and a sharp break from habit is a signal worth investigating.
Agents break that premise in two directions. First, an agent has no habits to baseline on day one — it arrives fully capable, broadly permissioned, and its “normal” is whatever its first week of tasks happened to be. Second, an agent’s behavior changes for reasons unrelated to intent. A model update, a new tool dropped into its context, a prompt rewrite by the engineer who owns it — any of these shifts behavior overnight. UEBA reads that shift as a single anomaly. It is actually a regime change.
The capital-markets analogue is the drift term in a stochastic process. A price has volatility — the random jitter — and drift — the directional pull. UEBA was tuned for volatility: the one-off spike against a stable line. Agents demand that you measure drift instead: the steady, compounding migration of behavior away from baseline. That is the metric this piece defines.
| Stat | Value | Source |
|---|---|---|
| Enterprises with at least one unsanctioned agent on a managed endpoint | 88% | Ospiri signature pipeline, 2026 |
| Average annualized cost of a single uncontrolled agent incident | +$670K | Ospiri, against IBM Cost of a Data Breach baselines |
| Median window from first agent deployment to first material incident | 12-18 months | Ospiri field data |
You cannot watch a fleet you cannot baseline. This piece walks through how Ospiri ports behavioral analytics from users to agents — and why the observability layer has to be rebuilt, not retrofitted.
UEBA for Users vs Behavioral Analytics for Agents
The instinct on most security teams is to point the existing UEBA tool — Splunk UBA, Microsoft Defender for Identity — at the agent fleet and call it covered. It is not. The two problems are structurally different.
| Dimension | UEBA for users | Behavioral analytics for agents |
|---|---|---|
| Baseline period | Weeks of observed habit | None — the agent is fully capable in hour one |
| What changes behavior | Intent, role change, account compromise | Model update, new tool, prompt rewrite, context change |
| Speed of change | Gradual — humans adapt slowly | Instant — one deploy changes everything at once |
| Self-limiting factors | Hesitation, fatigue, fear of getting caught | None — the 10,000th action runs exactly like the first |
| Anomaly volume | Low — humans are repetitive | High — agents legitimately do new things constantly |
| Right primitive | Deviation from a stable baseline | Drift rate against a versioned baseline |
The last row is the whole argument. A user UEBA tool asks “how far is today from normal?” An agent tool has to ask “how fast is normal itself moving, and against which version of the agent?”
Why Agent Drift Compounds Faster Than User Drift
Here is the distinction that matters: user drift is idiosyncratic and self-limiting; agent drift is systematic and unbounded. Five mechanics drive the gap.
- No hesitation tax. A human drifting toward risky behavior slows down — second-guessing, checking, asking a colleague. That friction is a detection window. An agent has none; it executes the boundary-crossing action at full speed, identical to a routine one.
- No fatigue ceiling. A person can exfiltrate only so many files before going home. An agent will iterate a destructive loop thousands of times between a model update and the next analytics batch job.
- Silent re-baselining. UEBA quietly absorbs gradual change into the baseline as the user’s new normal. For an agent, laundering a model update into “normal” is precisely the failure — the tool adapts to the regime change instead of flagging it.
- Correlated across the fleet. One human drifting is one incident. A model update drifts every agent of that type at once. User drift diversifies; agent drift is systematic risk, and systematic risk does not diversify away.
- The blast radius travels with the permissions. A drifting agent still holds whatever filesystem, network, and credential scope it had on day one. Drift plus broad standing permission turns a behavior change into an agent security incident.
The Drift Coefficient
You measure drift the way you measure any exposure: decompose it into factors, weight them, and produce a single number you can mark.
Drift Coefficient = (New-Surface Rate × Permission Scope) + (Action Velocity × Baseline Staleness)
Two halves, four factors. The first captures how much new behavior is appearing and how much it can reach; the second, how fast the agent acts and how stale its baseline has become.
| Factor | Definition | Scoring rubric (0–10) |
|---|---|---|
| New-Surface Rate | Share of this week’s behavior signatures — directories, syscalls, network endpoints, tools — absent from the agent’s baseline | 0 = no new signatures in 30 days; 10 = >50% new signatures week-over-week |
| Permission Scope | Breadth of resources a drifting action can reach — filesystem, network, identity, secrets, code execution | 0 = read-only single directory; 10 = full kernel access with persistent credentials |
| Action Velocity | Actions per hour against in-scope resources | 0 = idle; 10 = >100 actions/hour with no human-in-the-loop |
| Baseline Staleness | Time since the baseline was last re-validated against a known-good agent version | 0 = re-validated this week; 10 = baseline predates the current model or prompt version |
Worked example. A Cursor instance that just took a model update is now touching three new directories and a new network endpoint, runs with full filesystem scope, fires ~40 actions per hour, baseline last validated two model versions ago: New-Surface Rate 7, Permission Scope 8, Action Velocity 6, Baseline Staleness 9. Coefficient = (7 × 8) + (6 × 9) = 110.
Compare a stable, sandboxed Aider instance on the same laptop, restricted to one project directory: New-Surface Rate 1, Permission Scope 3, Action Velocity 5, Baseline Staleness 2. Coefficient = (1 × 3) + (5 × 2) = 13.
Same engineer, same toolchain — an eight-fold drift delta, visible before it resolves into an incident rather than after.
What the Drift Coefficient Requires That UEBA Cannot Give You
A drift coefficient is only as good as the telemetry under it. UEBA was architected around a human identity and a slowly moving baseline, and three of its assumptions have to be replaced.
| Requirement | UEBA today | What agent drift detection needs |
|---|---|---|
| Baseline model | One rolling baseline per identity | A baseline pinned to a model + prompt + tool-config version; a new version resets it, never absorbs into it |
| Telemetry depth | Auth logs, file access, network metadata | Kernel-level syscall and filesystem visibility — the agent’s plan is gone, only its actions remain |
| Re-baseline policy | Silently absorbs gradual change | Treats a version change as a regime change requiring explicit re-validation |
| Enforcement coupling | Detection only — pages a human | Drift score wired to an agent firewall so a high coefficient can throttle scope, not just generate a ticket |
That last row is the difference between observability and control. A coefficient that only alerts is a smoke detector with no sprinkler; coupled to enforcement, one crossing threshold can narrow the agent’s permission scope automatically — buying the time a human needs to judge whether the new behavior is a feature or a failure.
What CISOs Should Do This Quarter
This is a fortnight of setup, not a consulting engagement, if the endpoint telemetry is already flowing.
| Step | Action | Output | Effort |
|---|---|---|---|
| 1 | Pin a versioned baseline for each sanctioned agent — model, prompt, tool config | Baseline registry | 2 days |
| 2 | Instrument new-surface telemetry — directories, syscalls, endpoints, tools — per agent | Weekly new-surface feed | 1 week |
| 3 | Compute the drift coefficient on the four-factor rubric, per endpoint and per agent type | First fleet drift snapshot | 2 days |
| 4 | Set a coefficient threshold that triggers re-validation, wired into agent observability tooling | Continuous drift alerting | 1 week |
The output of week two is a ranked list of which agents in the fleet are migrating fastest, and which version change set them moving. The output of quarter two is a flat drift line — agents that change only when you decide they should.
The Bottom Line
UEBA was built to catch a human who breaks a habit; an agent has no habits and no hesitation, so the metric that matters is not the anomaly but the drift rate. Porting behavioral analytics to agents is not a matter of repointing an existing tool — it requires a versioned baseline, kernel-depth telemetry, and a re-baseline policy that treats every model update as a regime change, not a new normal to absorb. The drift coefficient gives you a single decomposable number for that migration, comparable across endpoints and agent types. Detection alone is a smoke detector; the coefficient earns its keep coupled to enforcement that can act before a human reads the alert.
If your team is sizing agent monitoring for the Q3 planning cycle, request a working session. We will walk through your environment, compute a first drift coefficient across a representative sample of your agent fleet, and scope where detection needs to couple to enforcement. 90 minutes.