Identity ≠ Credential: the model behind NHI security

Secret scanners find strings. Identity governance tools list accounts. Cloud posture tools evaluate policies. Each is useful, and each quietly assumes that the thing it finds is the identity. It is not.

A small vocabulary

• An identity is a principal that can be authenticated and authorized: a service account, a workload identity, an OAuth application, a CI/CD job identity, an AI agent.
• A credential is something an identity presents to prove it is that identity: an API key, a token, a certificate, a key pair, a cloud access key.
• An owner is the human or team accountable for the identity’s existence and behaviour.
• A service is what the identity authenticates to.
• A resource is what the service lets the identity reach.
• An action is what the identity actually does to the resource.

The useful model is a graph, not a list:

Owner → Identity → Credential → Service → Resource → Action

One identity may hold many credentials. One credential may be copied into many places. One identity may reach many resources through many services. The security questions that matter — who is responsible, what is the blast radius, what should we revoke — live on the edges of this graph, not in any single node.

Why the distinction changes the answer

Consider a single leaked string in a repository.

• A scanner’s answer: rotate it.
• The graph’s answer: this credential belongs to svc-billing-export, whose owner left four months ago, which authenticates to a production cloud account with an admin role and can reach two databases and a backup bucket — and it was used yesterday from a CI runner. Rotating the key without assigning an owner and scoping the role simply produces a new key with the same blast radius.

The NHI population

Non-human identities are not one thing. A workable taxonomy:

• Service identities — service accounts, application identities, service principals, daemon identities.
• Workload identities — Kubernetes service accounts, cloud workload roles, managed identities, serverless and container identities.
• Machine identities — certificates, machine keys, mTLS, SPIFFE/SPIRE identities.
• Integration identities — OAuth apps, SaaS integrations, connected applications, app registrations.
• Automation identities — CI/CD, deployment, infrastructure-as-code, RPA and scheduled automation.
• Credential-backed identities — principals that exist only as a key, token or certificate.
• AI identities — agents, agent service principals, MCP server and tool identities, agent-to-agent identities, coding agents.
• Emerging identities — agent-created identities, ephemeral identities, identity brokers, delegated identities.

Each class fails differently. Service identities are orphaned. Integration identities are over-scoped. Automation identities are reused across environments. AI identities inherit everything the developer had.

What “govern” means for a machine

Governance for people is built around joiners, movers and leavers. For machines the lifecycle is messier, but the questions are the same:

1. Does this identity have an accountable owner?
2. Does it have a stated purpose, and does its access match that purpose?
3. Are its credentials short-lived, rotated and stored somewhere that is not a wiki page?
4. Is it still used? By whom, from where?
5. When should it stop existing, and who decides?

If any of those is unknown, the honest inventory says so. That is the starting point for every other control.