Zero trust for workloads and AI agents needs new controls

At a glance

What this is: This primer explains why zero trust must extend beyond human users to workloads, service accounts and AI agents, with verified identity, policy enforcement, ephemeral credentials and continuous conditional access as the four required controls.

Why it matters: IAM and security teams need a single governance model that covers human, machine and agentic access, because the same static credential patterns now create risk across all three identity classes.

By the numbers:

• Machine identities outnumber human identities by 82 to 1 in the average enterprise.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.

👉 Read Aembit's analysis of zero trust for workloads and AI agents

Context

Zero trust for workloads is the extension of identity-first security to non-human actors such as service accounts, CI/CD pipelines and AI agents. The gap is not theory. Most organisations still let these identities authenticate with static API keys, long-lived tokens or hardcoded secrets, which means access is tied to possession of a secret rather than verified runtime identity.

That model fails more sharply as agentic systems enter production. When a workload or AI agent can decide which resources to access and when, static provisioning no longer describes actual behaviour, and network controls cannot reliably constrain access at the point of use. The central question for IAM programmes is no longer whether zero trust applies to machines, but whether current controls can evaluate machine behaviour continuously enough to matter.

Key questions

Q: How should security teams implement zero trust for workloads and AI agents?

A: Start by giving each workload or agent a verifiable runtime identity, then enforce request-level policy and issue short-lived credentials only after the identity and context checks pass. The practical goal is to remove standing secrets and make access decisions at the point of use, not at deployment time.

Q: Why do static secrets create more risk for non-human identities than for human users?

A: Static secrets are copied easily, persist across environments and often outlive the workload that first used them. For service accounts, pipelines and agents, that persistence turns a single compromise into repeated access, especially when leaked credentials remain valid for long periods.

Q: What breaks when network controls are used instead of request-level policy for machine access?

A: Network controls can tell you where traffic can flow, but they cannot decide whether a specific workload should call a specific API at a specific moment. That leaves overpermissioned identities, lateral movement and posture drift outside the control boundary.

Q: What should teams do when workload posture changes during an active session?

A: Re-evaluate access continuously and be prepared to reduce or revoke it before the session completes if the environment becomes untrusted or the workload starts operating outside scope. Continuous conditional access is what keeps runtime trust aligned with actual behaviour.

Technical breakdown

Runtime identity verification for workloads

Workloads do not prove identity the way human users do. They typically authenticate through a secret, which only proves possession, not provenance. Zero trust for workloads replaces that model with runtime attestation, where the platform vouches for the workload using cryptographic evidence tied to its execution environment. Kubernetes service account tokens, cloud instance metadata signatures and OIDC-issued identity tokens are examples of this pattern. The key technical shift is that identity is validated at request time, not assumed from a stored credential. For cross-cloud and SaaS access, identity federation bridges trust boundaries by exchanging one signed identity for another.

Practical implication: replace shared secrets with attested workload identities that can be verified at request time, especially across cloud and SaaS boundaries.

Policy enforcement at the resource boundary

Zero trust depends on a policy engine making an access decision for each request, then enforcing it where the resource is reached. For human access, that logic often sits in SSO and identity-aware proxies. For workloads, many teams still rely on static role bindings or network segmentation, which cannot evaluate the sensitivity of the specific API call or the workload's current posture. Application-layer enforcement is the more precise model because it can combine identity, resource sensitivity and environmental context before granting access. Least privilege becomes operational only when the decision is scoped to the workload, the resource and the moment of access.

Practical implication: move workload authorisation out of coarse network controls and into request-level policy enforcement at the application or API boundary.

Ephemeral credentials and the secret zero problem

Static credentials create a durable attack surface because they can be copied, reused and left active long after their original purpose. Ephemeral credentials invert that risk by being short-lived, narrowly scoped and issued only after identity and policy checks succeed. This removes the need for a bootstrap secret in many workflows, which is often called the secret zero problem. If an attacker intercepts an ephemeral credential, the exposure window is small. If the workload never stores the credential, rotation burden also drops because the platform handles issuance at runtime instead of relying on human-managed vault workflows.

Practical implication: issue short-lived runtime credentials for machine access and eliminate bootstrap secrets wherever the platform can support it.

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

Static credential governance was built for identities that remain stable long enough to be reviewed. That assumption fails when workloads and AI agents authenticate, act and expire through short-lived runtime sessions rather than durable human-style access cycles. The implication is that entitlement models built around long-lived secrets no longer describe the real access surface for non-human identities.

