JIT Access

Just-In-Time (JIT) access replaces standing privileges with access that is granted only when it's needed and only for as long as it's needed. Instead of holding permanent root on a database host, a member requests access for a bounded window, states a reason, and an admin approves it. The grant opens on approval and closes itself automatically when the window ends.

This is the Zero-Trust way to handle privileged access: nothing is granted by default, every grant is justified and time-boxed, and there is no leftover standing access to remember to clean up.

JIT covers two resource types today:

• SSH devices — a request grants temporary SSH access, as a specific Unix login, to one device.
• Databases — a request grants temporary access to one registered database (no login to pick; database auth is carried through your own client). See Database Access.

Pick the resource type when you open a request. The model is built to extend to further resource types (networks, services) in the future.

Open it from the dashboard under JIT Access.

Where did SSH Elevation go?

The old SSH Elevation flow now lives here, under JIT Access — the same request/approve/expire lifecycle, generalized into a resource-typed model. The previous SSH → Elevation URL redirects to JIT Access, so existing links keep working.

Requesting access

Anyone in the workspace can open a request — including for a device they can't currently reach, since requesting is exactly how you obtain that access.

1. Go to JIT Access and click Request access.
2. Device — pick any organization device. Use the filter box to search by name, host, IP, or owner (for example db-prod).
3. Login — the Unix user the grant opens access as (for example postgres, deploy, or root). It must be a valid Unix login: lowercase letters, digits, dash, or underscore.
4. Duration — how long access stays open. Pick a preset from 30 min up to 8 hours. Access closes automatically when this window elapses.
5. Reason — required. A short note that's shown to the approver and recorded for audit, for example "Investigating elevated error rate on the API host."
6. Click Submit request. It enters the approval queue as pending.

After submitting, the JIT Access page shows two views of your own requests:

• Your active grants — live grants with a countdown to auto-close.
• My requests — the full history of everything you've opened, with its current status.

While a request is still pending, you can Cancel it yourself.

Approving requests

Approving is admin-only. Open JIT Access → Approvals for the org-wide queue. Filter by status:

Filter	Shows
Pending	Awaiting a decision (the default view)
Approved	Granted requests
Denied · expired	Rejected requests, plus revoked, cancelled, and timed-out ones
All	Every request

Each card carries who is asking, the login and device they want, the reason, when it was requested, and the requested window. Privileged logins such as root are highlighted so they stand out in the queue.

For a pending request you can:

• Approve — access goes live immediately for the requested duration.
• Deny — the request is rejected.

Self-approval is blocked

You cannot approve your own request. The Approve button is disabled on your own rows, and the server rejects a self-approval even if it's attempted directly. Privileged access always needs a second person.

Active grants, expiry, and revoke

Open JIT Access → Active grants for a board of every live grant across the workspace. Each card counts down to its automatic close and shows who holds it and when it was granted.

• Automatic expiry — when the window ends, the grant closes on its own. No new connection can be opened under it, and there is no standing access left behind.
• Revoke now — an admin can end a grant before it expires. Access closes immediately.

An SSH session that is already open when a grant reaches its expiry — or is revoked — winds down as its underlying short-lived credential lapses, rather than being granted indefinitely. The point of JIT is that access does not outlive the approved window.

Audit

Every step of the lifecycle is recorded in the activity log: the request, who approved or denied it, revocations, and automatic expiry — along with the actor, the target device, and the login involved. This gives you a complete, reviewable trail of who had privileged access, to what, when, and why.

Related

• SSH Access Rules — standing access for what several people need routinely; easier to audit than a stream of one-off approvals
• SSH Sessions — review live and recorded SSH sessions
• Sudo bridge — passwordless sudo for mesh-authenticated sessions
• Activity logging — where JIT request, approval, and expiry events are recorded
• Zero Trust — the model JIT access is built on