Just-in-time elevation

Just-in-time access means nobody holds administrative rights all the time. Instead of an account that is permanently privileged, a person asks for privilege when they need it, gets it for a bounded period, and loses it again. The security argument is simple: privilege that does not exist at the moment an attacker steals an account cannot be abused with that account.

Qorionix uses the phrase for two different mechanisms, and confusing them will lead you to plan around something that is not there. The time-boxed grant that gates a privileged session works and is what you should use. The cloud token minting engine is built and not connected to anything. This article covers both and is explicit about which is which.

The two things called JIT

What the working mechanism actually grants

A JIT access request does not create a temporary account, add anybody to a group, or hand out a temporary password. It creates a record that says: this person, for this credential, for this many minutes, approved by these people, may open one privileged session.

The grant is spent when the session starts. It is bound to the session it opened and cannot be used again — approve one request and you get one session, not a window in which sessions may be opened freely.

Four conditions are checked at the moment a session is requested, and all four must hold:

• The grant belongs to you, for this credential, in this organisation. All three are compared. This is what stops one person activating somebody else's approval.
• Its status is approved. A pending request, a denied one or a revoked one will not start a session.
• It has not already been used. Once a grant has activated a session it is finished.
• It has not lapsed. An expired grant is refused with approval record has expired.

How this differs from checking out a standing credential

The distinction matters because the credential itself is not just-in-time. It is a standing secret: it sits in the vault, it is the same secret between rotations, and the account it opens exists on the target the whole time.

What is just-in-time is the permission to use it, plus the fact that using it never reveals it. That is a smaller claim than a product that mints a fresh identity per session, and it is the honest one. Two things follow that are worth being clear about:

The account on the target keeps its privileges between sessions

If someone learns the vaulted password by another route — an old note, a configuration file, a backup — the account still works. The JIT grant does not constrain them, because it is enforced by Qorionix and not by the target. This is the reason credential rotation matters even when every session is brokered: rotation is what makes an old copy of the secret useless.

A grant is a permission, not a lease on the secret

There is no exclusive lock. Two people cannot hold the same credential in the sense of a classic checkout system. Concurrency is bounded by policy instead — the default allows one active session per credential at a time, and a second request is refused with maximum concurrent sessions reached for this credential.

Duration, and where the clock actually starts

The requested duration defaults to 60 minutes if you do not state one. The maximum is set by policy: any active policy governing the credential can cap it, and a request over the cap is refused with the numbers in the message.

403 Forbidden
{"error":"action violates privilege elevation policy: requested duration 240 min exceeds policy max 60 min"}

One defect in this area you should know about because it weakens a control you might be relying on. The policy cap is applied to the duration exactly as submitted, before the sixty-minute default is filled in. A request that simply omits the duration field is therefore checked against a value of zero, passes any cap, and then becomes sixty minutes. So a policy setting max_duration_min to 30 does not constrain a client that omits the field. Until this is fixed, do not treat a duration cap below 60 minutes as enforced.

And a second, larger gap: nothing ends a session when its grant expires. The expiry is checked when the session starts and never again. The only automatic bound on a running session is the gateway's maximum session duration, eight hours by default. A policy that says sixty minutes is refusing longer requests; it is not cutting sessions off at the hour. Terminating a session is a manual action, and it is worth making it a habit rather than an exception.

You will also not see a grant visibly change to an expired state. The state exists in the data model and no code writes it. A lapsed grant stays in whatever state it was in and is refused when used. Read the expiry timestamp rather than looking for a status change.

Approval is part of the grant, and it is never automated

Whether a grant needs approval at all is a policy decision, and the default for a newly created policy is that it does. The full workflow — who approves, what they must attest to, quorum, and the gaps in it that you should know about — is in Access requests and approvals. One structural rule is worth repeating here because it holds at every autonomy tier and is not a configuration option:

Granting privileged access is never automated. The capability is not exposed to Sentinel-Q at all. The tool registry refuses to hold a grant-class capability, so it is enforced by the type system and the boot sequence rather than by asking the model to behave. Sentinel-Q can read a pending request and give your approver a recommendation, and its response always carries the note that a human approver must action the request. It cannot approve anything, and no prompt can persuade it to.

What cloud elevation would do, and why we are describing it anyway

We are documenting an unreachable feature for one reason: the console names it, so you will ask. Here is what the code does, so that you can judge whether to wait for it.

It would mint a short-lived credential from a cloud provider and return it to the caller. Three providers are implemented, each in the provider's own idiom:

Two design consequences are worth noting even in its unbuilt state, because they would still be true on the day it ships. First, what comes back is a bearer token or a temporary key triple, and nothing else: no database grant, no group membership, no lease that Qorionix tracks. Second, there is no revoke path. The only thing that ends an elevation is the cloud provider's own expiry baked into the token. If you elevate somebody for an hour and then change your mind, you would have to go to the provider.

Also absent, in case you have read otherwise: Kubernetes is not implemented at all, and workload identity federation — the mechanism that would remove the need to hold a long-lived cloud key in the first place — is described in a design note and not built. There is no approval check, MFA check, policy check or audit entry in front of cloud elevation, for the simple reason that there is no caller to attach one to.

What to do about cloud privilege in the meantime

The goal behind cloud elevation is that nobody holds a standing cloud administrator key. Two things the product does today move you toward that, and neither requires the elevation engine.

1. Put the cloud keys you do have into the vault and rotate them. AWS access keys and Entra ID service principal secrets both have working rotation engines. A standing key that changes every thirty days is a much smaller problem than a standing key from 2021. See Credential rotation, and what it actually changes.
2. Use the cloud provider's own just-in-time features for human access. Entra ID Privileged Identity Management and AWS IAM Identity Center permission sets do the elevation part properly and are enforced by the provider rather than by us. There is no shame in the honest division of labour: use them for cloud role elevation, and use Qorionix for the servers, network devices and databases they do not cover.

The one thing not to do is to record in a policy document that Qorionix provides just-in-time cloud elevation. It does not yet, and an auditor who tests that statement will find the panel and the absence of any way to use it.

What to do next

1. Read the approval workflow in full — including the two gaps in it you should compensate for.
2. Set the policy that decides duration, approval and MFA.
3. Read how a session is opened once a grant exists.