What is Non-Human Identity (NHI) in AI Security?

TL;DR

• Non-human identities (service accounts, API keys, AI agents) now outnumber human identities roughly 45 to 1 in the enterprise.
• A real NHI credential needs four properties: cryptographic non-repudiation, explicit scope policies, ephemeral lifetime, and automated lifecycle governance.
• Traditional service accounts fail AI agents on three fronts: infinite scope privilege escalation, no model-lineage visibility, and inability to revoke without breaking dependents.
• Prompt injection is the attack unique to AI-agent NHIs — it hijacks a valid credential's actions, so only behavioral scoring, not stronger auth, catches it.
• NHI governance maturity is now a factor in cyber-insurance underwriting and enterprise vendor security questionnaires, not just an internal hygiene concern.

What is Non-Human Identity (NHI) in the context of AI agents?

Non-Human Identity (NHI) is a cryptographically verifiable digital identity assigned to an automated software entity rather than a person. For AI agents specifically, a real NHI credential needs four properties: cryptographic non-repudiation (actions signed by an HSM-backed key), explicit scope policies embedded in the credential itself, an ephemeral lifetime rather than a long-lived secret, and automated lifecycle governance — registration, monitoring, and revocation without manual intervention.

Introduction: The Machine Identity Explosion

In modern cloud-native architectures, non-human identities (NHIs) — service accounts, API keys, OAuth tokens, container workloads, and autonomous AI agents — outnumber human users by a ratio exceeding 45 to 1 (CyberArk Identity Security Threat Landscape 2025).

While enterprise Identity and Access Management (IAM) has focused almost exclusively on Single Sign-On (SSO) and Multi-Factor Authentication (MFA) for human employees, non-human identities have become the primary attack vector for breach incidents. The emergence of autonomous AI agents — software entities capable of multi-step reasoning, external tool execution, and dynamic API orchestration — has transformed NHI from a hygiene problem into an existential security crisis.

This article defines Non-Human Identity (NHI) in the context of AI agent security, details why traditional service accounts fail, and outlines the cryptographic standards required to secure machine actors.

---

Defining Non-Human Identity (NHI) for Autonomous Systems

A Non-Human Identity (NHI) is a cryptographically verifiable digital principal assigned to an automated software entity. Unlike human credentials, an NHI credential must define four explicit properties:

• Cryptographic Non-Repudiation: Every action performed by the software principal must be signed using a private key bound to a Hardware Security Module (HSM) or cloud KMS.
• Explicit Scope Policies: The credential must embed immutable operational boundaries (e.g., maximum transaction amounts, allowed API routes, permitted hours of operation).
• Ephemeral Lifetime: Credentials must be time-bounded (short-lived X.509 certificates) to eliminate long-lived secret risk.
• Automated Lifecycle Governance: Registration, baseline creation, continuous behavioral monitoring, and revocation must be managed programmatically without human intervention.

Explore Kakunin's dedicated platform architecture on our Non-Human Identity Platform page.

---

Why Traditional Service Accounts Fail for Autonomous AI Agents

For decades, enterprise security teams relied on static API keys and hardcoded service account secrets to grant permissions to background jobs. When applied to autonomous AI agents, this approach breaks down completely due to three core architectural flaws:

Flaw 1: Infinite Scope Privilege Escalation

Static API keys grant binary access: an API key either has access to an endpoint or it does not. An autonomous AI agent operating with a static service account key can execute unauthorized secondary tool calls or data mutations if prompted or manipulated by prompt injection attacks.

Flaw 2: Lack of Contextual Lineage

When an API gateway receives a request signed with a generic service account key, it cannot determine which specific AI agent instance or model version initiated the request. Was it an approved financial underwriting agent (v3.1.0) or an unvetted experimental script? Static keys offer zero model lineage visibility.

Flaw 3: Inability to Revoke Ephemerally

If a static API key is revoked, every application service using that credential immediately crashes. This operational dependency discourages security teams from rotating keys, leaving compromised credentials active for months or years.

Read our technical deep-dive on replacing service accounts in our X.509 Cryptographic Identity Guide.

---

Zero Trust Architecture Alignment (NIST SP 800-207)

NIST Special Publication 800-207 (Zero Trust Architecture) establishes that implicit trust based on network location must be replaced by continuous, explicit verification. For AI agent NHI, Zero Trust requires:

