Before we go deeper, let's set some context. Many SIEMs treat entities as flat records, a snapshot of what's true right now, rebuilt on demand from raw logs. That works until you need to know how the environment got here, what changed, what was resolved, how a risk score compounded over time. Elastic's Entity Store is architected differently. Every entity is a living record, continuously enriched by background jobs called maintainers, each responsible for one facet of the entity. Maintainers establish relationships, perform identity resolution, and calculate risk scoring. These are all composed onto the record over time, all inspectable, and all correctable. A companion post on entity record quality explains why this matters.

Going one level deeper, this piece explores how records are built and connected in the first place, along with how their risk scores are updated, relationships are tracked, and identities are resolved. The short answer is a single abstraction. Entity store v2, introduced in Elastic v9.4, is built on maintainers. Each maintainer runs on its own clock, continuously updating the record you eventually query. The entity store is the result of a set of maintainers enriching each entity based on the raw or derived signal around it, not an append-only index you simply write entities into.

Let's build that picture from the engine up.

What the entity store does and why it runs on ES|QL

The Entity Store is the layer that turns your telemetry (for example endpoint, identity provider, and cloud logs), identity and asset inventories, and threat detections into one queryable profile per user, host, and service. This means analysts can pivot on information and insights gained from an enriched entity record, instead of reconstructing it from raw logs every time.

Entity store Version 1 did that with Elasticsearch transforms.

Version 2 rebuilds the engine on Elasticsearch Query Language (ES|QL). Each entity extraction cycle runs a query that filters the relevant logs and aggregates them. In the next crucial step, the cycle performs a LOOKUP JOIN back against the existing entity index to carry forward previously observed entity attributes and behaviors.

FROM logs-*
  | WHERE ...                                          // logs for this entity type + window
  | STATS ... BY entity.id                             // collapse many events into one record
  | LOOKUP JOIN .entities.v2.latest.security_default-00001
      ON entity.id                                     // field retention against the store itself
  | EVAL ...                                            // keep-latest / keep-first retention

ES|QL provides query flexibility and coverage for the fields and field types that the schema needs. It also provides a pipeline that you can reason about and extend, with retention and merge logic expressed directly, instead of through the limited flexibility and operational choreography needed with transforms.

How an entity record is built, from raw signal to resolved identity

Here's the part that's usually glossed over. Let's take a look at the entity extraction and building process by following one host from its raw event to its finished record.

• Step 1: The raw signal ingested to Elasticsearch. Your endpoint detection and response (EDR) agent and identity provider write events into data streams that are matched by a logs-* index pattern, as do your cloud integrations. There isn’t anything entity-shaped yet, just events with fields like user.name, host.name, and event.category.

• Step 2: Extraction collapses events into a record. During its run cycle, the ES|QL query above filters the logs relevant to an entity definition, and then STATS ... BY entity.id collapses potentially thousands of events into one entity store row/record per entity, keeping the first-seen and latest entity lifecycle values that matter. The LOOKUP JOIN merges that fresh row with the entity's existing record, so nothing observed outside the window is lost. The output is a single, denormalized document in the latest index: the entity's base identity and lifecycle, in addition to its attributes.

• Step 3: Identity is keyed deliberately. Which entity a row belongs to is the highest-stakes decision in the whole system. Key it wrong and you can blend several distinct users into one entity, or split one user across many. So the store doesn't guess. It derives a deterministic identifier, the entity unique ID (EUID), from the fields that actually identify the entity.

• Step 4. Maintainers compose the rest. The entity record is there, but it doesn’t yet know who it talks to (relationships) or what behaviors it exhibits. It also doesn’t yet know which various account entities are used by the same user or how risky the entity is. Those facets are layered onto the entity record by maintainers, and that's the heart of Entity Analytics.

The key to building entity relationships - the deterministic entity ID

