Workload identity is becoming the control plane for AI agents

At a glance

What this is: This analysis argues that workload identity is becoming the practical control plane for AI agents and other non-human identities, with SPIFFE and SPIRE used as the connective tissue for short-lived, attestable access.

Why it matters: IAM and NHI teams need to treat agent identity, workload attribution and secret handling as one governance problem because autonomous systems now cross trust boundaries at machine speed.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 69% of organisations now have more machine identities than human ones.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• 72% of identity professionals find machine identities more challenging to manage than human identities, citing poor internal processes and insufficient tooling.

👉 Read GitGuardian's analysis of workload identity, SPIFFE and AI agents

Context

Workload identity is the layer that proves a service, job, agent or API caller is what it claims to be before it receives access. The gap is that most enterprise controls still assume human-centric authentication, while non-human identities multiply across cloud, CI/CD and AI systems faster than governance can keep up.

That mismatch matters because a single compromised NHI credential can create a large and often invisible blast radius. For IAM and NHI practitioners, the real problem is not only secret sprawl, but also attribution, authorization and lifecycle control when autonomous agents act on behalf of users and systems.

Key questions

Q: How should security teams govern AI agents that can act across multiple systems?

A: Treat each AI agent as a non-human identity with explicit scope, bounded permissions and clear delegation records. Require attested identity before tool access, log both the initiating user and the workload that executed the action, and block sensitive operations unless policy approves them. The goal is not just access control. It is preserving accountability when autonomous software crosses trust boundaries.

Q: What is the difference between workload identity and secret rotation?

A: Workload identity proves what the workload is, while secret rotation only changes the credential it uses. Rotation can reduce exposure time, but it does not solve attribution, overprivilege or cross-domain trust. Organisations need both, yet workload identity is the stronger control because it ties access to an attested machine identity rather than a reusable secret.

Q: Why do AI agents complicate zero trust architecture?

A: AI agents complicate zero trust because they are dynamic, distributed and often delegated to act on behalf of users or systems. Zero trust still applies, but the organisation must verify both the agent’s identity and the scope of the action at runtime. That means continuous checks, short-lived access and logging that can reconstruct intent after the fact.

Q: When does JIT access create less risk than standing privilege?

A: JIT access reduces risk when the organisation can reliably issue, scope and revoke privileges for a single task without breaking operations. It is less effective if the approval path is manual, if revocation is slow or if the workload can keep tokens beyond their intended use. JIT works best when paired with attestation and strong audit trails.

Technical breakdown

Why long-lived workload credentials keep failing

Most legacy workload authentication still depends on static API keys, shared secrets or certificates that persist far longer than the workload itself. That design creates standing privilege, weak attribution and a large attack surface when credentials leak into code, logs or CI systems. In multi-cloud and hybrid environments, teams often bolt together custom patterns instead of using one identity fabric, which makes policy drift inevitable. The problem is not simply secret storage. It is that the credential model does not match the speed, scale or transience of modern workloads.

Practical implication: Replace durable credentials with short-lived, workload-bound identity and enforce rotation, revocation and audit as default controls.

How SPIFFE and SPIRE change workload trust

SPIFFE defines a portable identity format for workloads, while SPIRE provides the runtime that issues and validates those identities. In practice, the model uses attestation to prove workload properties, then issues a short-lived SVID that can be exchanged for scoped credentials. That reduces dependence on long-lived secrets and helps separate authentication from authorisation. The architectural shift is important because it lets different platforms share a common trust fabric without forcing each team to build bespoke identity logic. The governance win is consistency, not just convenience.

Practical implication: Use SPIFFE and SPIRE to standardise identity proof, then layer policy and logging on top of the same trust fabric.

Why AI agents intensify the workload identity problem

AI agents are not a new category of user. They are workloads with execution authority, tool access and the ability to chain actions across systems. That makes agent identity harder than ordinary service authentication because the system must track both who triggered the action and what the agent was allowed to do. When agents hop across providers, the main challenge becomes delegation with clear scope and explicit intent, not just login. Without that, teams lose both accountability and containment when something goes wrong.

Practical implication: Treat every agent as a non-human identity with bounded permissions, clear delegation records and explicit approval paths for sensitive actions.

Threat narrative

Attacker objective: The attacker aims to turn one stolen non-human credential into broad, hard-to-detect access across workloads and cloud services.

1. Entry occurs when a long-lived API key, plaintext secret or overprivileged service account is exposed in code, logs or a CI workflow.
2. Escalation follows when the credential can access multiple systems or trust domains without narrow scoping, giving the attacker a large invisible foothold.
3. Impact is achieved when the compromised NHI is used to move laterally, call tools or exfiltrate data while appearing like legitimate automation.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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 now the operating model for non-human governance. The article’s strongest signal is that identity, access and attribution can no longer be separated when software acts autonomously. NHI governance is moving from inventory management to runtime control, where every workload needs a verifiable identity and a defensible permission boundary. Practitioners should expect workload identity to become the default control layer for AI-enabled systems.

