- A secrets vault protects credentials it already knows about. The majority of service accounts, OAuth tokens, API keys, and machine-to-machine connections in a typical enterprise were never registered in any vault and never will be without a dedicated discovery pass.
- NHI platforms do four things a vault cannot: find identities that were never registered, map what those identities can actually do across cloud and SaaS, assign ownership to a human, and flag identities that have not been used in months but still hold standing privilege.
- The market splits into three architectural camps: API-graph platforms that interrogate cloud and SaaS control planes without an agent, secrets-intelligence platforms that scan code and pipelines for exposed credentials, and full-lifecycle governance layers that sit on top of existing PAM and IAM.
- Pricing models vary widely: per-identity, per-integration, per-seat, and flat-rate enterprise commitments all exist, and almost no vendor publishes list prices. Run a discovery pass before you scope a purchase, because identity count estimates made without tooling are routinely wrong by an order of magnitude.
- AI agents and autonomous workflows are collapsing the boundary between NHI security and AI agent security. Platforms that cannot distinguish a long-lived service account from an ephemeral agentic identity are already behind.
Non-human identity security platforms discover, inventory, and govern machine identities including service accounts, API keys, OAuth tokens, CI/CD pipeline credentials, and workload certificates across cloud, SaaS, and on-premises environments. They differ from secrets vaults by finding identities that were never stored in the vault, mapping the effective permissions each identity holds, and assigning human ownership so that stale or over-permissioned identities can be remediated or rotated.
What a Secrets Vault Does Not Do (and Why That Gap Is Now the Problem)
Most security teams inherit a mental model where PAM and vault coverage equals NHI coverage. That model breaks the moment you ask a specific question: how many OAuth tokens exist in your environment right now, and which ones have write access to production data? The vault knows about credentials that were deliberately stored there. It knows nothing about the token a developer minted six months ago to connect a Slack integration to a Salesforce sandbox and never rotated.
This is not an edge case. SaaS-to-SaaS integrations proliferate without any IAM team involvement. A product manager authorizes a third-party app through an OAuth consent flow. A CI/CD pipeline gets a long-lived GitHub Actions secret that never makes it into the vault. A cloud function spins up with an overly permissive service account because the developer copied an example from the documentation. Each of these creates a non-human identity with real access and no governance record.
The NHI platforms reviewed here address a specific architectural gap: discovery of identities outside the vault’s awareness, effective-permission mapping across cloud and SaaS control planes, and lifecycle governance that connects each identity to a human owner. Storage and rotation of known credentials is a separate, solved problem. The gap is everything the vault never learned about.
The SecurityOpsWire NHI Sizing Test: Run This Before You Buy Anything
Before scoping a platform purchase, run what this article calls the SecurityOpsWire NHI Sizing Test: a four-question discovery pass that gives you a defensible estimate of your actual NHI population and tells you which platform category fits your environment.
- Cloud service account count: Query your AWS IAM, Azure Entra, and GCP IAM APIs for all service accounts, service principals, and workload identities. Count the ones with no login activity in 90 days. That number is your standing-privilege overhang.
- SaaS OAuth token inventory: Pull the OAuth app grants from Google Workspace, Microsoft 365, Salesforce, and Slack. Count distinct third-party apps. The ratio of approved apps to apps the IT team can name is your shadow-integration ratio.
- Pipeline secret exposure: Run a static scan across your Git repositories for secrets in source code. The findings here tell you whether you need a secrets-intelligence platform alongside an NHI governance layer, or whether the vault enrollment problem is your primary risk.
- Ownership coverage: Pick 20 service accounts at random and ask whether a named human is responsible for each. If fewer than half have a documented owner, ownership mapping is your first operational need, not credential rotation.
The answers determine platform fit more reliably than any vendor demo. A team that finds 80 percent SaaS exposure with low cloud service-account sprawl needs a different tool than one with ten thousand AWS IAM roles and minimal SaaS surface.
14 Non-Human Identity Security Platforms Compared
Each entry below covers: what the platform discovers and how, how deep its permission analysis goes, and what is publicly known about pricing. Where vendors do not publish pricing, that is noted directly rather than papered over with vague language about “flexible options.”
1. Astrix Security
Astrix Security was built as an API-graph platform focused specifically on third-party integrations: OAuth tokens, API keys, and service-to-service connections that link SaaS applications together. Discovery works by connecting to the control planes of SaaS and cloud providers and pulling the full graph of what is connected to what, without requiring an agent on endpoints or VMs.
Permission analysis in Astrix covers effective scope, not just granted scope. The platform surfaces when an OAuth token was granted broad write permissions but only ever used read operations, which is the signal that matters for right-sizing. It also tracks whether a connected third-party app is still in active use or was last seen authenticating months ago.
A relevant corporate development: according to Astrix Security’s own website, Astrix Security is now part of Cisco. The announcement states: “Astrix Security is now part of Cisco. This marks an exciting new chapter, bringing our AI Agent and Non-human Identity security capabilities to a broader range of organizations. As part of this transition, Astrix has ended standalone sales of new licenses effective June 30th, 2026.” Astrix Security’s website further states that “Existing customers will continue to receive the service and support outlined in their current agreements, and we are actively working on bringing Astrix capabilities into Cisco over time.” Teams evaluating Astrix should note that standalone licensing is no longer available; the platform’s capabilities are being absorbed into Cisco’s security portfolio. Pricing for the integrated Cisco offering is not publicly disclosed.
2. Entro Security
Entro Security positions itself as a secrets-context platform: it integrates with vaults including HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, and CyberArk, and then builds the context layer those vaults lack. Discovery pulls the inventory of secrets from connected vaults and enriches each one with information about where it appears in code repositories, CI/CD pipelines, and running workloads.
The permission analysis depth depends on the cloud provider. Entro maps what each secret actually grants in the cloud control plane and flags when a secret’s effective permissions exceed what the owning application needs. Ownership mapping is a first-class feature: the platform traces each secret back to the team or individual who created it and assigns a human accountable owner.
Pricing is not publicly disclosed.
3. Oasis Security
Oasis Security takes a lifecycle-governance approach across both human and non-human identities, with a specific emphasis on service accounts in Active Directory, Azure Entra, and cloud-native environments. Discovery is agentless and operates by connecting to identity provider APIs to enumerate all service accounts, managed identities, and federated credentials.
Permission analysis in Oasis covers group memberships, role assignments, and effective access computed across nested groups, which matters because the raw role assignment often understates what a service account can actually reach. The platform tracks usage analytics to identify stale accounts and flags accounts whose permissions have drifted upward since creation.
A relevant corporate development: according to Oasis Security’s website, the company has been acquired by Cyera. The website states: “Oasis has been acquired by Cyera. Discover how we’re building the next-generation AI security platform.” Teams evaluating Oasis should verify current product availability, licensing terms, and roadmap directly with Cyera. Pricing is not publicly disclosed.
4. Token Security
Token Security focuses on cloud workload identities with an emphasis on runtime behavioral analysis. Discovery connects to AWS, Azure, and GCP control planes and also reads kubeconfig and service account tokens in Kubernetes environments. The platform correlates what an identity is configured to do with what it has actually done, surfacing permissions that exist in policy but have never been exercised.
This last-used analysis is where Token Security differentiates from pure control-plane scanners: it joins the IAM policy graph with CloudTrail, Azure Monitor, or GCP audit logs to compute unused permissions, not just granted permissions. For teams running heavily permissive cloud environments inherited from rapid growth, that behavioral signal is the starting point for remediation.
Pricing is not publicly disclosed. Token Security does not publish a self-serve tier.
5. Natoma
Natoma positions itself around the ownership problem in NHI governance, with discovery spanning cloud IAM, SaaS OAuth, and CI/CD pipeline credentials. The platform’s stated focus is connecting each NHI to a human owner and maintaining that mapping as organizations change. Note that at the time of publication, Natoma’s public website does not expose detailed product documentation; teams evaluating this platform should request a direct briefing to verify current capabilities and coverage depth.
Based on available positioning, Natoma uses code repository metadata, deployment records, and directory data to automate ownership assignment where possible, and generates access review campaigns targeted at identified owners with attestation tracking. For teams whose primary NHI problem is not knowing who to call when a stale service account needs to be disabled, an ownership-first architecture fits better than platforms that lead with raw discovery. Pricing is not publicly disclosed.
6. Clutch Security
Clutch Security approaches NHI governance from the rotation and remediation side. Discovery is agentless, connecting to cloud and SaaS APIs, but the platform is built around operationalizing what you find: automated rotation workflows for API keys and service account credentials, with integrations to CI/CD systems so that rotated secrets are pushed to the right place without manual steps.
Permission analysis covers what each identity is scoped to access, with particular depth on secrets sprawl across repositories. The platform flags when the same credential appears in multiple locations, which is a common pattern when developers copy secrets into configuration files rather than pulling from a vault at runtime. Pricing is not publicly disclosed.
7. Britive
Britive takes a just-in-time access model to NHI, similar to what PAM vendors offer for human privileged access. Discovery covers cloud service accounts and machine roles across major cloud providers and SaaS platforms. The core differentiator is ephemeral access: instead of a service identity holding standing permissions, Britive grants permissions at the moment they are needed and revokes them immediately after the job completes.
For teams running batch workloads or pipelines where the NHI needs elevated cloud access for a narrow window, this architecture eliminates the standing-privilege problem rather than just monitoring it. The trade-off is operational complexity: the application code or pipeline must be able to request and receive credentials dynamically, which requires some engineering effort to integrate. Pricing is not publicly disclosed.
8. Aembit
Aembit focuses on workload-to-workload authentication, the specific moment when one service needs to prove its identity to another without a human in the loop. Discovery enumerates the service-to-service trust relationships in an environment by inspecting network calls, service mesh configurations, and cloud workload identity federations.
The platform’s architecture is closer to a workload identity broker than a governance scanner: it sits in the path of service-to-service calls and enforces policy at the access layer, similar to how a network proxy enforces traffic policy. Permission analysis covers what each workload identity is authorized to call and what it has called. For teams building or operating microservices environments where lateral movement between services is the primary risk, this in-line model offers stronger enforcement than a scanner that reports findings after the fact. Pricing is not publicly disclosed.
9. Veza
Veza built its platform around an access graph that covers both human and non-human identities across cloud, SaaS, data, and on-premises systems. Discovery connects to identity providers, cloud IAM, SaaS application APIs, and data platforms, pulling the full permission graph. The differentiator is breadth: Veza can show who or what can access a specific Snowflake table, an S3 bucket, or a GitHub repository in a single query.
Permission analysis in Veza computes effective access, meaning it resolves nested groups, role inheritance, and cross-system trust chains down to the specific data object or resource. For NHI use cases, this means you can ask which service accounts have read access to a specific RDS database and get a verifiable answer rather than a partial view from a single IAM system. Veza is positioned at the enterprise end of the market. Pricing is not publicly disclosed and the company quotes per environment.
10. Saviynt
Saviynt is an established identity governance platform that has extended its coverage to NHI as part of its broader IGA offering. Discovery connects to cloud providers, SaaS applications, and on-premises directories. The platform’s NHI capabilities sit inside the same governance engine that manages human identity lifecycle, which is an advantage for teams that want a single access review and certification process for both human and machine identities.
Permission analysis covers role assignments and effective access, with particular depth on enterprise application integrations given Saviynt’s IGA history. For organizations that already run Saviynt for human identity governance, adding NHI coverage within the same platform avoids a separate tool, separate integrations, and a separate review workflow. For teams without an existing Saviynt deployment, the platform’s complexity and enterprise pricing are more appropriate for larger environments. Pricing is not publicly disclosed.
11. CyberArk
CyberArk’s (now Idira) NHI coverage comes through its Secrets Manager and Conjur products alongside newer machine identity capabilities in its identity security platform. Discovery in the secrets context covers vaulted credentials, pipeline secrets, and application credentials enrolled in Conjur or Secrets Manager. The platform has deep integration with CI/CD tooling including Jenkins, GitLab, and GitHub Actions for secrets injection at build time.
CyberArk’s permission analysis is strongest for credentials it manages directly. The platform is less focused on discovering credentials that were never enrolled than on securing the ones that are brought into its management perimeter. For organizations with mature PAM deployments and an enrollment-first strategy, CyberArk extends naturally into machine identities. For teams whose primary problem is shadow NHI discovery, a dedicated discovery-first platform complements the vault rather than replacing it. Pricing is not publicly disclosed; CyberArk sells through enterprise agreements.
12. GitGuardian
GitGuardian approaches NHI security from the secrets-detection angle: the platform scans Git repositories, CI/CD pipelines, code hosting services, and internal developer tools for exposed secrets including API keys, tokens, certificates, and credentials embedded in code. Discovery is the primary function, and it operates across public and private repositories with both pre-commit hooks and continuous monitoring of the full commit history.
Permission analysis is deliberately not part of GitGuardian’s scope: it finds the secret and tells you where it is, what service it belongs to, and whether it appears to be active. What the secret can actually do in the cloud or SaaS environment is left to the team or to a complementary platform. For teams whose primary NHI risk is secrets in source code, GitGuardian addresses that specific vector with more depth than a generalist NHI platform. GitGuardian publishes pricing for its self-hosted and SaaS offerings on its pricing page; enterprise tiers are quoted.
13. P0 Security
P0 Security focuses on just-in-time cloud access with a developer-workflow orientation. Discovery covers cloud IAM roles, service accounts, and the permissions requested through the platform’s access request system. The JIT model means that standing permissions for human and non-human identities are replaced with time-bound grants that expire automatically.
For NHI specifically, P0 targets the CI/CD and developer tooling surface: pipeline jobs, cloud shell sessions, and infrastructure-as-code runs that currently hold standing cloud permissions. Permission analysis covers the effective cloud permissions attached to each identity and what would be granted versus what is minimum-necessary. The platform’s integration with Slack and GitHub for access requests makes it practical for engineering teams that are allergic to heavyweight IAM consoles. Pricing is not publicly disclosed.
14. Akeyless
Akeyless is a secrets management platform with a cloud-native, SaaS-delivered architecture and a particular focus on DevOps and CI/CD environments. Discovery covers secrets stored in the Akeyless vault and integrations with external secret sources. The platform’s Dynamic Secrets feature generates short-lived, just-in-time credentials for databases, cloud providers, and SaaS services rather than storing long-lived secrets that can be stolen.
Permission analysis covers the access policies governing which workloads or identities can request which secrets, with audit logging of all access events. Akeyless publishes a pricing page at akeyless.io/pricing with community, business, and enterprise tiers; specific rates for enterprise are quoted. For teams that want a vault-first architecture with JIT credential generation, Akeyless covers that pattern with a modern deployment model that does not require self-hosted infrastructure.
How Do These Platforms Actually Discover Identities Nobody Registered?
Discovery methodology is the most important differentiator among these platforms, and the differences are architectural, not cosmetic. Three distinct approaches exist in this market.
Control-plane enumeration is used by platforms like Astrix, Oasis, Veza, and Token Security. These platforms authenticate to cloud and SaaS APIs using read-only credentials and pull the complete list of identities, roles, and permissions from the provider’s own data. They find identities that were never registered in a vault because they query the authoritative source of truth for each system, not the vault. An OAuth token that a developer created through a SaaS admin console appears here because the SaaS platform’s API exposes it, regardless of whether the vault knows it exists.
Secrets intelligence scanning is used by platforms like GitGuardian, Entro, and partially Clutch. These platforms scan code repositories, CI/CD configurations, container images, and sometimes runtime environments for credential material. They find identities that were embedded in source code, passed through environment variables, or baked into build artifacts. This approach catches a different population of NHIs than control-plane enumeration: the credentials that live outside any IAM system entirely.
Runtime behavioral analysis is used by platforms like Token Security, Aembit, and Britive. These platforms observe actual API calls, network connections between services, and authentication events to map what identities exist and what they are actually doing. This approach catches identities that are active in the environment even when neither the IAM records nor the code repositories expose them clearly.
Most organizations need at least two of these three approaches to achieve meaningful coverage. A control-plane scan finds the IAM surface. A secrets scan finds the code and pipeline surface. Runtime analysis finds the behavioral surface. A single platform that covers all three with depth is not yet the common case; most of the platforms above lead with one approach and supplement with another.
What Is the Right Platform for Each Environment?
The right tool depends on where your NHI population actually lives, not on a feature checklist. Consider a company running three AWS accounts, two GCP projects, Google Workspace, Salesforce, and a Slack instance, with a 12-person engineering team that deploys via GitHub Actions. Their primary NHI risks are: OAuth tokens minted by the product and engineering teams for SaaS integrations, GitHub Actions secrets that never made it into a vault, and AWS IAM roles created during infrastructure experiments that were never cleaned up. For that environment, an API-graph platform like Oasis addresses the SaaS surface (noting that Oasis has been acquired by Cyera , verify current availability), and a secrets-intelligence platform like GitGuardian covers the pipeline surface. Token Security or a similar cloud-behavioral platform closes the IAM audit gap.
Contrast that with a financial services organization running on-premises Active Directory federated with Azure Entra, with 400 service accounts, a mature CyberArk deployment, and a team that has already enrolled the known service accounts into the vault. Their gap is not secrets in code; it is privilege drift in enrolled service accounts and unknown service accounts that were created outside the normal provisioning process. Saviynt or Veza fits that pattern better than a secrets-detection platform.
| Platform | Primary Discovery Method | Permission Analysis Depth | SaaS-to-SaaS Coverage | Cloud IAM Coverage | Pricing Model |
|---|---|---|---|---|---|
| Astrix Security | API graph / control plane | Effective scope vs. used scope | Strong (core focus) | Moderate | Not public; now part of Cisco , standalone licensing ended June 30, 2026 |
| Entro Security | Vault integration + code scan | Cloud effective permissions per secret | Moderate | Strong | Not public |
| Oasis Security | IdP and cloud API enumeration | Nested group resolution, usage analytics | Moderate | Strong | Not public; acquired by Cyera , verify availability |
| Token Security | Control plane + audit log behavioral | Unused permissions via log join | Moderate | Strong | Not public |
| Natoma | Cloud IAM + SaaS OAuth + CI/CD | Effective cloud permissions + ownership | Moderate | Strong | Not public |
| Clutch Security | API graph + repo scan | Secrets sprawl location tracking | Moderate | Moderate | Not public |
| Britive | Cloud IAM + SaaS API | JIT grants; standing privilege eliminated | Strong | Strong | Not public |
| Aembit | Service mesh + network inspection | Workload-to-workload call analysis | Limited | Strong (microservices) | Not public |
| Veza | Multi-system access graph | Resource-level effective access | Strong | Strong | Not public; enterprise quoted |
| Saviynt | IGA connectors | Role and effective access | Strong (IGA breadth) | Strong | Not public; enterprise quoted |
| CyberArk | Vault enrollment + pipeline integration | Deep for enrolled credentials | Moderate | Strong | Not public; enterprise agreements |
| GitGuardian | Repository and pipeline scanning | Secret presence and validity; no IAM join | Limited | Limited | Published tiers; enterprise quoted |
| Akeyless | Vault + dynamic secrets generation | Access policy and audit log | Moderate | Strong | Published tiers; enterprise quoted |
| P0 Security | Cloud IAM + access request system | JIT grants; minimum-necessary analysis | Limited | Strong | Not public |
How Does NHI Platform Pricing Actually Scale With Identity Count?
Almost every platform in this market declines to publish list pricing. That is the accurate answer, and it matters operationally: you cannot budget for a tool when you do not know your own NHI count, and you do not know your count until you have done some form of discovery. This creates a purchasing loop that favors vendors who offer a free discovery tier or a proof-of-concept engagement.
Several pricing models appear in this market based on conversations with practitioners and the limited public disclosures that exist. The most common is per-identity or per-managed-identity, where the unit is the number of service accounts, tokens, or secrets under management. This model creates a tension: the platform’s value is discovering identities you did not know about, but discovering more identities increases your bill. Teams negotiating these contracts should ask for all-inclusive discovery with governance-tier pricing based on the subset actively managed.
A second model is per-integration or per-connector, where pricing scales with the number of cloud accounts, SaaS applications, or identity providers connected. This model is more predictable for large environments with bounded integration counts but penalizes teams with wide SaaS sprawl. A third model is flat-rate enterprise commitment, common among platforms like Veza and Saviynt that sell into large organizations with complex procurement requirements. GitGuardian and Akeyless are the exceptions in this list: both publish tiered pricing on their public sites, making them easier to budget without a sales conversation.
The operational cost the pricing pages never show: the engineering hours required to onboard integrations, investigate findings, and drive remediation workflows. A platform that generates 5,000 unranked findings with no owner assigned to each identity is not cheaper to operate than one with 1,000 prioritized findings attached to named owners, regardless of licensing cost.
Are AI Agents Non-Human Identities, and Do These Platforms Cover Them?
AI agents authenticate, hold API keys, call external services, and accumulate permissions exactly like any other non-human identity. The technical profile is nearly identical to a CI/CD pipeline credential: it is a programmatic identity with scoped access that needs to be discovered, governed, and rotated. The difference is behavioral: agents make decisions autonomously, their call patterns are less predictable than a batch job, and their permission scope tends to expand as the agent’s capabilities grow.
None of the platforms in this list were built with agentic AI as a primary use case, but several are adapting. The NHI governance layer matters for agents because the same governance gaps apply: an agent identity created to test a prototype may end up with production database access that was never revoked. The platform capabilities that matter most for agent identities are runtime behavioral baselining (what does normal API call volume look like for this identity?) and tight permission scoping (does this agent actually need write access, or did the developer grant it for convenience?).
For teams governing AI agent identities alongside conventional NHIs, the coverage question is worth asking specifically in vendor evaluations. The broader AI agent identity governance space is developing alongside the NHI market; SecurityOpsWire’s coverage of AI agent security platforms and AI agent discovery and monitoring tools addresses the emerging tooling in that adjacent space.
Which Platforms Cover SaaS-to-SaaS Integrations, and Why Does That Gap Matter?
SaaS-to-SaaS integrations are the fastest-growing segment of the NHI problem because they are invisible to cloud IAM. When Salesforce connects to DocuSign through an OAuth integration, neither AWS nor Azure sees that credential. It does not appear in CloudTrail or in any cloud IAM audit log. The only way to find it is to query the Salesforce or DocuSign API directly.
Platforms with strong SaaS-to-SaaS coverage are Britive, Saviynt, and Veza. Astrix Security historically led in this area as a purpose-built SaaS integration graph platform, but as noted above, Astrix ended standalone sales in June 2026 and is being absorbed into Cisco. Teams with SaaS-to-SaaS coverage as a primary requirement should verify current availability of Astrix capabilities directly with Cisco, and evaluate the remaining independent platforms accordingly. Platforms that lead with cloud IAM coverage, like Token Security or P0 Security, have limited visibility into the SaaS OAuth surface by design.
The practical implication: a team that secures its AWS IAM thoroughly but does not inventory its SaaS OAuth grants has a large, ungoverned NHI population that a cloud-focused platform will never find. The MCP security tooling space is also developing patterns for governing service-to-service connections in AI workloads, which overlaps with the SaaS-to-SaaS NHI problem at the integration layer.
What Should a Security Team Evaluate Before Selecting an NHI Platform?
Five questions cut through the demo noise.
- Where does your NHI population actually live? Cloud IAM, SaaS OAuth, CI/CD secrets, code repositories, and service mesh credentials each require different discovery methods. A platform that is strong at cloud IAM may be blind to half your actual surface.
- Does the platform join its discovery findings with permission data from the authoritative source, or does it just list what it found? Finding a service account is table stakes. Computing what that account can actually access across nested groups, cross-account roles, and SaaS grants is where the platforms diverge sharply.
- Can it assign an owner to each identity it finds, and does that ownership feed an automated review workflow? An unowned finding is an unsent ticket. Ownership mapping and review automation are what determine whether discovery translates into remediation.
- How does pricing scale with discovered identity count, and does the vendor offer a free discovery tier before you commit? The answer to this question reveals whether the vendor’s incentives align with yours.
- What does remediation actually look like? Does the platform generate a report, open a ticket, automate rotation, or sit in the path of authentication to enforce policy? The further right on that spectrum the platform sits, the more engineering integration it requires and the more operational value it delivers.
Teams building AI-powered workflows should also ask whether the platform can baseline the normal call behavior of a workload identity and alert on deviation, since agentic identities generate call patterns that look anomalous by conventional standards. For context on how identity governance intersects with AI security program design, SecurityOpsWire’s analysis of AI-SPM versus AI agent security covers where those disciplines overlap and where they diverge.
Frequently Asked Questions
What does an NHI platform do that a secrets vault does not?
A secrets vault manages credentials that were deliberately stored in it. An NHI platform discovers credentials that were never stored anywhere, including OAuth tokens minted through SaaS admin consoles, service accounts created outside normal provisioning, and API keys embedded in code. It then maps the effective permissions each identity holds across cloud and SaaS systems, assigns human ownership, and tracks usage to identify identities that are stale or over-permissioned. Vaults secure what they know about. NHI platforms find what the vault never learned about.
How do NHI platforms discover service accounts that were never registered anywhere?
The primary method is control-plane enumeration: the platform authenticates to cloud IAM APIs, SaaS provider APIs, and identity provider APIs using read-only credentials and pulls the complete list of every identity the system knows about, whether or not it was registered in a vault or governed through a formal provisioning process. A secondary method is secrets scanning of code repositories and CI/CD pipelines, which finds credentials that exist in artifacts rather than in any IAM system. These two approaches cover most of the unregistered NHI population.
What is the difference between NHI management and machine identity security?
Machine identity security is a broader category that includes TLS certificates, code-signing keys, and SSH keys used to authenticate machines to each other. NHI management focuses specifically on programmatic access credentials: service accounts, API keys, OAuth tokens, and workload identities used by software to call APIs and access resources. There is significant overlap, but platforms marketed as machine identity security often have stronger certificate lifecycle management, while NHI platforms tend to have deeper coverage of SaaS OAuth and cloud IAM identities.
Are AI agents considered non-human identities for governance purposes?
Technically yes. An AI agent that authenticates to external services holds a credential, accumulates permissions, and creates audit events like any other service account. The governance requirement is the same: discover the identity, map its permissions, assign a human owner, and rotate credentials on a defined schedule. The operational difference is that agent call patterns are less predictable than batch jobs, which makes behavioral baselining more important and permission scoping more difficult to get right initially.
How does pricing scale with NHI identity count?
Most NHI platforms price on a per-identity or per-managed-identity basis, with enterprise quotes rather than published rates. A smaller number price per integration or connector. GitGuardian and Akeyless are the exceptions with publicly published tiers. Because discovery typically reveals far more NHIs than a team expected, identity-count pricing can scale unpredictably. Negotiate for all-inclusive discovery with governance pricing based on the actively managed subset, and ask for a free discovery pass before committing to a contract size.
Do NHI platforms cover on-premises service accounts as well as cloud and SaaS?
Coverage varies by platform. Oasis and Saviynt have strong on-premises Active Directory coverage as part of their IGA heritage, though Oasis has been acquired by Cyera , verify current product availability directly. CyberArk covers on-premises environments through its vault and PAM integrations. Platforms built primarily for cloud-native environments, like Token Security or P0 Security, have limited on-premises visibility by design. If on-premises service accounts are a material part of your NHI population, verify connector support explicitly before evaluating any platform.
What is service identity governance?
Service identity governance is the practice of applying the same access review, certification, and lifecycle management controls to non-human identities that identity governance platforms apply to human user accounts. This includes: periodic access reviews where a human owner attests that a service account’s permissions are still appropriate, automated deprovisioning or disabling of accounts that fail attestation or show no recent activity, and change-detection alerts when a service identity’s permissions expand outside of its baseline. Most IGA platforms have added service identity governance as an extension of their existing human identity workflows.
How to Read These Findings Without Buying the Wrong Thing
The most common mistake in NHI platform evaluations is starting with a feature checklist instead of a population estimate. Teams that begin by asking “which platform has the most integrations” end up buying a tool sized for an identity population they never actually counted. The right sequence is: run the discovery pass first, size the actual NHI population by environment type, identify which discovery approach your environment most needs, and then evaluate platforms against that specific requirement.
Platform consolidation is a real consideration here. If your organization already runs CyberArk for human PAM, extending into NHI within that platform avoids a second governance console and a second integration set, even if the NHI coverage is narrower than a dedicated discovery platform. If you are starting from scratch or your primary risk is SaaS OAuth and pipeline secrets rather than vaulted credentials, a purpose-built NHI platform likely delivers faster time-to-coverage. Neither answer is universal.
The market is moving fast enough that acquisition status and product scope can change between the time you read this and the time you sign a contract. The Astrix acquisition into Cisco , with standalone licensing already ended as of June 2026 , and the Oasis acquisition by Cyera are both examples of how quickly the ownership and roadmap picture shifts in this segment. Verify current product scope directly with each vendor during evaluation, and weight recent customer references over documentation that may not reflect the current product. The AI agent and NHI security market is consolidating; what is a standalone platform today may be a module inside a larger platform within a year.