The Entity Store currently supports three primary, schema-backed entity types: users, hosts, and services. Alongside these sits a fourth, polymorphic category known as generic entities.
The generic entity type isn’t constrained to a fixed schema, but rather provides an extensibility layer for the entity store platform. For example, by leveraging cloud and orchestrator fields, it represents resources like EC2 instances, S3 buckets, and Kubernetes clusters as first-class entities today. This flexibility allows the entity store to encompass a broad spectrum of assets without the architectural overhead of defining a new entity type for every resource class.

Everything the entity store does, including merging today's events onto the current entity record and linking two accounts into one resolved user, hinges on one field: entity.id, the EUID.

The EUID is a deterministic, human-readable string (a type prefix and then the fields that actually identify the entity, joined with @), rather than a random universally unique identifier (UUID) or a hash. Note the addition of a user entity namespace at the end of the user EUID. We’ll explain the role that plays below.

user:jane.doe@example.com@okta
host:9f86d081-1e0c-4b3f-8a2d-2c1e7bed425e
service:api-gateway

How is the EUID derived? For each entity, the store walks an ordered list of candidate identity fields and takes the first complete one. If a field a candidate needs is missing, that candidate is skipped and the next is tried, so a partial observation never produces a malformed ID.

Why do we need a namespace for user entities? While host and service entities rely on sufficiently unique keys like host.id or service.name, a user's identity, for example an email address, can be observed in many different log sources, but is authoritative only within its issuing domain. The namespace provides the necessary disambiguation, resolving the specific collision challenges unique to user identity records.

| Entity type | ID fields (priority order) | Example EUID | Namespace | | :----------------------- | :-------------------------------------------------------------- | :----------------------------------------------------- | :------------------------------------------------------------- | | Host | host.id, then host.name, then host.hostname | host:9f86d081-1e0c-4b3f-8a2d-2c1e7bed425e | (none) | | Service | service.name | service:api-gateway | (none) | | User (identity provider) | user.email, then user.id, then user.name@domain, then user.name | user:jane.doe@elastic.com@okta | Provider name: okta, entra_id, microsoft_365, active_directory | | User (local/endpoint) | user.name scoped to host.id | user:jdoe@9f86d081-1e0c-4b3f-8a2d-2c1e7bed425e@local | local |

• Host: The first present of host.id, host.name, host.hostname, giving host:<value>.
• Service: service.name, giving service:<name>.
• User: This is the interesting one, because a user's identity depends on where their activity was observed.

Users: Identity provider versus the local host. A user's EUID always ends in a namespace, the last @-delimited segment, and that segment is what stops two accounts that merely look alike from colliding.

When a user comes from an identity provider, the namespace is that provider (okta, entra_id, microsoft_365, active_directory) and the store keys on the most authoritative identifier it has: email, then user id, then name@domain, and then name.

user:jane.doe@elastic.com@okta

The same user's Entra ID account becomes …@entra_id, a different EUID, on purpose. They’re two authoritative accounts until resolution ties them together. We are going to see how resolution achieves this later in the blog.

When a user is seen only through endpoint or host telemetry, with no authoritative directory account behind them, the store scopes them to the machine and suffix the ID as local:

user:jdoe@9f86d081-1e0c-4b3f-8a2d-2c1e7bed425e@local

The middle segment is the host's durable identifier (host.id) and not its renamable hostname, so jdoe on a laptop stays distinct from jdoe on a shared bastion host, and the identity survives a machine being renamed or reimaged. The local namespace is an explicit signal: This is activity on this box, not a verified global identity. (Note the host in the example above and this local user share the same host.id. That's how the Entity Store knows they belong together.)

What makes an entity source authoritative and how to construct one

The EUID logic leans on a word that deserves a precise definition: authoritative. When an identity-provider-backed user earns a real namespace (okta or entra_id, among others) and high-confidence treatment, it's because the incoming events cleared a specific bar. Here's the bar and how to clear it with your own integrations.

What qualifies as authoritative identity data. The store treats an event as an authoritative identity signal when either of these is true:

| Classification path | Required ECS fields | Confidence | Resulting namespace | | :-------------------------------------- | :-------------------------------------------------------- | :--------- | :----------------------------------- | | Asset inventory | event.kind: asset | High | Provider name (okta, entra_id, etc.) | | Endpoint-observed (neither bar cleared) | user.name + host.id present, but no authoritative signal | Medium | local (scoped to host) | | Unclassifiable | None of the above | N/A | No entity created |

• The event is an asset / inventory document with event.kind: asset. This is how Elastic's identity integrations (Okta, Entra ID, Active Directory, and the cloud asset sources) publish their user and account inventories.

Clear either bar and the user becomes a first-class, identity-provider-backed entity at high confidence, and the preferred canonical record when identities are later resolved. Miss both, but carry a user.name and a host.id, and the user is instead scoped to that host in the local namespace at medium confidence. If both of these conditions are false and no host exists to associate the event with, no entity is created at all. That last case is deliberate restraint, not a gap; the store would rather create nothing than manufacture a noisy identity from an ambiguous event.

Two filters apply before any of this runs: The event's event.outcome must not be failure (a failed login isn’t evidence that an account exists), and it must carry at least one of user.email, user.id, or user.name.

Which namespace you get. Once an event qualifies, the namespace is derived from its source, the first non-empty of event.module or the leading segment of data_stream.dataset.

An authoritative event from an unrecognized source still creates a real entity. It just lands in the unknown namespace and you lose provider-level disambiguation (identical usernames from two namespaces can collide) and clean grouping. So, for a custom integration, the goal isn't only to qualify as authoritative, it's to be recognized.

How to accommodate a custom integration or pipeline. If you ingest identity data through a custom Fleet integration, a Logstash pipeline, or an Elasticsearch ingest pipeline, set these Elastic Common Schema (ECS) fields so the store classifies your entities the way you intend:

1. Mark the shape. For an account inventory, such as a local directory service, or configuration management database (CMDB), set event.kind: asset.
2. Provide an identity. Populate at least one of user.email (this is best, since it's the top priority), user.id, or user.name, plus user.domain where you have it.
3. Name your source. Set event.module (or the leading segment of data_stream.dataset) to a value the store maps. If you're feeding one of the known providers, reuse its naming so you inherit the right namespace. If your source is genuinely new, expect unknown until a mapping is added.
4. Don't let real identities look local. The local classification triggers when an identity event carries both user.name and host.id but doesn't clear the authoritative bar. If you're publishing directory data, don't attach a host.id to it. That field is the signal that says "endpoint-observed, scope it to this box." Reserve it for genuinely host-local activity.
5. Skip the noise. Don't emit failure outcomes as identity evidence. Note, too, that the store already excludes common shared and service account names (root, jenkins, deploy, postgres, admin, and similar) from the local namespace, so they never become per-host user entities.

Get these right, and your custom source behaves exactly like a built-in one: Authoritative users resolve and score at full fidelity, and endpoint-observed users stay correctly host-scoped. Plus, nothing downstream has to special-case where the data came from.

How maintainers add entity resolution, relationships, and risk scoring to entities

As discussed at the start of this post, the entity store is updated by dedicated background tasks called maintainers. Each of these has a specific job: building relationships between entities and resolving identities, along with updating risk scores.

The framework gives every maintainer its lifecycle, scheduling, and health reporting for free, making the entity store extensible by design. Any new entity enrichment capability ships as a new maintainer on the same rails, without re-architecting the entity store or breaking backward compatibility. Several maintainers already run in the current version, and recent additions, such as entity relationships derived from observed entity behaviors, have been added exactly this way. Even entity risk scoring, one of the most impactful risk-centric capabilities in the product, is implemented as just another maintainer composing one more facet of the entity record.

Maintainers discover and store entity relationships

Let’s take a look at one of the relationship maintainers. Once a day, the accesses_frequently / accesses_infrequently maintainer runs an ES|QL query over relevant telemetry and, for each actor→target pair, counts successful accesses over a 30-day window. If the count is:

• greater than or equal to an Elastic-defined threshold, the relationship becomes accesses_frequently.
• less than the threshold, the relationship becomes accesses_infrequently.

Today, it reads from Elastic Defend (endpoint logins), AWS CloudTrail (StartSession / SendSSHPublicKey), system auth (SSH logins), and system security (Windows events 4624/4648). A sibling, communicates_with, builds communication links from Elastic Defend, system auth, system security, Jamf Pro, and AWS CloudTrail.

The relationships are written straight onto the entity record as arrays of target IDs:

// a user entity in .entities.v2.latest.security_default-00001
"entity": {
  "id": "user-abc…",
  "relationships": {
    "accesses_frequently": { "ids": ["host-def…", "host-ghi…"] },
    "communicates_with":   { "ids": ["service-jkl…"] }
  }
}

A maintainer performs entity resolution

The resolution maintainer links fragmented accounts, the Okta jdoe, the Entra ID jdoe, and the on-prem Active Directory jdoe, into one resolved user. The risk maintainer then scores the resolved user, so the risky service token and the benign laptop login that both belong to John Doe are scored as John Doe: one record, not three that an analyst has to reconcile in their head.

Resolution happens two ways. Most of it is automatic: a background task runs every five minutes and links user entities that share the same user.email, so accounts converge on their own as the data arrives. When you need to step in, you can link or unlink manually from the entity flyout in the UI, or call the API directly.

POST /api/security/entity_store/resolution/link
{
  "target_id": "user:jane.doe@elastic.com@okta",
  "entity_ids": ["user:jane.doe@elastic.com@entra_id"]
}

POST /api/security/entity_store/resolution/unlink
{
  "entity_ids": ["user:jane.doe@elastic.com@entra_id"]
}

The near-term plan is to expand the out-of-the-box matching logic so more identities link automatically without anyone manually creating the links.

A maintainer calculates and updates entity risk scores

The risk score maintainer runs hourly by default. On each run, it queries the detection alerts over a configurable rolling time window (past 30 days by default) and for each entity those alerts touch, aggregates the alert risk scores into a single normalized entity risk score and risk level.

Entity risk scoring also extends across resolved identities. First the risk scoring maintainer calculates an entity risk score for each user entity (one per account) based on any detection alerts related to that account. Next it calculates a distinct entity risk score for the resolved user across all of their linked accounts. For example, a malicious service token alert on one account, and an excessive laptop login rate alert from a different account, where both accounts belong to John Doe, roll up into a single user entity risk score for the resolved John Doe. That holistic view is possible because the resolution maintainer ran first, then the risk scoring maintainer reads the graph (set of linked accounts) that the resolution maintainer produced, and is able to assign a risk score to the user, not only the constituent accounts If an analyst or AI agent decides to investigate the provenance of a resolved user risk score, the answer is easily obtained.

Every entity store decision is inspectable and correctable

The store's engine and its relationship maintainers are built on ES|QL, the same query language that Elastic users already employ, so what a maintainer reads,computes, and writes is inspectable, rather than proprietary magic. Every entity lives as a document in an Elasticsearch index, so its full state is there to read, including the relationships that were drawn and the accounts that were resolved into one user, plus the signals behind a risk score.

Entity data is wrong sometimes; that's the reality of identity data. Because the state is represented as Elasticsearch documents, you can correct them through APIs. When resolution gets it wrong, two people merged or one user split across two records, you can link or unlink identities right through the UI, and the risk score maintainer rescores the corrected resolved user on its next run. When you need to pull an entity into scope or set its criticality, watchlists let you say so directly. With Elastic Agent Builder, an AI agent can walk you through an entity's data and make those corrections for you, without leaving the Elastic UI.

What entity maintainers mean for security analysts

With entity resolution, relationship mapping, and risk scoring running as automated maintainers, human analysts and AI agents gain efficient access to the entity context they need to perform investigations. The entity store is extensible, so entities continue gaining relationships and enrichments as new maintainers ship or new data sources are ingested, with no migration or re-architecture. Nothing is hidden, so every risk score traces back to the alerts and other factors (for example, asset criticality, watchlist membership) that produced it, and a finding becomes something you can explain using the Agent Builder chat with the entity analytics tools and skills rather than a black box you have to trust.

In addition, wrong data doesn't have to stay wrong; a bad resolution link takes one API call or Agent Builder action to fix. What you're left with is a single queryable record per entity, host, and service that can evolve over time.

What’s coming next in the Entity Analytics Roadmap

The science of entity analytics is ongoing. One area we’re digging into is integrating non-human identities (NHI) as entities. AI agents, service accounts, and agentic workloads are among the fastest-growing concerns across today’s attack surface. While this research continues, the core objectives involve finding an optimal way to link an AI agent's sessions to existing entities by tracking its utilized Service accounts or connected devices and services, as well as assessing the risk of AI agent behavior

Also under the hood, we're reworking log extraction to split the work by data source confidence, so authoritative identities and lower-confidence enrichment are handled separately.
Additionally, we’re exploring enhancing the agentic UEBA capabilities to reason about an entity, connect the dots, and suggest relevant leads for the analyst to explore.

Entity risk scoring is getting continued attention too. Currently, a detection alert carries one static alert risk score that affects the entity risk score of every entity it involves, so the actor and the target can come out looking equally risky. The direction is towards a dynamic, entity-centric risk score that gives each entity its own contribution based on the role it played in the observed interaction, and its own context.

For practitioners with their hands on the Elastic Security UI, the entity analytics overview experience is due for a refresh, with risky entities shown more simply and clearer actions to investigate them.

Entity analytics is available in Elastic Security. Learn more about entity analytics.

Not the machine learning models. Not the anomaly detection algorithms. Not the risk scoring engine. The entities: the foundations to teach your system about the data and protect it.

Get the entities wrong, and everything downstream is contaminated, including AI. Your baselines are fiction. Your risk scores are noise. Your analysts are chasing ghosts. And the worst part? Most user and entity behavior analytics (UEBA) implementations get the entities wrong from day one. This blog explains why the entities you don't create matter and how a confidence-tiered model helps.

A note on terminology before we go further: in this piece we’ll distinguish between the real-world thing — a person, a host, a service — and the entity record Elastic Security creates to represent it. The argument that follows is about which records are worth creating, not about which things exist. We’ll use “entity record” when the distinction matters.

One username, hundreds of identities

Consider the simplest possible approach to creating a user entity record: Take a user.name field from an event log and call it an entity. A username like deploy appears in your telemetry, so you create a deploy entity record and start building a behavioral baseline.

The problem is immediate and severe. That deploy username might exist on 200 servers. It might be used by 12 engineers and a continuous integration and continuous deployment (CI/CD) pipeline. The behavioral baseline you're building is a smoothie blended from hundreds of different machines, used by different people, for completely different purposes. The system is treating a string match as an identity, barely one step above random.

When this entity record inevitably generates elevated risk scores, analysts investigate, only to discover that the "anomaly" was just a different engineer using the same shared account in a slightly different way. Multiply this across every common username in a large environment and you've built a system that generates investigative busywork at industrial scale.

The opposite mistake: An empty dashboard

Some security vendors recognize the problem and swing to the other extreme. They decide (correctly, in principle) that only identity-provider-backed entity records are trustworthy enough for behavioral analytics. If you can't tie an entity record to an authoritative account in a directory like Okta, Entra ID, or Active Directory, don't create one at all.

The engineering reasoning is defensible. The product experience is catastrophic.

A customer rolls out endpoint agents across their fleet, opens the security analytics dashboard, and sees nothing. Zero entities. The feature looks broken. The SOC analyst has no idea why no users are showing up, and worse, has no visibility into the activity happening on those endpoints right now. A purist entity data model has produced a blind spot. 

The missing middle: Host-scoped identity

Most vendors building UEBA have historically picked between two unsatisfying defaults, bare usernames that blend everyone into noise, or IdP-only entities that leave most deployments with nothing. But without explicit governance over which signals come from which source, the noise still leaks through.What's missing is a middle layer: entities derived from endpoint telemetry that are tightly scoped enough to be meaningful but carefully governed enough to avoid the noise problem.

The instinct might be to simply pair a username with a host and call it an entity record. But without guardrails, this just moves the noise problem down one level. deploy on prod-web-03 is still five engineers' blended activity. root on a shared bastion host is still everyone and no one. You've reduced the blast radius from "all servers" to "one server," but the behavioral baseline is still a fiction if the underlying account is shared, automated, or observed only through a failed brute-force attempt that never actually succeeded.

The real question isn't whether to create local host-scoped entity records. It's which host-scoped entity records are worth creating and with what governance over how they participate in risk scoring and identity resolution downstream.

The Elastic approach: Two kinds of entities, governed differently

One answer is to recognize that not all record sources are equal and to build that distinction into the architecture itself, governing how each record is created, enriched, scored, and resolved.

This is the approach Elastic Security takes. Instead of treating all entity records as interchangeable, the system draws a clear line between identity-provider-backed entities and endpoint-observed local host entities and governs each category differently under the hood.

Identity-provider-backed entities are created only by authoritative identity systems: Okta, Entra ID, Google Workspace, Active Directory, and other identity-provider namespaces across identity and access management (IAM), cloud platforms, software as a service (SaaS), and privileged access management (PAM) systems. These entity records represent verified accounts in systems that own and manage those accounts. They get the full analytical treatment, that is, rich behavioral baselines, cross-platform enrichment from 120+ security integrations, and full participation in person-level risk scoring.

Endpoint-observed entities are created from endpoint telemetry: Your endpoint detection and response (EDR) agent observes jdoe active on a specific host and creates a host-scoped entity record tied to that local machine. These entity records are real and useful, but the system knows they carry less identity certainty, and it governs them accordingly. 

Analysts don't need to think about any of this machinery. What they see is an entity store that's populated from day one with more accurate user entity records. The governance happens in the architecture so it doesn't have to happen in the analyst's head.

(An endpoint-observed entity for sarah.chen active on her corporate MacBook. The entity name (sarah.chen\@CORP-MAC-SC-2024) uses the human-readable hostname for readability. The entity ID (user:sarah.chen\@b92f1e3a-7d4c-4a8b-9f2e-1c3d5e7f9012\@local) uses the machine's hardware UUID instead of its hostname — this is intentional. Hostnames change when a device is renamed or reimaged; the hardware UUID is permanent. The @local suffix identifies this as an endpoint-observed entity: it represents sarah.chen's activity on this specific machine, not sarah.chen as a verified identity across your organization.)

From fragmented accounts to a Unified User Group. 

Even when you get entity record creation right, you’re still left with a fragmentation problem no amount of per-entity discipline can solve alone.

Consider John Doe in a large enterprise. He has an Okta account for SaaS access, an Entra ID account tied to his corporate laptop, and an Active Directory account for on-prem systems. Each is a legitimate, authoritative entity record by every standard described above, and yet they’re three separate records for the same human being, each with its own risk history, each generating signals in isolation.

When John’s Entra account shows a lateral movement indicator the same day his Okta account flags a suspicious login from an anomalous location, those signals may never connect. They exist as separate entities, investigated in isolation, by analysts who have no automated way to know they belong to the same person. The cross-surface campaign that entity analytics is supposed to catch hides in plain sight between identity providers.

Elastic Security solves this through automatic entity resolution: consolidating a user’s fragmented digital footprint across Okta, Entra ID, Active Directory, and more into a single unified identity. John Doe becomes a first-class citizen in the entity store: one primary record, all associated accounts grouped together, one aggregated risk score that reflects everything happening across every identity surface he touches. Resolution runs continuously as new integrations come online, without manual curation.

In the image above, we've created one entity record per user account and grouped them together, so when an analyst reviews the record, all related identities appear in one place.

What this changes for analysts

For the security operations center (SOC) analyst working a 2 a.m. alerted by their Elastic agentic workflow, these two architectural decisions (confidence-tiered entity governance and unified identity resolution) change the investigation fundamentally.

Instead of opening four separate entity cards for the same person, they open one. Cross-provider risk signals are aggregated into a single score, and attack narratives that span identity systems are visible as narratives, not as disconnected data points buried in separate views.

Compare this to investigating a bare deploy entity record with a risk score of 70 that’s actually an artifact of 12 people’s blended activity across 200 servers. One investigation leads somewhere. The other erodes trust in the entire capability, which is the real cost of noisy entity records. Not just the false positive itself, but the analyst who learns to ignore entity risk scores entirely.

The entities records you don't create

Perhaps the most underappreciated aspect of entity analytics design is restraint. Every entity record you create has a cost: Compute for baselining, storage for history, analyst attention when it generates alerts, and potential for noise propagation into the broader analytical model.

The discipline to not create an entity record (to require a minimum evidence threshold) is what separates an entity analytics system that gets more useful over time from one that slowly drowns its operators in noise.

In practice, this means maintaining a configurable exclusion list for common service and shared accounts: root, jenkins, deploy, postgres, and others like them. These accounts exist on hundreds of machines, are used by automated processes and multiple humans interchangeably, and would produce baselines that mean nothing. Elastic Security ships a default list covering the most common offenders. Today the list operates at the username level — root is excluded uniformly regardless of which host it appears on — and is fixed. Future iterations will make it configurable, letting teams add their own environment-specific service accounts and, eventually, specify compound patterns that combine username and host. That would allow excluding root globally on shared infrastructure while still creating a host-scoped entity when that account appears on a personal workstation where the activity is attributable to a specific person. The architecture is already built for it: because endpoint-observed entities are keyed as {user.name}@{host}, compound rules are a coherent extension, not a redesign.

The higher-fidelity approach we've described directly mitigates the broader noise problem. When entity records are created from any username string in a log, your ML models end up baselining service accounts, typo'd logins, and shared kiosk accounts as if they were people — a 2 a.m. backup job looks anomalous against a human baseline, and a one-event typo'd login never accumulates enough data to baseline at all. When entity records are anchored to authoritative identity sources and resolved across their various login forms, the model learns patterns for actual humans doing actual work. Anomalies become meaningful because the baseline is meaningful.

The best entity analytics isn't the one that creates the most entities. It's the one that creates the right entities, governs them by what it actually knows about their source and scope, and builds its analytical investment proportionally. Everything else (risk scoring, behavioral baselines, entity resolution, anomaly detection, and AI skills) is downstream of that foundational decision. Get the entity records right, and the analytics follow. Get them wrong, and no amount of machine learning or AI can save you.

Entity analytics is available in Elastic Security. Learn more about advanced entity analytics and how the entity store governs user entities.

The hunting gap no one talks about

Ask any threat hunter what slows them down, and you'll hear the same answer: it’s not the querying or the pivoting; it's the blank page. The moment before the hypothesis is formed. Most analysts know that somewhere in their telemetry there are patterns that signal compromise, lateral movement, or abuse; they just don’t know where to start.

Modern AI agents have a discovery problem: they’re brilliant at answering questions but useless if you don’t know what to ask. This "curiosity gap" traps security teams in a cycle of reactive hunting. Whether it’s waiting for a vendor threat intelligence report to drop, an alert to scream, or a CISO to grill the team during a QBR, the damage is often already done. While analysts wait for a hypothesis, AI-powered adversaries are moving at machine speed—widening an already dangerous window of opportunity.

The industry has tried to close this gap through detection rules, threat intel feeds, and user and entity behavior analytics (UEBA) scoring. These are necessary, but they're static frames applied to a dynamic reality. A UEBA anomaly tells you something is unusual. It doesn't tell you why it matters in your environment today.

The core problem

Detection rules tell you what to look for that’s very specific. Threat intel tells you what others found. Neither one tells you what your environment is uniquely at risk for right now, because neither one actually knows your environment.

Building the foundation: The entity store

Solving the hunting gap required us to first solve a data problem. Hunting leads are only as effective as their context; and in security, context is the sum of everything true about an entity over time.

We built the Elastic entity store as a purpose-built ontology for exactly this. Unlike Elastic Common Schema (ECS), which captures the state of a field at event time, the entity store is a longitudinal record, a living profile of characteristics of every user, host, and service in your environment. It tracks four dimensions that matter for security reasoning:

// Entity Store Schema — Core Characteristics

entity.attributes // Who/what the entity IS
  mfa_enabled: false // From AWS integration
  privileged_groups: ["Domain Admins"] // From AD
  asset_criticality: "high"

entity.lifecycle // Temporal facts
  first_seen: "2024-09-14T08:22:00Z"
  last_active: "2025-03-31T23:47:00Z"
  dormancy_detected: true // Inactive 47 days, now active

entity.behavior // Anomalous signals (rolling window)
  brute_force_victim: true
  unusual_login_hours: true
  new_geo_access: "DE" // First access from Germany

entity.risk // Scored risk aggregation
  calculated_level: "Critical"
  score: 94.2

This schema isn’t just storage; it's also a reasoning substrate. Each field represents a signal that, in combination with others, tells a coherent story about an entity's current threat posture. A user who was dormant for 47 days, is now active outside business hours, logged in from a new country, and doesn't have multifactor authentication (MFA) is not just risky in isolation; that combination is a hunting lead.

Reasoning over entity data

With the entity store providing rich context, we built Entity analytics AI-hunting leads. These reasoning modules traverse entity profiles and correlate data across users and hosts to surface patterns that human analysts would find meaningful, if they had the time to look everywhere at once.

These AI-generated hunting leads are automatically surfaced on our Entity analytics home page, ingesting the entity store state to identify combinations that constitute a threat hypothesis. This isn't a simple rule match; it’s a narrative hypothesis grounded in your actual environment.

What makes this different

Proactive hunting assistance tools are emerging across the industry. Many are useful tools, but they share a fundamental constraint: They reason over threat intelligence reported information plus event telemetry, not over accumulated entity knowledge.

The difference matters. A query-based approach can find events that match a pattern. An entity-aware approach can find entities that, given everything we know about them, are likely to be involved in something worth investigating. That's a fundamentally richer signal source, and it's one that gets sharper over time as entity history accumulates for what’s been missing in retrohunt features in modern security information and event management (SIEM).

Hunting as a continuous discipline

The promise of proactive security is stopping attackers before they reach their objective. Traditionally, the barrier has been analyst capacity. With the rise of AI-driven attacks, this is becoming an impossible task for humans alone.

Entity analytics AI-generated hunting leads don't replace hunters; they multiply them. A senior analyst no longer spends hours figuring out where to look. Instead, they start their shift with a prioritized set of hypotheses that the AI-generated hunting leads already curated. Their time is preserved for what only humans can do: validation, decision, escalation, and response.

What's next

Entity analytics AI-generated hunting leads are the first production expression of a broader capability roadmap: an Elastic Security that doesn't wait for you to ask a question. As Entity analytics matures, with expanded entity types such as tracking AI agents, the reasoning surface expands accordingly.

Entity analytics is available in Elastic Security. Learn more about advanced entity analytics, AI-hunting leads and how the entity store governs user entities.