• Continuous Authentication: Verifying mTLS client certificates on every individual API request.
• Continuous Authorization: Evaluating behavioral risk scores before executing database writes or financial transfers.
• Tamper-Proof Forensics: Writing every decision, input hash, and risk score to Write-Once-Read-Many (WORM) append-only storage.

---

Recommended Next Steps

To de-risk machine credentials across your engineering team, read our guide on Securing Shadow AI Agents or review our API Reference Docs.

The NHI Maturity Model: From Ad Hoc to Continuous

Enterprises do not arrive at rigorous non-human identity governance in one step. Maturity progresses through four distinct stages, and most organizations deploying AI agents today are still clustered in the first two — a gap that widens as agent fleets scale faster than the controls meant to govern them.

Understanding where an organization sits on this curve matters because each stage has a different failure mode. Ad hoc environments fail through omission — nobody notices an orphaned credential until it is exploited. Managed environments fail through drift — the inventory is accurate on the day it is built and stale within a quarter. Automated environments fail through blind trust in the automation itself. Only the continuous stage treats identity as a live signal rather than a static record.

Stage 1: Ad Hoc

Credentials are provisioned manually, often by copying a pattern from an existing service account. There is no central registry, no consistent naming convention, and no owner of record beyond whoever happened to create the key. Expiration is either absent or set arbitrarily long to avoid breaking something. This stage is functionally identical to how most organizations handled service accounts a decade ago, except AI agents multiply far faster than human-provisioned service accounts ever did.

Stage 2: Managed

A central identity or security team introduces a registry, a request process, and periodic access reviews. This is real progress, but it is fundamentally a point-in-time control — an inventory that is correct on audit day and increasingly wrong afterward. Managed-stage organizations can answer "what agents exist" but usually cannot answer "what did agent X actually do at 3pm yesterday" without stitching together logs from three or four systems after the fact.

Stage 3: Automated

Provisioning, scoping, and expiration are codified into pipelines rather than tickets. Certificates or tokens are issued programmatically with policy-defined lifetimes, and revocation is triggered by defined events — an agent decommission, a role change, a failed compliance check — rather than a person remembering to act. This is the stage where cryptographic non-repudiation (an X.509 certificate bound to a specific agent identity, for example) starts to replace shared secrets and static API keys as the default credential type.

Stage 4: Continuous

Identity, behavior, and policy are evaluated in real time rather than at issuance. A continuous-stage program does not simply trust that an agent's scope is still appropriate because it was appropriate when the credential was minted three months ago; it scores the agent's live behavior against its declared baseline and adjusts trust accordingly. Kakunin's own risk-scoring model — a continuous 0.00–1.00 score with auto-revocation typically triggered at 0.85 or above, enforced within a sub-60-second SLA through CRL/OCSP propagation — is an implementation of this stage rather than of Stage 3's periodic issuance model. The distinction matters: automated issuance answers "was this agent trustworthy when it was created," while continuous governance answers "is this agent still trustworthy right now."

How AI Agent Governance Differs From Service Accounts, IoT, and Containers

Non-human identity is not a single category with uniform risk. Service accounts, IoT devices, container workloads, and AI agents all fall under the NHI umbrella, but they diverge sharply in what makes them dangerous and what governing them well requires.

Traditional service accounts are largely static: a batch job or integration authenticates the same way, to the same endpoints, for its entire operational life. Risk comes from over-scoping and neglect, not from unpredictability. IoT devices carry a different profile — fixed function, but frequently unpatchable, physically distributed, and often authenticated with embedded credentials that cannot be rotated without a firmware update. Container workloads are ephemeral by design; the governance challenge there is less about long-lived credential sprawl and more about ensuring a workload identity is scoped correctly for the seconds or minutes it exists.

AI agents combine the worst properties of all three and add one none of them have: autonomous, context-dependent decision-making. An agent's action sequence is not fully predictable at provisioning time the way a batch job's is. It may call new tools, chain requests across systems, or alter its own behavior based on the content it processes — including content supplied by untrusted third parties. That means agent governance cannot rely purely on scope definition at issuance, the way service-account governance historically has. It requires the same cryptographic rigor NIST SP 800-207 calls for, applied continuously rather than checked once, because the thing being authorized is not just "this workload" but "this workload's judgment in the moment."

Attack Techniques Targeting Non-Human Identities

