What breaks when just-in-time access is applied only to users and not permissions?

Why This Matters for Security Teams

Applying just-in-time access only to users creates a false sense of control because the identity is gated while the permission set remains permanently available. For non-human identities, that distinction matters. A service account, API key, or agent credential can still exercise dormant rights if those rights are left attached to the role. NHI risk is therefore not just about when access is granted, but whether the privilege exists at all.

This is why the problem shows up so often in breach analysis. NHIs frequently carry excessive privileges, and NHI Mgmt Group notes in the Ultimate Guide to NHIs that 97% of NHIs carry excessive privileges, widening the attack surface. When a credential is compromised, JIT on the login path does not stop the attacker from invoking unused rights already attached to the identity. The gap is especially visible in environments that rely on RBAC without continuous privilege trimming or task-scoped issuance.

Practitioners should read this as a ZSP problem, not a scheduling problem. JIT is only meaningful when privileges are absent until required, then removed immediately after use. Guidance from the OWASP Non-Human Identity Top 10 aligns with that view: standing privilege is the real risk, even if access requests are time-bound. In practice, many security teams encounter privilege misuse only after a service account or agent has already exercised rights that should never have been standing in the first place.

How It Works in Practice

Real JIT for NHI means the access decision and the privilege set are both ephemeral. Instead of granting a role that already contains broad permissions, the platform issues a narrow entitlement for a task, attaches a short TTL, and revokes it on completion. That can be implemented with PAM workflows, workload identity, policy-as-code, and secrets systems that mint credentials on demand rather than store long-lived values. For autonomous systems, that distinction is critical because the workload may chain tool calls, change behaviour mid-run, or request access in ways no static role model anticipated.

Current guidance suggests the control stack should include three layers: workload identity to prove what the agent or service is, runtime policy to decide whether the requested action is allowed, and ephemeral secrets to keep the credential lifetime short. This is where the issue goes beyond “access approved or denied.” A request can be approved for one operation and still fail safely if the underlying permission was never pre-positioned. That approach is consistent with the Ultimate Guide to NHIs — Key Challenges and Risks, which highlights over-privilege, weak visibility, and slow remediation as recurring NHI failure modes.

• Issue credentials per task, not per role duration.
• Bind access to workload identity and context, not just membership in a group.
• Use time-boxed permissions with automatic revocation after completion.
• Rotate or invalidate secrets when task scope changes or execution ends.

For implementation, teams often pair this with standards-oriented guidance such as the OWASP NHI material and runtime authorization models inspired by Zero Trust Architecture. Where possible, short-lived OIDC tokens or SPIFFE-based workload identities reduce the blast radius because the credential proves the workload is authenticated without leaving broad permissions in place. These controls tend to break down when legacy automation depends on shared service accounts with embedded standing rights because the task boundary is no longer enforceable at runtime.

Common Variations and Edge Cases

Tighter JIT controls often increase operational overhead, so organisations have to balance reduced exposure against deployment complexity and latency. That tradeoff is real, especially when the environment spans CI/CD pipelines, batch jobs, and third-party integrations. Best practice is evolving, but there is no universal standard for this yet: some teams can enforce task-scoped entitlements cleanly, while others must phase in JIT around the riskiest permissions first.

One common edge case is an automation path that starts as a user-facing workflow but ends as machine execution. In that pattern, access may be correctly gated for the human operator, yet the downstream service account still holds broad rights. Another is agentic AI, where an autonomous system may discover additional tools, branch into new actions, or request permissions outside the original design. In those environments, static RBAC alone is too coarse, and intent-based or context-aware authorization becomes more appropriate, although current guidance suggests this is still an emerging practice rather than a settled standard.

The practical lesson is to treat standing permission as the defect, not merely standing access. The 52 NHI Breaches Analysis shows how often compromised non-human identities become the entry point once privilege is already present. For teams comparing models, the OWASP guidance and the NHI Mgmt Group research both point in the same direction: JIT must constrain the privilege itself, or the control becomes cosmetic rather than protective.

Related resources from NHI Mgmt Group

• How should security teams decide whether JIT access is safe for non-human identities?
• What is the difference between zero trust for users and zero trust for NHIs?
• What is the difference between JIT access and Zero Trust for NHIs?
• What breaks when teams only manage agent permissions at approval time?