TL;DR: Workloads, service accounts and AI agents still rely on static secrets even as machine identities outnumber humans by 82 to 1 in the average enterprise, according to CyberArk and Aembit’s analysis, leaving traditional zero trust controls unable to govern runtime access. Static credential assumptions break once agents choose resources and timing autonomously, so identity-first, ephemeral and continuous controls become the baseline.
At a glance
What this is: This analysis argues that zero trust controls built for human users do not adequately govern workloads, service accounts, CI/CD pipelines and AI agents that still rely on static secrets and autonomous runtime decisions.
Why it matters: IAM, PAM and NHI teams need to treat workload identity as a runtime governance problem because access now spans ephemeral credentials, federation and agent-driven decision paths.
By the numbers:
- Machine identities outnumber human identities by 82 to 1 in the average enterprise, according to Aembit’s cited CyberArk research.
Context
Zero trust for human access is now familiar, but the same model often breaks down for non-human identities. Workloads, service accounts, CI/CD pipelines and AI agents still depend on static secrets even though they execute outside human sign-in flows and across cloud, SaaS and on-premises boundaries.
The governance gap is not only credential lifetime. AI agents can decide which resources to access and when, which means least privilege cannot be fixed entirely at provisioning time. That makes runtime identity, policy and conditional access central to NHI governance rather than an advanced option.
Key questions
Q: How should security teams govern workload access when static secrets are still in use?
A: Start by treating static secrets as transitional, not acceptable end-state controls. Map where service accounts, CI/CD jobs and workloads still depend on stored credentials, then move those paths to runtime identity and scoped issuance. The key decision is whether the credential can be verified and revoked per request rather than protected only by rotation.
Q: Why do static NHI credentials increase third-party breach impact?
A: Static NHI credentials increase third-party breach impact because they persist beyond the moment of use. If a token or service account secret is copied into a report or repository, the attacker can replay it later and potentially pivot into connected systems. The longer the credential lives, the larger the downstream blast radius becomes.
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: What should teams do when an AI agent can choose resources and timing on its own?
A: Move governance from pre-approved access bundles to request-by-request evaluation. Autonomous behaviour means least privilege cannot be assumed safe at deployment time because the agent may discover new paths during execution. Teams should constrain runtime access, re-evaluate context continuously and avoid granting broad standing permissions.
Technical breakdown
Why static secrets fail for workload identity
Static API keys, service account passwords and long-lived tokens prove possession of a secret, not the real identity of the workload presenting it. That model works poorly once credentials are copied into config files, environment variables or CI/CD systems, because any process that finds the secret can use it. In zero trust terms, the control point is too early and too brittle. Runtime identity needs cryptographic proof tied to the execution environment, such as attestation or signed tokens, so access can be evaluated per request instead of per deployment.
Practical implication: Treat stored secrets as evidence of legacy access design, not a sufficient authentication model for workloads or agents.
How policy enforcement works across trust boundaries
Zero trust for workloads depends on a policy engine, a policy administrator and a policy enforcement point working together at the resource boundary. The engine evaluates identity, posture and context, the administrator issues or denies access, and enforcement happens where the request meets the target system. This matters because network controls cannot reliably decide whether a specific workload should reach a specific API, database or SaaS service. The policy has to scope access by workload, resource and time window across clouds and platforms.
Practical implication: Move access decisions to the request boundary instead of relying on subnet rules or static IAM role bindings.
Why ephemeral credentials change the attack window
Ephemeral credentials reduce the value of interception because the credential expires before an attacker can reuse it. Instead of storing a reusable key and rotating it later, the system issues a short-lived, scoped credential only when a workload or agent needs it. That removes the bootstrap secret in mature designs and shrinks the dwell time created by leaked tokens. For AI agents, the benefit is even clearer because the credential can be issued for one task and one context, then disappear before a second path opens.
Practical implication: Design for short-lived issuance and immediate expiry so a stolen credential cannot become standing access.
Threat narrative
Attacker objective: The attacker aims to reuse machine credentials to reach sensitive systems with the legitimacy of a trusted workload or service account.
- Entry occurs through static API keys, long-lived tokens or hardcoded secrets stored in code, config files or CI/CD systems.
- Privilege use follows once the stolen secret authenticates as the workload or service account without proving the runtime context.
- Escalation happens when overpermissioned access lets the identity reach APIs, databases or third-party services beyond the intended task.
- Impact is persistent access and extended dwell time because the credential remains valid long after discovery.
Breaches seen in the wild
- 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
Zero trust for workloads fails when identity is reduced to secret possession. The article shows that workloads and agents are still authenticated with API keys, service account passwords and certificates that only prove someone stored a credential. That assumption was designed for static machine access, not for runtime-executing identities that can be copied, reused or intercepted. The implication is that workload identity has to be governed as a live proof problem, not a storage problem.
Runtime identity is now the control plane for non-human access. Once workloads span cloud, SaaS and on-premises environments, network segmentation cannot tell a legitimate request from an inappropriate one. NIST SP 800-207 is relevant here because access must be evaluated at the policy boundary, not inferred from network location. Practitioners should read this as a shift from perimeter control to per-request authorization.
Ephemeral credential trust debt is the hidden liability in modern NHI programmes. Every long-lived secret copied into code, pipelines or vaults creates future exposure even when rotation exists on paper. The article’s 82 to 1 ratio underscores that the scale of machine identity now overwhelms human-centric governance assumptions. The practitioner conclusion is simple: the lifecycle of the credential, not just the identity, is the unit of control.
AI agents collapse least-privilege assumptions at provisioning time. Least privilege is usually defined before execution begins, but autonomous agents choose resources and timing during runtime. That means access scope can drift after approval and before human review. NIST’s AI governance concept that agents must be known, trusted and properly governed reinforces that agent behaviour changes the governance problem itself, not just the volume of identities.
Conditional access must become state-aware for machine execution. A workload or agent that is trusted at session start can become unsafe if its posture, environment or request pattern changes mid-task. The important governance shift is that access review cadence alone cannot keep pace with machine-timed decisions. Practitioners need to think in terms of continuous evaluation, not periodic certification, if they want zero trust to hold for NHIs and AI agents.
From our research library:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
- 69% of organisations still authenticate machine identities with long-lived API keys, according to the 2026 State of AI Agent Identity Security Report.
- Read next: Agentic AI Identity Guide
What this signals
Ephemeral credential trust debt: the real problem is not whether credentials rotate, but whether they still exist as reusable objects after the session that needed them has ended. When secrets linger in code, CI/CD or environment variables, every copy becomes future exposure that zero trust never fully removes.
Access review cadences were built for identities that persist long enough to be certified. Workloads and AI agents that acquire and release access inside a task leave little stable evidence for post-hoc governance, so issuance-time controls matter more than periodic review.
Conditional access has to become state-aware across posture, timing and execution context. A request that is valid at start may no longer be valid after the workload changes state, especially when an AI agent is making runtime decisions across multiple trust boundaries.
For practitioners
- Verify workload identity at runtime Use attestation, signed tokens or platform-issued identity so the workload proves who it is on each request instead of relying on a stored bootstrap secret.
- Replace static credentials with ephemeral issuance Scope access to a single task or session and expire the credential immediately after use so intercepted secrets cannot be reused.
- Enforce policy at the resource boundary Evaluate identity, posture and context before every access grant across cloud, SaaS and on-premises targets instead of trusting network location.
- Continuously evaluate AI agent access Treat autonomous agent requests as dynamic and recheck posture, scope and timing throughout the task because initial approval does not predict later behaviour.
Key takeaways
- Workload and agent access still leans on static secrets, which means the security model often trusts stored credentials more than runtime identity.
- The scale problem is real: machine identities outnumber human identities by 82 to 1 in the average enterprise.
- Zero trust for non-human access depends on verified identity, ephemeral credentials and continuous policy evaluation at the point of use.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centres on static secrets used to authenticate workloads and agents. |
| NHI-07 — Long-Lived Secrets | Long-lived API keys and tokens are the main exposure described in the article. | |
| NHI-05 — Overprivileged NHI | The article warns that static bindings often grant more access than a task requires. | |
| Recommendation — Replace secret-based authentication with runtime-verifiable workload identity. Eliminate long-lived workload secrets and scope credentials to task duration. Reduce standing permissions so each workload can reach only its intended resources. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article focuses on governing entitlements and authorization for non-human access. |
| Recommendation — Apply PR.AA-05 to continuously scope and review workload and agent authorizations. | ||
| NIST Zero Trust (SP 800-207) | Policy Engine — Policy Engine | The article’s core model is request-time policy evaluation across trust boundaries. |
| Recommendation — Evaluate every workload request through a policy engine before issuing access. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Stolen secrets and over-scoped access are the compromise path discussed here. |
| Recommendation — Map exposed machine credentials to credential access and lateral movement detection. | ||
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.
- Ephemeral Credentials: Ephemeral credentials are short-lived access artefacts issued for a limited task or session. They reduce the window for abuse, but they only improve security when paired with strong scope limits, telemetry, and automatic revocation at task completion.
- Conditional Access: Conditional access is a policy model that decides whether an action should proceed based on context such as posture, resource sensitivity, timing, and scope. For AI agents, it must be evaluated at request time so a valid credential does not automatically equal permitted behaviour.
- Runtime Attestation: Runtime attestation is a control that cryptographically proves a request came from the expected system or workload. It adds evidence to machine-to-machine access decisions, which is especially valuable when bearer tokens alone cannot distinguish a real integration from an attacker replaying credentials.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 6, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org