Just-in-time workload access exposes the limits of standing privilege

At a glance

What this is: This is an analysis of just-in-time access for workloads, showing how ephemeral credentials, attestation, and policy-based issuance replace standing secrets and reduce persistent exposure.

Why it matters: It matters because IAM, PAM, and NHI programmes still fail when machine credentials outlive the task, and practitioners need controls that can govern access at runtime instead of at provisioning.

By the numbers:

• GitGuardian found that 64% of secrets confirmed valid in 2022 were still active and exploitable four years later.
• Attackers begin probing exposed AWS credentials in under 17 minutes on average.

👉 Read Aembit's analysis of just-in-time workload access and standing privilege

Context

Just-in-time access for workloads is a governance model for machine identities that issues temporary credentials only when a task needs them. The article argues that standing API keys, tokens, and passwords create persistent access paths that remain exploitable long after the original issuance event.

The primary identity issue is not convenience, it is trust duration. Once a workload identity is tied to static secrets, the programme assumes access can be safely pre-provisioned and later rotated, but modern cloud and CI/CD environments create far shorter decision windows than those controls were designed to handle.

Key questions

Q: How should security teams phase out standing workload credentials?

A: Begin with the highest-risk workloads first, especially databases, external APIs, and CI/CD pipelines that currently depend on long-lived secrets. Replace local storage with runtime credential issuance, and use shadow mode to compare JIT policy decisions against the old access model before enforcing them in production.

Q: Why do standing NHI credentials remain such a high-risk pattern?

A: Because they create a persistent backdoor that can stay valid long after the workload or secret should no longer be trusted. A leaked credential can be reused across systems, which turns one exposure into durable access until rotation finally succeeds.

Q: What breaks when workload access is still governed like human access?

A: Human-style review cycles are too slow for machine speed. Workload credentials can be issued, copied, and abused within minutes, so certification and manual revocation often arrive after the access has already been used.

Q: Who is accountable when a workload secret remains active after compromise?

A: The accountable teams are the owners of secret issuance, runtime policy, and revocation workflows, because JIT access only works when identity, policy, and delivery are governed together. The control failure is not just exposure, it is allowing access to persist beyond its intended task.

Technical breakdown

How workload attestation replaces password-based trust

Workload attestation is the cryptographic proof that a machine or service is running where it claims to be running. Instead of relying on a password or long-lived secret, the access broker checks evidence such as a cloud instance identity document or a Kubernetes service account token, then decides whether the workload is trustworthy enough to receive a short-lived credential. This is not MFA for machines. It is a different trust primitive designed for non-human identities that can be instantiated, destroyed, and recreated faster than a human can review them.

Practical implication: treat attestation as the trust anchor for workload access and remove any workflow that depends on static shared secrets as the primary proof of identity.

Policy evaluation for ephemeral workload credentials

A policy engine turns identity into an access decision at runtime. It does not just verify who the workload is, but whether the context is acceptable right now, including posture, environment, and time-bound conditions. That matters because a valid workload identity is not enough if the runtime environment is compromised or out of policy. In a JIT model, the broker issues a token only after policy evaluation succeeds, and the token scope is intentionally narrow so the workload can complete one task and then lose access automatically.

Practical implication: define policy conditions around environment and posture, then test them in shadow mode before allowing them to gate production credentials.

Ephemeral token delivery and secretless execution

Ephemeral delivery changes the operational model from distributing secrets to brokering temporary access. Sidecars, agents, or extensions inject short-lived tokens into the workload at runtime, which means the application does not need to store credentials locally. When a target still depends on a long-lived secret, a broker can retrieve it at runtime without exposing it directly to the workload. The architectural value is not just rotation. It is removing the secret from places where it can be copied, replayed, or left behind in logs, images, and repositories.

Practical implication: prioritise secretless execution for high-value workloads first, then broker any remaining legacy secrets only through controlled runtime injection.

Threat narrative

Attacker objective: The attacker wants durable, repeatable access to workload-connected systems by abusing secrets that were never meant to expire quickly enough.

1. Entry occurs when exposed API keys, tokens, or passwords are discovered in repositories, images, or config files and provide standing access to workloads.
2. Credential abuse follows because the leaked secret remains valid long enough for an attacker to reuse it across systems without needing further compromise.
3. Impact is persistent access to databases, APIs, or production services until manual rotation finally breaks the backdoor.

Breaches seen in the wild

• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.
• Google Firebase misconfiguration breach — Firebase misconfigurations exposed 19.8M secrets across developer instances.

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

NHI Mgmt Group analysis

Standing credential trust is the real failure mode, not secret rotation alone. The article shows why machine credentials create a durable attack surface when access survives beyond the task that created it. Once a key becomes an always-on identity proof, every downstream control depends on perfect detection and revocation timing. That is the wrong operating assumption for NHI governance, and practitioners should treat exposure duration as the primary risk variable.

