Non-Human Identity (NHI) Security

What a non-human identity actually is

A non-human identity is any principal or credential that authenticates without a person behind it at the moment of use. That is a wide tent, and deliberately so. In a typical cloud and SaaS estate, NHIs include:

• Cloud IAM principals: IAM roles, service accounts, managed identities, and the long-lived access keys attached to them.
• Secrets and keys: API keys, database credentials, HMAC signing keys, and provider access keys.
• OAuth tokens and grants: refresh tokens, personal access tokens, and the SaaS-to-SaaS grants that let one app act inside another.
• Certificates: TLS server and client certs, and code- or artifact-signing keys.
• Workload identities: the identity a pod, function, or CI job assumes at runtime.
• AI agents: an emerging class that calls tools and takes actions on a schedule or on demand.

The common thread is that a machine, script, pipeline, or model is using the credential, so the usual human guardrails - a login prompt, MFA, a manager who offboards you, an annual access review - either do not apply or are quietly skipped. That gap is the entire subject of this page.

Why NHI exploded

NHIs are not new. What changed is the sheer count and the rate of creation. Four forces stacked on top of each other:

• Cloud. Every autoscaling group, Lambda, container, and managed service assumes an identity. Infrastructure that used to be one server with one login is now hundreds of ephemeral workloads, each with a role.
• SaaS. Modern business runs on dozens of SaaS apps wired together with OAuth grants and API keys. Every "Connect your Google account" or "Add to Slack" button mints an NHI, often with broad scopes, often approved by an end user with no security review. See SaaS security for the integration-sprawl angle.
• CI/CD. Pipelines deploy to production, so they hold credentials to production. A single GitHub Actions workflow or CI/CD runner can carry keys to multiple clouds, registries, and secret stores.
• AI agents. The newest force. Agents need credentials to act, and they are proliferating faster than any governance process was designed to handle.

The practical result is that in most environments NHIs outnumber human identities many times over, and unlike employees, they are created constantly and deprovisioned almost never.

The core problems: sprawl, ownership, over-permissioning, secrets

NHI risk is not one problem. It is five that reinforce each other.

Sprawl

You cannot secure what you cannot count, and almost no one can count their NHIs. They are created by developers, automation, and self-service SaaS connections, spread across clouds and hundreds of apps, with no central registry.

No ownership

A service account created for a migration three years ago is still there, still privileged, and the person who made it has left. When no human owns an identity, no one rotates its secret, questions its permissions, or deletes it. Ownership is the single most under-appreciated NHI control.

Over-permissioning

NHIs are routinely granted far more than they use, because scoping is hard and broad grants "just work." Wildcard IAM policies and admin-equivalent service accounts are common. This is the same least-privilege problem covered in IAM, amplified because there is no human to notice the excess.

Long-lived secrets

Static keys that never expire are the defining NHI risk. A key committed to a repo, baked into an image, or pasted into a config file can sit valid for years. When it leaks, there is no MFA and no session timeout to save you. Secret handling is covered further in data security.

No lifecycle

Human identities have a lifecycle: joiner, mover, leaver. NHIs usually have only "created." No rotation cadence, no re-certification, no offboarding. The fix for every problem above starts with giving NHIs a real lifecycle.

What NHI failure looks like in real breaches

These are not hypotheticals. Several of the most instructive cloud breaches are, at their core, NHI failures.

• Stolen static credentials with no MFA. In the Snowflake / UNC5537 campaign, attackers used valid credentials for accounts that lacked MFA to log straight into customer data warehouses. Machine and service logins that never got an MFA or federation layer were exactly the exposure.
• Infostealer-harvested credentials. In the Uber breach, an attacker who got initial access found hardcoded admin credentials for a privileged access tool, then pivoted. Secrets sitting in scripts and shares are NHI credentials waiting to be reused.
• An over-permissive long-lived token. In the Microsoft SAS token leak, an Azure Shared Access Signature token that was scoped far too broadly and set to a very long expiry exposed 38TB of internal data, including secrets and private keys. It is a textbook NHI story: a long-lived, over-permissioned, unmonitored token.

The pattern repeats: a credential that outlived its purpose, was scoped too broadly, or was never protected by a second factor. Browse the full breach timeline and you will see identity, human and non-human, at the root of most of it.

Discovery and inventory

Every NHI program starts with an inventory, and the good news is you can build a useful first pass from native APIs before buying anything. Work source by source:

