Behavioral detections as code close the UEBA gap in TQL

At a glance

What this is: TENZIR shows how behavioural detections can be expressed as code in TQL, using mergeable per-entity baselines for sets, shapes, counts, and drift.

Why it matters: This matters because IAM and security teams need behavioural analytics they can inspect, test, and govern instead of black-box UEBA outputs that are hard to validate or operationalise.

Context

Behavioural detection fills the gap left by rules that only evaluate one event at a time. Questions like whether a host has ever run a binary, whether a source is unusually chatty, or whether an account has changed its mix of activity require comparing current events with an entity's own history rather than a fleet-wide constant. For practitioners, the governance issue is not just detection quality, but whether the logic can be reviewed, versioned, and reproduced like any other security control.

In this article, the identity angle is indirect but real: the same scoring patterns that baseline hosts, accounts, and sources also apply to user activity, service behaviour, and agent interactions. That makes the post relevant to IAM and NHI teams because behavioural analytics increasingly touches human identities, service identities, and workload identities in the same monitoring pipeline.

The central change is architectural. Instead of pushing behavioural questions into an opaque UEBA platform or a manually maintained notebook, the pipeline stores compact baselines in lookup tables and evaluates live events against those baselines in TQL. That makes behavioural detection a governed data product rather than a separate analytics silo.

Key questions

Q: How should security teams implement behavioral detection as code without using opaque UEBA tools?

A: Teams should express behavioral logic in queryable pipelines, keep baselines as data, and tie each detector to a stable entity key such as host or account. That makes the scoring reproducible, testable, and reviewable in the same change-control process as rules. The goal is not more analytics theatre, but detection logic that analysts can inspect and improve.

Q: Why do single-event rules miss the behaviours that matter most?

A: Single-event rules cannot compare an event with an entity's own history, so they miss first-sighting binaries, unusual fan-out, and distribution drift. Those behaviours only become visible when the current event is evaluated against past activity for the same host, account, or source. The control failure is not the alert engine, but the absence of entity context.

Q: What are the signs that behavioural baselines are not working properly?

A: Common warning signs are baselines with too little history, scores that treat every entity the same, and detections that cannot be explained from the underlying data. If the model cannot show what was learned, or if it still pages on normal behaviour for one entity while missing the same pattern on another, the baseline design is too coarse.

Q: When should teams prefer explainable behavioural scoring over opaque analytics?

A: Prefer explainable scoring when the detection will be tuned, audited, or shared across SOC and identity teams. If analysts cannot inspect the baseline, reproduce the result, or review changes to the logic, the control is hard to govern even if it produces useful alerts. Explainability becomes a security requirement once the model influences operational decisions.

Technical breakdown

Why single-event rules fail for behavioural detection

A single-event rule can only test what is present in one record, so it struggles whenever the question depends on a comparison with history. That is why Sigma-style logic handles process names, thresholds, and matches, but not whether this host has ever executed this binary or whether this source is extreme for its own past. Behavioural detection requires entity context, not just event content. The article's key mechanism is to treat the baseline as data that can be joined back to each event, which turns a historical comparison into a normal pipeline step.

Practical implication: teams need a detection design that enriches live events with entity history before scoring, not after alerting.

How mergeable baseline models make behavioural logic auditable

The article's baseline models are compact records built with summarize, then merged and queried like ordinary data. Different feature types use different model shapes: frequency tables for categorical sets, t-digests for distributions, HyperLogLog for distinct counts, and model divergence for drift. Because each baseline is stored as readable table data, it can be printed, diffed, reviewed, and tested. That matters because the governance problem with UEBA is often not statistical power but explainability, change control, and operational ownership of the model itself.

Practical implication: store behavioural baselines in version-controlled, inspectable tables so analysts can validate model changes like code changes.

What the set, count, and drift models are actually measuring

The set model answers whether a value has ever appeared for an entity, such as a process name on a host. The count model measures how unusual a volume or fan-out is for that same entity, such as destinations reached in a short window. The drift model compares two distributions, which lets the pipeline catch activity mix changes even when every individual value is familiar. Together, these models cover the common behavioural questions that do not fit static allowlists or thresholds. The result is not generic anomaly detection, but entity-specific behavioural context.

Practical implication: map each behavioural question to the right model type rather than forcing all detections into one threshold pattern.

Threat narrative

Attacker objective: The attacker seeks to look normal long enough to move laterally or execute tooling without triggering a rule that only understands single events.

1. Entry occurs when a host, account, or source begins doing something that is technically allowed but historically unusual for that entity, such as running a never-seen binary or reaching new destinations.
2. Credential or privilege abuse is suggested when the observed behaviour expands beyond the entity's normal scope, such as an account suddenly touching many hosts or a source fan-out jumping far above baseline.
3. Impact follows when the abnormal activity becomes operationally meaningful, allowing the detection pipeline to surface compromise, lateral movement, or living-off-the-land behaviour before it blends into routine telemetry.

