What is a non-human identity?
A non-human identity (NHI) is any principal that authenticates and acts without a person at the keyboard: a service account, a workload identity, a CI/CD job, an OAuth application, an API key that stands in for an application, an AI agent. If it can be authenticated, can be authorized and can do something to a resource, it is an identity — whether or not a directory lists it.
Three properties make NHIs different from the human identities most security programs were built around:
- They are created by engineers, not by HR. There is no joiner process, so there is often no owner, no purpose statement and no end date. Nobody phones a service account to ask what it was doing at 03:14.
- They authenticate with things that can be copied. Keys, tokens and certificates move between laptops, pipelines, wikis and chat. A person notices when they are locked out; a service account does not notice when its key is in three places.
- They outnumber people. Every pipeline, integration, workload and agent adds principals, and the population grows faster than any review cycle can follow.
Identity ≠ credential. A credential is what an identity presents to prove itself. One identity may hold many credentials; one credential may be copied into many places. Secret scanners find the strings. Identity security asks who the string belongs to, who owns that identity, what it can reach and what it is doing. Read the model.
A working taxonomy
Non-human identities are not one thing, and each class fails in its own way. Classification is not bookkeeping: it decides which questions you ask of an identity and which evidence you collect.
| Class | Examples | Typical failure |
|---|---|---|
| Service identities | Service accounts, application identities and registrations, service principals, daemon identities | Orphaned when the team that created them moves on |
| Workload identities | Kubernetes service accounts, cloud workload roles, managed identities, serverless, container and VM identities | Bound to broad roles because scoping was deferred |
| Machine identities | Certificates, machine keys, mTLS, SPIFFE/SPIRE and workload certificates | Expire unexpectedly, or never expire at all |
| Integration identities | OAuth apps, SaaS and API integrations, connected apps, app registrations, service-to-service identities | Over-scoped consent granted once and never reviewed |
| Automation identities | CI/CD, deployment and infrastructure-as-code identities, GitHub Actions, GitLab CI, Jenkins, RPA, scheduled jobs | Reused across environments with long-lived secrets |
| Credential-backed identities | API keys, tokens, JWT clients, SSH keys, signing keys, cloud credentials | Exist only as a secret, so nobody treats them as an account |
| AI identities | Agents, agent service principals and OAuth connections, MCP server and tool identities, agent-to-agent and orchestration identities, coding agents | Inherit a developer's authority and use it at machine speed |
| Emerging identities | Agent-created agents, agent-created service identities, ephemeral identities, identity brokers, delegated identities | Appear and disappear faster than reviews can run |
Two practical notes. First, an identity can belong to more than one class over its life — a credential-backed identity becomes a service identity the moment someone attaches it to a named account. Second, when the evidence does not support a class, the honest label is unclassified, not a guess.
The relationship model
Every identity sits in a chain
A human owns an identity; the identity holds a credential; the credential authenticates to a service; the service can reach resources; the identity performs actions on them; and something decides whether each action is allowed. Agents extend the chain with the tools they use, the agents they delegate to and the data they receive.
- Humanaccountable owner
- ownsNHI / Agentservice, workload, agent
- entitled toTool
- tool belongs toMCP server
- has credentialCredentialkey, token, certificate
- authenticates toService / APIcloud, SaaS, data
- can accessResourcebucket, table, repo
- performsActionread, write, delete, deploy
- authorizationDecisionallow · challenge · deny
The security questions that matter — who is accountable, what is the blast radius, what should be revoked — live on the edges of this chain, not in any single node.
Read the chain edge by edge and each one is a control surface:
- Owns
- Human → identity. The accountability edge. When it is missing, the identity is orphaned and every other remediation stalls at “who owns this?”
- Has credential
- Identity → credential. The exposure edge. Age, type, rotation, where copies live and whether the credential is vaulted belong here.
- Authenticates to
- Credential → service. The trust edge. Which systems accept this credential, and whether they would accept it from anywhere.
- Can access
- Service → resource. The reachability edge. Effective access, evaluated across roles and trust policies, and the blast radius it implies.
- Performs
- Identity → action. The behaviour edge. What the identity actually does, from where, compared with what it could do.
- Authorization
- Action → decision. The control edge. For agents especially: should this identity perform this action on this resource, right now, with this authority?
A list of accounts cannot represent any of this. A graph can, and it can attach evidence to each edge — the IAM snapshot, the authentication log, the HR record — so that every finding can be walked back to the records that support it.
The ten risks that matter
The ten categories below follow the OWASP Non-Human Identities Top 10, a community list maintained by OWASP. The descriptions and the questions are ours; the full mapping to evidence and controls has its own page.
| Risk | What it looks like | First question to ask |
|---|---|---|
| Improper offboarding | Identities outlive the people and projects that created them | Which identities belong to people who have left? |
| Secret leakage | Credentials copied into code, CI, chat and documents | Where are live copies of this credential? |
| Vulnerable third-party NHI | Vendor integrations with standing access and broad scopes | What can each integration reach inside our environment? |
| Insecure authentication | Static keys where federation or short-lived tokens were possible | Would we accept this authentication method from a person? |
| Overprivileged NHI | Effective access far wider than observed use | What does it do, versus what could it do? |
| Insecure cloud deployment configurations | Pipelines obtaining identity through long-lived secrets or loose trust policies | How does each pipeline get its identity? |
| Long-lived secrets | Credentials that never expire | How old is the oldest credential that still works? |
| Environment isolation | Non-production identities that can reach production | Can anything cross the boundary? |
| NHI reuse | One identity or credential doing several jobs | Is the same credential seen from multiple services or hosts? |
| Human use of NHI | People logging in as machines | Are there interactive sessions on service identities? |
Beyond the ten, the same graph explains the second-order risks: identity sprawl, ownership mismatch (the named owner is not the real one), purpose and permission drift, transitive access through chains of trust, blast-radius amplificationwhere one credential unlocks many services, and shadow integrations and shadow AI that arrive as new OAuth grants rather than new applications.
What good looks like
A mature NHI program can answer seven questions for every identity, and can show the evidence for each answer rather than assert it.
| Question | Good looks like | Evidence |
|---|---|---|
| Does it exist in the inventory? | Continuous discovery across every environment, not an annual export | Connector snapshots with timestamps |
| What is it? | A class, a subtype, an environment and a criticality | Classification rule and matched attributes |
| Who owns it? | An attested owner with a purpose statement and an end date | Attribution signals and the attestation record |
| What credentials does it hold? | Short-lived where possible, rotated, vaulted, with no stray copies | Credential metadata, rotation history, scan results |
| What can it reach? | Effective access known and close to observed use | Permission evaluation versus activity |
| Is it still used? | Dormancy computed from observed authentication, unknown where the source is silent | Authentication logs, last-seen |
| When does it end? | A decommission path with a rollback window and a human who signs | Lifecycle state changes in the audit trail |
The order matters. Inventory before classification, classification before ownership, ownership before credential and access work — because rotating a key or scoping a role without an owner is a guess with production consequences. A 30-day plan covers the first three steps.
How Trustivan approaches it
Trustivan is the control plane for non-human and agentic identities: one graph that unifies identity, credential, access, agent and action context. We label every capability honestly — what is available today, what is a future capability and what is not built, by design.
Discovery & inventory
AvailableFive read-only connectors — AWS IAM, GitHub, Kubernetes, HashiCorp Vault and Model Context Protocol — enumerate machine identities, the metadata of their credentials and the resources they reach.
NHI Discovery & InventoryClassification with evidence
AvailableEach identity carries one type from a closed set across every connector, with the provider’s raw type kept as evidence and unknown when nothing maps.
ClassificationOwnership & lifecycle
AvailableOwners read from provider tags or assigned by a person, recorded as owned, unresolved or unowned with the basis, and lifecycle states from discovery and, where the provider reports it, last use.
Ownership & LifecycleIdentity graph & search
AvailableOwners, identities, credentials, services and resources as a graph with evidence on every edge, searchable by class, environment, owner state and last use.
Identity GraphCredential security
AvailableCredential metadata mapped to the identities that hold it; age, rotation-overdue, expiry, exposure and sharing findings. Secret values are never read, and nothing is rotated at the provider.
Credential SecurityAccess intelligence
AvailableEffective access as an upper bound, transitive reach, access paths, blast radius and cross-account trust on the graph. Overprivilege measured against observed use is a future capability.
Access IntelligenceAI agent security
AvailableAgents and MCP tools with owners, declared autonomy, declared tool entitlements and agent findings. No connector discovers an agent, and no screen registers one.
AI Agent SecurityAction authorization
AvailableThirteen deny-by-default rules over principal and credential state, tool entitlement, effect, resource impact, autonomy and standing grants, returning ALLOW, CHALLENGE or DENY. Tool entitlements are declared by an operator.
Secure Every Action