NHI Security7 min read

Non-Human Identities: The Fastest Growing Attack Surface

Service accounts, API keys, CI/CD tokens, and AI agents now outnumber human identities 10:1. Why NHI governance is the most urgent challenge in identity security.

TigerIdentity Team•January 13, 2026

Every cloud deployment, every microservice, every CI/CD pipeline, and every AI agent creates non-human identities. These NHIs now vastly outnumber humans — yet most organizations manage them with spreadsheets, shared credentials, and hope.

While security teams have spent decades perfecting human identity management with SSO, MFA, and conditional access, non-human identities have proliferated unchecked. The result is a massive blind spot that attackers are actively exploiting.

The NHI Explosion

10:1

Ratio of NHIs to human identities

68%

of NHIs have excessive permissions

45%

of API keys never rotated

82%

of breaches involve compromised credentials (including NHI)

Types of Non-Human Identities

Non-human identities come in many forms, each with unique characteristics and risk profiles:

NHI Type	Examples	Risk Factors
Service Accounts	Cloud IAM roles, Kubernetes service accounts	Often over-privileged, rarely audited
API Keys	REST API tokens, webhook secrets	Long-lived, shared across teams
CI/CD Tokens	GitHub Actions, Jenkins, CircleCI	High privilege, auto-generated
AI Agents	OpenClaw, LangChain agents, copilots	Broad access, autonomous actions
IoT/Device	Sensors, edge devices, embedded systems	Hardcoded credentials, no rotation
RPA Bots	UiPath, Automation Anywhere	Screen-level access, often admin

Why Traditional IAM Fails for NHIs

Traditional identity and access management systems were designed for humans. When applied to non-human identities, fundamental gaps emerge:

No lifecycle management

NHIs are created on-demand and forgotten. No onboarding, no offboarding, no recertification. They accumulate like technical debt.

No behavioral baseline

What is "normal" for a service account? Without usage patterns, detecting anomalies is impossible.

Shared credentials

Multiple systems using the same API key. When one is compromised, all are compromised. Rotation becomes impossible.

No MFA option

You can't send a push notification to a service account. Traditional authentication controls don't apply.

The NHI Governance Framework

Effective NHI governance requires a purpose-built approach that addresses the unique characteristics of machine identities:

Discovery

Automatically discover all NHIs across cloud, SaaS, and on-prem systems. You can't govern what you can't see. TigerIdentity's connectors scan AWS, Azure, GCP, Kubernetes, GitHub, and 50+ other platforms to build a complete NHI inventory.

Classification

Categorize by type, risk level, owner, and business criticality. Not all NHIs are equal — production deployment keys warrant more scrutiny than development sandbox tokens.

Policy

Apply least-privilege, time-bound access policies per NHI. Define what each identity can access, when it can access it, and under what conditions. Continuously enforce these policies in real-time.

Monitoring

Behavioral baselines with anomaly detection for every NHI. Track normal usage patterns and alert on deviations — unusual access times, unexpected resources, geographic anomalies, or privilege escalations.

Lifecycle

Automated rotation, expiration, and decommissioning. Set maximum lifetimes for credentials, enforce rotation policies, and automatically revoke access for unused or orphaned identities.

How TigerIdentity Manages NHIs

TigerIdentity treats non-human identities as first-class citizens in the identity graph. Every NHI gets the same governance rigor as human identities — continuous authorization, behavioral monitoring, and adaptive access control.

Here's an example policy for a CI/CD service account that deploys to production. The policy restricts deployments to business hours and requires approval for off-hours access:

apiVersion: policy.tigeridentity.com/v1
kind: NHIPolicy
metadata:
  name: prod-cicd-deployment
  description: Production deployment service account policy
spec:
  subject:
    type: service_account
    id: cicd-prod-deployer
    tags:
      - cicd
      - production
      - high-privilege

  access:
    resources:
      - type: kubernetes_cluster
        id: prod-cluster-us-east
        actions:
          - deploy
          - rollback
          - scale

    conditions:
      - name: business_hours_only
        expression: |
          time.hour >= 9 && time.hour < 18 &&
          time.weekday in ["Mon", "Tue", "Wed", "Thu", "Fri"]

      - name: approved_pipeline_only
        expression: |
          request.source.pipeline_id in [
            "github-actions-prod",
            "jenkins-prod-pipeline"
          ]

      - name: change_ticket_required
        expression: |
          request.metadata.change_ticket != null &&
          request.metadata.change_ticket matches "CHG-[0-9]+"

  monitoring:
    anomaly_detection: enabled
    alert_on:
      - off_hours_access
      - unexpected_resource
      - privilege_escalation
      - unusual_volume

  lifecycle:
    max_session_duration: 4h
    credential_rotation: 30d
    auto_revoke_if_unused: 90d

This policy ensures that even highly privileged service accounts operate within defined guardrails. If the CI/CD system attempts to deploy outside business hours, it requires explicit approval. If it accesses unexpected resources, alerts fire immediately.

Ready to govern your non-human identities?

Get complete visibility and control over service accounts, API keys, CI/CD tokens, and AI agents with TigerIdentity's continuous authorization platform.

Schedule a Demo Start Free Trial

AI Security