Workload identity for AI agents exposes the limits of user IAM

At a glance

What this is: This is an analysis of why workload identity for AI agents and other machine workloads cannot be governed effectively with user IAM or PAM controls designed for human sessions.

Why it matters: IAM and PAM teams need to treat AI agents, pipelines, and workloads as a separate identity class because machine-speed authentication, ephemeral runtime, and protocol diversity change the control model.

Context

Workload identity is the control problem that governs how machines, services, pipelines, and AI agents authenticate to other systems. The article argues that user IAM and PAM were designed around human login sessions, while workload identity has to operate continuously, at machine speed, and without interactive approval steps.

The governance gap appears when teams try to reuse human identity controls for workloads that spin up and disappear quickly, change target systems often, and chain multiple services in one execution path. For identity programmes, that makes workload identity and agentic AI governance a distinct operating model rather than a minor extension of existing IAM.

Key questions

Q: How should security teams govern AI and workload identities at runtime?

A: Security teams should govern runtime identities by combining least privilege, continuous telemetry, and approval-gated containment. The goal is not just to issue credentials safely, but to detect when those credentials are being used in ways that increase blast radius. Runtime governance should include scoped permissions, event correlation, and clear escalation thresholds.

Q: Why do user IAM and PAM break down for AI agents and service workloads?

A: User IAM and PAM assume human sessions, approvals, and predictable interaction patterns. Workloads and AI agents authenticate repeatedly, often without a human present, and may need access decisions that reflect runtime context rather than a static role. That makes session-first tools a poor fit for machine-speed identity governance.

Q: What breaks when workload identity is built as a homegrown project?

A: The first prototype often works, but the design usually breaks when more environments, target systems, and credential types are added. Teams then discover they need repeated policy logic, multiple delivery patterns, and unified audit evidence, which turns a small implementation into an ongoing platform commitment.

Q: How can organisations tell whether workload identity controls are actually working?

A: Look for evidence that access decisions are being enforced by policy rather than by shared secrets. If you can trace each workload-to-service request, see the context used for the decision, and revoke access without breaking unrelated systems, the controls are doing real work.

Technical breakdown

Why user IAM breaks for workload identity

User IAM assumes a person logs in, establishes a session, and then works inside a bounded interaction model. Workloads behave differently: they authenticate repeatedly, often thousands of times per day, and frequently run in ephemeral infrastructure where the credential lifecycle must match runtime, not human activity. That means password vaults, approval workflows, and session consoles do not map cleanly to the machine-to-machine problem. The article’s core point is not that these controls are broken, but that they were built for a different identity subject. Workload identity needs continuous, non-interactive authentication and policy evaluation at the access layer.

Practical implication: separate workload identity design from human IAM design and stop treating user-session controls as the default model for machine access.

Why workload identity needs proxy, SDK, and CLI patterns

The article describes three common delivery patterns for workload credentials. SDK-based integration places credential retrieval inside application code, CLI-based retrieval supports scripted and pipeline workflows, and proxy-based delivery injects credentials transparently without changing the application. Each pattern solves a different deployment constraint, which is why teams building a production-grade system often need all three. The architectural challenge is not just issuing a secret. It is doing so consistently across Kubernetes, VMs, serverless, and SaaS CI/CD environments that do not all allow the same attachment model. Coverage gaps appear when one pattern is stretched into every environment.

Practical implication: map each workload class to the credential delivery pattern it can actually support before standardising on one integration model.

Why attestation and policy are the real control layers

Before issuing a credential, a workload identity system has to verify what is calling, where it is running, and whether the request is within policy. The article points to cryptographic attestation and real-time policy evaluation as the two load-bearing layers. Attestation answers identity proof at runtime, while policy answers whether the target resource, token type, and context should be allowed. Without both, organisations fall back to bootstrap secrets, scattered logs, or per-service policy fragments that cannot reconstruct access decisions cleanly. That is why workload identity is a governance system, not just a credential broker.

Practical implication: build attestation and policy enforcement as first-class controls rather than bolting them onto the application or secrets layer.

Threat narrative

Attacker objective: The practical attacker objective in this pattern is to exploit weak workload trust boundaries or over-broad credentials to reach downstream systems without being constrained by human-session controls.

1. Entry occurs when teams bootstrap workload access with hardcoded secrets, metadata calls, or other initial trust assumptions that let the workload retrieve its own credentials.
2. Escalation happens when the same pattern is extended across more services, environments, and target systems, increasing the number of places where credentials and policy logic must be maintained.
3. Impact appears as fragmented audit trails, inconsistent least-privilege enforcement, and a credential model that no longer matches how ephemeral workloads and AI agents actually operate.

Breaches seen in the wild