Ephemeral credential trust debt: The article points to a structural problem where organisations keep reissuing secrets instead of removing the need for them. That debt accumulates in code, images, pipelines, and incident response playbooks because the programme still assumes secrets can be safely stored and later cleaned up. The practical conclusion is that the security model inherits risk from every place a secret can be copied, not just from where it was first issued.

JIT for workloads is a zero-trust control pattern, not an access convenience feature. The model matters because it shifts authorisation from preprovisioned access to runtime decisioning, which is where non-human identities actually operate. This aligns most closely with OWASP NHI and zero-trust thinking, because workload identity should be validated at the moment of use rather than trusted indefinitely. Teams that keep treating machine access as a provisioning problem will keep missing the actual control point.

Runtime credential brokerage is the governance bridge between legacy applications and secretless design. The article makes clear that many environments cannot eliminate long-lived secrets overnight, so the broker becomes the control plane for access mediation. That does not solve the trust problem by itself, but it does contain it inside an auditable, policy-driven path. Practitioners should see this as a transitional governance model, not a destination.

Access review processes do not solve machine identity risk when the credential outlives the review cycle. The review model was designed for access that persists long enough to be observed, certified, and revoked. Workload credentials are often consumed, copied, and abused far faster than that process can act. The implication is that NHI governance must move from retrospective certification to runtime control, because the old governance window is too slow for machine speed.

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.
• DeepSeek alone generated 113,000 new exposed API keys in 2025, showing how AI ecosystems can expand credential exposure before guardrails catch up.
• The secret-sprawl pattern is documented in the Guide to the Secret Sprawl Challenge, which helps teams map where exposure starts and how governance should follow it forward.

What this signals

Ephemeral access will keep moving from optimisation to baseline control. As workload identity becomes more automated, programmes that still rely on static secret inventories will spend more time chasing exposure than preventing it. The governance shift is from storing credentials safely to eliminating the need to store them at all, and that changes how IAM, PAM, and DevOps teams divide ownership.

With 24,008 unique secrets exposed in MCP configuration files in 2025 alone, the surrounding toolchain is now part of the identity perimeter, not just the application stack. Teams should expect runtime credential brokerage, attestation, and policy evaluation to become standard design requirements wherever machine identities touch tools, data, or agents.

Standing privilege is becoming an identity blast-radius problem. Once a credential can be copied into code, images, or pipelines, the number of places it can persist multiplies quickly. That makes secretless design and runtime mediation the practical controls to watch, especially in environments that cannot complete a full secret inventory before the next deployment cycle.

For practitioners

• Inventory high-value standing credentials first Start with database connections, external API integrations, and CI/CD pipelines that currently rely on long-lived secrets. Replace the highest-risk paths before expanding to lower-value workloads, and track where hardcoded secrets still live in code, images, and config files.
• Use attestation as the access gate Require cryptographic proof from the workload environment before issuing any token. Use cloud identity documents or Kubernetes service account tokens as the trust input, not a shared password or copied secret.
• Run policy changes in shadow mode Compare new JIT decisions against your current access model before enforcement. This lets you validate posture, environment, and time-based rules without breaking production access paths.
• Broker the remaining legacy secrets at runtime Where you cannot remove a long-lived secret immediately, inject it only through a controlled broker or sidecar at execution time. Prevent local storage in applications so the secret does not persist in memory, logs, or repositories.
• Measure secret reduction and policy compliance together Track how many static secrets have been eliminated, how consistently runtime decisions match policy, and how much manual rotation effort has been removed. Use those measures to identify where standing privilege still remains.

Key takeaways

• Standing workload credentials create durable exposure because they outlive the task that uses them.
• The scale problem is already measurable, with millions of new hardcoded secrets appearing each year and many old ones still valid.
• The control shift is toward attestation, runtime policy, and secretless delivery rather than relying on rotation after exposure.

Key terms

• Just-in-time access: Just-in-time access is a credentialing model that grants access only when a workload needs it and removes it when the task is done. In practice, it replaces standing secrets with short-lived, policy-bound tokens so machine access is valid for minutes or seconds, not indefinitely.
• Workload attestation: Workload attestation is cryptographic proof that a machine or service is running in an expected environment. It gives the access system evidence to trust the runtime identity before issuing credentials, which is why it replaces passwords and MFA prompts in non-human identity flows.
• Standing privilege: Standing privilege is access that remains available after the original need has passed. For machine identities, it usually appears as a long-lived key, token, or password that can be reused, copied, or abused until someone manually rotates or revokes it.
• Ephemeral credential: An ephemeral credential is a short-lived secret or token issued for one task or session. It reduces the time an attacker has to exploit a leaked credential, but it only helps if issuance, scope, and expiration are enforced at runtime.

Deepen your knowledge

Just-in-time workload access and ephemeral credential governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are replacing standing secrets in CI/CD, cloud workloads, or service integrations, it is worth exploring.

This post draws on content published by Aembit: Just-in-time access for workloads and the problem with standing privileges. Read the original.