What breaks when teams use the same JIT model for all access?

Why This Matters for Security Teams

Using one JIT pattern for every access request sounds efficient, but it collapses two different risk models into one. Ordinary task access can usually rely on approval, short duration, and auto-revocation. Privileged access is different because the blast radius includes secrets, sessions, and downstream systems, so the control set must be stronger. NHI Management Group’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which is exactly why “temporary” alone is not enough.

This is where teams often misread least privilege. A JIT workflow for a human approving a ticket is not the same as a JIT grant for an API key, service account, or agent that can chain tools and move laterally. Current guidance from OWASP Non-Human Identity Top 10 and broader Zero Trust practice points toward context-aware, time-bounded access, but there is no universal standard that says one JIT template fits all workload types.

In practice, many security teams encounter over-privilege only after a short-lived grant has already been abused, rather than through intentional design of separate access paths.

How It Works in Practice

The practical fix is to treat “JIT” as a family of controls, not a single workflow. For standard operational access, JIT can mean approval plus short-lived entitlements. For privileged access, it should also include session containment, scoped secrets, and strong audit logs. For autonomous workloads, the better primitive is workload identity, not a human-style approval step. That means cryptographic identity for the workload, runtime policy evaluation, and credentials that expire automatically after the task completes.

Good implementations separate the access path by risk level:

• Low-risk task access: ticket-based approval, time-boxed RBAC, and automatic revocation.
• Privileged admin access: PAM, session recording, command restriction, and secret checkout with strict TTL.
• Agent or service access: workload identity such as SPIFFE or OIDC, plus policy-as-code evaluated at request time.

That distinction matters because JIT for an NHI is not just “grant then revoke.” It is also about where the secret lives, who can replay it, whether the session can be contained, and whether the action can be audited after the fact. NHI Mgmt Group’s Ultimate Guide to NHIs — Key Challenges and Risks highlights how secrets exposure and excessive privilege amplify each other, which is why runtime controls matter more than workflow convenience. Best practice is evolving toward context-aware authorization rather than static time windows. As a result, the access decision should reflect what the actor is trying to do, not just how long it has been active. These controls tend to break down in CI/CD-heavy environments because ephemeral pipelines often share credentials and reuse runners, making containment and attribution weak.

Common Variations and Edge Cases

Tighter JIT controls often increase operational overhead, requiring organisations to balance stronger containment against developer and operator friction. That tradeoff becomes obvious in environments with machine-to-machine traffic, legacy admin tools, and agentic AI systems that initiate multiple chained actions.

One common edge case is privileged automation. A backup job, deployment pipeline, and incident-response script may all be “temporary,” but they do not deserve the same policy. Current guidance suggests that privileged workflows should use shorter TTLs, stronger approval gates, and dedicated session controls, while routine service-to-service access should use workload identity and narrowly scoped tokens. Another edge case is AI agents: because they can adapt mid-task, a JIT grant based only on start time can be too broad by the end of the session.

This is also where visibility matters. The 52 NHI Breaches Analysis shows the pattern repeatedly: once secrets are shared across environments, the revocation story becomes weaker than the original approval story. For organisations using agentic workflows, OWASP Non-Human Identity Top 10 is a useful reference, but it should be paired with runtime policy and secret isolation rather than treated as a checklist for all access types.

The guidance breaks down when legacy systems cannot separate session control from authentication, because the same token is then being used for identity, authorization, and transport.

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 JIT access and Zero Trust for NHIs?
• What breaks when AI agents and humans share the same access model?
• How should security teams govern AI use when the same model creates different risk in different contexts?