> ## Documentation Index
> Fetch the complete documentation index at: https://docs.bytebase.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Just-in-Time Access

Just-in-Time (JIT) access grants database access only when it's needed and only for a limited time, instead of leaving standing permissions in place. A member requests access, an approver reviews it, and the grant expires automatically — so unused privileges never accumulate, every grant is tied to a stated reason, and each use is recorded for audit.

Bytebase offers two ways to request access just-in-time, one per [permission model](/security/database-permission/overview/):

* **Request a role** — a time-boxed [role](/security/database-permission/request/) (e.g. `SQL Editor Read User`) for a broad range of permissions on the selected databases.
* **Request an access grant** — a limited, elevated privilege: run one approved read-only statement, optionally unmasked or exported. See [Access Grants](/security/database-permission/grant/).

<img src="https://mintcdn.com/dbx/h_wtkbPVmuS2QOfq/content/docs/security/database-permission/just-in-time/two-approaches.svg?fit=max&auto=format&n=h_wtkbPVmuS2QOfq&q=85&s=43097c6c2eb688df32d142b6f3a71633" alt="The two just-in-time approaches converge on expiring, audited access" width="1080" height="620" data-path="content/docs/security/database-permission/just-in-time/two-approaches.svg" />

Either way, the request goes through an [approval flow](/change-database/approval/) and is recorded in the [audit log](/security/audit-log/).

## Choose an approach

|                      | Time-boxed role                                                                                                      | Access grant                                                                                             |
| -------------------- | -------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- |
| **You get**          | a project role on the selected databases                                                                             | permission to run one approved read-only statement                                                       |
| **Granularity**      | the role's permissions, scoped to databases, schemas, and tables                                                     | a single statement, plus optional **Unmask** and **Export**                                              |
| **Duration presets** | 1 week – 1 year, capped by [maximum role expiration](/security/database-permission/request/#maximum-role-expiration) | 1 hour – 7 days, capped by [maximum request expiration](/security/database-permission/grant/#expiration) |
| **Project setting**  | **Allow request role**                                                                                               | **Just-In-Time access**                                                                                  |
| **Approval source**  | **Request Role**                                                                                                     | **Request Just-In-Time Access**                                                                          |
| **Best for**         | ongoing work that needs repeated access                                                                              | one-off production reads, incident lookups, ad-hoc exports                                               |

Each approach has its own project setting and approval source — the setting turns on role requests or access grants, not the workflow itself. Set them up where each mechanism is documented: [Enable role requests](/security/database-permission/request/#enable-role-requests) and [Enable access grants](/security/database-permission/grant/#enable-access-grants).

## Expiration and audit

Both approaches end the same way: the access expires on its own — a role binding at its expiration date, an access grant when its approved window (counted from approval) runs out — and the [audit log](/security/audit-log/) records every query and export along with the role or grant that authorized it.

For the full request flows, see [Roles](/security/database-permission/request/) and [Access Grants](/security/database-permission/grant/).