Identity does not equal control unless the request itself is governed. A verified workload identity still becomes risky if static role bindings or network rules are the only enforcement layer. This is why request-level policy at the resource boundary matters: it aligns authorisation with the specific action, not merely with the actor's existence. Practitioners should treat coarse access binding as incomplete governance, not finished zero trust.

Ephemeral credential trust debt: every long-lived key, token or certificate accumulates hidden blast radius because it can persist across repositories, pipelines and vaults long after the workload has changed. The article's data on hardcoded secrets and valid leaked credentials shows why detection alone does not close the exposure. The practitioner conclusion is simple: any programme that tolerates persistent machine credentials is carrying deferred breach exposure.

AI agents widen the zero trust problem because they introduce decision-making into access paths that were previously deterministic. Traditional controls assume the actor's purpose, timing and target set are known at deployment. Once an agent can choose resources and timing at runtime, least privilege is no longer just a smaller permission set, it is an assumption collapse around predictable intent. The implication is that governance must be based on observed behaviour, not predeclared workflows.

Continuous posture checking becomes mandatory once the actor can move across trust boundaries mid-task. A workload that begins a session in compliance may still drift into unsafe access if its environment changes or its behaviour expands beyond the original scope. NIST SP 800-207's identity, policy and enforcement model helps, but the operational lesson is broader: zero trust for machines is only credible when access can be re-evaluated as conditions change.

From our research:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to The State of Secrets Sprawl 2026.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
• For the broader access-control picture, Guide to SPIFFE and SPIRE shows how workload identity and attestation can replace secret-based trust models.

What this signals

Ephemeral credential trust debt: the longer a machine credential survives, the more likely it is to become unowned, unreviewed and still active in production. With 64% of valid secrets leaked in 2022 still exploitable today, the governance signal is clear: detection without revocation does not reduce the attack surface.

The practical change for IAM and security programmes is that workload identity can no longer sit outside the main zero trust strategy. Teams need shared controls across CI/CD, cloud workloads and AI agents so that runtime identity, policy and posture are evaluated as a single system instead of three separate programmes.

For teams building toward SPIFFE-style workload identity, the near-term signal is that attestation and short-lived issuance are becoming baseline design choices rather than architecture preferences. SPIFFE workload identity specification provides the vocabulary, but the operational test is whether access can still be explained, revoked and audited at runtime.

For practitioners

• Map every non-human identity to an owner and a runtime boundary Inventory service accounts, CI/CD identities, API keys and agent credentials together, then assign explicit ownership, scope and expiry conditions. If an identity cannot be tied to a workload, pipeline or agent session, it should not remain active.
• Replace shared secrets with attested workload identity Use platform-native attestation, federation and short-lived tokens so the workload proves provenance at request time instead of relying on stored keys in files, variables or build systems. This is especially important for cross-cloud and SaaS calls.
• Enforce request-level policy at the application boundary Move authorisation decisions closer to APIs and services so policy can consider identity, resource sensitivity and current posture before each request is allowed. Avoid treating firewall rules or subnet access as sufficient control for machine identities.
• Eliminate bootstrap secrets from pipelines and agents Remove hardcoded API keys, service account passwords and long-lived certificates from CI/CD workflows, then use ephemeral issuance at runtime. This reduces the chance that a single leaked secret becomes persistent access.
• Log and review posture changes as access events Treat host health, environment changes and anomalous access patterns as reasons to re-evaluate or revoke machine access. Conditional access should be able to terminate a session when the workload's trust context changes.

Key takeaways

• Non-human identities now represent a larger and more persistent access problem than most human IAM programmes were built to handle.
• Static secrets remain the central failure mode because leaked credentials often stay active long after discovery, turning exposure into exploitable access.
• Zero trust for workloads only works when identity, policy, ephemeral credentials and continuous posture checks operate together at request time.

Key terms

• Workload Identity: A workload identity is the verifiable digital identity assigned to a machine process, service account or agent so it can authenticate without a human user behind it. In mature environments, that identity is bound to runtime evidence, not to a reusable secret stored in code or configuration.
• Ephemeral Credential: An ephemeral credential is a short-lived access token issued for a specific request or task and then allowed to expire quickly. It reduces blast radius because compromise is temporary, and it shifts trust from stored secrets to runtime verification and policy enforcement.
• Conditional Access: Conditional access is the practice of granting or restricting access based on current identity, posture and environment signals. For non-human identities, it matters because a workload can start trusted and become risky mid-session if its host, route or behaviour changes.

Deepen your knowledge

Zero trust for workloads and AI agents is covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building identity governance for service accounts, pipelines or autonomous systems, it is worth exploring.

This post draws on content published by Aembit: Zero trust for workloads and AI agents. Read the original.