What Are Non-Human Identities? (Oasis Security)

Source: Oasis Security — What Are Non-Human Identities? (2026). Local copy: .raw/articles/oasis-what-are-non-human-identities-2026-04-30.md.

Key Claim

NHIs are a structurally different governance class from human identities. The mismatch is not just terminological: HR-driven IAM and credential-storage-focused PAM cannot govern decentralized, developer-created, ownerless identities that scale 45–100× faster than humans. Securing NHIs requires purpose-built strategies, not retrofits.

Methodology

Vendor blog (Oasis Security positioning piece) grounded in:

  • Rubrik Zero Labs — NHI-to-human ratio 45:1 enterprise average; up to 100:1 in some orgs.
  • arxiv 2503.18255 — machine identities per enterprise grew from 50K (2021) to 250K (2025); 400% increase.
  • IBM 2025 Cost of a Data Breach Report10.22M US average breach; report explicitly recommends NHI controls.
  • Three named incidents: Microsoft AI Storage / SAS token (38TB exposure), CircleCI OAuth breach, Mercedes-Benz service-account misuse.

Notable Findings

1. NHI taxonomy (eleven types)

TypeAuthentication mechanism
Service AccountUsername/password; service-account secret
Service PrincipalClient secret or certificate (cloud-native)
System AccountOS-issued, typically high privilege
IAM RoleAWS-style role with temporary session credentials
API KeyStatic key for machine-to-machine
Machine Identity (VM / container / serverless)Cloud-issued cert / SVID
Token (OAuth, JWT)Time-limited bearer
Certificate (TLS, mTLS)Asymmetric key
Storage Access KeyLong-lived, broad-permission
Database UserApplication-level
Personal Access Token (PAT)Developer-generated, often long-lived
SAS Token (Azure)Time-limited, granular

2. Identity-credential coupling (sharper than current wiki framing)

“Special considerations arise in scenarios where identities are inseparable from the authentication string, as seen in Storage account access keys, Shared Access Signatures (SAS) tokens, and API keys for SaaS applications like Snowflake.”

Where the credential is the identity, rotation is identity rotation. The Credential Proxy Pattern for AI Agents cannot separate what is structurally inseparable; some workflows must rotate-as-identity-rotation. See new concept: Identity-Credential Coupling.

3. Why human-identity controls fail for NHIs

Eight structural differences:

PropertyHumanNHI
CentralizationIT-managed, single source of truthDecentralized, created by developers, citizen-developers, IT, infrastructure-as-code
OwnershipTied to individualShared across teams / apps; often unowned
ScaleLinear with org headcount10–100× human count, growing exponentially
Rate of changeHR-driven (joiner/mover/leaver)Code-pace (per commit / per deploy)
ProvisioningIT-mediatedDeveloper-driven, often invisible to IT
Secret expirationFrequent password rotationOften never rotated; sometimes no expiration
Operational risk of rotationLow (user can re-authenticate)High (rotation can break production workflows)
Authentication factor diversityThree-factor (know / are / have) + MFA + SSOSingle-factor (the secret); no MFA equivalent

Implication: when an attacker gets a service-account secret, there is no MFA challenge or SSO step to stop them.

4. Why legacy IAM and PAM fail

  • IAM: built around HR-driven joiner/mover/leaver lifecycle events. NHIs don’t have HR events — they have code commits and deploys. Ownership assignment, certification, and deprovisioning are extremely difficult.
  • PAM: stores secrets in a vault but lacks usage context — what does the secret connect to, is it still required, what depends on it. Without that context, rotation is operationally risky and least-privilege is unenforceable.

5. Six-pillar securing-NHI strategy

PillarMaps to Agentic AI Security Capability Maturity Model — A 2026 Practical Proposal
Enforce least privilege by defaultD2 L3+ (already covered)
Establish ownership and accountabilityD1 L3 (decision-rights matrix) + D2 L3 (per-NHI human owner field)
Automate credential rotationD2 L4 (credential proxy + rotation cadence)
Monitor behavior continuouslyD7 L4 (per-credential behavioral baselines for NHIs)
Integrate NHI governance into the development lifecycleD8 L3 + D2 L3 (CI/CD gate; new: dev-lifecycle integration as level criterion)
Align NHI governance with Zero Trust principlesD2 + D5 (already covered conceptually; sharpened to “Zero Trust without NHI visibility is incomplete”)

6. Real-world incidents

IncidentVectorNHI lesson
Microsoft AI Storage BreachMisconfigured SAS token38TB internal data exposed (passwords + private keys); SAS tokens have identity-credential coupling — rotation requires identity rotation.
CircleCI BreachOAuth token compromiseMass-rotation across thousands of customer environments — rotation infrastructure must be tested.
Mercedes-Benz BreachService accounts with excessive privilegesLong-lived, over-permissioned NHIs are persistent attacker access.

Gap Analysis vs Existing Framework

What the post confirms (already covered)

Gaps the Oasis post surfaces

Five sharpenings worth applying

  1. Identity-credential coupling is a load-bearing concept the wiki has not named. Where the credential IS the identity (SAS tokens, storage access keys, PATs, Snowflake API keys), the credential proxy pattern cannot help — these workflows must rotate-as-identity-rotation. New concept page: Identity-Credential Coupling.
  2. HR-driven vs code-pace lifecycle mismatch — NHIs don’t have joiner/mover/leaver. The CMM D2 L3 should explicitly require an NHI lifecycle that does not depend on HR events; D2 L4 should require automated provisioning gates at code-deploy time (tied to CI/CD, not to onboarding).
  3. Dependency mapping before rotation — Oasis: “Where rotation is operationally risky, invest in dependency mapping to understand what will break before making changes.” This is concrete CMM D9 L4 evidence: the org must maintain a per-credential consumer-graph (what depends on this credential) before automated rotation is enabled.
  4. NHI scale evidence is currently single-sourced (CyberArk 82:1). Oasis adds Rubrik 45:1 and arxiv 250K-per-enterprise — both worth surfacing in Non-Human Identity (NHI) for triangulation.
  5. Eleven NHI types vs current treatment — wiki lists service accounts and SPIFFE-flavor workload IDs but does not enumerate Service Principals, IAM Roles, PATs, SAS tokens, Storage Access Keys, Database Users. Each has a distinct rotation / ownership / detection profile. Worth enumerating in Non-Human Identity (NHI).

What the framework provides that Oasis does not

  • CMM cumulative levels with floor rule (CMMC import).
  • ID-tagged evidence (ASI03 for identity findings).
  • Lethal Trifecta, CFI, runtime AI-BOM — broader agentic primitives.
  • Standards crosswalk (Agentic AI Security CMM — Standards Crosswalk Matrix) — Oasis name-checks Zero Trust and IBM but doesn’t crosswalk.
  • Six-plane reference architecture — Oasis content fits cleanly into D2 + D7 + D8 + D9.

Strengths and Weaknesses

Strengths. Sharpest published treatment of why HR-driven IAM fails for NHIs. Clear identity-credential-coupling articulation. Concrete incident anchors. Six-pillar strategy maps cleanly to existing CMM domains.

Weaknesses. Vendor blog: Oasis Security is positioned as the answer; technical implementation depth is thin. No discussion of agent-specific NHI concerns (e.g., NHIs created by AI agents themselves, MCP server identities, A2A cryptographic identity). No engagement with NIST CAISI Concept Paper (Feb 2026) on AI agent identity. No mention of platform-vs-prompt enforcement.

Relations