In many teams, privileged access is standing access: an engineer or an AI agent holds production permissions all day to use them for a few minutes. Just-in-time access flips that default, so a privilege exists only while the task that needs it runs.

What is just-in-time access?

Just-in-time access (JIT access) is an access model in which a user, service or AI agent receives a privilege only when a specific task requires it, for a limited time, and loses it automatically when that time ends. Applied to admin and production rights, it is called just-in-time privileged access, or JIT privileged access. Time-bound access, temporary elevated access and ephemeral access describe the same idea.

JIT access is least privilege applied over time. NIST defines least privilege as restricting access privileges to the minimum necessary to accomplish assigned tasks. Just-in-time access adds the clock: the minimum privilege, for the minimum duration, tied to a reason someone can read later.

The opposite is standing access: permissions assigned once and kept indefinitely, whether or not anyone uses them. Standing privileges are convenient, but each one is available at any hour to an attacker who steals the credential, to a script with a bug, and to an agent that misreads its instructions.

How does JIT access work?

Every just-in-time access management system runs the same loop, whatever the resource: a database, a server over SSH, a Kubernetes cluster, an MCP server or a cloud role.

  1. Request. A user or agent asks for a specific privilege on a specific resource, with a reason and a duration.
  2. Approve. A human approver or an automatic rule decides. Low-risk requests can be approved by rule; production writes usually need a person.
  3. Grant. The system creates the narrowest grant that covers the task: a temporary role, a short-lived credential, or a time-limited exception to a deny policy.
  4. Expire. When the window closes, or the single operation completes, the grant is removed without anyone having to remember.
  5. Audit. The request, the reason, the approver, the grant and the activity during the window are recorded together.

What goes into a JIT access request?

A useful JIT access request answers four questions: who is asking (a named identity, not a shared account), what they need (a resource and an action), why (a ticket, an incident or a short reason) and for how long. Approvers decide faster when the request reaches them in chat, with approve and deny buttons, than in a ticket queue.

Where is expiry enforced?

Here’s the catch: expiry is only as strong as the point that enforces it. If JIT works by adding a role or opening a firewall port, removing it later stops new connections but may leave an open one alone. Microsoft documents this for just-in-time VM access in Defender for Cloud: connections that are already established aren’t interrupted when the approved period expires (as of November 2026).

Enforcing JIT at a proxy that evaluates each request closes that gap: every query is checked against the grants valid at that moment, so an expired grant stops applying on the next request, even inside an open session.

What are zero standing privileges?

Zero standing privileges (ZSP) is the end state of just-in-time access: no identity holds sensitive privileges by default. People keep the everyday access their job needs, such as reading a staging database, and every privileged action (a production write, root on a server, an admin role) goes through a JIT request. Here is how just-in-time access control changes the picture compared with standing privileges:

  • Exposure window. A standing privilege is usable every hour the account exists; a JIT grant only during the approved window.
  • Stolen credentials. A leaked credential with standing rights works until someone rotates it. Without an active grant, it reaches nothing privileged.
  • Audit trail. Standing access leaves logs of what happened, not why the access existed. Every JIT window has a requester, a reason and an approver.
  • Access reviews. JIT grants expire on their own, so periodic reviews of who still needs what have far less to cover.

Zero standing privileges doesn’t mean zero access. Teams that remove every permission at once get flooded with requests, and approvers start approving without reading. Start with the privileges that do the most damage when misused, and move those behind JIT first.

What are the types of JIT access?

  • Time-bound access. The grant covers every matching action until it expires, for example write access to one database for two hours. Most JIT access is this type.
  • One-off access. The grant covers a single operation, such as one reviewed DELETE statement, and is used up by its first match.
  • Ephemeral credentials. A broker issues a credential valid for minutes or an hour, so the person or agent never holds a long-lived password.
  • Temporary elevation. The user joins a privileged role or group for the window, then leaves it, as is common in cloud and identity platforms.
  • Policy exceptions. A default-deny policy blocks the action, and an approved request creates a temporary exception to that policy for one identity.

These combine. A common pattern pairs ephemeral credentials for authentication with a time-bound exception for authorization, so both the credential and the permission expire.

