Just-in-time access for humans and agents: what changes now

At a glance

What this is: This is a just-in-time access primer showing how time-bound, scope-bound permissions can reduce standing privilege across human, NHI, and agent use cases.

Why it matters: It matters because IAM, PAM, and lifecycle teams need controls that shrink privilege windows without slowing legitimate work across people, service accounts, and autonomous systems.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.

👉 Read Linx Security's just-in-time access primer for humans and agents

Context

Just-in-time access is a privilege model that grants access only for a defined task and then removes it automatically. For identity security teams, the real issue is not whether access can be elevated, but whether standing access has become the default across people, service accounts, and agents.

That governance gap matters because modern identity programmes now have to manage short-lived human elevation, machine credentials, and agent behaviour in one operating model. Once autonomous systems are in scope, privilege is no longer a static entitlement that can be reviewed on a predictable cadence; it becomes a runtime decision with a shrinking window for oversight.

Key questions

Q: How should security teams implement just-in-time access for high-risk admin roles?

A: Start with a small set of sensitive roles, define who can request them, and make expiry mandatory for every grant. Keep the approval path tied to the resource owner, not a central queue, and ensure the platform revokes sessions, tokens, and keys automatically when the task ends.

Q: Why do standing privileges create more risk than time-bound access in identity programmes?

A: Standing privileges create continuous exposure because the access exists even when nobody is actively using it. Time-bound access narrows the exposure window, limits the blast radius of misuse, and makes review easier because each grant has a purpose, a duration, and an owner.

Q: What breaks when agents inherit a human user's access rights?

A: The governance model breaks because the agent can act at machine speed with permissions that were never sized for its runtime behaviour. Human access assumptions do not hold when the identity can branch, retry, and complete tasks before a reviewer can intervene.

Q: Who should approve just-in-time access requests when both security and business owners are involved?

A: The resource owner should approve the operational need because they understand the task, while security should define the guardrails for higher risk or separation-of-duties cases. That split keeps approvals fast without losing control over sensitive changes.

Technical breakdown

How just-in-time access changes RBAC and ABAC

Just-in-time access adds duration and task scope to the basic role or policy decision. RBAC still defines the baseline entitlement, while ABAC narrows who qualifies under current conditions such as MFA, device posture, or location. JIT then issues a short-lived grant for a specific action and resource, rather than a permanent membership change. In practice, that means the policy engine decides eligibility, but the fulfilment layer must enforce expiry, revoke the session, and log the request, approval, and reason. Used correctly, the model keeps least privilege continuous instead of episodic.

Practical implication: separate eligibility from activation so every elevation has an expiry, an owner, and an audit trail.

Why agents complicate just-in-time access

Agents are not just automated users. The article treats them as identities that can interpret context, adapt, and pursue alternate paths until a task is complete. That changes the governance problem because the system may need to grant access at runtime, revoke it mid-flow, and prevent reuse of a human sponsor's standing permissions. If the agent inherits broad credentials, blast radius expands quickly because action speed and request volume are machine-scale. JIT for agents therefore has to bind credentials to task, time, and ownership, not to a static human approval chain.

Practical implication: issue agent-scoped credentials separately and forbid reuse of human standing rights.

What a scalable JIT architecture needs

A workable JIT programme needs four layers: visibility, policy and decision, intelligence, and fulfilment and audit. Visibility creates a catalog of identities, entitlements, owners, and targets across SaaS, cloud, and data platforms. Policy defines what can be requested and for how long, while intelligence adds context such as role fit, peer access, and violation history. Fulfilment must provision the smallest practical unit, such as ephemeral roles or short-lived tokens, and remove them on expiry. Without all four, JIT becomes a manual workflow instead of a control model.

Practical implication: build JIT as an end-to-end governance workflow, not as a request form bolted onto PAM.

Threat narrative

Attacker objective: The objective is to turn temporary operational need into persistent high-risk access that can be abused for broader system reach or data exposure.

1. Entry begins when standing access or inherited privilege already exists, giving the identity a durable starting point that does not need fresh approval for each task.
2. Escalation occurs when that access is reused beyond the immediate purpose, especially if groups linger or an agent inherits broader rights than the task requires.
3. Impact follows when excess privilege increases the blast radius, audit burden, and the chance that sensitive actions occur outside the intended control window.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Standing access is the real control failure, not just an inconvenience. JIT only matters because persistent privilege is still the default in many enterprises, and that default turns routine elevation into latent exposure. The article is right to frame standing access as background risk that grows quietly over time. The practitioner implication is simple: if you cannot inventory and constrain standing privilege, you cannot claim least privilege.

Identity blast radius: the decisive concept here is how much damage one grant can cause before it expires. JIT changes the unit of control from membership to session, which reduces the time available for misuse and the scope available for lateral movement. That is especially important when agents are involved, because machine speed compresses the review window further. The practitioner implication is to measure every elevation by how far it can spread, not just by who approved it.

