Just-in-time access still depends on where trust sits

At a glance

What this is: This article argues that just-in-time access only reduces risk when temporary credentials sit inside an architecture that also removes standing privilege and limits trust in the issuer.

Why it matters: IAM, PAM, and NHI teams need to judge JIT by control of keys, policy enforcement, and lifecycle boundaries, not by expiry alone.

By the numbers:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
• 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.

👉 Read Akeyless's analysis of just-in-time access, zero-knowledge, and runtime authority

Context

Just-in-time access is a control pattern for reducing the lifetime of privileged access. In identity programmes, it replaces standing privilege with short-lived, purpose-bound credentials so that access exists only long enough for the task to be completed. The unresolved issue is not whether credentials expire, but whether the trust model behind them still concentrates too much power in the issuer or platform.

For NHI governance, the real question is where the control boundary sits when workloads, services, and AI-driven systems are the identities being authorised. If a platform can issue, hold, or reconstruct the secrets it protects, then JIT can shrink exposure without fully removing the underlying trust dependency. That makes architectural design part of identity governance, not just a vaulting detail.

Key questions

Q: Should organisations use just-in-time access for machine identities?

A: Yes, when the task is time-bound and the access can be cleanly scoped. Just-in-time access reduces standing privilege, but only if the organisation can automate approval, expiry, and revocation. It works best for administrative workflows and high-risk actions, not for every always-on service dependency.

Q: Why do standing privileges remain a problem even when credentials expire?

A: Expiry reduces the time window, but it does not remove the presence of a reusable trust relationship or the possibility that the platform can reconstruct protected material. Standing privilege is dangerous because it creates durable access paths that attackers can reuse quickly. JIT only changes the risk if it also removes persistent accounts and secret custody.

Q: What should teams evaluate before adopting a zero-knowledge JIT architecture?

A: Check whether the provider can reconstruct customer secrets, whether the customer retains exclusive control of the critical cryptographic fragment, and whether the architecture still allows the service to decrypt protected assets. If those answers are unclear, the design may be operationally convenient but not truly trust-reducing.

Q: What is the difference between JIT access and runtime authority?

A: JIT governs when credentials are issued and how long they last. Runtime authority governs what an identity can do after access has already been granted, which matters for cloud automation and AI-driven workflows. The first reduces credential exposure, while the second constrains actions during execution.

Technical breakdown

How dynamic secrets reduce credential exposure

Dynamic secrets are credentials created on demand, assigned a limited lease or TTL, and revoked automatically when the lease ends. This reduces the window in which an attacker can reuse a stolen secret, especially for databases, cloud services, and ephemeral workloads. The mechanism is effective because it removes long-lived reuse, but it does not by itself answer who controls the signing, storage, or revocation path behind the credential lifecycle. In practice, the value comes from combining issuance, policy, and expiry into one governed flow rather than treating dynamic secret generation as a standalone feature.

Practical implication: validate that expiry, revocation, and policy enforcement are bound to the same control plane.

Why zero-knowledge changes the JIT trust model

Zero-knowledge architectures aim to prevent any single service from ever holding complete key material. In the model described here, fragments of cryptographic material remain separate, and operations occur without reconstructing the full key. That matters because temporary credentials alone still leave the provider in a position of trust if it can decrypt, reconstruct, or expose the secrets those credentials protect. For identity architects, the point is that JIT can be cryptographically stronger when the platform is structurally unable to impersonate the customer’s protected assets.

Practical implication: test whether the provider can reconstruct protected material, not just whether it advertises ephemeral access.

How JIT extends to machine identities and workloads

Machine identities do not authenticate like humans. They authenticate through cloud IAM, Kubernetes identities, certificates, API keys, or enterprise identity providers, after which policy determines whether dynamic credentials should be issued. That makes JIT a workload governance pattern as much as an access pattern. The important shift is from provisioning permanent secrets to authenticating the workload first and generating access only when the task requires it. This matters across CI/CD, databases, and infrastructure automation because the lifecycle of the identity is now machine-paced, not human-paced.

Practical implication: map every workload identity to an issuance path that avoids static secret distribution.

NHI Mgmt Group analysis

JIT access only works as a trust-limiting control when the issuer cannot become the secret holder. The article’s core distinction is between short-lived credentials and architectural control of the underlying trust boundary. If the provider can reconstruct keys or retain usable secret material, the control reduces exposure but does not eliminate dependency. Practitioners should treat credential expiry and cryptographic separation as different governance problems.

