Just-in-Time Access: Standing Privilege Is the Breach Path

What just-in-time access actually means

Most access in most companies is standing access. Someone needed a permission once, an admin granted it, and it stayed. Nobody scheduled its removal because removal was never part of the grant. Three years later that permission is still attached to the account, still valid, and still invisible until an auditor or an attacker finds it.

Just-in-time access inverts the default. Permission is granted for a stated reason, for a bounded window, and it is reclaimed when the window closes. Palo Alto Networks describes the end state, zero standing privileges, as "eliminating all permanent (standing) access rights for every identity, human or machine." JIT is the mechanism that gets you there: elevate for a task, for a set time, then drop back down.

The idea is not new. What changed is that the cost of standing access became measurable, and the number of identities holding it stopped being a human-scale number.

Standing access is where the breach actually happens

The 2026 Verizon Data Breach Investigations Report reports a genuine shift at the front door: 31% of breaches now start with software vulnerabilities, unseating stolen credentials as the top initial access vector for the first time. It would be easy to read that as good news for identity teams. It is not.

Credentials did not stop mattering. They moved. Counted across the whole breach, not just the first step, credential abuse still appears in 39% of breaches, and 73% of ransomware victims had an associated infostealer infection or credential leak in the year before the attack. The exploit gets the attacker in. The standing permissions attached to whatever identity they land on decide how far they get.

Unit 42 measured the same thing from the incident response side. Across more than 750 major incidents handled between October 2024 and September 2025, identity weaknesses played a material role in nearly 90% of investigations, and 65% of initial access was driven by identity-based techniques.

This is the honest case for JIT, and it is narrower than the marketing usually claims. Time-boxing access will not stop a phish and it will not patch a CVE. What it does is shrink the blast radius of every credential that eventually leaks, because most of the permissions an attacker would want to inherit no longer exist at the moment they arrive.

The identity count stopped being human-scale

There is a second reason this became urgent in 2026. The Cloud Security Alliance's whitepaper on non-human identity and agentic AI governance puts it plainly: service accounts, API keys, OAuth tokens, machine certificates, and the credentials wielded by AI agents "now outnumber human users by an average of 45 to 1, and in cloud-native environments the ratio can reach 144 to 1."

Other 2026 estimates run higher still. The spread between them is itself the finding. Nobody has a confident count, because most of these identities were created by whoever needed them, in whatever tool needed them, with no lifecycle attached. The same paper reports that 78% of organizations have no documented policy for creating or removing AI identities, and only 8% are highly confident their existing IAM can manage AI and non-human identity risk.

Manual review does not scale to that population. A quarterly campaign that works reasonably well for 400 employees does not work for 18,000 tokens, and it works even less well for an agent that was spun up on Tuesday for one workflow and never turned off. We wrote about the structural version of this problem in The AI Governance Gap and What Is the Access Layer for AI Agents?. The short version: if access has no expiry, something has to remove it, and at this scale that something cannot be a person.

Why JIT projects stall

Almost every security team agrees with the principle. Far fewer have it running. The failures are consistent, and they are not about buy-in.

How Lutril does it

In Lutril, JIT is configured per application on the Policies page. Each policy targets one audience, either Employees or AI agents, and can be scoped to a specific access level. A policy written for a specific level wins over the app default, so "Admin on Notion" and "Member on Notion" can behave completely differently.

Each audience gets three settings: what happens on request, the maximum duration, and optional conditions.

Duration is a ceiling, not a fixed value

The maximum duration is set in hours on the policy. The requester is asked "How long do you need access?" and picks from a ladder of 1 hour, 4 hours, 8 hours, 1 day, 3 days, or 7 days, filtered down to whatever the policy allows. The same prompt renders as a dropdown in Slack, a choice set in Teams, and a select in the Lutril app.

An approver can shorten a grant when they decide. They cannot lengthen one. The effective window is the smallest of the three numbers in play: the policy maximum, what the requester asked for, and what the approver granted. There is no path through the flow that produces access lasting longer than the policy allows.

