Agent identity at the IAM and Kubernetes layer: the 2026 control-plane decision tree for non-human identity

Bottom line. The conceptual case for non-human identity for AI agents was made at AM-029. The implementation question — which IAM control plane fits which agent topology, was deferred. The 2026 deployment landscape has clarified into four credible vendor options (Okta NHI, Microsoft Entra ID Workload Identities, Auth0, Keycloak) plus two infrastructure-native options (SPIFFE/SPIRE for Kubernetes, AWS IAM Roles Anywhere for AWS-anchored). The right-choice decision turns on three factors: existing IAM relationship, deployment topology, and the cross-platform integration burden the customer can absorb.

If you run AI agents in production for a mid-market or enterprise organisation in 2026, the question that should sit on your security and platform team’s roadmap is not whether your agents need first-class identity, they do — but which control plane carries that identity in a way that matches your existing IAM relationship and deployment topology. Most enterprises in late 2025 and early 2026 are still running agents on either over-scoped service accounts (the legacy infrastructure team’s existing pattern, extended sideways) or hardcoded API keys (the engineering team’s pragmatic shortcut). Both patterns produce the audit-substrate gaps and IAM-policy bypasses that the EchoLeak cross-agent prompt-injection case and the OWASP Agentic Top 10 (AM-043) walked.

This piece walks the six 2026 control-plane options, the deployment-topology decision tree, the audit substrate the deployment must produce regardless of vendor choice, and the procurement-defensible posture for an enterprise re-architecting its agent identity layer.

The four SaaS IAM options

Okta NHI. Okta’s Non-Human Identity product line sits within the Okta Identity Platform and extends the identity graph to cover non-human principals, service accounts, application identities, AI agent identities. The product surface includes lifecycle workflows (creation, rotation, deprovisioning), secrets management, scoped-permission models, and the audit trail Okta produces for human identities extended to NHI events. The procurement fit is enterprises already running Okta as the IAM substrate for human identity; extending to NHI is a contractual and architectural extension rather than a new vendor relationship.

The strengths are integration depth with the existing Okta surface (the same admin console, the same audit substrate, the same federation patterns) and the breadth of supported applications via Okta’s connector library. The trade-off is that Okta NHI is a SaaS-first product; deployments that want fully on-premises or fully air-gapped IAM substrates do not fit cleanly.

Microsoft Entra ID Workload Identities. Microsoft’s identity platform renamed its Service Principal model into the Workload Identities surface and extended the capabilities for non-human authentication. The integration with Azure resources, Microsoft 365 workflows, and the broader Microsoft platform is the procurement-relevant strength. The OAuth-on-behalf-of patterns that allow an agent to act on behalf of a human user with constrained permissions are particularly mature in the Entra ID surface.

The procurement fit is enterprises already running Entra ID for human identity, particularly those running Azure-anchored deployments or Microsoft 365 workflows the agent needs to integrate with. Cross-cloud deployments (agents on AWS or GCP needing Microsoft identity) work but require additional configuration.

Auth0. Auth0 (now part of Okta) sits between full enterprise IAM and developer-friendly identity-as-a-service. The Auth0 model has historically been more flexible for application-developer-driven NHI patterns, with broad SDK coverage and a more permissive integration model than Okta’s enterprise surface. For organisations running multiple SaaS products with their own identity needs, Auth0 is often the path of least resistance.

The procurement fit is mid-market organisations with developer-led IAM decisions, organisations running multiple products that each need their own identity surface, and organisations that prefer the more developer-friendly model over the enterprise-administrator model. The acquisition by Okta in 2021 means the longer-term trajectory blurs into the broader Okta surface, but the Auth0 product remains differentiated.

Keycloak. Keycloak is the open-source IAM platform maintained by Red Hat (now IBM) and the broader open-source community. The procurement fit is enterprises that need fully self-hosted IAM substrates, for compliance reasons, for cost reasons, or for sovereignty reasons. The capability surface is broad (OAuth 2.0, OIDC, SAML, identity federation, role-based access control) and the platform supports both human and non-human identity patterns.

The trade-off is operational responsibility. Keycloak deployments are the customer’s substrate to operate, scale, and maintain. The TCO is lower in licensing terms and higher in operational terms; the right-fit case is enterprises with the platform engineering capacity to absorb the operational load.