Ephemeral credentials do not solve trust debt on their own. Short-lived tokens reduce exposure time, but they do not remove the need to prove workload origin, constrain scope or track delegation. If the underlying trust model still depends on ad hoc approvals or manually managed secrets, the organisation simply inherits a faster version of the same risk. The practitioner conclusion is to pair rotation with attestation and policy.

Identity blast radius is the right way to think about NHI risk. A single compromised NHI can now span cloud providers, APIs and agentic workflows before defenders notice. That changes the governance question from 'How many secrets do we have?' to 'How far can one credential travel?' Teams should design for containment first, because containment defines survivability.

Clean attribution will become a security requirement, not a logging nicety. When agents act on behalf of users, the organisation must preserve who initiated the action, which workload executed it and what policy allowed it. Without that chain, incident response and audit become guesswork. Practitioners should treat attribution as part of access control, not as an after-the-fact reporting task.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• Our research also shows that 73% of vaults are misconfigured, which helps explain why secret handling remains a structural control problem rather than an isolated hygiene issue.
• For a deeper operational view, see the Guide to SPIFFE and SPIRE, which explains how workload attestation and portable identity can replace brittle trust assumptions.

What this signals

Identity blast radius will become a board-level metric for NHI programmes. When one credential can authorize actions across cloud services and AI workflows, the question is not merely whether secrets are rotated, but how far a compromised identity can travel before containment kicks in.

With 69% of organisations already running more machine identities than human ones, according to the Critical Gaps in Machine Identity Management report, scaling governance by manual review is no longer credible. Practitioners need policy automation, attestation and ownership mapping that survive organisational sprawl.

The next programme constraint is attribution. Teams that cannot tie user intent to workload execution will struggle to investigate agent-driven actions, enforce least privilege or satisfy audit requirements. Aligning NHI controls to standards such as the OWASP Non-Human Identity Top 10 gives that work a practical baseline.

For practitioners

• Inventory every non-human identity Build a current inventory of service accounts, API keys, workload identities and AI agents across cloud, CI/CD and internal platforms. Prioritise the identities with standing access, cross-domain privileges and unclear ownership, then review them on a recurring schedule.
• Replace static secrets with short-lived identity Use attested workload identity and credential exchange patterns instead of long-lived API keys in code, config files and pipelines. Where rotation remains necessary, make it automatic and pair it with revocation checks so expired credentials cannot linger.
• Scope agent permissions by task and context Define what each AI agent is allowed to do, on whose behalf, and under which approval conditions. Enforce least privilege at the tool and data layer, and require logging that preserves both user intent and workload identity.
• Centralise policy and logging for workload access Standardise policy enforcement across environments so identity proof, credential issuance and audit data follow the workload. Use a single control pattern where possible, because bespoke per-team implementations make governance and incident response harder.

Key takeaways

• Workload identity is becoming the core governance layer for non-human systems, because static secrets cannot safely represent modern software behaviour.
• The scale problem is already operational, not theoretical, since compromised NHIs create broad blast radius and often evade detection for long periods.
• Practitioners should pair attested identity, short-lived credentials and clean attribution before agentic AI expands the control gap further.

Key terms

• Workload Identity: A workload identity is the machine-facing proof that a service, job or agent is allowed to act. It replaces reliance on shared secrets with a verifiable identity that can be attested, scoped and revoked. For NHI governance, it is the foundation for least privilege at runtime.
• Non-Human Identity: A non-human identity is any digital identity used by software rather than a person, including service accounts, API keys, certificates, tokens and AI agents. These identities often outnumber human users and can create broad risk when ownership, rotation and scope are poorly controlled.
• Identity Blast Radius: Identity blast radius is the amount of systems, data and workflows that a single compromised credential or identity can reach. It is a practical way to measure the impact of overprivileged NHIs, because the issue is not just whether access exists, but how far it can spread.
• SPIFFE Attestation: SPIFFE attestation is the process of proving that a workload is the one it claims to be before it receives identity. It binds runtime trust to concrete workload properties, helping organisations issue short-lived identities instead of reusable secrets that are hard to govern at scale.

What's in the full article

GitGuardian's full post covers the operational detail this analysis intentionally leaves for the source:

• Conference examples of how Uber, Block and AWS are applying SPIFFE and SPIRE in production.
• The speakers' specific view of how AI agents should carry SVID-based identity across cloud providers.
• Implementation lessons on x509 issuance, token exchange and workload attestation at scale.
• The article's broader commentary on where teams are moving beyond API keys and spreadsheet governance.

👉 GitGuardian's full post expands on the talks, implementation patterns and operational lessons from Workload Identity Day Zero.

Deepen your knowledge

Workload identity, secret rotation and NHI lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is replacing ad hoc secrets with attestable identity, it is a practical place to build the programme foundation.