Checking out a credential

If you have used a privileged access product before, you will be looking for a checkout: a button that takes an exclusive lock on a password, shows it to you, and hands it back when you are done. This article explains why the request-approve-session-terminate lifecycle below is still the pattern we want you to use for most work, and points you to the two newer, narrower actions that now exist alongside it.

What a checkout was invented to solve

The classic pattern comes from a world where the only way to use an administrator password was for a person to type it. Given that constraint, a vault can still improve matters considerably: it can insist you say why you want it, record that you took it, stop two people taking it at once, and change the password afterwards so the copy in your head stops working. That last step is called check-in, and it is where most of the value sits.

Every one of those improvements is a mitigation for the same underlying problem — that a human being now knows the password. Once a person has read it, no software controls what happens next. They can write it down. They can reuse it. They can still remember it in eighteen months when they work somewhere else. Check-in exists because the vault has lost control of the secret and rotation is the only way to take it back.

So the honest framing is this: a checkout is a well-designed workaround. Qorionix implements the thing the workaround was working around.

The lifecycle Qorionix has instead

Four steps, and the shape maps onto a checkout closely enough that the mental model transfers.

1. 1

   Request access, with a justification

   You ask for access to a specific credential and write down why. The justification is not a formality — it is the thing an approver reads, and it is what the audit record carries when someone asks in six months what that maintenance was for. Covered in Access requests and approvals.

2. 2

   An approver reviews it

   A named person approves or refuses. This is the step that has no equivalent in 'the password is in the shared notes' — and it is the step that most changes behaviour, because writing a reason that another human will read is a mild but effective brake.

3. 3

   Start a session

   The platform checks the approval, decrypts the secret, hands it to the session gateway, and the gateway injects it into a connection to the target. What you receive back is a listener endpoint — an address and port on the gateway that you point PuTTY, ssh or your RDP client at. Not the password.

4. 4

   Terminate the session

   This is the check-in equivalent. Terminating drops the live connection legs immediately, on both sides. There is no window in which the connection persists after you have finished with it.

The step that does the real work is the third one. Because the secret goes from the vault into the connection without passing through a person, there is nothing to check back in. Nobody memorised anything. The password after the session is the password before the session, and that is fine, because its confidentiality was never breached.

How the window is bounded

A checkout is time-boxed for a reason that has nothing to do with tidiness. Standing access is the default state of every badly managed privileged account in the world: somebody needed it once, it was granted, and nothing ever took it away. The count of people who can change your domain controller only ever goes up. Bounding the window inverts that — access expires unless renewed, so the count trends back towards zero on its own.

Qorionix bounds it in three ways, none of which is a lock on a password.

The approval is single-use

An approval records the session it was used to start. Once it has been used, it cannot be used again. This is the actual analogue of the checkout token: an approval granted for Tuesday's maintenance cannot quietly become standing access on Thursday, and reusing yesterday's approval is refused rather than tolerated.

Concurrency is capped, per credential

The access policy carries a max_concurrent_sessions value and it defaults to 1. So the effect an exclusive lock was reaching for is present, achieved by counting live sessions rather than by locking a row.

The session ends when it is terminated

And terminating is a first-class action rather than a cleanup job, because the connection legs are live TCP connections the gateway owns. Nothing is left half-open waiting for a timeout to notice.

The concurrency cap is the one you will meet first in practice. Attempting a second simultaneous session on a credential whose policy allows one returns HTTP 409 with:

If you see this and believe nothing else is running, the usual cause is a session that was closed at your end — the terminal window shut, the laptop slept — without being terminated in Qorionix. Terminate it explicitly and try again. If two of you legitimately need to work on the same machine at the same time, raise the limit on that credential's policy deliberately, rather than routing around it, so the decision is recorded where the next person will see it. See PAM access policies.

What is recorded, and what is not

The audit trail for privileged access is hash-chained: each record commits cryptographically to the one before it, so a record cannot be removed from the middle of the history without the chain failing to verify. That property is what makes the trail worth showing an auditor — a plain log table can be edited by anyone who can write to the database, and everybody in the room knows it.

Recorded, in the ordinary course of a session:

• The access request, with its justification, and who made it.
• The review — who approved or refused, and when.
• The session itself, and which approval it consumed.
• The termination.
• Every change to the target, as its own chained record: pam.target.create, pam.target.update, pam.target.delete, pam.target.test.
• The session content, for proxied sessions — the keystrokes and output for SSH, the screen for RDP, both searchable. See Session recording and transcripts.

Not recorded, anywhere, ever: the secret. It is not logged, not written into the audit row, and not returned in an API response. This is stated in the code as a contract on the session path — the plaintext is decrypted immediately before the connection is made and is never persisted by the component that handles it. A vault whose audit trail contains the passwords would have moved the problem rather than solved it.

When you genuinely need the password

There are real cases. The gateway is down. The network path between Qorionix and the target is broken. The machine is in a state where only the physical console will do. Refusing to have an answer for these would not be security; it would be a design that makes an outage worse.

For an outright platform outage, Break-glass access is deliberately separate from ordinary vault access: it is loud, it notifies, it is time-bounded, and using it is an event rather than a routine. For the narrower case where the platform is up but you genuinely need the plaintext itself — pasting it into a tool that cannot be proxied, or handing a one-off credential to a vendor — that is what Reveal is for. Neither is the vault's normal read path. The reason a normal read path does not exist is that a normal read path gets used normally, and within a month it is how everybody gets passwords and none of the rest of this article means anything.

One structural rule applies to all of it, and it does not have an exception for confidence or for autonomy tier: granting privileged access is never automated. Sentinel-Q can investigate a privileged session, correlate it with a sign-in from an unusual country, and tell you it looks wrong. It cannot approve an access request, because that capability is not exposed to the model at all. There is nothing there for a persuasive prompt to reach.

What to do next

1. Set up a proxied SSH session on one non-critical server and drive it end to end yourself before rolling it out to anyone else.
2. Read how approvals are structured, and decide who approves what.
3. Check the concurrency and duration limits on the credentials that matter most.
4. Know where the break-glass path is before you need it at two in the morning.