Agent Identity: NHIs, SPIFFE/SPIRE, and the Blended Identity Model

Every enterprise security program is built on identity. Authentication, authorization, access control, audit trails — they all start with answering one question: who is requesting access? For decades, that question was synonymous with human users. Your identity stack managed employees, contractors, and occasionally partners. Then came Non-Human Identities (NHIs) — service accounts, API keys, machine certificates, CI/CD tokens — and the ratio shifted dramatically.

NHIs outnumber human identities by 17:1 in average enterprises according to the Veza 2026 State of Identity & Access Report, with cloud-native architectures pushing ratios beyond 100:1 according to Obsidian Security research, and as high as 500:1 in advanced cloud-native architectures [1]. The same research found that 50% of organizations experienced security breaches tied to compromised machine identities — including API keys and TLS certificates — in the past year. Industry surveys report that 72% of organizations suffered at least one certificate-related outage, and only 12% have achieved automated lifecycle management for their non-human identities [2].

Traditional human IAM — quarterly access reviews, static entitlements, manual provisioning — was never designed for this scale. It fails for standard machine identities. For AI agents, the failure is catastrophic. Agents are autonomous: they make decisions and take actions without waiting for human approval. They are dynamic: their capabilities change with each prompt, tool integration, or model update. They delegate: a single agent can spawn sub-agents or chain requests across dozens of downstream systems. And they operate at machine speed: by the time your quarterly access review catches an over-provisioned agent, the damage window is measured in months.

The identity problem for AI agents is not an incremental extension of existing NHI management. It is a qualitative shift that requires new primitives: cryptographic identity, lifecycle governance tied to agent behavior rather than calendar cycles, and a blended identity model that evaluates both the agent and its human principal in a single authorization decision.

Human identity management uses the Joiner-Mover-Leaver (JML) lifecycle: onboard when hired, adjust when roles change, offboard when they leave. Agent identity requires the same rigor — but adapted for entities that are created programmatically, evolve through capability changes rather than job transfers, and can be replicated or forked without HR involvement. The four phases below map the JML pattern to agent-specific controls. Each phase has mandatory gates. Skipping gates creates the orphaned identities, credential sprawl, and permission creep that become breach vectors [1][2].

Click any phase to expand operational details and control requirements.

SPIFFE (Secure Production Identity Framework for Everyone) is a set of open standards for assigning cryptographic identities to workloads in distributed systems. SPIRE (SPIFFE Runtime Environment) is the reference implementation. Together, they solve the fundamental identity problem for AI agents: how do you prove that this specific agent, running in this specific environment, is the agent it claims to be — without relying on static secrets? [3]

The SPIFFE architecture assigns every workload a SPIFFE ID — a URI in the format spiffe://trust-domain/path/to/workload — and issues a SPIFFE Verifiable Identity Document (SVID) to prove that identity. SVIDs are short-lived X.509 certificates or JWTs that expire and auto-rotate, eliminating the static credential problem that plagues traditional NHI management. When an agent needs to authenticate to a tool, API, or peer agent, it presents its SVID. The receiving service validates the certificate chain back to the trust domain root. No passwords, no API keys, no long-lived tokens.

SPIFFE/SPIRE was designed for microservices workload identity and is well-established in Kubernetes and cloud-native environments. Its adoption for AI agent workloads is emerging — recommended by security researchers and being incorporated into commercial identity platforms, though documented production case studies of standalone SPIFFE/SPIRE deployments specifically for agents are still limited. The migration pattern mirrors what drove microservice adoption: organizations start with static credentials, suffer a breach or outage from credential exposure, and then migrate to cryptographic identity. The difference for agents is the urgency. A compromised microservice credential typically grants access to one service. A compromised agent credential grants access to every tool, data store, and downstream system the agent can reach — which, according to the confused deputy attack pattern, may include systems the agent was never intended to access [4].

Traditional IAM answers one question at a time: “Who is this user?” or “What is this workload?” Human IAM systems (Okta, Entra ID, Ping) authenticate people. Machine identity platforms (CyberArk, HashiCorp Vault, SPIFFE/SPIRE) authenticate workloads. These two systems rarely intersect because humans and machines operate in separate contexts.

AI agents break this separation. An agent is a workload — it runs as a process, consumes compute, and authenticates to services. But it also acts on behalf of a human — the user who invoked it, the team that deployed it, the business owner who authorized its capabilities. When an agent requests access to a resource, the authorization decision must evaluate both identities simultaneously: the agent's workload identity AND the human principal's identity, at the same request, at the same time [5].

Aembit calls this pattern the Blended Identity Model — evaluating agent workload identity and human principal identity together in a single authorization decision. It answers the question traditional IAM cannot: “Is this specific user, using this specific agent, authorized to access this specific resource right now?”

The practical impact is significant. Consider an enterprise where both engineering and security teams use Claude Desktop with MCP tool integrations. Under traditional IAM, the Claude Desktop agent has a fixed set of tool permissions. Under blended identity, the same agent instance running for an engineer can access Jira and GitHub but not the vulnerability scanner, while the same agent running for a security analyst can access the vulnerability scanner but not the production deployment pipeline. The agent's effective permissions are the intersection of its own capability set and the invoking user's authorization scope.