The threat models used to secure human accounts translate poorly to agents. Attackers targeting NHIs favor three techniques in particular, and each defeats a specific traditional Identity and Access Management assumption.

Token and Credential Theft

Long-lived API keys and static bearer tokens remain the most common entry point, precisely because they are frequently embedded in code, logged in plaintext, or cached beyond their useful life. Once exfiltrated, a static credential grants an attacker everything the original agent could do, with no cryptographic proof distinguishing legitimate use from theft. This is the core argument for short-lived, non-repudiable credentials — an mTLS-enforced X.509 certificate issued per agent, with a bounded validity window, cannot be silently reused the way a copied API key can, and its revocation is enforceable at the gateway rather than dependent on the thief's target ever rotating the secret.

Privilege Escalation via Prompt Injection

This technique is specific to AI agents and has no clean analog in service-account or IoT threat models. An attacker embeds instructions in content the agent is expected to process — a document, an email, a webpage, a tool response — attempting to redirect the agent's actions beyond its intended scope using the agent's own legitimate credentials. Because the resulting requests originate from a valid, authenticated identity, signature-based and network-layer defenses see nothing anomalous. The only reliable detection surface is behavioral: an agent that suddenly requests data outside its historical access pattern, or invokes tools it has never called before, is exhibiting a risk signal independent of whether its credential is valid. This is precisely the gap that real-time behavioral scoring is built to close, and why identity alone — however cryptographically strong — is an insufficient control for agentic systems.

Lateral Movement Between Agents

Multi-agent systems increasingly delegate tasks to one another, and each delegation is an implicit trust decision. Without explicit scope policies and lineage tracking, a compromised low-privilege agent can use inter-agent calls to reach a higher-privilege one, effectively laundering its access through a chain of legitimate-looking requests. Defending against this requires that every delegated action carry verifiable lineage back to its originating identity — not just "agent B made this request" but "agent B made this request on behalf of agent A, which was itself authorized for this class of action." An append-only audit trail that a database trigger prevents from being altered or deleted after the fact is what makes that lineage forensically reliable rather than merely asserted.

Building an NHI Inventory and Ownership Model

A registry of agent identities is necessary but not sufficient. The recurring failure mode in enterprises that build an inventory is that it answers "what exists" without answering "who is accountable for it," and an identity with no accountable owner tends to outlive its purpose, retain excess scope, and go unreviewed indefinitely.

An effective ownership model assigns, at minimum, four attributes to every agent identity at creation time, and treats the absence of any one of them as a provisioning failure rather than an acceptable gap:

• A named accountable owner (a person or a team, not a project name) responsible for the agent's continued business justification
• A declared purpose and scope statement specific enough that a deviation from it is detectable, not a generic description that could apply to any workload
• A defined review cadence and expiration — even automated, continuously-scored credentials benefit from a scheduled human check on whether the agent should still exist at all
• A decommissioning path that is tested, not assumed — the ability to revoke the identity and confirm the revocation propagated, rather than discovering during an incident that the credential still works

NHI Governance Maturity as an Underwriting and Procurement Signal

As NHIs have come to outnumber human identities by roughly 45 to 1 across the enterprises tracked in CyberArk's 2025 report, insurers and enterprise procurement teams have started treating machine-identity governance as a distinct underwriting and due-diligence line item, separate from general access control questions.

Cyber insurance applications increasingly ask whether non-human credentials are inventoried, whether they expire automatically, and whether revocation can be demonstrated within a defined time window — questions that map directly onto the maturity stages above, and that an ad hoc or even a managed-stage organization typically cannot answer with evidence rather than assertion. Vendor security questionnaires from regulated counterparties, particularly in financial services, are following the same pattern: a growing share now ask explicitly how a vendor's autonomous or automated systems authenticate, whether that authentication is cryptographically non-repudiable, and whether the vendor can produce a tamper-evident record of an agent's actions on request.

This shift is a direct consequence of the same regulatory pressure driving MiCA and EU AI Act compliance obligations: auditors, insurers, and counterparties are converging on the same underlying question, which is whether an organization can prove — not merely claim — what its autonomous systems did and that unauthorized ones were stopped in time. Organizations that can produce a governance-stage answer, backed by a real inventory, real ownership, and a real revocation SLA, are increasingly the ones that clear underwriting and procurement review without extended remediation cycles. Kakunin customers can review their own agent fleet against this maturity model through the platform's compliance dashboard, and evaluate current identity posture with an /assessment.