NHI Security vs. Secrets Managers vs. CNAPP
Where Each Layer's Job Actually Ends
Security teams evaluating a dedicated NHI platform are usually working through some version of the same question from the other direction: we already have a secrets manager and a CNAPP — doesn't that cover this? This guide breaks down what each of these three categories is actually built to do, where each one's visibility stops, and how to tell whether the gap between them is large enough to justify a fourth platform.
- Once a credential is checked out of your secrets manager, can anything tell you what it does next — or only that it was checked out?
- Does your CNAPP's secrets scanning extend to SaaS-to-SaaS integrations and OAuth grants, or only to cloud infrastructure and code repositories?
- If a service account or API token started behaving differently tomorrow — a new destination, a different data volume, an unusual time of day — would anything notice, and would anyone be told?
If the honest answer to any of these is "we're not sure," that uncertainty is the gap this category of tooling exists to close.
What each category is actually built to do
Secrets managers — HashiCorp Vault, AWS Secrets Manager, Azure Key Vault — are built around a single job: centralize, encrypt, and control access to static credentials. Passwords, API keys, certificates, and connection strings live in an encrypted store instead of hardcoded in source or config files, and every retrieval is logged. For the specific problem of credential sprawl in code, this is genuinely effective, and worth having regardless of what else is in the stack.
CNAPPs — Wiz, Orca Security, Prisma Cloud — are built around a different job: scanning cloud environments for structural risk. Misconfigured storage, exposed network paths, unpatched container images, overly permissive IAM roles, and increasingly, secrets that were accidentally committed to a repository or left in plaintext in a config file. The focal point is the asset — whether a piece of infrastructure is configured correctly and free of known vulnerabilities.
NHI security platforms — Oasis Security, Entro, Aembit, and others in this category — start from a different focal point again: the identity. Rather than the credential string or the infrastructure it sits in, they track the actual digital entity — an API key, OAuth token, service account, or autonomous AI agent — across however many systems it touches, and ask what that entity is doing on an ongoing basis, not just where it's stored or whether the host it runs on is patched.
The boundary matrix
The differences are easiest to see side by side. The table below maps the same set of questions across all three categories.
| Question | Secrets Managers | CNAPP | NHI Platforms |
|---|---|---|---|
| Primary focal point | The secret — the credential string itself. | The asset — the cloud resource, container, or repository it lives in. | The identity — the entity using the credential, and what it does with it. |
| Visibility scope | Only credentials explicitly stored in the vault. | Cloud infrastructure, container images, and CI/CD repositories. | Designed to span multi-cloud, on-prem, and SaaS-to-SaaS integrations — actual coverage depends on how many connectors a given vendor has built. |
| Core question answered | Is this credential encrypted at rest, and was its retrieval logged? | Does this environment have a known misconfiguration, vulnerability, or exposed secret? | What system owns this credential, what is it talking to right now, and does that match its normal pattern? |
| Shadow or unmanaged credentials | Not visible — a vault only sees what was deliberately stored in it. | Partially visible — can flag secrets exposed in code or storage, but not ones that were never written down anywhere scannable. | The core purpose of the category — built to surface tokens that exist outside any vault, including ones security teams don't know about. Discovery completeness still varies by vendor and by SaaS coverage; worth testing against your own environment. |
| Runtime behavior monitoring | Logs when a secret was retrieved, not what happened after. | Point-in-time posture snapshot — not built to track a credential's behavior after issuance. | Continuous behavioral monitoring — flagging changes in volume, destination, or timing for a given identity — is the category's core differentiator, though detection maturity varies meaningfully between vendors. |
| AI agent governance | Can store the API keys an agent authenticates with. | Can flag if an AI workload's underlying infrastructure violates baseline cloud-posture rules. | Built to catalog autonomous agents as identities in their own right — mapping delegated permissions and monitoring agent-specific behavior. |
What a secrets manager can't see
A secrets manager's job ends at the point of retrieval. Once an application queries the vault, pulls a credential into memory, and starts using it, the vault has no further visibility. It cannot tell whether that credential has since been copied out of memory by malware, whether it carries more access than the task in front of it requires, or whether the person who originally requested it left the company a year ago.
It is also entirely dependent on developers and integrations actually using it. Credentials issued automatically by a SaaS platform — an OAuth grant between two connected apps, a webhook token, an API key generated by a third-party integration — typically never touch the vault at all, because nothing in that workflow was built to put them there.
A secrets manager answers "was this credential stored and retrieved securely?" It doesn't answer "what is this credential doing right now, and is that normal?"
What a CNAPP doesn't reach
A CNAPP is built to find structural flaws — an open storage bucket, a vulnerable container image, an IAM role with far more permissions than it needs. Most have added secrets scanning that flags credentials accidentally committed to a repository or left in plaintext in a config file, which overlaps somewhat with the shadow-credential problem above.
But a CNAPP evaluates infrastructure, not identity relationships. If an attacker obtains a perfectly valid, correctly-scoped OAuth token belonging to a legitimate integration, nothing about the infrastructure is wrong — the bucket is still configured correctly, the container is still patched, the IAM role still matches policy. The credential has been hijacked, but the posture scan has nothing to flag. CNAPPs are also largely scoped to cloud-native footprints and CI/CD; they generally don't reach interactions happening entirely within SaaS-to-SaaS integrations, such as a Salesforce connector talking to Slack through a webhook neither tool's cloud account is aware of.
A CNAPP answers "does this environment have a structural flaw an attacker could exploit?" It doesn't answer "is this valid credential currently being used by someone other than its owner?"
A documented example: the 2023 Okta support-system breach
In October 2023, Okta disclosed that attackers had used a compromised service account — itself a non-human identity — to access its customer support case management system. Inside that system were HAR files that several customers had uploaded for troubleshooting, and those files contained live session tokens. The attackers extracted those tokens and used them to access admin sessions directly in at least five customer environments, including BeyondTrust, Cloudflare, and 1Password; Okta later said files belonging to roughly 134 customers had been accessed during the incident, though follow-on activity was concentrated on a small number of targets.
Neither of the boundaries described above would have caught this. The compromised tokens weren't sitting in anyone's secrets manager — they were live session artifacts generated by ordinary authenticated activity and embedded in a debugging file. Nothing about the affected customers' cloud infrastructure was misconfigured from a CNAPP's perspective; the access used valid sessions through a SaaS support portal, not an exposed resource or unpatched vulnerability. What did work, by BeyondTrust's own account, was identity-centric behavioral detection — an API call from a session that didn't match that account's normal pattern, flagged within roughly thirty minutes.
That "is this behavior normal for this identity, right now" question is exactly the one secrets management and CNAPP aren't built to answer, and it's the capability NHI platforms are built around.
Where each layer's job ends
Eliminate hardcoded credentials, centralize storage, and log who retrieved what and when. The job ends at the point of retrieval — what the credential does afterward is outside the vault's scope by design.
Maintain infrastructure posture: patching, configuration, exposed resources, and secrets left in places they shouldn't be. The job ends at the infrastructure boundary — a valid credential being used by the wrong party doesn't register as a posture problem.
Sit across both, plus SaaS: discover non-human identities regardless of where they were issued, map what each one is connected to and who owns it, and monitor ongoing behavior for drift. This is the layer built to answer whether an identity is doing what it's supposed to be doing, right now.
None of these layers substitutes for another, and none of them is optional. The practical question for a team that already has a secrets manager and a CNAPP isn't whether to replace either one — it's whether anything in the current stack is actually answering the third layer's question. For most organizations with any meaningful number of service accounts, OAuth grants, and SaaS integrations, the honest answer is no. That's the gap this category exists to close.
Related: the OWASP agentic AI identity controls guide goes deeper on autonomous agent governance specifically. The audit and compliance mapping guide covers how NHI lifecycle controls map to SOC 2, NIST, PCI DSS, ISO 27001, and other frameworks. The landscape section covers how the NHI vendor market itself is segmented.