Agent inheritance is a governance assumption that breaks under runtime automation. The idea that an agent can safely reuse a human sponsor's access was designed for human-paced escalation paths. That assumption fails when the actor can act continuously, branch to alternate actions, and complete work before a human review cycle closes. The implication is that access governance has to be rebuilt around actor-owned scopes, not delegated human privilege.

Visibility is the prerequisite control, and most programmes do not have it. JIT cannot govern what the organisation cannot see, especially when the identity estate includes people, service accounts, workload identities, and agents. The article's graph-based model is directionally correct because every approval decision depends on an accurate entitlement map. The practitioner implication is to treat identity inventory quality as a control objective, not a data hygiene task.

JIT for agents is a lifecycle problem as much as an access problem. The article correctly ties short-lived credentials to ownership, allowed tasks, and revocation on expiry. That aligns with OWASP NHI and Zero Trust thinking, where lifecycle and verification have to be continuous rather than episodic. The practitioner implication is to govern agent access as a bounded lifecycle with explicit offboarding, not as a one-time enablement event.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• For the broader control model behind those numbers, see 52 NHI Breaches Analysis, which shows how lifecycle gaps and standing privilege turn into repeatable incident patterns.

What this signals

Identity blast radius: JIT should be treated as a blast-radius control, not merely an approval workflow. When access lives only for the task window, the organisation reduces the chance that a routine elevation turns into a durable foothold, especially across cloud consoles and SaaS admin roles.

The programme signal to watch is not how many requests get approved, but how many grants are revoked automatically and how much standing privilege disappears over time. If those numbers do not move together, JIT is adding process without reducing exposure.

For teams building out machine and agent governance, the same model now needs to extend into short-lived credential issuance, owner-based approvals, and fast offboarding. The lifecycle lesson is consistent: access must die as deliberately as it is created.

For practitioners

• Inventory standing privilege by actor type Map human users, service accounts, workload identities, and agents separately, then identify which grants are persistent, which are task-based, and which are never used. Prioritise high-risk admin rights, cloud consoles, SaaS super-user roles, and CI/CD credentials.
• Set expiry as a mandatory control Require every elevated grant to carry an expiry, a task scope, and an owner. Use ephemeral roles, short-lived tokens, or policy attachments that revoke sessions automatically when the work ends.
• Bind agents to their own credentials Give agents separate service principals or machine identities instead of letting them inherit a human sponsor's standing access. Limit them to an allow list of tasks, and block any attempt to expand scope without explicit approval.
• Use approval context to reduce fatigue Surface role fit, peer usage, violation history, and task sensitivity to approvers so they can decide quickly without relying on manual investigation. Reserve security review for high-risk elevations or separation-of-duties conflicts.
• Measure revocation, not just request volume Track mean time to elevation, auto-revoke rates, median session length, and the percentage reduction in standing high-risk entitlements. Pair those metrics with periodic review results so you can prove the model is shrinking exposure.

Key takeaways

• Just-in-time access matters because standing privilege remains a structural source of exposure across human and non-human identities.
• The biggest governance shift is moving from permanent entitlements to task-scoped grants that expire automatically and leave a durable audit trail.
• For agentic systems, the control question is no longer who can ask for access, but whose access the agent is allowed to consume at runtime.

Key terms

• Just-in-Time Access: A privilege model that grants access only for a defined task and removes it automatically when that task ends. In practice, it turns elevation into a short-lived control with an owner, a scope, and a duration, instead of a permanent entitlement that must be remembered later.
• Standing Privilege: Access that remains active beyond the moment it is needed. Standing privilege is dangerous because it expands exposure between uses, makes misuse harder to spot, and creates account, role, or token state that continues to exist even when the operational need has already ended.
• Identity Blast Radius: The amount of damage an identity can cause before controls catch up or the access is removed. For humans, service accounts, and agents, blast radius depends on scope, duration, and the number of systems the identity can reach during its active window.
• Agent Registry: An inventory of autonomous or semi-autonomous actors that records owner, purpose, allowed tasks, baseline permissions, and activity. It is the minimum governance layer for agent identity because you cannot control what you cannot identify, scope, or audit consistently.

What's in the full article

Linx Security's full blog post covers the operational detail this post intentionally leaves for the source:

• Task-by-task rollout guidance for turning sensitive admin work into JIT-eligible requests
• The practical approval and escalation model for resource owners, security teams, and high-risk changes
• Implementation patterns for ephemeral roles, short-lived tokens, and automatic session revocation
• Agent guardrails including separate credentials, human initiation for scope changes, and kill-switch handling

👉 The full Linx Security post covers rollout, agent guardrails, and measurement 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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.