Visibility
Privileged Access
IAM Engineer
Cloud Security
Find every privileged NHI and prove which ones actually use their privilege to eliminate the ones that don't
Quick Summary: Dormant NHI Detection and Decommissioning is one of the highest-impact steps an enterprise can take to shrink its attack surface — Oleria Trustfusion, an AI-native identity security platform, identifies every inactive non-human identity across your environment and gives you the cross-app context to decommission them safely, before attackers exploit the gap.
The service account that picked up Administrator scope in 2021 for a one-time setup task - and kept it - is more dangerous than anything on your privileged-account watchlist. Oleria finds every admin-scope NHI across your entire stack and shows you exactly how much of that privilege is actually used.
Privilege accumulates. A service account gets Administrator policy attached for a one-time setup task and keeps it forever. An IAM role gets a permissive trust policy "just for now" and that policy outlives every stakeholder who knew why. By the time someone goes looking, "privileged NHI" is a fuzzy category that means different things in AWS, Azure, GCP, Salesforce, Snowflake, and Okta. The ones you remember to track aren't the ones that will get exploited.
OWASP NHI5:2025 - "Overprivileged NHI" - is consistently the highest-prevalence NHI risk in published research. CIS Benchmarks and NIST guidance both flag overprivileged service accounts as a top remediation priority, and enterprise security teams consistently report it as one of the hardest problems to stay ahead of. OWASP's LLM Top 10 adds a newer dimension: excessive agency - AI integrations and custom apps that inherit workspace-level access at deployment, with no mechanism to scope permissions down afterward. The pattern is universal: privilege gets granted in a hurry, never gets reviewed.
Yet the inventory most teams have is a list of named privileged accounts they remember to track, not the actual set of NHIs with admin scope. CSPM finds the misconfigurations. CIEM finds the effective permissions. Neither treats roles as identities with owners, lifecycle, and review cycles. The thing the cloud team needs - "show me every NHI with admin scope, who owns it, what scope it actually exercises" - sits between the categories.
Oleria's Privileged NHI Access Usage Verification capability maps every admin-scope non-human identity across all platforms and shows you exactly which ones actually exercise that privilege — so you can right-size with evidence, not guesswork.
AWS Administrator, Azure Owner, Salesforce System Administrator, Snowflake ACCOUNTADMIN, Okta Super Admin - normalized into one list, so nothing hides in the gap between platforms.
Every privileged NHI shows what scope it holds versus what scope it has actually exercised. Right-sizing candidates surface automatically - no manual triage needed.
For cloud roles, Oleria traces what NHIs can assume them across up to three hops. Privilege gained through a chain is just as dangerous as privilege held directly; now you can see it.
Every privileged NHI gets a named owner, declared purpose, and last review date. No exceptions, no "we'll get to it later
You connect AWS (across 23 accounts), Entra, Salesforce, Snowflake, and Okta. The platform finds 8,124 NHIs total. Of those, 423 hold admin or near-admin scope. Sorted by usage, 187 of those have not exercised admin scope in 90 days - they're right-sizing candidates, queued automatically. Sorted by ownership, 89 admin-scope NHIs are unowned. Sorted by trust-policy permissiveness, 34 AWS roles allow assume from a wildcard principal. The cloud team takes the trust-policy queue, the data team takes the Snowflake ACCOUNTADMIN slice, the SaaS admin takes the Salesforce System Administrator queue. Three months later, granted-versus-used delta is at 12%, down from 65%. Drift to overprivilege is detected within hours of the next admin grant.
Defaults are app-specific and follow vendor and OWASP guidance. AWS Administrator, Azure Owner, Salesforce System Administrator, Snowflake ACCOUNTADMIN, Okta Super Admin. You customize per app, per role - because what's "privileged" in your environment may include custom roles your team has defined.
Yes. If an NHI has assume-role rights into a privileged role, it shows up on the privileged-by-chain list. Three-hop chains traced. The chains are where attackers operate; visibility shouldn't stop at the first role.
Directly. NHI5:2025 is "Overprivileged NHI." The right-sizing workflow that comes from this inventory is the practical mitigation OWASP recommends. We make it tractable rather than theoretical.
Service accounts that can grant privilege to others - through impersonation, role delegation, IAM PassRole - flag separately. Privilege escalation visibility builds on this inventory. The first step is always: know what's actually privileged today.
Privileged NHI inventory maps directly to least-privilege controls required by SOC 2 CC6 and PCI-DSS 7. The granted-vs-used evidence and review cycle are audit-ready exports, not manual compilation.
