Inside Oasis’s NHI Enrichment Layer: How Context Gets Built

NHI Enrichment is the process of attaching operational context to every non-human identity: ownership, dependencies, behavioral baselines, and credential relationships. Instead of keeping this data scattered across identity providers, vaults, and SIEMs, Oasis anchors it to the identity itself, turning findings into decisions.

Most identity teams have more data than they can use: logs, alerts, dashboards, exported CSVs from multiple tools (IGA, IdP, PAM). The challenge isn't volume. The challenge is that all this data doesn't tell a story.

A service principal exists in Entra ID with a name, a creation date, and permissions. A secret lives in HashiCorp Vault with no pointer back to the identity that uses it. An authentication event sits in Splunk with no indication whether it's normal behavior or a true anomaly. Three systems, three fragments, no picture.

That disconnection is what makes NHI and agentic access security so operationally difficult. You can't rotate a secret without knowing what consumes it. You can't assess blast radius without knowing what breaks if the identity goes down. You can't investigate an alert without knowing whether the behavior is unusual and whether it touches a business-critical system: payments, order fulfillment, customer data.

Every one of those is a context question. And that's exactly what Oasis's enrichment layer is built to answer.

‍

What does NHI Enrichment mean and why does it matter?

Enrichment means attaching the missing context an identity team needs to act, not just observe. For every non-human identity and AI agent, Oasis continuously builds a living profile that connects:

• What the identity is (metadata, type, lifecycle signals)
• Who and what can use it (real consumers and dependencies)
• What can reach and what it actually did (resources and privileges)
• What credentials power it (secrets, keys, certificates)
• What “normal” looks like (behavioral baseline + deviations)
• What changed over time (an auditable timeline)
• Who’s behind it (vendor context)
• Why it matters to the business (apps/workflows it powers, data sensitivity, production impact, financial/HR criticality)

Instead of keeping these answers scattered across tools, Oasis anchors them to the identity, so a finding becomes a decision. 

And we don't stop at insight. Oasis turns that context into digestible work packages (Projects) that bundle related NHI issues into prioritized, assignable cleanup and lifecycle initiatives, rather than a flat list of alerts.

‍

How does each integration deepen NHI context

Each integration adds a new dimension to every identity's profile, and those dimensions compound rather than simply stack.

Azure tenant: Oasis gains identity metadata, permission assignments across Entra and Azure resources, and resource access maps. 

Okta or Active Directory: Oasis understands how service accounts are synced and used across on-prem and cloud, adding ownership and usage context. 

HashiCorp Vault or Azure Key Vault:Vaulted secrets, keys, and certificates tied to each identity are surfaced and linked. 

Wiz or Cyera: and Oasis can map which identities can reach sensitive data (like PII) and where that data lives. 

SharePoint or Teams: Oasis can detect secrets shared in plaintext and link them back to the identities they belong to. 

ITSM:Oasis can operationalize lifecycle actions, routing findings, driving rotation/cleanup workflows, and tracking remediation. 

Each integration answers a question the others can't. An IDP knows what an identity is permitted to do, not what it's actually doing, or what depends on it operationally. A secret manager knows what credentials exist, not which consumers are using them and what those consumers can access. And a SIEM can show events, but not whether they’re expected for a specific identity.

Oasis takes all of it and anchors it to the identity. The enrichment accumulates there, not scattered across systems. And the more you connect, the more complete and actionable that profile becomes. If you are an Oasis customer, see the full list of Oasis integrations. 

‍

What does a complete NHI identity profile include?

The practical output of all that integration is an identity profile that Oasis builds and maintains continuously for every NHI and AI agent. This is where enrichment becomes operational, and where the architecture directly enables the things teams struggle to do confidently: rotation, investigation, decommissioning, ownership assignment, all powered by context that captures dependencies and downstream consequences.

‍

The Graph: who uses the identity, what it reaches, and how

The most distinctive enrichment surface in Oasis is the identity Graph. Rather than showing a static record of what an identity is configured to do, the Graph shows what's actually happening across three live layers:

• Consumers: The services, applications, API gateways, or third parties actively authenticating as the identity, along with the specific credentials they're using and where they're connecting from.
• Resources: The downstream assets the identity can reach (storage blobs, databases, tables, roles), along with the privilege level it holds over each.
• Secrets: The credentials tying consumers to the identity.

All three layers update continuously as your environment changes, not on a quarterly review cycle.

Caption: See what uses an identity, what credential it uses, and what access it unlocks, end to end.
Alt text image: Oasis graph view linking consumers, a client secret, a service principal, and Azure roles/resources.

Cloudflare's March 2025 outage illustrates exactly what's missing without this map: old credentials were retired before anyone confirmed that production had migrated off them, because there was no live view of what was using what. The graph is that map, before you rotate, Oasis shows you every consumer that will be affected, what they're connecting from, and which resources they'll lose access to.

The graph also handles cases your configuration management doesn't. Consumers that have failed to connect appear with a red indicator, surfacing broken dependencies before they become production incidents. When multiple consumers share characteristics they're grouped, and you can ungroup them to investigate each individually. And when you need to follow a chain of related identities, the Graph lets you pivot from one identity's view to a related entity, an agent, a vault, an access key, without losing context. When an IP maps to a known vendor's infrastructure, that attribution is labeled directly on the consumer node, so you don't have to manually figure out who's behind an authentication event.