• CI/CD pipeline exploitation case study: Credentials in an exposed .git/config let a researcher edit a Bitbucket pipeline so it planted their SSH key on the server. No victim was named.
• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Workload identity is not a subset of user IAM. It is a different identity discipline with different runtime assumptions, different credential lifecycles, and different audit requirements. Human IAM is built around login sessions and interactive control points, while workloads and AI agents operate continuously in ephemeral environments. Practitioners should stop framing this as a product selection problem and treat it as an identity architecture boundary.

Secret-zero bootstrapping is the weakest assumption in most homegrown workload identity designs. The article shows that teams usually solve credential retrieval by introducing a bootstrap credential, an instance metadata call, or a Kubernetes service account. That assumption is designed for environments where a trusted starting point already exists. It fails when the access path itself must prove identity before any credential is issued. The implication is that bootstrapping, not rotation, is often the earliest design flaw.

Policy fragmentation is the real scaling failure in workload identity programmes. When one environment uses one policy model and another uses a different one, least privilege becomes a local property instead of a governable control. The article shows how SDK, proxy, and CLI paths each produce different operational outcomes unless policy is centralised at the access layer. Practitioners should evaluate workload identity by policy consistency across environments, not by integration count alone.

AI agents make workload identity a governance problem, not a tooling extension. Agentic systems chain services together and make autonomous decisions about what to access next, which means access policy has to reason about behaviour as well as identity. That changes the control question from 'who authenticated' to 'what runtime path is this identity taking.' The implication is that agent access governance has to be designed around runtime context and delegated actions, not human approval workflows.

Identity blast radius is the concept teams should use to assess operational risk. A workload identity system that cannot produce unified attestation, policy evidence, and audit trails across Kubernetes, CI/CD, serverless, SaaS, and legacy systems leaves a large blast radius when access goes wrong. This is especially true when the same platform team becomes responsible for both implementation and exception handling. Practitioners should measure whether their controls compress or expand the identity blast radius across deployment types.

From our research library:

• 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
• 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
• Read next: Cloud Workload Identity Guide

What this signals

Workload identity programmes fail when teams keep treating machine access like a variation of user access. The practical shift is to govern issuance, attestation, and audit as runtime controls for services and AI agents, not as extensions of human IAM.

Identity blast radius: the size of the access surface that becomes exposed when workload credentials, policy logic, and audit evidence are split across environments. The wider that blast radius, the more likely a single compromise or misconfiguration can spread through pipelines, cloud services, and agent workflows.

Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey. That gap signals that AI agent identity governance is moving faster than programme maturity.

For practitioners

• Separate human IAM from workload identity Define workload identity as its own control domain, with separate requirements for machine authentication, policy evaluation, and audit evidence. Do not extend user-session controls as the default design pattern for services or AI agents.
• Map credential delivery by workload class Use SDK integration where application changes are acceptable, CLI patterns for scripts and CI/CD jobs, and proxy delivery where transparent injection is required. Match the delivery model to the environment instead of forcing one pattern everywhere.
• Make attestation mandatory before issuance Require cryptographic proof of workload identity before credentials are issued, and validate environment-specific claims such as platform, namespace, task, or token context. Treat bootstrap secrets as a design smell, not a permanent starting point.
• Centralise policy at the access layer Enforce the same policy model before requests reach downstream systems, so access rules do not depend on each target service’s native authorization model. This is the only way to keep least privilege consistent across mixed environments.
• Unify audit trails across environments Collect identity-centric logs that show which workload accessed which resource under what policy, and make sure those records are consistent across cloud, CI/CD, and legacy systems. Fragmented logs are not usable evidence for governance or compliance.

Key takeaways

• Workload identity is governed differently from user IAM because machine access is continuous, ephemeral, and protocol-diverse.
• Homegrown implementations usually fail at scale when credential delivery, attestation, policy, and audit have to work across many environments.
• AI agents raise the stakes because their access paths are runtime-driven, which makes issuance-time governance more important than session-based review.

Key terms

• Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.
• Cryptographic Attestation: Cryptographic attestation is a method of proving that a workload or service is genuine by using cryptographic evidence instead of static shared secrets. It is especially useful for short-lived access models because identity proof is tied to runtime context rather than reusable credentials.
• Secret Zero: Secret zero is the first credential needed to reach a secrets store, identity broker, or protected system. It is the root trust dependency that often survives even when everything else is rotated. If that initial credential is exposed, the rest of the secret model can collapse very quickly.
• Policy Enforcement Point: A policy enforcement point is the control that applies an authorization decision at the place where an action occurs. In distributed systems, it may sit inside an API gateway, application, or workflow engine, and it depends on a consistent decision format to avoid bespoke integrations.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.