Manual JIT depends on human approval for each request, while dynamic JIT evaluates live context before granting access. Manual workflows are slow and easy to rubber-stamp, but dynamic JIT can use behaviour, location, and risk signals to decide whether access should be approved, escalated, or denied.
Why This Matters for Security Teams
Manual JIT and dynamic JIT both aim to remove standing access, but they solve different operational problems. Manual JIT is a human workflow: a request is reviewed, approved, and then access is granted for a limited time. Dynamic JIT is a runtime decision process: access is evaluated against live context such as device posture, location, time, behaviour, and task risk before anything is issued. For NHIs, that distinction matters because many identities are already over-privileged and poorly visible in practice, as highlighted in the Ultimate Guide to NHIs — What are Non-Human Identities.
From a control standpoint, manual JIT depends on people staying alert, consistent, and available. That creates queue delays and approval fatigue, especially where requests are repetitive. Dynamic JIT is closer to NIST Cybersecurity Framework 2.0 style risk management because it treats authorisation as an active decision, not a clerical step. Current guidance suggests this is more suitable for automated workloads and service identities that can change behaviour without notice. In practice, many security teams discover the weakness of manual approvals only after a privileged token was approved too easily or reused too long, rather than through any deliberate access design.
How It Works in Practice
Manual JIT usually starts with a ticket, chat approval, or manager sign-off. Once approved, PAM or an access broker issues a credential with a short time window. That can work for maintenance windows and emergency support, but it still assumes the requester can explain the need before access begins. Dynamic JIT changes the decision point to runtime. Instead of trusting a pre-approved request, the system evaluates the current context and issues a short-lived credential only if the request still matches policy.
For NHI and agentic workflows, that runtime decision should be paired with workload identity and ephemeral secrets. The agent proves what it is through cryptographic identity, then receives a task-scoped credential that expires quickly after use. This is where intent-based authorisation becomes useful: access is granted for a specific goal, not a broad role. That approach aligns well with the NIST view of continuous risk-informed governance and with the NHI lifecycle controls described in the Ultimate Guide to NHIs — What are Non-Human Identities.
- Manual JIT: human approval first, then time-bound access is issued.
- Dynamic JIT: policy evaluates live signals first, then access is issued, escalated, or denied.
- Best-fit signals include location, device health, workload identity, task sensitivity, and behaviour anomaly.
- Short-lived secrets reduce exposure if the task completes, fails, or is hijacked.
In environments that use NIST Cybersecurity Framework 2.0 as a baseline, dynamic JIT fits the broader move toward continuous verification and least privilege. These controls tend to break down when legacy systems require persistent service accounts because the workload cannot present strong identity and the platform cannot revoke access cleanly.
Common Variations and Edge Cases
Tighter JIT controls often increase operational overhead, requiring organisations to balance speed against assurance. Manual JIT is still practical for rare, high-risk administrative actions where a human should review intent, even if the workflow is slower. Dynamic JIT is better for high-frequency machine access, but current guidance suggests it is still an evolving pattern rather than a universal standard.
The main edge case is brownfield infrastructure. If a system cannot support workload identity, policy-as-code, or short TTL secrets, dynamic JIT may degrade into a disguised manual approval process. Another common exception is break-glass access, where emergency override is permitted but should be tightly logged and reviewed. For agentic systems, the need is even stronger because autonomous software can chain tools, change direction mid-task, and request new access paths without human prompting. That is why static RBAC and long-lived secrets are a poor fit for goal-driven agents, while dynamic, context-aware controls better reflect real execution risk.
There is no universal standard for this yet, but the direction of travel is clear: use manual JIT for exceptional human cases, and dynamic JIT for automated or agentic workloads that need ephemeral access aligned to task intent. Where teams still rely on broad roles and reusable credentials, NHI risk accumulates quickly even when the approval process looks controlled on paper.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | Agentic systems need runtime authorisation and short-lived credentials. | |
| CSA MAESTRO | MAESTRO addresses agent identity, tool access, and runtime control. | |
| NIST AI RMF | AIRMF supports governance for dynamic, risk-based AI authorisation. |
Use AIRMF governance to define accountability and runtime risk checks for JIT decisions.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on May 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