‍

The NHI audit trail: what changed, when, and who acted

Enrichment isn't only about the present state of an identity. It’s also about adding the time dimension to the identity story.

The Oasis Timeline gives every identity a chronological audit trail combining two event streams: events from the identity provider (credential additions, role changes, permission modifications) and events from Oasis itself (issues created, resolved, severity escalated, ownership changed). Together, they provide the foundation to investigate what happened before and after a meaningful event, and to understand the identity over time, including who has been managing it most actively, so teams can drive ownership and take action.

That sequencing is what makes the difference between an anomaly you can investigate and one you can only react to after the fact.

Caption: A chronological audit trail for every identity: changes, issues, and remediation in one place
Alt text image: Oasis Timeline view listing identity changes and remediation events over time.

‍

How do you detect anomalous NHI behavior without alert noise?

Knowing how an identity is being used is foundational, it's how you manage the lifecycle safely, validate dependencies, and avoid breaking production. Behavioral enrichment adds the next layer: it tells you whether that usage looks expected, so the same activity data can support ITDR without becoming a flood of alerts.

Oasis builds a baseline for each identity by grouping its consumers according to five shared signals: ASN (the network or internet provider), geolocation (country of access), IP type (internal vs. public), the organization they're associated with, and the specific credential they used. Each consumer group gets its own baseline of normal activity, established over rolling windows of 30, 60, or 90 days.

Deviation detection operates at two levels:

• Within a known consumer group: if a previously stable group starts behaving differently (new geolocation, different credential, unusual volume), it surfaces in orange.
• New consumer group appearing: if a combination of signals has never appeared in the baseline window, it's flagged red and treated as high risk automatically.

This two-level model is what distinguishes meaningful detection from alert noise. A new IP accessing an identity might be a legitimate new service or an attacker. The baseline resolves that ambiguity, it knows whether that ASN, geolocation, and credential combination has ever appeared before.

Caption: Behavioral enrichment baselines NHI activity by consumer group and flags new or drifting patterns so teams can spot risky changes without alert noise.
Alt text image: Consumer group activity timeline for an AWS access key with ASN and location details

‍

Vendor and application attribution: resolving NHI ownership at scale

Some of the most valuable context isn't another field on an identity, it's attribution: knowing what an identity belongs to, what it powers, and who's on the other side of its activity.

Oasis uses a grouping layer to connect identities, credentials, and consumers into higher-order entities: applications and third parties. That grouping draws from multiple signals: naming and metadata, observed usage and dependencies, consumer infrastructure, and credential relationships, so identity sprawl resolves into legible units: "these identities belong to Payments," "these are tied to HR tooling," "these are owned by Vendor X."

When the grouping resolves to a third party, Oasis builds vendor context that directly informs prioritization. A service principal tied to an unrecognized vendor carries meaningfully different risk than one tied to a well-established provider, even if the permission set looks identical. That context surfaces inside the Graph, down to labeling consumer nodes when IPs map to known ranges.

‍

What becomes possible with full NHI context?

We've written about the posture trap, the state most identity programs end up in where findings accumulate faster than teams can act on them, because acting requires confidence that the data alone doesn't provide. Framed the five questions that context needs to answer for any NHI and AI agent. The secret scanning post showed what changes when you treat a leaked credential as an identity problem rather than a string-matching problem.

Enrichment is the common foundation underneath all of it. The Graph is only reliable enough to rotate against because it's built from live, cross-source data. Behavioral baselines are only specific enough to be actionable because they're scoped to individual consumer groups. Vendor context only informs prioritization because it's attached to the identity itself.

A finding without enrichment is a data point. A finding with full context is a decision.

To see how the enrichment layer works across discovery, rotation, and investigation, start with the product overview.

‍

FAQ

What is NHI enrichment?

NHI enrichment is the process of attaching operational context, including ownership, dependencies, behavioral baselines, and credential relationships, to every non-human identity so security teams can act on findings with confidence.

How does Oasis build identity context for non-human identities?

Oasis correlates data from identity providers, secret vaults, SIEMs, EDRs, cloud platforms, and ITSM tools, then anchors all context to the identity itself through a live graph, behavioral baselines, and a chronological timeline.

What data sources does NHI enrichment require?

NHI enrichment draws from identity providers (Entra ID, Okta, AD), secret managers (HashiCorp Vault, Azure Key Vault), cloud platforms (AWS, Azure, GCP), data security tools (Wiz, Cyera), EDR toos (Crowdstrike, Microsoft Defender for Endpoint, and SentinelOne) and ITSM systems. Each integration adds a new dimension to every identity's profile.

How do behavioral baselines detect NHI anomalies?

Oasis groups each identity's consumers by five signals (ASN, geolocation, IP type, organization, credential used) and establishes a baseline over 30, 60, or 90 days. Deviations within known groups surface in orange. Entirely new consumer groups are flagged red as high risk.