The Rise of NHI Security: What Oasis, Entro, and Astrix Miss

Two years ago, most security teams could not tell you how many service accounts they operated. Today, NHI security is a named Gartner category, three vendors have raised nine-figure rounds, and the average enterprise has more machine identities than employees. The category has arrived.

But the category is fragmented. Oasis Security anchors on discovery and posture. Entro Security leads with secrets. Astrix Security started with third-party OAuth grants. Aembit brokers workload access. Each vendor is excellent at what they built for, and each solves only one slice of the actual problem.

Consider what it looks like in practice when a team uses three of these tools concurrently. The secrets scanner finds a GitHub Actions token. The posture tool classifies it as high-risk. The workload broker has never heard of it because it was never enrolled. Three dashboards. Three alert queues. One human wondering which of the three is actually authoritative. That friction is not an integration problem — it is a category-structure problem.

The category, mapped

Each of these products earns its keep — the teams building them are sharp, and the problems they are solving are real. The issue is not vendor quality; it is that buying all five still leaves gaps. Aembit cannot tell you who owns the workload it is brokering. Astrix does not know about the service account behind the OAuth client. Entro finds the secret but cannot decide whether to revoke the session that is currently using it.

The gap lives in the connective tissue — the identity graph that would let a single policy say: "This secret, owned by this team, used by these workloads, accessed by these AI agents, is over-privileged and has not been rotated in 147 days." No point tool can make that statement. They each see one dimension of the same problem.

Why the gaps compound

The fragmentation is not just an inconvenience. When multiple tools cover overlapping but non-identical perimeters, three specific pathologies emerge that individually look tolerable and collectively create a breach-sized hole.

• Alert fatigue amplification. Three tools generate three alert streams, each calibrated independently. A secrets tool flags an API key as "exposed." A posture tool flags the same identity as "low-risk." The analyst gets two contradictory signals and dismisses both.
• Remediation ownership ambiguity. When the posture tool finds a problem and the remediation workflow lives in the secrets tool, who triggers the rotation? The workflow stalls in the seam between products. One large financial services firm we spoke with traced a 23-day remediation delay to exactly this cross-tool handoff.
• Policy consistency failure. Each tool has its own policy language. You write a rule in Entro that says "no secret older than 90 days." You write a rule in Oasis that says "flag identities with no rotation in 90 days." They are different rules about the same thing, and they will drift.

The identity graph is the missing primitive

What none of the point tools ship — because each is incentivised to grow its own inventory — is a shared identity graph. The graph is the primitive that makes every downstream capability coherent: detection, enforcement, compliance, ownership routing. Without it, each tool is reasoning about a subset of reality.

Consider a fairly routine question: "Which AI agents have access to production databases?" To answer it from point tools, you need to reconcile agent inventories from your developer tooling, OAuth grants from Astrix, database service accounts from Unosecur, and workload identities from Aembit — then join them manually. In a graph, this is a two-hop query. The difference is whether your security team can answer the question in thirty seconds or thirty days.

# Graph query: AI agents with production DB access
MATCH (a:Agent)-[:USES]->(sa:ServiceAccount)
      -[:HAS_PERMISSION]->(r:Resource {env: "production", type: "database"})
WHERE a.last_seen > now() - duration("7d")
RETURN a.id, a.owner, sa.name, r.name, r.sensitivity
ORDER BY r.sensitivity DESC

The code above is trivial to write. It is impossible to execute if the Agent, ServiceAccount, and Resource nodes live in three different products' private databases. The graph is not a feature — it is the prerequisite for every useful feature.

What a unified platform actually needs

• Discovery beyond one plane. Not just cloud IAM. Not just secrets. Every NHI — service account, API key, bot, AI agent — across cloud, code, CI/CD, and SaaS.
• Live behavioural detection. Posture scoring is table stakes. Real value is TIDR-style behavioural signals streamed through a decision engine.
• In-line policy enforcement. Detection without enforcement generates alerts and homework. Sub-50 ms decisions and short-lived credentials collapse the response loop.
• AI agent governance. MCP is now the dominant tool-use protocol. If your platform cannot proxy MCP calls, it cannot govern the fastest-growing NHI type.
• One identity graph. NHIs relate to humans, humans relate to secrets, secrets belong to workloads. A stack of disconnected point tools cannot answer any interesting question.
• Unified policy language. Writing the same rule in five DSLs is not policy management — it is policy chaos. One YAML-based DSL that compiles to executable rules across every NHI type is non-negotiable.
• Compliance evidence generation. The SOC 2 auditor does not care which of your three tools produced the evidence. The unified platform produces it once, consistently, from the same underlying data.

The enforcement gap is the most urgent

Of the five requirements above, enforcement is the one where the existing market is most exposed. Posture tools find problems elegantly. Secrets tools surface credentials beautifully. But when an anomaly is detected at 02:00, the credential is still valid at 02:01 and at 02:30 when someone finally reads the alert. The time-to-enforcement gap is where breaches live.

Real enforcement means that a TIDR signal — say, a service account making an unusual volume of cross-region calls — feeds directly into a running decision engine that can revoke the session, shorten the next credential TTL, or trigger a step-up authentication challenge for the human owner. All of that has to happen in seconds, not minutes. And it has to happen without a human in the loop, because threats at machine speed require responses at machine speed.

The AI agent dimension everyone is underestimating

Every existing NHI vendor was designed before AI agents were a meaningful category. The architectural assumptions — that an NHI is a service account, a bot, or an API key — do not translate cleanly to agents that spawn sub-agents, invoke dozens of MCP tools per session, operate across multiple systems in a single turn, and may act with degrees of autonomy that no prior NHI type exhibited.

AI agents create new attack surfaces that posture scores cannot capture. An agent's "posture" at session start may be perfectly clean. Its third tool call — triggered by adversarial content in a document it read — may be a privilege escalation attempt. Static posture is blind to this. Only per-call, in-line policy enforcement inside an MCP gateway can catch it.

None of the existing point tools were architected for per-call governance at MCP latency. They were built to scan and report, not to sit in the critical path of a live agent session. This is not a gap you can patch onto a posture tool — it requires a different architecture.

Reading the market signals

The consolidation signals are already visible. Larger identity vendors — the established IAM players — are beginning to acquire point tools rather than build. Enteprise procurement teams are pushing back on multi-vendor NHI stacks in renewal conversations. And the most telling indicator: the security teams running mature NHI programmes are not buying more point tools; they are asking how to reduce the number they already have.

What this tells you about timing: if you are standing up an NHI programme today, buying a point tool is a two-year rip-and-replace. Buying a platform is a ten-year foundation. The economic argument is not close.

What TigerIdentity contributes

TigerIdentity was built as the unified answer. Discovery inherits from a graph, not a spreadsheet. Secrets, workloads, and AI agents share the same policy DSL. TIDR runs continuously across every NHI type. The MCP gateway proxies AI agent tool calls in-line. And every decision resolves in under 50 ms so enforcement is real, not aspirational.

The platform covers more than 80 integrations out of the box — cloud IAM, secrets managers, Kubernetes, CI/CD systems, SaaS identity providers, and MCP-compatible AI agent clients. Each connector feeds the same identity graph, and the same policy engine governs every node in it. That coherence is what the point-tool category cannot replicate by design.

If you are evaluating the NHI security category and finding that no single vendor covers the ground you care about, this is exactly why. The category is real. The consolidation is inevitable. Now is the time to pick the platform, not the point tool.