Just-in-time access

Just-in-time (JIT) access lets a user ask for access to a resource only when they need it, have it granted for a bounded window, and have that access disappear on its own when the window ends. It is a TEAM-plus capability — available to teams rather than individual free-tier accounts — and it is the alternative to handing out permanent grants that pile up unseen.

The problem it solves

Permanent grants accumulate. Someone needs production access for one incident, gets it, and keeps it for a year. Multiply that across a team and your standing access no longer reflects who actually needs what — it reflects every past one-off, none of which anyone remembers to revoke. JIT inverts that: access is requested for a reason, granted for a duration, and gone afterward, so the access that exists is the access in active use.

The request and approval flow

1. Request. A user requests access to a resource — a vault, an SSH host, or a fleet command — stating the role they need, how long they need it, and a free-text reason.
2. Justify. The request can carry a written justification that restates the requested scope and summarizes the stated reason for the approver and the audit trail, flagging a reason that is vague or insufficient for the access asked for. When no model is reachable, a deterministic justification is used instead, so the record is always meaningful.
3. Review. Approvers — the team’s OWNER and ADMIN members — review the request and approve or deny it.
4. Grant. An approved grant is time-boxed: it carries an expiry, and once that expiry passes the grant reads as expired and confers no access — no separate revocation step or sweeper is needed.
5. Audit. The request, the decision, and the grant all land in the tamper-evident audit trail, so who asked for what, who approved it, and how long it lasted are all attributable.

What a grant can elevate to

JIT can only grant the non-privileged roles, VIEWER and EDITOR. It deliberately cannot grant ADMIN or OWNER, so an approved grant can never hand someone the manage_members power used to approve grants in the first place. The effective role for the duration of the grant is the higher-privilege of the user’s base role and the grant — JIT elevates, it never downgrades. See Roles and permissions for the role model.

The grant window is bounded on both ends: it cannot be shorter than a few minutes or longer than 24 hours, so even an approved request stays short-lived by construction.

Contrast with permanent grants

Permanent grant	Just-in-time grant
Granted once, lives until someone remembers to revoke it	Granted for a stated window, expires on its own
Reason is lost after the fact	Reason and justification recorded at request time
Accumulates as unseen standing access	Reflects access in active use

Where to go next

• See the roles a grant can confer in Roles and permissions.
• Learn how teams act as the approval unit in Teams overview.
• Request and broker access to many hosts at once with Fleet commands.