The two infrastructure-native options

SPIFFE/SPIRE. SPIFFE (Secure Production Identity Framework for Everyone) is a CNCF-incubated open standard for workload identity, with SPIRE as the reference implementation. The model is cryptographic identity issued at workload start time, with automatic rotation and cryptographic validation without round-trips to a central authority. Workloads receive an X.509 SVID (SPIFFE Verifiable Identity Document) or a JWT-SVID; the identity is bound to the workload’s runtime context (Kubernetes pod, VM, container) and is validated cryptographically.

The fit case is Kubernetes-native deployments where workloads need cryptographic identity that scales without central-authority bottlenecks. AI agents running as Kubernetes pods, particularly in multi-cluster or multi-cloud topologies, get cleaner identity primitives from SPIFFE/SPIRE than from a SaaS IAM. The standards are open, the implementation is open-source, and the integration with cloud-native infrastructure (Istio, Envoy, mTLS service meshes) is native rather than bolted-on.

The trade-off is operational complexity. SPIRE deployment is non-trivial — the SPIRE server, the SPIRE agents, the trust bundles, the workload registration entries, and the operations team needs Kubernetes-native expertise. The integration with non-Kubernetes workloads (legacy applications, non-containerised services) requires bridging through SPIRE’s federation patterns or through a complementary IAM stack.

AWS IAM Roles Anywhere. AWS IAM Roles Anywhere extends AWS IAM roles to workloads running outside AWS, using X.509 certificates as the trust anchor. A non-AWS workload presents its certificate to Roles Anywhere, receives temporary AWS credentials scoped by the role’s IAM policy, and uses those credentials to access AWS resources. The audit trail flows through CloudTrail, the same surface that records AWS-internal activity.

The fit case is AWS-anchored enterprises with hybrid deployments, agents partly inside AWS, partly outside, that need uniform IAM policies across the boundary. The right-choice case is when the customer’s identity primitives are most naturally AWS IAM roles. The wrong-choice case is non-AWS-anchored enterprises that would inherit AWS-specific IAM patterns just to use Roles Anywhere; for those, Okta or Entra ID is typically the better integration.

The decision tree

The vendor-neutral decision tree resolves on three factors.

Factor 1: existing IAM relationship. If the enterprise runs Okta for human identity, the default is Okta NHI. If it runs Entra ID, the default is Entra ID Workload Identities. If it runs Keycloak self-hosted, the default is Keycloak with the NHI patterns. The reason is integration density — extending the existing IAM relationship to cover NHI is materially less expensive than introducing a second IAM vendor.

Factor 2: deployment topology. If the AI agents run as Kubernetes pods in multi-cluster or multi-cloud topologies, SPIFFE/SPIRE produces cleaner primitives and may be preferable to the SaaS IAM extension regardless of the existing IAM relationship. If the agents run AWS-native with cross-boundary integration needs, IAM Roles Anywhere may be preferable. The deployment topology trumps the IAM relationship when the topology is sufficiently divergent from human-user-style identity.

Factor 3: cross-platform integration burden. Mixed deployments (Okta humans + Entra workloads, or Okta humans + AWS-native agents) are the hardest case. The choices are: federate between two IAM platforms (operationally complex, audit-substrate fragmentation), pick a third option (Auth0 or Keycloak) sitting between, or accept the operational cost of running two IAM stacks for different identity classes. The procurement-defensible posture is to choose explicitly rather than to drift into the third option through inattention.

The decision tree applied to common 2026 patterns:

• Okta-anchored enterprise, agents on Azure. Okta NHI for the agent identity, federation with Entra ID for Azure resource access. Operationally moderate, audit-substrate consolidated in Okta.
• Microsoft-anchored enterprise, agents on Azure or M365. Entra ID Workload Identities. Cleanest integration, audit-substrate native.
• Cloud-native enterprise, agents on Kubernetes across clouds. SPIFFE/SPIRE for workload identity, with a SaaS IAM (Okta or Entra) for human-user-driven agent invocation patterns.
• AWS-anchored enterprise, agents partly on-prem. IAM Roles Anywhere for the cross-boundary integration, with the on-prem agents authenticating via certificates issued from the customer’s PKI.
• Self-hosted-IAM-required enterprise (compliance or sovereignty). Keycloak with the NHI patterns, optionally with SPIFFE/SPIRE for the Kubernetes-native agent layer.
• Mid-market enterprise without strong existing IAM relationship. Auth0 or Keycloak depending on the operational-vs-licensing trade-off the customer prefers.