Standing privilege is the real failure mode, not credential length alone. Long-lived access remains the most exploitable condition because it creates reusable trust artifacts for both attackers and insiders. A short TTL helps, but the governance value comes from removing persistent accounts, not merely shortening their lifespan. The decisive question is whether the identity ever exists in a permanently usable form.

Dynamic secrets are an NHI control, but they are not sufficient for autonomous workflows. As AI-driven infrastructure operations expand, the access question shifts from issue-and-expire to what the identity can do once access is granted. That means JIT remains necessary, but it no longer describes the full security boundary when execution can continue after authentication. Identity governance must therefore separate credential issuance from action authority.

Runtime Authority is a useful concept because it exposes the limit of credential-centric security. Once access is granted, policy has to keep governing action, not just the token. That is especially relevant for machine identities that trigger changes in cloud, CI/CD, or infrastructure systems. The practical conclusion is that identity programmes need both issuance control and post-issuance decision control.

Operational simplicity is now part of identity security design, not a separate efficiency goal. If a JIT architecture requires vault sprawl, HSM burden, or complex recovery procedures, teams often preserve standing privilege as a convenience tradeoff. That is how weak governance survives inside otherwise modern programmes. Practitioners should evaluate whether the control actually displaces risk or just relocates it into operations.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey.
• Systems with least-privileged AI access had a 17% incident rate versus 76% for over-privileged systems, according to The 2026 Infrastructure Identity Survey.
• OWASP NHI Top 10 is the right next read when you need to map temporary access patterns to agentic application risk.

What this signals

Identity blast radius: JIT controls are only as strong as the trust boundary behind them, which means identity programmes now need to measure who can issue, hold, or reconstruct secrets, not just how long those secrets last. With 67% of organisations still relying heavily on static credentials despite the risks they pose to agentic AI deployments, the transition away from standing privilege is already behind the operating model.

As AI and machine identities absorb more operational responsibility, JIT becomes one layer in a broader governance stack that also includes runtime authority, lifecycle offboarding, and policy enforcement after authentication. Teams that treat ephemeral credentials as the finish line will miss the bigger issue: whether access can still be constrained once execution begins.

For practitioners

• Audit where standing privilege still survives Map every human, workload, and service account that can persist beyond a task boundary, then prioritise the identities that can reach cloud, database, and CI/CD systems without re-authentication.
• Separate credential expiry from trust custody Require evidence of who can issue, hold, and potentially reconstruct protected secrets, and reject designs where the service provider retains cryptographic control over customer data.
• Standardise workload-first JIT issuance Use cloud IAM, Kubernetes identity, certificates, or enterprise identity providers as the front door, then issue only time-bound credentials after the workload is authenticated.
• Review post-issuance authority for machine identities Assess whether access controls still govern actions after a token is minted, especially in automation paths that can change infrastructure without human review.

Key takeaways

• JIT access reduces exposure only when it removes standing privilege and limits who can control the trust boundary behind the credential.
• The evidence is clear that over-privilege and static credentials continue to dominate AI and machine identity risk, so architectural control matters as much as expiry.
• Practitioners should evaluate JIT by secret custody, runtime authority, and workload-first authentication rather than by temporary access alone.

Key terms

• JIT — Just-in-Time Access: A security approach that grants access permissions only for the duration needed to complete a specific task, then automatically revokes them. JIT access eliminates standing privileges for NHIs, dramatically reducing attack surface.
• Zero-Knowledge Architecture: A design pattern in which the service provider cannot decrypt customer data because it never receives the keys needed to do so. The provider may store encrypted data and coordinate sync or processing, but it remains technically unable to read plaintext unless the architecture is broken.
• Dynamic Secret: A secret generated on-demand for a specific task and automatically revoked after use or expiry. Dynamic secrets dramatically reduce the risk of credential exposure compared to static, long-lived secrets and are considered best practice.
• Runtime authority: Runtime authority is the permission an AI system has while it is actively deciding and acting, not just when it is approved. In governance terms, it is the point where access, tool use, and action scope become operational, which is why build-time review alone cannot prove safety.

What's in the full article

Akeyless's full article covers the operational detail this post intentionally leaves for the source:

• The DFC cryptographic model and customer-controlled fragment design used to separate key custody from the SaaS layer.
• The platform-level handling of dynamic secrets across databases, Kubernetes, CI/CD, and cloud workloads.
• The article's explanation of how zero-knowledge is presented as an architectural property rather than a policy promise.
• The runtime authority discussion that extends beyond issuance into action governance after credentials are granted.

👉 The full Akeyless article covers the DFC architecture, customer-controlled key custody, and machine identity details.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.