Access Requests

Access requests provide time-limited database access with an approval workflow. Developers request access for a specific time window, admins approve or deny, and access automatically activates and expires on schedule. This separation of duties ensures that temporary access is always justified, reviewed, and auditable.

Overview

Permanent policy assignments give users ongoing access to databases. Access requests complement this by enabling time-limited access — a developer can request access to a production database for a two-hour maintenance window, and the access automatically expires when the window closes.

There are two types of access requests:

• Policy request — request assignment to an existing named policy for a time window. The policy's table grants and masking rules apply as-is.
• Ad-hoc request — specify exactly which tables, columns, and masking levels you need. An ephemeral policy is created on approval with just those grants.

Request Lifecycle

Every access request follows a defined state machine from submission to expiry:

The normal flow is: Pending → Approved → Active → Expired. If the start time is immediate, the request goes directly from Pending to Active on approval. An admin can deny a pending request or revoke an approved/active request at any time.

Requesting Access

Developers submit access requests through the console UI at My Access → New Request. The form above is a live preview of the actual request form with sample data.

Policy Requests

Choose an existing policy from the dropdown. You will receive the same table grants and masking rules defined in that policy for the duration of your time window. All policies on the target database are visible to all organization members.

Ad-hoc Requests

Specify exactly which tables you need access to, which operations (SELECT, INSERT, UPDATE, DELETE), and the masking level for each column. This is useful when no existing policy covers your exact needs, or when you need temporary unmasked access to normally-masked columns.

For each table, you can specify individual column masking levels:

Approving Requests

Organization admins review pending requests in the console at Requests. Any admin can approve or deny any request in the organization.

Admin Actions

Modifying on Approval

When approving, admins can narrow the scope of a request. For example, an admin might shorten the time window, remove tables from an ad-hoc request, or change column masking levels. Modifications are applied as part of the approval — there is no back-and-forth negotiation. The requester sees the approved request with a summary of what changed.

Separation of Duties

Admins cannot approve or deny their own access requests. If an admin needs temporary access, a different admin must review and approve the request. This prevents privilege escalation and ensures every access grant has independent oversight.

Automatic Lifecycle

Once approved, access requests activate and expire automatically — no manual intervention required.

Activation

A background scheduler checks every minute for approved requests whose start time has arrived. When activated, the system recomputes the user's effective policy on the target database and pushes the updated grants to the agent. If the user already has an active connection, the new grants take effect on their live session.

Expiry

The same scheduler detects active requests whose end time has passed and transitions them to expired. The system recomputes the effective policy without the expired grants, pushes the update to the agent, and if the user loses all access, their active connections are terminated.

Effective Policy Integration

A user's effective policy on a database is the union of their permanent policy assignments and any active approved requests. Both contribute table grants and masking rules, merged using the standard resolution algorithm (grant union, most-restrictive masking wins).

Revoking Access

Admins can revoke an approved or active request at any time. Revocation takes effect immediately:

1. The request status changes to revoked.
2. For ad-hoc requests, the ephemeral policy is removed.
3. The user's effective policy is recomputed without the revoked grants.
4. The updated policy is pushed to the agent in real time.
5. If the user loses all access, active database connections are terminated.

Admins can add an optional note when revoking to explain the reason (e.g. incident response, scope change, or user departure).

Ephemeral Policies

When an ad-hoc request is approved, the system creates an ephemeral policy containing exactly the grants specified in the request. This policy is automatically managed — you do not need to create or clean it up.

• Ephemeral policies are named automatically (e.g. "[Request] [email protected] - 2026-02-04 - a1b2c3d4").
• They appear in the policy list while active but are excluded after expiry or revocation.
• Expired ephemeral policies are retained for audit purposes.

Policy requests do not create ephemeral policies — they create a time-scoped assignment to the existing policy, which is removed on expiry.

Duration Limits

Requests are subject to duration and scheduling limits. These guardrails prevent excessively long or far-future requests. Requests that exceed them are rejected with a descriptive error message.

Audit Trail

Every access request is retained indefinitely for compliance and audit purposes. The full history of each request is recorded:

• Submission — who requested what, for which database, with what justification
• Decision — who approved or denied, any modifications made, decision notes
• Activation and expiry — timestamps of when access became active and when it ended
• Revocation — who revoked, when, and why

Database connections are linked to the access requests that enabled them. This lets you answer questions like "show all connections made under request #123" or "which emergency access requests were used in the last 30 days."