The audit substrate every option must produce

Regardless of the vendor choice, the agent identity layer must produce three audit-substrate elements that downstream compliance and incident-response workflows depend on.

Identity issuance event. When the agent’s NHI was created, by whom, with what scope, and against what business justification. The record is the starting point for any later inquiry into whether the agent’s permissions were appropriate, whether the issuance followed the customer’s IAM policy, and whether the audit trail itself is complete.

Authentication events. Every time the agent authenticated against the IAM substrate, with timestamp, method (certificate, token, OIDC flow), source (the agent’s runtime context), and the resulting session. The authentication record is what allows incident response to determine whether a compromise occurred and at what point.

Authorisation events. Every IAM policy decision the agent triggered, with the action requested, the resource targeted, the policy evaluation, and the decision (allow / deny / conditional). The authorisation record is what allows the customer to verify that the agent’s runtime behaviour matched the scoped permission model and to detect anomalous behaviour patterns.

The combination produces the audit substrate that satisfies EU AI Act Article 12 (claim AM-046) for agent identity events and that supports incident response when the agent is suspected of compromise. The substrate is the operational dependency for the agent red-team companion piece (AM-126), without identity events in the audit log, red-team findings cannot be reproduced or remediated.

What changes in procurement

Three procurement language additions are now defensible asks for AI deployments where the agent identity layer is in scope.

Vendor commitment to NHI as a first-class identity class. The IAM vendor or platform commits to treating non-human identity as a primary capability, not as a secondary surface to be retrofitted. The contractual signal is dedicated documentation, dedicated support workflows, and roadmap commitments to NHI capability development.

Audit substrate completeness. The IAM vendor produces the three audit elements above (issuance, authentication, authorisation) in formats the customer’s broader audit infrastructure can consume, with retention windows that match the customer’s compliance requirements (typically 1-7 years depending on regulatory regime).

Cross-platform integration documentation. Where the deployment topology requires cross-platform integration (Okta + Entra, SPIFFE + AWS IAM, etc.), the vendor documents the integration patterns and the audit-substrate consolidation approach. Customers should not be discovering cross-platform integration patterns at deployment time.

The procurement-defensible posture is that the agent identity layer is part of the AI deployment’s load-bearing infrastructure, not a peripheral concern. The 2024-2025 pattern of running agents on shared service accounts or hardcoded API keys is now actively retired in 2026 procurement; the replacement architecture has to be specified at contract time.

What this piece does not claim

This piece does not claim that any of the four SaaS IAM vendors is materially better than the others for general-purpose NHI. The right choice depends on the customer’s existing IAM relationship and deployment topology; the four are credible options for different fits.

This piece does not claim that SPIFFE/SPIRE is appropriate for non-Kubernetes deployments. The standard works most cleanly in Kubernetes-native topologies; deployments that mix Kubernetes with non-Kubernetes workloads typically need bridging architecture that adds operational complexity.

This piece does not claim that the audit substrate description is complete. EU AI Act Article 12, the broader compliance frameworks (NIST AI RMF, ISO 42001), and the incident-response disciplines may impose additional substrate requirements specific to the customer’s deployment. The three elements above are the minimum, not the maximum.

What changes this read

Three triggers would shift the analysis. A material vendor product release that changes the capability surface of any of the six options (Okta, Entra, Auth0, Keycloak, SPIFFE/SPIRE, AWS IAM Roles Anywhere). A regulatory development under the EU AI Act, NIST AI RMF, or ISO 42001 that imposes specific NHI requirements on AI deployments. Industry-standards convergence on cross-platform NHI federation patterns that simplify the mixed-deployment cases.

We will re-test against Okta, Microsoft Entra ID, Auth0, Keycloak, SPIFFE, and AWS IAM Roles Anywhere on or before 4 Jul 2026.

The companion reading is AM-029 the conceptual case for NHI, AM-126 agent red-teaming for the threat-model surface, AM-043 OWASP Agentic Top 10 for the broader threat catalogue, and AM-046 EU AI Act Article 12 audit substrate for the compliance integration.