When either identity changes context, access narrows automatically. If the engineer moves to a different team, their new role may not include Jira access — and the agent's Jira tool integration is immediately scoped out for that user. If the agent gains a new tool integration, the blended model requires that both the agent AND the user are authorized for that tool before access is granted. This is the principle of least privilege applied to composite identities [5][6].

Cryptographic identity and blended access control require an enforcement point. In enterprise agent deployments, that enforcement point is the Identity Gateway — an intermediary that sits between agents and their target systems, handling authentication, authorization, and credential injection without exposing secrets to the agent itself.

Identity Gateways like the Aembit MCP Identity Gateway and the Solo.io AgentGateway implement what is called secretless credential exchange. The agent presents its identity token (SVID, JWT, or OAuth token bound to the blended identity context). The gateway validates the token, evaluates the blended identity policy, and — if authorized — injects a just-in-time (JIT) credential for the target system. The agent never holds the credential for the downstream service. It never sees it. The credential is minted for a single request and expires immediately after [5][7].

For MCP deployments, the identity gateway covers all MCP server connections — every tool the agent can access goes through the gateway. For A2A (Agent-to-Agent) communication, a centralized gateway enforces mTLS, RBAC, DLP, and schema validation for inter-agent traffic. This solves the fundamental problem: agents should not hold secrets for the systems they interact with. The gateway holds the secrets. The agent holds only its own identity [5][7].

Identity gateways enable a containment capability that static credential management cannot: runtime policy enforcement. Because every agent request flows through the gateway, access decisions are made at the moment of execution — when the agent calls an MCP tool or triggers an API — not at deployment time. A single policy change can revoke a specific agent's access globally, across all connected systems, in real time.

This is fundamentally different from traditional credential rotation. When you rotate an API key, you invalidate the old key and issue a new one — but the agent may have cached the old key, or other agents may share the same key. When you revoke an agent's identity through the gateway, the revocation is targeted and complete. No credentials to rotate. No shared secrets to track. The agent's SVID is revoked at the trust domain level, and gateways reject subsequent requests from that identity. Propagation speed depends on architecture: active CRL pushing achieves near-real-time revocation, while TTL-based SVID expiry bounds the window to the remaining TTL. In-flight multi-step operations may complete their current step before revocation takes effect, so containment procedures must include transaction rollback and partial-state cleanup for workflows interrupted mid-execution [5].

For incident response, this capability transforms the containment phase. Instead of hunting for every API key an agent might hold, you execute a single action: suspend the agent's identity. Then trace all actions through delegation chains to identify scope of impact. Then analyze decision patterns to understand what was accessed. Then implement containment before resuming operations. The identity gateway's audit log provides the complete forensic record of every request the agent made, which user authorized each request, and which downstream systems were accessed [5][7].

The kill switch is not an emergency-only tool. Runtime policy enforcement also enables graduated response. Instead of full termination, you can narrow an agent's permissions in real time: restrict it to read-only access, block specific tool categories, or require human approval for all requests above a risk threshold. This graduated approach maintains service continuity while containing the threat, buying time for investigation without the business impact of a full shutdown.

Agent identity is not a standalone security concern. It maps directly to the major AI governance frameworks that enterprises are already implementing. The governance stack — NIST AI RMF, ISO 42001, and the EU AI Act — all include provisions that implicitly or explicitly require the identity controls described in this article. The table below maps each framework requirement to the specific identity capability that satisfies it [8][9][10].

The OWASP Agentic Security Initiative identifies identity spoofing (T9) as a distinct threat category, noting that agents without cryptographic identity are vulnerable to impersonation attacks where a malicious process claims to be a legitimate agent and inherits its permissions [4]. SPIFFE/SPIRE directly addresses this: workload attestation proves the agent's identity through environment verification, not through shared secrets that can be stolen. The BBOM complements identity by documenting what the agent is authorized to do, while the identity infrastructure proves that this is the agent authorized to do it.

Agent identity is the foundational layer that every other agentic security control depends on. You cannot enforce least-privilege without knowing what the agent is. You cannot build audit trails without knowing who triggered the agent. You cannot contain a compromised agent without the ability to revoke its identity globally. Every security capability discussed across the Secure pillar — from threat modeling to incident response to tool misuse prevention — assumes that identity is solved.

The organizations that get agent identity right will deploy autonomous systems with confidence: every agent is cryptographically verified, every action is attributable to both an agent and a human principal, every capability change triggers recertification, and every credential is just-in-time and single-use. The organizations that skip this layer will discover that an unidentified agent with static API keys and no lifecycle governance is the most dangerous Non-Human Identity in their entire enterprise.

For the governance integration, see the Agent Governance Stack for the full NIST-ISO-EU AI Act mapping. For the threat context that identity controls defend against, start with the Agentic AI Threat Landscape. For the documentation standard that complements identity, see the BBOM guide. For the protocol layer where identity gateways operate, see the MCP deep dive. Visit the Security News Center for the latest developments in NHI security.