HI
Human Identity (HI) Taxonomy
Every NHI tool assumes a human-identity layer exists (typically Entra ID, Okta, AD, or an IGA) and reads from it. Included for completeness — and because the HI/NHI boundary is blurring (see shared accounts below).
| # | Category | Class | Description | Examples |
|---|---|---|---|---|
| H1 | Employees (full-time) | Identity | W2/T4 workers in the HR system of record. | Salaried staff in Workday/SAP SuccessFactors synced to Entra ID; badge + SSO identity |
| H2 | Contractors / contingent workers | Identity | Time-bound non-employee identities. | 6-month agency developer; seasonal warehouse staff; SOW consultant with an end-dated account |
| H3 | Partners / B2B users | Identity | External org users with federated access. | Distributor logging into a partner portal via SAML federation from their own tenant |
| H4 | Customers / B2C users | Identity | End-user accounts in CIAM scope. | Retail-banking app logins; e-commerce accounts in Auth0 / Descope / Entra External ID |
| H5 | Privileged users / admins | Identity | Elevated-access humans. | Domain admins; cloud root/owner; DBAs; break-glass emergency accounts in CyberArk PAM |
| H6 | Vendors / 3rd-party admins | Identity | External support personnel. | MSP engineer with vendor PAM access; OEM support rep granted temporary admin |
| H7 | Dormant / orphan human accounts | Identity | Inactive accounts no longer linked to a person. | Departed employee whose account was never disabled; account with no owner after a reorg |
| H8 | Shared / generic human accounts | Identity | Discoverable but a governance problem; now often treated as a machine-account sub-type. | admin, sysadmin, guest, a shared ops mailbox, a kiosk login used by a shift |
| H9 | Test / synthetic accounts | Identity | QA, training, demo accounts. | qa_user01; load-test personas; sales-demo seed accounts; training-sandbox users |
The blurring boundary: several IGA vendors have begun classifying “shared accounts” as a machine-account
sub-type rather than a human identity (per the NHI Lab source documents; verify the specific vendor/release before external use).
Historically a shared account was a human identity used by many; most tools now govern it as a machine identity.
1
Tier 1 — Agentic / AI Identities
The frontier. Autonomous actors that acquire permissions at runtime, spawn sub-agents, and chain actions across systems. Where the discovery gaps are widest.
Why this tier is hard: agents are not passive credential holders — they invoke APIs, write and run code, and spawn other agents at runtime. Each behavior expands the blast radius of a single compromised credential far beyond a static service account. Sub-agent governance (#3) is the single biggest market gap.
| # | NHI Type | Class | Description | Examples |
|---|---|---|---|---|
| 1 | RPA bots | Identity | Robotic process automation robot identities. | A UiPath robot logging into an ERP; an Automation Anywhere bot; Blue Prism worker |
| 2 | AI agents (sanctioned) | Identity | Custom-built, third-party, or enterprise-built agents. | A customer-support agent on Microsoft Agent Framework; a Bedrock agent; a Gemini Enterprise Agent Platform (formerly Vertex AI) agent |
| 3 | AI agent sub-agents | Identity | Agents spawned dynamically by parent agents. | A planner agent that spins up a research sub-agent and a code-writer sub-agent per task |
| 4 | MCP servers | Identity | Model Context Protocol servers exposing tools. | A self-hosted MCP server exposing a Jira tool; a filesystem MCP server in an IDE |
| 5 | MCP tools | Capability | Individual tool entries within an MCP server — an authorizable action, not an actor identity. | create_ticket, read_file, run_query as discrete authorizable tools |
| 6 | Chatbots | Identity | Conversational bot identities. | A Copilot Studio bot; a Slack bot user; a Teams bot with Graph permissions |
| 7 | LLM API keys | Credential | Spending-sensitive keys to model providers. | An OpenAI/Anthropic key; an Amazon Bedrock key; a Gemini Enterprise Agent Platform (formerly Vertex AI) key |
| 8 | Vector DB credentials | Credential | Access to embedding stores. | A Pinecone API key; Weaviate credentials; a Qdrant access token for a RAG app |
| 9 | AI model registry credentials | Credential | Access to model registries. | A Hugging Face token; an MLflow registry credential; an Azure ML registry token |
| 10 | Memory / state store credentials | Credential | Agent memory and framework state stores. | A Redis credential backing agent memory; an agent-framework session-state store key |
| 11 | Browser-use agent sessions | Both | Agents driving real browsers. | An Anthropic Computer Use session; an OpenAI Operator browsing session |
| 12 | Personal AI tool usage | Identity | Employees using personal AI accounts for company data. | Staff pasting code into personal ChatGPT Plus / Claude Pro / Gemini accounts |
| 13 | Shadow / unsanctioned AI agents | Identity | Agents running outside governance. | An agent installed in a developer’s Cursor IDE; a business-unit SaaS auto-pilot nobody registered |
| 14 | Vendor / supplier AI agents | Identity | Third-party agents authorized into your environment. | Your CRM vendor’s AI agent holding a Salesforce service account; a support tool’s agent with Slack OAuth |
2
Tier 2 — Static / Credential-Based NHIs
Long-lived credentials, keys, tokens, and certificates. This is what most “NHI vendors” were originally built to discover.
| # | NHI Type | Class | Description | Examples |
|---|---|---|---|---|
| 15 | Service accounts (AD/on-prem) | Identity | Long-lived accounts for Windows services, scheduled tasks, legacy apps. | svc_sqlbackup running a nightly job; an AD account behind a Windows service |
| 16 | Application service accounts (cloud) | Identity | Cloud-native machine principals. | Entra service principal; AWS IAM user; GCP service account app@project.iam.gserviceaccount.com |
| 17 | API keys | Credential | Long-lived strings authenticating apps to APIs. | Stripe sk_live_…; SendGrid key; a weather-API key in a mobile backend |
| 18 | OAuth tokens / refresh tokens | Credential | Delegated-auth credentials for SaaS-to-SaaS access. | A Slack app’s refresh token; Google Workspace OAuth grant for a scheduling tool |
| 19 | Access / bearer tokens | Credential | Short-lived authorization tokens. | JWT bearer token on an API call; a 1-hour cloud access token |
| 20 | Personal Access Tokens (PATs) | Credential | User-scoped tokens, commonly in dev tooling. | GitHub PAT in a CI script; GitLab/Atlassian token pasted into automation |
| 21 | Webhooks | Credential | Outbound integration credentials embedded in URLs. | A Slack incoming-webhook URL with an embedded secret; a CI → chatops callback URL |
| 22 | TLS/SSL certificates | Both | x.509 certs identifying servers, services, mTLS clients. | A web-server cert; an mTLS client cert between two microservices |
| 23 | Code signing certificates | Credential | Certs that sign binaries, packages, container images. | Authenticode cert signing a Windows installer; a cosign key for container images |
| 24 | SSH keys (host & user) | Credential | Asymmetric keypairs for SSH auth. | A deploy key on a bastion host; id_ed25519 reused across servers |
| 25 | Database credentials | Credential | Connection-string passwords, DB-native users. | A Postgres app_rw user; a connection string with an inline password |
| 26 | Hardcoded secrets in code | Credential | Credentials committed to source repos. | An AWS key in config.py; a token in git history; a password in a Dockerfile |
| 27 | Environment variables / config files | Credential | Credentials in .env, config.yaml, ConfigMaps. | A .env with DB_PASSWORD; a Kubernetes ConfigMap holding an API key |
| 28 | Embedded credentials in firmware | Credential | Credentials baked into device firmware (IoT/OT). | A default admin password in a camera’s firmware; a hardcoded key in a PLC image |
3
Tier 3 — Workload / Cloud-Native Identities
Identities tied to running workloads, containers, pipelines, and cloud roles. Partially covered by most vendors.
| # | NHI Type | Class | Description | Examples |
|---|---|---|---|---|
| 29 | Kubernetes service accounts | Identity | Pod-mounted identities. | A default SA token mounted into a pod; a namespaced SA for a controller |
| 30 | Kubernetes secrets | Credential | K8s-native secret objects (often base64-only). | A Secret holding a registry pull credential or DB password |
| 31 | Container / image identities | Identity | Identities tied to running containers. | A workload identity bound to a specific image digest; a sidecar’s identity |
| 32 | SPIFFE SVIDs | Both | Workload attestation identities (CNCF standard). | A SPIRE-issued spiffe://trust-domain/ns/app SVID for mTLS between services |
| 33 | IAM roles | Identity | Role-based cloud identities. | An AWS IAM role; an Azure managed identity; a GCP service account with roles |
| 34 | Cross-account / federation roles | Identity | AssumeRole, Workload Identity Federation patterns. | An AWS cross-account AssumeRole; GCP WIF; AWS IAM Roles Anywhere |
| 35 | Service mesh identities | Both | Istio/Linkerd mTLS workload identities. | An Istio sidecar’s SPIFFE identity used for mesh mTLS |
| 36 | Cloud functions / serverless | Identity | Execution identities for serverless. | A Lambda execution role; an Azure Function’s managed identity; a GCP Cloud Function SA |
| 37 | CI/CD pipeline identities | Identity | Pipeline auth, increasingly OIDC-federated. | GitHub Actions OIDC token; a GitLab Runner’s identity; a Jenkins agent credential |
| 38 | Build agents | Identity | Self-hosted runners, ephemeral build credentials. | A self-hosted GitHub runner’s registration token; an ephemeral buildkit identity |
| 39 | Message bus credentials | Credential | Broker connection identities. | A Kafka/MSK SASL credential; a RabbitMQ user; an Azure Service Bus SAS token |
| 40 | Monitoring / observability agents | Identity | Telemetry forwarders and collectors. | A Datadog agent API key; a Splunk forwarder; an OpenTelemetry collector identity |
| 41 | Backup service accounts | Identity | Privileged backup credentials. | A Veeam/Rubrik/Commvault service account with broad read access |
| 42 | Mainframe accounts | Identity | z/OS security identities (human and non-human). | A RACF started-task ID; an ACF2 batch-job ID; a Top Secret service ID |
4
Tier 4 — Physical / Edge / Other (often forgotten)
Device, edge, and emerging machine identities. Largely invisible to the seven core NHI vendors — needs specialist tooling.
| # | NHI Type | Class | Description | Examples |
|---|---|---|---|---|
| 43 | IoT devices | Identity | Connected sensors and smart-building gear. | Security cameras; environmental sensors; smart locks; building HVAC controllers |
| 44 | OT / ICS device identities | Identity | Industrial control endpoints (Purdue model). | A PLC on a factory floor; an HMI panel; a SCADA endpoint in a utility |
| 45 | IoMT devices | Identity | Connected medical devices. | An infusion pump; a networked patient monitor; an MRI workstation |
| 46 | Network device identities | Identity | Infrastructure device identities. | Routers, switches, firewalls, load balancers with management credentials/certs |
| 47 | Mobile device certificates | Both | MDM-issued device identities. | An Intune/Jamf device cert on an employee phone representing the device |
| 48 | Browser extension credentials | Credential | The OAuth/API tokens an extension holds. (The extension itself is the actor; this row is its credential material.) | A Chrome extension with OAuth to Gmail; a productivity add-on with Salesforce scope |
| 49 | Edge computing identities | Identity | CDN/edge worker identities. | A Cloudflare Worker; a Fastly Compute service; an edge function identity |
| 50 | DIDs / VCs for machines | Both | Emerging W3C verifiable credentials issued to NHIs. | A 1Kosmos / Entra Verified ID credential issued to a machine identity |
+5
Emerging / Under-Discussion (Review Addendum)
These five were flagged in critical review as missing or buried in the 50-type list. They are kept as a clearly-marked addendum (lettered E1–E5, not renumbered) so the core taxonomy stays traceable to the source document and the vendor-matrix columns.
Why addendum, not renumber: the core type numbers line up with the vendor capability matrix (which scores the Tier 1 & Tier 2 priority rows). Renumbering would break that mapping. Treat E1–E5 as candidates to fold into a v2 taxonomy once the vendor matrix is re-scored against them.
| # | Emerging Type | Class | Description & why it was flagged | Examples |
|---|---|---|---|---|
| E1 | Managed identities (as first-class) | Identity | Arguably the most common cloud NHI, currently buried inside #33 “IAM roles.” Worth splitting out because its lifecycle (no secret, platform-managed) differs materially. | Azure system-assigned & user-assigned managed identities; the auto-rotated identity on a VM/Function |
| E2 | Passkeys / FIDO2 bound to workloads | Both | WebAuthn credentials are spreading from human auth into device/workload auth; not represented in the core list. | A FIDO2 credential provisioned to a kiosk or device; passkey-based workload attestation |
| E3 | Cloud KMS / signing keys | Both | Distinct from secrets (#26) and certs (#22): a cryptographic authority used by a principal to sign/encrypt — not an actor identity itself, but identity-bearing enough to govern. Notable omission. | An AWS KMS key; a GCP Cloud KMS key; an Azure Key Vault signing key used by a service |
| E4 | Data-plane access tokens (presigned / SAS) | Credential | Time-boxed, scoped grants to data objects. Partially under #21 webhooks but conceptually their own class — and a real exfil path for agents. | A presigned S3 URL; an Azure Storage SAS token; a GCS signed URL handed to an agent |
| E5 | Native (non-MCP) agent tools / skills | Capability | #4/#5 are MCP-specific. Framework-native function-calling tools aren’t cleanly captured — like MCP tools, they are authorizable capabilities, not actors. | Bedrock action groups; Gemini Enterprise Agent Platform (formerly Vertex AI) function-calling tools; MS Agent Framework skills |
Also considered, intentionally NOT added (merge candidates, kept separate in v1 for vendor-scoring granularity):
#18/#19/#20 tokens could collapse to one “tokens” row; #29+#30 (K8s SA + K8s secrets) overlap; #43–#46 device types could collapse to one
“device identities” row since none of the seven vendors cover them. Flagged for the v2 simplification pass, not changed here.
Naming note (May 2026): Google rebranded Vertex AI to the
Gemini Enterprise Agent Platform at Cloud Next 2026 (announced 23 Apr 2026). Examples above referencing it use the new name with the
former name in parentheses.
Class column — how to read it. The taxonomy mixes identities (the actor/principal),
credentials (the secret/key/token used to authenticate), and capabilities (authorizable actions/tools,
not actors). That’s correct for a discovery-coverage scoreboard, but they are provisioned differently in the
UC-01 Data Foundry, so each row is classified:
Identitythe acting principal
Credentialsecret/key/token used to authenticate
Botha principal asserted via cryptographic material (certs, SVIDs, DIDs)
Capabilityan authorizable action/tool, not an actor
Rows that mix principal and credential material (e.g. SSH keys, CI/CD OIDC tokens, message-bus credentials,
observability agents) are classified by their primary role in the foundry, not their only role — the
Examples column shows the underlying artifact either way.