• Each cloud. Enumerate IAM users, roles, and service accounts, their attached policies, and crucially their last-used timestamps. In AWS use IAM credential reports and Access Analyzer; in GCP enumerate service accounts and keys; in Azure inventory app registrations, service principals, and managed identities.
• SaaS. Pull the OAuth grants and connected/third-party apps from your major platforms (identity provider, email and docs suite, code host, chat). These are the SaaS-to-SaaS NHIs and are usually the least governed.
• Source control and pipelines. Scan repos and CI config for committed keys and tokens; enumerate deploy keys and pipeline secrets. See version control and CI/CD.
• Secret stores. Read the inventory out of your secrets manager so you know what is intended to exist.

Then correlate. The two highest-value derived attributes are last used (dormant credentials are cleanup candidates and stealthy risk) and owner (map each NHI to a human or team). Anything you cannot attribute an owner to goes on a remediation list. Dedicated NHI tools exist largely because this correlation across clouds and SaaS is tedious to do by hand and needs to stay current, but do not let tooling gate the first inventory.

Where CIEM, secrets management, and ITDR fit

NHI security overlaps three adjacent categories, and it helps to be precise about the boundaries.

CIEM answers "is this over-permissioned?"

Cloud Infrastructure Entitlement Management analyzes effective permissions and right-sizes them toward least privilege. It is the entitlement lens on your NHIs and is usually delivered as part of a CNAPP. NHI security uses CIEM findings but adds the questions CIEM does not: who owns this identity, is its secret rotated, and should it exist at all. See CSPM vs CNAPP.

Secrets management answers "where does the secret live and how does it rotate?"

A secrets manager stores credentials securely, brokers access to them, and can rotate them. It is essential plumbing, but a secrets manager full of long-lived keys is still a pile of long-lived keys. NHI security asks whether that secret needs to exist at all, which is where secretless approaches come in below.

ITDR answers "is this identity being abused right now?"

Identity Threat Detection and Response watches identity behavior for signs of compromise: impossible travel, anomalous API usage, a dormant service account suddenly active. For NHIs this is where detection lives, and it is covered more in the detection section.

None of these replaces the others. A mature program uses CIEM to right-size, a secrets manager (or federation) to handle credentials, and ITDR to catch abuse, all sitting on top of a current NHI inventory.

Workload identity federation and secretless access

If long-lived static secrets are the root NHI risk, the strongest fix is to stop having them. That is the idea behind secretless access: a workload proves its identity with a short-lived, verifiable token and exchanges it for access, so there is no standing key to leak.

OIDC-based workload identity federation

The most widely deployed pattern uses OpenID Connect. A workload gets a short-lived OIDC identity token from a trusted issuer, and the cloud is configured to trust that issuer for specific subjects. Common examples:

• GitHub Actions assuming an AWS role via OIDC instead of storing an AWS_ACCESS_KEY_ID in the repo.
• GKE Workload Identity, EKS Pod Identity, and Azure Workload Identity, which let Kubernetes pods assume cloud identities without mounting static keys.

A conceptual GitHub-to-AWS trust looks like this: the workflow requests an OIDC token, and AWS STS exchanges it for temporary role credentials.

SPIFFE and SPIRE

For workload-to-workload trust that is not tied to a single cloud, SPIFFE (Secure Production Identity Framework For Everyone) defines a standard identity format, the SPIFFE ID, and short-lived SVID credentials, and SPIRE is its reference implementation that attests workloads and issues those identities. The concept is the same as OIDC federation - a strongly attested, short-lived identity instead of a shared secret - applied uniformly across a fleet. It pairs naturally with service mesh mTLS and with zero trust, where every workload connection is authenticated rather than assumed-safe by network location.

Brokered access

A third pattern puts a broker in the middle: the workload authenticates to a broker with its attested identity, and the broker mints just-in-time, short-lived credentials to the target. This is the model some NHI vendors lead with, and it extends secretless access to targets that do not natively speak OIDC.

The point is not any single technology. It is a direction: move NHIs from long-lived shared secrets toward short-lived, attested, verifiable identities.

The AI-agent wrinkle

AI agents are the fastest-growing new class of NHI, and they break several assumptions at once. An agent that reads tickets, queries a database, and files a change needs credentials to do all three, so it is an NHI - but an unusual one:

• It acts at machine speed. An agent can make thousands of API calls in the time a human makes one, so a mistake or a compromise scales fast.
• Its behavior is non-deterministic. Prompt injection and tool-poisoning can steer an agent into actions its author never intended. If the agent holds broad credentials, that manipulation inherits broad access.
• It is granted broad access to be "helpful." The path of least resistance is to hand an agent wide permissions and a shared key, which is exactly the over-permissioning and long-lived-secret pattern you are trying to eliminate.

The governance answer is to treat every agent, and ideally every tool connection an agent uses, as a first-class NHI: its own scoped, short-lived credential (via federation or a broker, not a shared static key), a named human or team owner, least-privilege scopes per tool, and monitoring on its actions. Do not let an agent silently inherit a human's session or reuse one over-privileged service account. The AI and ML security guide goes deeper on prompt injection and agent-specific threats, and the Promptware case is worth reading for how agent manipulation plays out.

Detecting NHI abuse

Prevention reduces the surface; detection catches what slips through. NHIs are actually easier to baseline than humans because their behavior is narrow and repetitive - a pipeline calls the same handful of APIs from the same places every day. Deviations stand out. High-value signals for a cloud SOC and detection engineering team:

• A dormant NHI suddenly active. A service account or key unused for weeks that starts making calls is a classic sign of stolen-credential reuse.
• Credential used from a new location or ASN. A CI key that only ever authenticates from your runners' egress IPs, seen from a residential or hosting-provider IP, is a strong indicator.
• New or anomalous actions. A read-only reporting identity that suddenly calls iam:* or exfiltration-shaped APIs.
• Impossible velocity or volume. Especially for AI agents, a spike far beyond the learned baseline.
• OAuth grant anomalies. A new high-scope third-party grant, or an existing grant used in a new way.

This is the NHI-flavored view of ITDR, and it feeds directly into incident response. Two things make NHI detection actionable: rich last-used and source telemetry (so you can baseline), and the ownership mapping from your inventory (so an alert has someone to route to). Without an owner, even a perfect detection produces an alert no one can action.

A practical maturity path

You do not fix NHI in one quarter. A workable progression:

1. Inventory. Build the cross-cloud and SaaS NHI inventory from native APIs. Capture last-used for every credential. This alone surfaces the worst dormant and unowned identities.
2. Assign ownership. Map every NHI to a human or team. Anything unattributable becomes a remediation candidate. Ownership is what makes every later step possible.
3. Kill the obvious risk. Delete dormant identities, remove committed and embedded secrets, and revoke unused OAuth grants. This is the fastest blast-radius reduction available.
4. Right-size permissions. Use CIEM and last-used data to trim over-privileged NHIs toward least privilege.
5. Rotate and manage secrets. Put remaining static secrets behind a secrets manager with automated rotation, so nothing is long-lived by default.
6. Go secretless where it matters. Replace the highest-value keys with OIDC federation or a broker. Make secretless the default for new workloads and pipelines.
7. Continuous detection and lifecycle. Stand up ITDR-style monitoring, and give NHIs a real lifecycle: creation standards, periodic re-certification, and deprovisioning.

Most organizations are stuck between steps one and two. If you do nothing else this quarter, get the inventory and assign owners; every other control gets easier once you can name who is responsible for each identity.

The NHI tooling market

A dedicated NHI-security category has emerged, and it is consolidating quickly. The category is listed in the vendor landscape; treat this as a map of approaches, not a ranking, and evaluate against your own environment.

• Discovery and governance for SaaS and OAuth. Vendors such as Astrix and Entro lead with inventory and governance of SaaS-to-SaaS grants, API keys, and third-party integrations.
• Broad enterprise lifecycle. Oasis and Token Security emphasize wide coverage across cloud, SaaS, and on-prem plus NHI lifecycle and certification workflows.
• Secretless brokering. Aembit and Clutch (and offerings from broader IAM vendors) focus on replacing static credentials with policy-based, short-lived access rather than governing existing keys.
• Newer entrants. Natoma and others are extending these ideas, increasingly toward AI-agent identity.

The market is actively consolidating - as of mid-2026 there have been reports of larger security and networking vendors moving to acquire NHI startups - so validate a vendor's independence and roadmap during evaluation. And the usual caveat applies: no single tool is "the best." The CNAPP platforms increasingly fold NHI features in alongside CIEM (disclosure: the site's author works at Wiz), while the specialists go deeper on SaaS and OAuth. Match the tool to where your NHI risk actually concentrates, which your inventory will tell you.