Breaches seen in the wild

• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
• ArtiPACKED 2024: Unit 42 found public GitHub Actions artifacts in major open source projects leaking live GITHUB_TOKENs, runtime tokens and cloud tokens.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Behavioural detection belongs in the same governance layer as other security controls, not in a separate UEBA island. Once behavioural questions are expressed as code and backed by inspectable baselines, they can be reviewed, tested, and changed with the same discipline as rules and policies. That reduces the gap between detection engineering and security governance, which is where many black-box analytics projects fail. The practitioner conclusion is simple: if a behavioural control cannot be inspected, it cannot be governed.

Behavioural baseline debt: organisations accumulate risk when entity history exists only inside opaque models or one-off notebooks. The article shows a better pattern: make the baseline a first-class data object that can be merged, queried, and versioned. That shifts the problem from buying more analytics to managing the lifecycle of detection logic itself. Practitioners should treat baselines as controlled security assets.

This approach narrows the distance between IAM telemetry and detection logic. The same entity-centric method can be applied to user accounts, service accounts, hosts, and agent behaviour, which is exactly where identity governance and detection start to overlap. That matters because modern identity programmes increasingly need to monitor behaviour, not just entitlements. The practitioner takeaway is that behavioural analytics should be designed alongside identity data models, not bolted on later.

TQL-based behavioural detection is most valuable where teams need repeatable explanation, not just better scoring. A model that an analyst can understand, diff, and test is easier to operationalise than a model that simply emits a risk score. This does not eliminate the need for statistical tuning, but it does make the control defensible in audits and change reviews. The practitioner conclusion is to prioritise explainability and lifecycle control over analytics novelty.

Named concept: detection as code for behaviour. The article defines a useful operational pattern where behavioural baselines, scoring logic, and tests live in version control alongside other detections. That is more than a packaging choice. It is a governance model for how security teams should own behavioural analytics. Practitioners should adopt the pattern where they need durable, reviewable detection rather than outsourced interpretation.

What this signals

Detection as code now has a behavioural layer. Teams that already version rules should extend the same control model to behavioural baselines, because the governance problem is the same: can you review what changed and why the alert fired? The practical test is whether your telemetry pipeline can show both the logic and the historical context that produced the finding.

Behavioural analytics should be designed around entity lifecycles, not around product categories. Hosts, users, service accounts, and agent-like workloads all generate activity that must be interpreted relative to their own history. That means IAM and SOC teams need shared data definitions for entities, windows, and baseline freshness before they can trust behavioural findings.

Detection-as-code only closes the gap when the baseline is part of the control, not an external black box. The strongest operating model is one where the baseline can be inspected, diffed, and retired like any other security asset. That gives practitioners a defensible path from raw telemetry to explainable behavioural detection.

For practitioners

• Implement per-entity behavioural baselines Store host, account, source, or service history as inspectable lookup-table rows so each detection can compare live events against that entity's own past.
• Use the right model type for each signal Map categorical history to frequency tables, numeric distributions to t-digests, distinct fan-out to HyperLogLog, and distribution shifts to divergence scoring.
• Version behavioural detections with tests Keep behavioural scoring pipelines in Git with fixtures and pull-request review so changes to thresholds, windows, and baselines are auditable.
• Reject stale or immature baselines Gate scoring on baseline readiness so missing history, low sample counts, and retired behaviour do not produce misleading findings.

Key takeaways

• Behavioural detections fail when they are forced into single-event rules, because the relevant signal is often a change relative to one entity's own history.
• The article's core contribution is a governed way to express baselines, scores, and drift as code rather than as opaque analyst tooling.
• For practitioners, the main decision is whether behavioural analytics will be treated as a versioned control with lifecycle ownership or as an unreviewed analytics sidecar.

Key terms

• Behavior Baseline: A record of normal activity for a non-human identity, including typical consumers, resources, and actions over time. Baselines help security teams detect when an identity is being used in an unusual way and provide the context needed to enforce least privilege safely in dynamic environments.
• Frequency Table: A compact model that records how often each categorical value appears for an entity, such as process names or destination domains. It supports first-sighting and familiarity-style detections by showing whether a value is common, rare, or entirely unseen for that specific entity.
• T-Digest: A bounded sketch that approximates numeric distributions while staying small enough to store and merge efficiently. In behavioral detection, it is useful for comparing a live value against the historical shape of bytes, durations, or other numeric telemetry without keeping every raw event.
• Jensen-Shannon Divergence: Jensen-Shannon Divergence is a symmetric measure of difference between two probability distributions. It is often used in drift monitoring because it provides a bounded, more stable way to compare training and production data, making distribution change easier to interpret for operational teams.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and identity practitioners build the governance habits that underpin defensible identity controls across modern programmes.