What are examples of just-in-time access?

  • A production write for a migration. An engineer requests write access to the production database for two hours. A teammate approves in Slack, the block on production writes is lifted for that engineer only, and it returns on its own two hours later.
  • Break-glass during an incident. The on-call engineer needs root on a server at night. A single on-call lead approves, the access is time-limited, and the use is reviewed the next day.
  • Just-in-time admin access. An administrator activates an admin role for 30 minutes to change an identity provider setting, then drops back to a regular account.
  • An AI agent querying a database. A coding agent asks for read access for its current session to debug an issue, and the person who started it approves.

How does JIT access work for AI agents?

AI agents make standing access riskier: they run unattended, act fast and follow instructions that can come from untrusted content. A shared database password in an agent’s environment gives every session standing access, with no record of who asked for it.

Just-in-time access for AI agents follows the same loop with three extra rules:

  • The agent has its own identity. It authenticates with a short-lived token from its platform (OIDC, for example) that also names the human who started the session.
  • The agent can request but never approve. A human approves, usually the person who started the session, and the identity that creates the grant is separate from the agent’s, so the agent can’t grant itself access.
  • The scope comes from verified identity, not from the request text. The agent picks the reason and the duration, and the approver sees both. Which person and session the grant covers comes only from verified token claims, because the agent controls its own request payload.

The Devin integration is a worked example. Devin is blocked by default, requests access with a reason and a duration, and the person who started the session approves in Slack. The exception covers only that person’s Devin session and expires after the requested duration; a new session needs a new approval. The setup guide has the full policy and workflow.

How do you implement just-in-time privileged access?

These just-in-time privileged access best practices apply to any JIT access management tool:

  1. Map standing access first. List who holds production, admin and root rights, and how often each is used. Rarely used privileges move behind JIT most easily.
  2. Deny by default at the resource. Block the sensitive action and make each JIT grant an exception to that block, so a forgotten grant expires into a deny.
  3. Keep durations short and fixed. Offer a few choices, such as 30 minutes, 1 hour, 4 hours or 1 day. Longer windows need a stronger reason.
  4. Approve where people already work. A request that waits a day in a ticket queue pushes people back to shared credentials; a chat approval takes minutes.
  5. Scope each grant to one identity, one resource and, where possible, one kind of action or one session.
  6. Separate requester and approver. Nobody approves their own request, and no agent approves anything.
  7. Log the reason next to the activity, so an auditor sees the request, the approver and the queries run during the window in one place.
  8. Plan break-glass before you need it. Decide who grants emergency access when the usual approver is asleep, and review every use.

How does JIT access relate to PAM?

Just-in-time access is one capability of privileged access management (PAM). PAM covers the wider lifecycle of privileged access: brokering connections to sensitive systems, managing credentials, recording sessions and auditing activity. Just-in-time privileged access management is the part that decides when a privilege exists at all.

PIM (privileged identity management) is a close term. PIM tools usually work at the identity layer, deciding who holds which privileged role and for how long. PAM tools usually work at the access layer, brokering and recording sessions to databases and servers. Both can implement JIT.

How does Formal implement just-in-time access?

Formal implements JIT access as time-bound exceptions to policies. Policies are written in Rego and enforced by the Formal Connector, a reverse proxy in front of resources such as Postgres, Snowflake, SSH and Kubernetes, which evaluates session rules when a connection opens and request rules on each request.

A policy suspension exempts one user or group from one policy. It is one-off (the first matching request) or time-bound (every matching request until it expires), can be narrowed with a CEL condition such as one resource name, and stores a reason for the audit trail. Deleting it revokes access immediately, and Formal checks expiry on every policy evaluation.

Formal Workflows automate the request and approval. A workflow chains a trigger (an API call, or a form submitted in Slack or with formal form fill in the Endpoint) to actions: an approval message in Slack, a call that creates the suspension, and a message back. Workflows are written in YAML and managed in the Control Plane, with Terraform or through the API.

Employees can also request a one-time or time-bound exception (30 minutes to 7 days) from the employee Catalog when a policy blocks an action; an admin approves it in the Access Requests queue, which sends no notifications. For agents that sign in with OIDC, Formal issues federation tokens that last at most one hour and never outlive the upstream token.

At Cursor, the published outcome is no standing production access: engineers request just-in-time access for a specific operational need instead of holding permanent production permissions. JIT is part of Formal PAM, where the Connector also masks, blocks or allows every query inline and records every session.