JIT Access (TTL & Scheduled Windows)

Just-in-time (JIT) access lets you grant a subject access to a resource for a fixed window of time — either starting immediately, or starting at a specific point in the future. When the window opens, access becomes active automatically. When it closes, the grant expires automatically. No manual activation or revocation needed.

JIT access is a direct policy grant with an optional start time and a time-to-live (TTL). It follows the same access paths as any other direct grant, with the addition that Vengtoo enforces both the start and the expiry at evaluation time.

When to use it

Scenario	JIT?
Contractor needs access for the duration of a project, starting now	Yes — TTL only
Contractor's access is approved today, but shouldn't begin until tomorrow at 2pm	Yes — starts_at + TTL
Car rental / equipment booking with a specific reserved window	Yes — starts_at + TTL
Emergency "break-glass" access for an on-call engineer	Yes — TTL only
Trial period for a new integration	Yes — TTL only
Permanent team member access	No — use a role instead
One-time human approval of a single request	No — use HITL

How it works

Create a direct policy assignment and set an expires_at timestamp. Optionally, also set a starts_at timestamp if access shouldn't begin immediately.

• If only expires_at is set, the grant is active from the moment it's created until it expires.
• If both starts_at and expires_at are set, the grant is inactive until starts_at, then active until expires_at.

At evaluation time:

• If the grant hasn't reached its starts_at yet, Vengtoo treats it as if the grant doesn't exist yet — decision: false.
• If the grant has passed its expires_at, Vengtoo treats it as if the grant no longer exists — decision: false.
• Between starts_at and expires_at (or from creation if no starts_at is set), the grant is active normally.

Both checks are evaluated independently and mirror each other: the start-time guard blocks the front of the window, the expiry guard blocks the back of it. Neither requires a background job — both are enforced live on every evaluation call.

The evaluation response

When a JIT grant is active and grants access, the response includes expires_in so the caller knows how long the grant remains valid:

{
  "decision": true,
  "context": {
    "reason": "Direct access granted — expires in 3540s",
    "access_path": "direct",
    "policy_id": "pol-789",
    "expires_in": 3540
  }
}

expires_in is in seconds from the time of the evaluation call. When it reaches zero, the next evaluation call will return decision: false.

If a grant exists but hasn't started yet, evaluation returns decision: false the same way an expired grant does — there's no separate "not yet active" reason code in the response today. If you need to surface when access will become available, read starts_at from the assignment directly.

Expiry and start-time behaviour

• Both the start and expiry checks are enforced at evaluation time — there is no background job that activates or revokes the grant.
• A grant that hasn't reached starts_at, or has passed expires_at, is automatically excluded from all evaluations.
• Grants outside their active window remain visible in the audit log and Decision Log for compliance purposes — scheduling a grant for the future, or letting one expire, is never silent.
• You can revoke a JIT grant early — before it starts or before it expires — by deleting the direct policy assignment.

Renewing access

JIT grants do not auto-renew. To extend access, create a new direct policy assignment with a new expires_at (and starts_at, if relevant). The old grant can be left to expire or deleted immediately.

Related

• Access Paths — how direct grants fit into evaluation.
• Delegation — an alternative when an agent needs to act on a user's behalf rather than holding the permission directly.
• HITL — when access requires per-request human approval rather than a pre-approved time window.