The clock starts when the decision lands, not when the request was filed. If an approver takes six hours to respond, the requester still gets their full window.

Conditions decide who skips the queue

Approval fatigue is what kills JIT programmes, so the interesting question is not "who is allowed" but "who should not need a human." The conditions editor asks exactly that, in one sentence: Grant automatically when. You build a rule, then answer a second question about everyone who does not match: does an approver decide and it still expires, or does an approver decide and it never expires.

Attributes that resolve today include department, job title, manager, HR status, MFA state, internal versus external, IdP status, outstanding security trainings, whether the person already has access to the app, the application's sensitivity, and the request itself: duration asked for, access level, and stated reason.

Any attribute that depends on a source you have not connected yet is shown as unavailable, with the reason written next to it. You never build a rule on a signal that will not arrive, and you always know which connection would unlock it. That sounds like a small thing. It is the third failure mode above, closed.

Failures resolve toward approval, never toward silence

A policy engine that cannot resolve a fact has three options: allow, deny, or ask a human. Lutril always asks a human. An unmet or unverifiable condition degrades to "approval required," never to a silent grant and never to a silent refusal. A deny rule is evaluated before scope, so narrowing a policy can never accidentally loosen it.

When a decision is made, the terms of the policy are frozen onto the grant. Editing the policy tomorrow does not rewrite what was authorized today, which is what makes the record usable as audit evidence rather than a snapshot of current configuration.

Every expiry Lutril sets is one it can honour. Time-boxing is wired to a real removal path, whether Lutril manages the account through the application's own provisioning or through Google Workspace and Microsoft Entra groups. The deadline is not a reminder in someone's calendar. It is the removal.

What happens at the deadline

A background job checks for expiring and expired grants every few minutes. Three things can happen.

A warning goes out first. Lead time is proportional to the grant, roughly a quarter of the window, capped at 24 hours. A 7 day grant is flagged a day ahead. A 1 hour grant is not warned at all, because a warning on a 1 hour grant is just noise. The message arrives in Slack or Teams with buttons to extend or to let it lapse.

Extensions are bounded. A grant can be extended up to three times, and each extension is re-resolved against the live policy rather than the frozen snapshot. If you tightened the policy since the grant was issued, the extension respects the new limit. There is no fresh approval round, because the approver already authorized "up to the policy maximum," and every extension is logged.

Removal is deprovision-first. Access is removed at the source before the grant is marked expired. If removal fails, the grant stays live and the failure is logged for the next pass. A record that says "expired" while the permission is still attached is worse than no record.

The same engine, applied to AI agents

Agent policies use the same table, the same conditions, and the same duration logic. Four things differ, and all four exist because an agent is not a person.

• The subject is the human driving the agent. Department, HR status, and training conditions evaluate against that person, not against a service account with no attributes to evaluate.
• An agent can never exceed its owner's access. That check runs before the policy is consulted. If the owner does not have the integration, no policy can hand it to the agent.
• Read and write are separate policies. Scope is matched exactly, so a read policy never implies write. An agent that can search your CRM does not thereby get to modify it.
• Single-use grants exist. Some agents get permission for exactly one call, consumed on the first successful use, with a short safety expiry behind it in case the call never comes.

Enforcement happens at the tool call, through the MCP proxy the agent connects to. If you want the mechanics of that layer, we covered it in MCP Governance. The relevant point here is that time-boxing an agent is not a different product from time-boxing an employee. It is the same policy, with the subject swapped.

What to demand of any JIT implementation

Whether you build this or buy it, these are the properties that separate working JIT from an expiry column in a database.

JIT will not fix your offboarding on its own, and it does not replace access reviews or a real departure process. What it does is change the default. Access that nobody renewed stops existing, without anyone remembering to remove it. At 45 non-human identities per employee and climbing, that is the only version of least privilege that survives contact with the actual number of identities you have.