Non-Human Identity (NHI)

Overview

Non-Human Identity (NHI) encompasses the vast ecosystem of identities assigned to machines rather than people. In the context of AI, NHI is exploding. Every model instance, vector database connector, and automated retrieval plugin represents a non-human actor requiring authentication. Securing NHI is the foundational layer for secure AI, as AI systems rely heavily on machine-to-machine (M2M) communication.

The shift from static "Service Accounts" to dynamic, attested NHI is the critical evolution required for secure AI at scale.

Architecture

The lifecycle of a Non-Human Identity in an AI ecosystem involves automated rotation and policy-based access.

Key Decisions

• Secret Management: Avoid hardcoded API keys. Use dynamic secrets injection or OIDC federation.
• Granularity: One identity per service vs. one identity per function. For AI, granular identities allow for better isolation of compromised components.
• Lifecycle Management: Automated rotation is non-negotiable. Long-lived keys are the #1 attack vector for NHIs.

Implementation

OAuth Client Credentials Flow

For server-to-server communication where no user is present:

1. Register the AI application as an OAuth Client.
2. Use the client_credentials grant type.
3. Receive an Access Token.

Kubernetes Workload Identity

Map Kubernetes Service Accounts (KSA) to Cloud IAM roles.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: rag-retriever
  annotations:
    iam.gke.io/gcp-service-account: rag-retriever-sa@project.iam.gserviceaccount.com

Risks

• Secret Sprawl: AI developers often hardcode keys in Jupyter notebooks or .env files, leading to leaks.
• Over-privileged Service Accounts: "God mode" service accounts are frequently used to "just get it working," leaving systems vulnerable.
• Lack of Visibility: Unlike user identities, NHIs often lack behavioral baselining, making it hard to detect when a service account starts behaving anomalously (e.g., scraping unusual data).