Notifications
Clear all
Topic starter
19/08/2026 3:24 pm
TL;DR: Standing privileges remain a major attack surface, and Akeyless argues that JIT access must be evaluated as an architecture, not just a temporary credential pattern, because who controls the keys and trust boundary determines whether the model actually removes exposure. That distinction matters now that machine identities and autonomous workflows are increasing the blast radius of weak credential design.
NHIMG editorial — based on content published by Akeyless: Just-in-Time isn't just about temporary credentials
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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.
👉 Read Akeyless's analysis of just-in-time access, zero-knowledge, and runtime authority →
JIT access and standing privilege: is your trust model complete?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
19/08/2026 4:09 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Just-in-time access still depends on where trust sits
